BusinessWorkflow was introduced to provide Workflow with an upper model that could be used to describe traversals of the Generic Longitudinal Business Process Model (GLBPM) and/or the Generic Statistical Business Process Model (GSBPM) either in a one off study or in a wave that is part of a StudySeries.

Steps and sub-steps from these and other models are BusinessProcesses in the BusinessWorkflow. A traversal corresponds to a DataPipeline that strings together the BusinessProcesses.

Each BusinessProcess can be decomposed into a series of steps through the optional use of its WorkflowStepSequence from the Workflows package.

The currency that is exchanged across BusinessProcesses are records, not variables and their values. Preconditions are one or more LogicalRecords. So are postconditions.

Namespace URI:
Color of objects in the uml graph: 
Recall that a LogicalRecord can define the structure of an electronic health record (EHR) like those that health providers build using the HL7 FHIR (Fast Healthcare Interoperability Resources) specification. FHIR is an information model in which "resources" host resources and variables to form trees. In our example we define a cohort (population) of men and women suffering from two specific comorbidities. Next we specify extractions that would retrieve demographic and income information for this cohort from one or more registries. Next we define a merge of registry data from the different sources. Then we define a merge that merges the product of this merge with the cohort's EHR data. Next we define a star schema with one or more fact tables. One fact table might be hospital stays. We now define a transformation that would move all of our person level data into the star schema. Finally, we specify one or more data cubes based on the star schema that allows us to consider how hospital stays vary in several dimensions. In the end we can look back (data lineage) and for each data cube specify a flow that begins with one or more data sources and proceeds through data management.
Explanatory Notes: 
The BusinessWorkFlow was developed in large part based on a single use case. This is the ETL (Extract, Transform and Load). Today ETL platforms may perform data management apart from the production of a data warehouse. Indeed with advances in computing, data warehouses have become less physical and more logical. Source data stays in place and ETL functions and products live in memory. Eventually products like data cubes may be "materialized". In this context metadata (data definitions, transformation definitions) is pivotal while "materializations" are not because the same definitions can be run and run again. Advances in computing make materializations more disposable. This use case where "virtualization" is in play creates special challenges for the description of the BusinessWorkflow. Sometimes when the data products that go between the BusinessProcesses in a BusinessWorkflow are not materialized, they become hard to describe.
Include in build?: 

Package Graph