|
|
| Line 1: |
Line 1: |
| | | | |
| − | = Executive Summary =
| |
| − | This newsletter is intended to keep HL7 Clinical Information Models and Tools (IIM&T) Project’s co-sponsors, stakeholders and proponents informed and engaged regarding status, issues and plans--in general and in support of the Jan 2017 HL7 meeting. Formulated by SMEs and endorsed by a solid base of stakeholders, this newsletter supports communications which is one of the three tenets of this project. The other two, namely, the integration work itself, supplemented by governance will capitalize on near term efforts to progress the project’s accomplishments and challenges, and will be showcased here. While injection of resources are certainly needed and more stakeholders who will push for this work, we will make the most of here-and-now efforts and meetings to demonstrate the merits of the integration of information models, enabled by tooling in order to bolster implementation assets such as but not limited to FHIR. Contributions are in turn acknowledged as offered by the FHA, DoD/VA IPO, ONC, VA and DoD, Intermountain Healthcare Systems and The Open Group. We know this area is complex, and is not well understood and offer this insight to assist. We believe there are too many efforts trying to build the ultimate skyscraper, starting however on the third floor, without a sufficient foundation. To better our current delivery systems and position us for the ultimate Learning Health System where the data demands and stakeholders are greater, this effort offers what is regarded as the missing link; the foundation to semantic interoperability. Your feedback and suggestions in this quest to communicate the evolution of this work are welcome.
| |
| − |
| |
| − | In addition to our featured article on integration accomplishments other insights include:
| |
| − | # The Data Access Framework (DAF) Core has been renamed US Core.
| |
| − | # The CIMI workgroup conducted an HL7 comments only ballot overviewing its Core Reference Model, Reference Architypes and Patterns approach. Ballot content was due to HL7 by December 3; so, results were available for the HL7 January 12-20, 2017 San Antonio, Texas Workgroup meeting.
| |
| − | ## As a part of this ballot the Patient Care Workgroup Skin / Wound Assessment pilot project’s DCMs are converted into FHIR profiles and extensions.
| |
| − | • Excluded from this ballot are FHIM domain models, CIMI Detailed Clinical Models (DCMs), and CQI/CDS Knowledge Artifacts (KNARTs).
| |
| − | The FHIM, CQI/CDS and CIMI teams are refactoring the FHIM Domain Class Models and CIMI Basic Meta Model (BMM) with the new Clinical Statement Reference Architypes and Patterns, derived from the Skin / Wound Assessment Pilot Project, as shown in Figure 2 and Figure 3.
| |
| − | ## FINDING’s ASSESSMENT and EVALUATION_RESULT are included in the Jan Ballot.
| |
| − | ## PROCEDURE and CONTEXT decompositions are planned for the May Ballot.
| |
| − | # CQI’s and CDS’s workgroups 2017 plans include completing CQL 1.2, the FHIR Clinical Reasoning Module (formerly CQF-on-FHIR IG) and the QI Core FHIR Profiles. QI Core is being updated to be derive from FHIR US Core (formerly DAF Core), and several production projects are in progress or planned for 2017.
| |
| − | # Concurrently, the IIM&T project is developing both A CLIM (SOLOR, FHIM, DCM, CQF, FHIR) 1) Practitioner Users Guide for Clinicians, Analysts and Implementers and a 2) Style Guide describing the high-level patterns, models and terminology bindings for Informaticists and developers.
| |
| − | # The SOLOR Team is refocusing and will report their status and plans later.
| |
| − |
| |
| − |
| |
| − |
| |
| − | = Featured Article: IIM&T Accomplishments =
| |
| − |
| |
| − | HL7 Project “Integration of Information Models and Tools (IIM&T)” is a work in progress. Since September 2016 the CIMI sponsored HL7 IIM&T Project Scope Statement was vetted by the co-sponsoring workgroups and Subject Matter Experts (SME) and is ready for the HL7 Steering Division (SD), FHIR Management Group (FMG) Technical Steering Committee (TSC) review during the January 2017 HL7 Workgroup Meeting in San Antonio and approval shortly after the meeting. An IPO DoD VA Joint Exploratory Team (JET) proposal was submitted to fund two years of pilot studies to verify and validate the IIM&T approach; where, funding results should be announced in February.
| |
| − |
| |
| − | The CIMI Working Group is currently defining an HL7 Common Logical Information Model (CLIM) which aims to unify and in some cases, integrate several existing models including the FHIM, CIMI DCMs, CQI QUICK and QI Core, US Core FHIR Profiles, FHIM, vMR, and QDM data models within an HL7 Service Aware Interoperability Framework (SAIF). This logical model shall also formally align with the SNOMED CT Concept Model and other standard terminologies that comprise SOLOR.
| |
| − |
| |
| − | In preparation for the January 2017 HL7 Comment Ballot, Galen Mulrooney, Claude Nanjo, Richard Esmond, Susan Matney and Jay Lyle focused the group’s initial efforts on:
| |
| − | # Identifying the technologies used to represent this model and defining proper guidelines for their use. In particular,
| |
| − | ## The CIMI Working Group identified UML Architype Modelling Language (AML) profile as the preferred modeling framework for the CIMI Reference Model and top level archetypes and then use of OpenEHR ADL technologies for the definition of downstream archetypes including detailed clinical models (DCMs). Note that AML models can be converted into their Basic Meta Model (BMM) and Archetype Description Language (ADL) representations, both are OpenEHR specifications.
| |
| − | ## The CIMI Working Group has agreed to model CIMI patterns using the OpenEHR BMM Specification and all constraints on these patterns using OpenEHR ADL Specification. The team has agreed to not allow the definition of new classes and attributes at the archetype (e.g., DCM) level.
| |
| − | # Achieving consensus on a common foundational model aligned with ISO13606 and OpenEHR serving as a starting point for both CIMI clinical models and CQF knowledge artifacts.
| |
| − | # Defining the proper alignment of the CLIM with the SNOMED CT Concept Model so that terminology alignment is not an afterthought but is done as part of the foundational development of the model.
| |
| − | # Defining the foundational FHIM and CIMI Clinical Statement Pattern to enhance the models’ alignment with the SNOMED CT SITUATION with Explicit CONTEXT concept model and allow for a consistent approach for the expression of ‘negation’; where, the CLIM must support the expression of presence and absence of clinical FINDINGs or the performance and non-performance of clinical ACTIONs and the expression of proposals, plans, and orders.
| |
| − | # Surfacing existing CIMI archetypes as formal UML models for community review and building on that work using existing models as a starting point in a joint development effort; where, the CIMI team introduced three new core models: the CLIM ASSERTION, EVALUATION_RESULT (AKA OBSERVATION or RESULT), and PROCEDURE Patterns.
| |
| − | # Exploring the generation of consistent and traceable FHIR profiles from CLIM artifacts, first manually and then using SIGG (MDHT, MDMI) and FHIR tools.
| |
| − |
| |
| − |
| |
| − | Historically, CIMI has focused on laboratory result OBSERVATIONs. The CIMI Working Group is currently working on further fleshing out the CLIM to include many of the core classes, which make up the FHIM, vMR, OpenEHR, and QDM models such as PROCEDUREs, medication-related classes, and ENCOUNTERs. In this ballot cycle, the CIMI Working Group also explored the structural relationship between physical EVALUATION_RESULT s and clinical ASSERTIONs using the Wound Assessment pilot study as a concrete use case; where, the pilot focused on the clinical-statement ASSERTION and EVALUATION_RESULT patterns as shown in Figure 3. For the May 2017 ballot cycle, we plan to expand this use case to include PROCEDURE and CONTEXT.
| |
| − |
| |
| − | == HL7 Patient Care Workgroup’s Wound Care Pilot Project Status ==
| |
| − |
| |
| − | Additional Details: http://wiki.hl7.org/index.php?title=PC_CIMI_Proof_of_Concept
| |
| − |
| |
| − |
| |
| − | [[file: PractitionersGuide_Architecture_ClinicalPerspective.jpg|none|700px|Clinical Perspective]]
| |
| − |
| |
| − |
| |
| − | '''Figure: Clinical Perspective of CLIM Reference Architypes, Patterns, DCMs And HeD KNARTs Based on SNOMED Observable Model'''
| |
| − |
| |
| − | Historically. CIMI focused on lab-result OBSERVATIONs; where, the Patient Care WG’s CIMI validation wound/Skin Assessment pilot study added clinical-statement FINDINGs, ASSERTIONs and EVALUATIONs (AKA OBSERVATIONs or RESULTs) as shown in Figure 3. The ‘2016Q4 EVALUATION_RESULT = the pre-2016 OBSERVATION in “Lab OBSERVATION”. Briefly, models based on CIMI, FHIM, QI Core, and US Core specifications, and using SOLOR terminologies require ambiguities to be resolved / harmonized. Galen, Claude, Richard, Susan and Jay are working on the harmonization represented in Figure 2 . The HL7 Patient Care Workgroup Wound Assessment Pilot Project is providing the reference use-case and information model for this pilot study. Claude and Galen have defined candidate clinical FINDING, ASSERTION and EVALUATION_RESULT Reference Architypes and Patterns, as shown in Figure 3 and the teams are working through concept inconsistencies. As an example, another inconsistency is the “SIGNATURE” concept which in FHIM is simply ATTRIBUTION (set of persons signing or cosigning a clinical statement), while in CIMI “SIGNATURE” is an ACT (EVENT) with full SNOMED CONTEXT (who, what, when, where, how, etc.); where, FHIM is migrating to the CIMI approach. Susan argues that Family Hx. and Patient Obx. Are ASSERTIONS; but, Stan points out that ASSERTION and EVALUATION_RESULT are structures, without implying semantics, and that any ASSERTION can be represented as a EVALUATION_RESULT (e.g., LOINC question and SNOMED reply pair).
| |
| − |
| |
| − | Lively January HL7 workgroup meeting discussions on Reference Architypes, Patterns, DCMs and KNARTs, and FHIR implementation models and tools, resulted in the Figure's FINDING (AKA OBSERVABLE) having both ASSERTION and EVALUATION_RESULT patterns; where, discussions are summarized in the Attachment. Note that both patterns have semantically equivalent structural patterns and are not arbitrary classifications (e.g., objective vs. subjective); where, the EVALUATION_RESULT pattern is generally a “LOINC-question and SNOMED-answer pair” (AKA FINDING, OBSERVATION); and, the ASSERTION pattern (AKA CONDITION, PROBLEM, DIAGNOSIS) implies the definition of a SNOMED concept (e.g., The patient has diabetes or skin ulcers; where, diabetes or skin ulcer are defined by one or more clinical evaluations).
| |
| − |
| |
| − | == Informatics Perspective ==
| |
| − |
| |
| − |
| |
| − | The Clinical Logical Information Model ('''CLIM''') consists of the three Basic Meta Model ('''BMM''') reference model layers and two archetype layers shown here.
| |
| − |
| |
| − | [[file: CIMI_Telecom_Figure_2017-01-26-04.jpg|none|900px|CIMI BMM 5 Layers]]
| |
| − |
| |
| − | The CIMI Reference Model is expressed using the OpenEHR Basic Metamodel (BMM) Language. The archetype layers are expressed using the OpenEHR Archetype Definition Language (ADL). While reference model modules define classes, attributes, and class hierarchies, the archetype layers only specify progressive constraints on the reference model but do not introduce new classes, attributes, and class-class relationships.
| |
| − |
| |
| − | # The CIMI '''Core Reference Model''' provides the core granularity of the CIMI model and introduces its top-level classes such as the DATA_VALUE class and the LOCATABLE class. This reference layer module defines the CIMI primitive types and core data types.
| |
| − | # The CIMI '''Foundational Reference Model''' is closely aligned to ISO13606 and the OpenEHR Core Reference Model. It defines foundational CIMI clinical documents and clinical record patterns. It also introduces the PARTY, ROLE, and PARTY_RELATIONSHIP patterns and defines the top-level CLUSTER class for complex CIMI type hierarchies. CQI Knowledge Artifacts may also leverage this layer.
| |
| − | # The CIMI '''Clinical Reference Model''' consists of the classes derived from existing CIMI archetypes, the FHIM, QUICK, vMR, and QDM. This layer defines the set of 'schematic anchors' (to borrow Richard Esmond's term) or core reference model patterns from which all CIMI archetype hierarchies and ultimately Detailed Clinical Models (DCMs) derive. Requirements for this layer come from FHIM, vMR, QDM, QUICK, FHIR US Core, SDC, etc...
| |
| − | ## The 'goal' is to define the reference models with low FHIR transformation costs where feasible noting that we will inherently have some divergence due to the different requirements underlying both models.
| |
| − | ## Galen points out that, FHIM’s expressivity will not carry over to CIMI DCMs given the models' different requirements (e.g., FHIM includes finance and accounting).
| |
| − | # The CIMI '''Foundational Archetypes''' define the top-level constraints on the CIMI Reference Model. These typically consist of attribute formal documentation and high level attribute semantic and value set bindings. Archetypes at this layer will provide the foundational requirements for future US Core and QI Core profiles. Future pilots will explore the generation of US Core and QI Core archetypes from these CIMI archetypes.
| |
| − | # The CIMI '''Detailed Clinical Model Layer''' represents the set of leaf-level constraining profiles on the foundational archetypes to create families of archetypes that only vary in their finest terminology bindings and cardinality constraints. This layer is intended to support clinical interoperability through an unambiguous specification of model constraints for information exchange, information retrieval, and data processing.
| |
| − |
| |
| − | From layers 1-5, we define the set of transformations (e.g., SIGG (MDHT, MDMI)) to generate the corresponding FHIR profiles including the US Core and QI Core profile sets. Note that FHIR profiles can be generated from the various levels of the archetype hierarchy depending on requirements. The lower down in the hierarchy, the more prescriptive the profile is in terms of constraints. Much like ADL Archetypes, FHIR profiles can be layered.
| |
| − |
| |
| − | It is important to note that some FHIR profiles may be derived from the Foundational Archetype Layer (e.g., US Core, some QI Core profiles, some CQIF profiles on PlanDefinition, Questionnaire and ActivityDefinition, etc...) and others from the DCM Layer (e.g., bilirubin, HgA1c, etc...). In other words, the arrow for FHIR Profiles stems out of the outer box rather than the last of the inner boxes (the DCM box).
| |
| − |
| |
| − | == Process Prospective ==
| |
| − |
| |
| − | '''CIMI Software Development Process “on FHIR”'''
| |
| − |
| |
| − | [[file: PractitionersGuide_Processes_00.jpg|none|700px|CIMI Processes]]
| |
| − |
| |
| − | The Figure shows potential Use-Case processes and products; where,
| |
| − | # Path 1 7 8 represents the ideal case; where, reusable FHIR-based components are available.
| |
| − | # Path 1 2 3 4 7 8 is when new requirements are met locally; but, HL7 Items A-C are not updated.
| |
| − | # Path 1 2 3 4 5 6 7 8 is when new requirements are met locally; and, HL7 Items A-C are updated.
| |
| − | # Step 9 is periodically done to configuration manage, version control, publish and standardize HL7 Items A-C.
| |
| − |
| |
| − | Our '''objectives''' are
| |
| − | # CLIM and FHIR artifacts are tool based and feely available .
| |
| − | # To produce quality documentation and training videos to enable:
| |
| − | ## 1, 2, 3, 4 done by Clinical Business-Analysts
| |
| − | ## 2, 3 and 4 governance done by the organizations doing the work
| |
| − | ## 5, 6 and 9 governance done by the appropriate HL7 workgroups
| |
| − | ## 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)
| |
| − | # Use existing FHIR implementation to realize the system (deploy the profiles) (Figure 1, process 7 and Item C)
| |
| − | ## 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:
| |
| − | # 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.
| |
| − | ## 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.
| |
| − | # 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.
| |
| − | # 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.
| |
| − | # 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).
| |
| − | # 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.
| |
| − | # 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.
| |
| − | # 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.
| |
| − | # Test and use software components is generally done by commercial, government and academic organizations and their contractors.
| |
| − | # 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.
| |
| − |
| |
| − |
| |
| − |
| |
| − | = FHIR Clinical Reasoning =
| |
| − | In the September 2016 ballot cycle, CQF balloted the FHIR-Based Clinical Quality Framework (CQF-on-FHIR) IG as an STU (Standard for Trial Use). This guidance was used to support the CQF-on-FHIR and Payer Extract tracks in the September 2016 FHIR connect-a-thon. The guidance in the FHIR STU was prepared as a Universal Realm Specification with support from the Clinical Quality Framework (CQF) initiative, which is a public-private partnership sponsored by the Centers for Medicare & Medicaid Services (CMS) and the U.S. Office of the National Coordinator for Health Information Technology (ONC) to identify, develop, harmonize, and validate standards for clinical decision support and electronic clinical quality measurement.
| |
| − |
| |
| − |
| |
| − | Part of the reconciliation for the CQF-on-FHIR IG September ballot involved incorporating the contents of the IG as a new module in FHIR, the FHIR Clinical Reasoning module.
| |
| − | The Clinical Reasoning module provides resources and operations to enable the representation, distribution, and EVALUATION_RESULT of clinical knowledge artifacts such as clinical decision support rules, quality measures, order sets, and protocols. In addition, the module describes how expression languages can be used throughout the specification to provide dynamic capabilities.
| |
| − | Clinical Reasoning involves the ability to represent and encode clinical knowledge in a very broad sense so that it can be integrated into clinical systems. This encoding may be as simple as controlling whether a section of an order set appears based on the specific conditions that are present for the patient in content in a CPOE system, or it may be as complex as representing the care pathway for patients with multiple conditions.
| |
| − | The Clinical Reasoning module focuses on enabling two primary use cases:
| |
| − | * Sharing - The ability to represent clinical knowledge artifacts such as decision support rules, order sets, protocols, and quality measures, and to do so in a way that enables those artifacts to be shared across organizations and institutions.
| |
| − | * EVALUATION_RESULT - The ability to evaluate clinical knowledge artifacts in the context of a specific patient or population, including the ability to request decision support guidance, impact clinical workflow, and retrospectively assess quality metrics.
| |
| − |
| |
| − |
| |
| − | To enable these use cases, the module defines several components that can each be used independently, or combined to enable more complex functionality. These components are:
| |
| − | * Expression Logic represents complex logic using languages such as FHIRPath and Clinical Quality Language (CQL).
| |
| − | * Definitional Resources describe definitional resources, or template resources that are not defined on any specific patient, but are used to define the actions to be performed as part of a clinical knowledge artifact such as an order set or decision support rule.
| |
| − | * Knowledge Artifacts represent clinical knowledge artifacts such as decision support rules and clinical quality measures.
| |
| − |
| |
| − |
| |
| − | For 2017, the Clinical Quality Framework initiative will continue to develop the FHIR Clinical Reasoning module and related standards. Specifically, the reconciled changes to the CQF-IG will be applied to the FHIR Clinical Reasoning module and published as part of FHIR STU3 in March 2017. The QI Core profiles will be updated to derive directly from US Core, and the QUICK tooling will be updated to provide conceptual documentation, as well as logical models suitable for use in authoring and evaluating CDS and CQI knowledge artifacts. The CQF initiative is actively working with multiple groups to continue to refine and implement the resources and guidance provided by the FHIR Clinical Reasoning module, including the National Comprehensive Cancer Network, the Centers for Disease Control and Prevention, and the National Committee for Quality Assurance.
| |
| − |
| |
| − |
| |
| − |
| |
| − | = SIGG (MDHT, MDMI) Tools Approach Status and Plans =
| |
| − | While the overall development plan for SIGG (MDHT, MDMI) has not changed, the timeline and/or path must shift in 2017. FHA will need to cease developmental funding of SIGG this month (January) due to other emergent priorities and the SIGG team is wrapping up final development activity and the documentation component in preparation for disengagement. If the JIF proposal is accepted or the IPO can provide for further development under the FPG JET moving forward, then the SIGG is prepared to continue SIGG development unabated.
| |
| − |
| |
| − | Currently the SIGG and the components of the SIGG are being used, and extended, in the following projects:
| |
| − | # FHIR Proving Ground IPO Jet – MDMI Models are being developed for DoD DES native format and the VA eHMP native format to provide data in conjunction with existing MDMI Models for FHIR Profiles. The use case is a complete round-trip starting with a FHIR query from a FHIR Server, accessing a native server with its native access language, and returning the result to the FHIR service as a FHIR payload. This project has extended the use of SIGG to include not only payload Semantic Interoperability but also a prototype for query Semantic Interoperability. Additionally, there was an alternative approach to the SIGG that was evaluated in this process, and the SIGG was selected as the superior solution.
| |
| − | # SAMHSA / AHIMA Case Definition Templates – The SIGG tooling, also branded as the SAMHSA Semantic Interoperability Workbench, is being extended to let Subject Matter Experts define and build special purpose templates for clinical pathways. The resulting templates are called Case Definition Templates. In the selection of the appropriate tooling for the project, 11 other products were evaluated.
| |
| − | # HL7 Structured Documents CDA on FHIR Working Group – The SIGG is being used by the working group to replace manually developed spreadsheets using automatically generate spreadsheets from the CCDA and FHIR MDMI Models. This will support the iterative development process of the Working Group as well as providing more detailed and precise information for the community.
| |
| − | # VA VLER – The use of the SIGG is being investigated by VA Subject Matter Experts to replace a process that uses manually development spreadsheets for mappings between VLER and CCDA data formats.
| |
| − | # HL7 FHIR RDF Working Group – Current members of the SIGG team and the HL7 FHIR RDF team are exploring how components of the SIGG and the SHEX / RDF technology can be coupled together to provide even broader capabilities.
| |
| − |
| |
| − |
| |
| − | = Commentaries =
| |
| − |
| |
| − |
| |
| − |
| |
| − | = Notes =
| |
| − |
| |
| − |
| |
| − | = Reference Information Links =
| |
| − | *2016-06 Preliminary Report https://1drv.ms/w/s!AlkpZJej6nh_k9YPmsR8Hl6zTlQ0NQ
| |
| − | *2016-08 Tech. Forum Notes https://1drv.ms/w/s!AlkpZJej6nh_k9gyRVADgOvM5SlJkQ
| |
| − | * 2016-09 Final Report https://1drv.ms/w/s!AlkpZJej6nh_k9dQ2qQnRuQM8gbu8A
| |
| − | * 2016-11 IIM&T Status Brief https://1drv.ms/p/s!AlkpZJej6nh_k90kDv1RNHeSvZ2gjw
| |
| − | * Briefing Slides https://1drv.ms/p/s!AlkpZJej6nh_k9dE-b_DAO8HSNNT6Q
| |
| − | * CIMI Practitioners’ Guide https://1drv.ms/w/s!AlkpZJej6nh_k6ZUeG7W6TaWcbTZ4Q
| |
| − | * CIMI Web Site http://www.opencimi.org
| |
| − | * CIMI Wiki http://wiki.hl7.org/index.php?title=Clinical_Information_Modeling_Initiative_Work_Group
| |
| − | * US CORE Wiki https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/DAF+Home
| |
| − | * HL7 Project Scope Statement https://1drv.ms/w/s!AlkpZJej6nh_k9dYlvNWaZ3DLPKSYg
| |
| − | * Newsletters https://1drv.ms/f/s!AlkpZJej6nh_k-RIHMWezhAd7fONHg
| |
| − | * PC-CIMI Proof of Concept http://wiki.hl7.org/index.php?title=PC_CIMI_Proof_of_Concept
| |
| − | * Work Breakdown MPP https://1drv.ms/u/s!AlkpZJej6nh_k9dK5WOB8zkkUuaKgA
| |
| − | * SNOMEDCT: https://confluence.ihtsdotools.org/display/DOCECL/Expression+Constraint+Language+-+Specification+and+Guide
| |
| − | * and http://ihtsdo.org/index.html ?
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | = Attachment =
| |
