Processes

 ACTION (Jan 16, 2017 HL7 meeting Q2): CIC asked CIMI to refine and enhance its processes 

CIC asked CIMI to refine and enhance its processes for:

• clear description of process, benefits, flexibility
  • simplify to get clinicians engaged.
• Anxiety disorder project
  • CIIC meeting in Jul
    • meet stakeholders' needs,
  • education on CIMI,

CIMI Software Development Process “on FHIR”

The Figure shows potential Use-Case processes and products; where,

1. Path 1 7  8 represents the ideal case; where, reusable FHIR-based components are available.
2. Path 1  2  3  4  7  8 is when new requirements are met locally; but, HL7 Items A-C are not updated.
3. Path 1  2  3  4  5 6  7  8 is when new requirements are met locally; and, HL7 Items A-C are updated.
4. Step 9 is periodically done to configuration manage, version control, publish and standardize HL7 Items A-C.

Our objectives are

1. CLIM and FHIR artifacts are tool based and feely available .
2. To produce quality documentation and training videos to enable:
   1. 1, 2, 3, 4 done by Clinical Business-Analysts
   2. 2, 3 and 4 governance done by the organizations doing the work
   3. 5, 6 and 9 governance done by the appropriate HL7 workgroups
   4. 7 and 8 done by Software Developers

At the January HL7 Workgroup meeting CIC requested further clarification / detail of Figure 1 to indicate where and how clinicians can efficiently participate in the process.

'As an example', when Michael van der Zel does Business Analysis / FHIR Development, he generally follows these steps:

• Understand and document the business process (aka Use-Case) (Figure 1, process 1)
  • Detail the process into steps
    • EHRS-FM might help determine functional requirements and their conformance criteria
  • Determine the needed information for each of the process steps (inputs and outputs)
    • EHRS-FM can help because it has a mapping to FHIM and FHIM has a mapping to FHIR
    • FHIM might also be used directly
  • Find existing models and terminology (DCM, FHIR, etc., (Figure, Items A. and C.)
• Create / adjust / profile DCM or terminology, if needed (Figure, processes 2 & 3)
• Find mapped FHIR resources or map / create / profile FHIR Resources from DCM logical models identified in previous steps. (Figure, process 4)

1. Use existing FHIR implementation to realize the system (deploy the profiles) (Figure 1, process 7 and Item C)
   1. Do Connecthatons (Figure, process 8)

Michael believes the process analysis step is very important and should be made explicit; where, CIMI’s CLIM is about logical models that are transformed (using predefined mappings) to implementation models (FHIR profile Resources). For the transformation of CLIM, we will explore the use of the SIGG and FHIR tooling. So, we intend to express CLIM as FHIR Logical Models AKA FHIR Logical Structure Definitions), using SIGG tooling, and then use FHIR mapping to generate FHIR resource profiles, analogous to what ClinFhir (David Hay) is doing. For testing software, Michael thinks the Connectathons are very important.

Following the Figure, a software (SW) project will follow some combination of these use case steps:

1. Do Business and FHIR Analysis to determine system requirement-specifications and conformance criteria (Figure 1, process 1); where, EHRS-FM might be used; because, it is traceable to CLIM (FHIM) and CLIM will be traceable to FHIR.
   1. Note that the HL7 Service Aware Interoperability Framework (SAIF) Enterprise Compliance and Conformance Framework (ECCF) can be used to maintain a project’s requirements-specifications, design and test artifacts.
2. Maintain the FHIM, CIMI, CQF, etc. models (Figure 1, process 2) to meet the requirements; where, these models may be updated and bound to SOLOR . This work can be done with an UML tool or the OpenEHR ADL workbench.
3. Maintain SOLOR (SNOMED with extensions for LOINC and RxNorm shown as Figure 1, process 3). If appropriate SOLOR concepts which do not exist, can be added using the IHTSDO workbench with ISAAC plugin. Processes 2 and 3 are closely related and may iterate back and forth or may be done simultaneously.
4. Use SIGG (MDHT, MDMI) to generate the needed implementation artifacts (e.g., FHIR structure definitions for profiles or extensions, CDA or NIEM IEPD specifications can also be done).
5. Governance involves change control, configuration management and version control; where, CLIM governance is generally federated. That is, local development organizations govern their own artifacts and may wish to provide versions to HL7. Appropriate HL7 workgroups govern HL7 artifacts and ballots.
6. Similarly, FHIR governance is generally federated; where, local development organizations govern their own artifacts and may wish to provide versions to HL7. At HL7, FHIR-compliant reusable-artifacts are governed by the FHIR workgroup.
7. Develop software components are generally done by commercial, government and academic organizations and their contractors. HL7 provides artifacts, documentation and training to empower these efforts.
8. Test and use software components is generally done by commercial, government and academic organizations and their contractors.
9. Periodically, CIMI and FHIM artifacts are balloted as HL7 and/or ISO standard, which include the set of clinical domain information models (e.g., FHIM covers 30+ domains), CIMI DCMs with SOLAR derived terminology value-sets. Having standard requirements-specification conformance criteria traceable to FHIR implementation artifacts can maximize efficiency and effectivity of multi-enterprise clinical-interoperability. These tool-based standardized clinical interoperability artifacts can be augmented with business, service and resource requirements-specifications conformance-criteria models and implementation artifacts. HL7 and its workgroups have identified best-practice principles and tools supporting its clinical-artifacts, which can provide standardized approaches for government, industry and academic organizations to adopt, train and use. These standard use-cases, conformance criteria models and implementation artifacts can be used and maintained within an HL7 Service Aware Interoperability Framework (SAIF) and Enterprise Compliance and Conformance Framework (SAIF) to support specific business use-cases, process models, acquisitions and/or developments.