CIMI Demonstration Project: Skin and Wound Domain
Fall 2018 HL7 Ballot Cycle
For-Comment Ballot sponsored by the Patient Care (PC) Work Group and co-sponsored by the Clinical Information Modeling Initiative (CIMI) Work Group
This is for-comment ballot on a demonstration project of the CIMI program.
The CIMI effort is focused on creating logical models of healthcare information, independent of implementation technologies and patterns. It aims to decouple the logical information content from the periodic changes we experience in technology. When a new technical platform is introduced, the technology can be adopted without needing to re-define the clinical information. Furthermore, regardless of implementation technology, all implementations following the same CIMI logical models will express the same information.
Readers unfamiliar with CIMI are referred to the CIMI Architecture, Methodology, and Style Guide for more information.
The demonstration project is designed to be a test case for how different groups, with different tools, approach CIMI modeling. The Skin and Wound assessment domain was selected because it provides a variety of modeling challenges, including broad coverage of data types, various entity relationships, and different use cases for capture, review, and reporting.
Each group is using the same Excel spreadsheet describing the Skin and Wound domain. The spreadsheet covers the various observations that can be made about a wound, for example, its location, size, color, odor, and many others. It includes LOINC codes for observations and panels, and answer sets (either LOINC or SNOMED CT) or units for quantitative observations. Some of the observations are nested; for example, a patient can have more than one wound, each wound can have more than one tunnel, and each tunnel on each wound on each patient can be measured.
Note that some groups were unable to complete the skin & wound domain; these have included their work on the quantitative lab domain instead.
One major goal of the demonstration project is to validate CIMI modeling patterns. CIMI has established an object-oriented class hierarchy that defines a rich set of base (parent) classes. Domain-specific models are created by applying up to four different modeling processes:
1. Selecting a CIMI-defined base class or base archetype (required);
2. Optionally, extending the base class (adding new attributes);
3. Optionally, constraining the derived child class or archetype (by restricting cardinality, applying fixed values to attributes, binding properties to value sets, or constraining the type of attributes),
4. If required, combining several classes through composition to form the desired domain model (for example, choosing the correct StatementTopic and StatementContext classes to form the desired type of clinical statement).
One of the primary questions of this demonstration project is whether different domain modelers can reliability and repeatably apply the four modeling processes to arrive at the same results. (For the demonstration project, all contributors are experts on CIMI, but to scale, modelers cannot be assumed to be CIMI experts.)
A second important question is whether the base classes, as currently defined by CIMI, are adequate to capture the Skin and Wound domain content.
FHIR is a major implementation target for CIMI models. The demonstration project would like to compare different approaches to mapping from CIMI to FHIR profiles.
CIMI recognizes that modelers have tooling preferences, and it is probably not feasible to expect all modelers to use the same tools to implement CIMI models. A second major goal is to see how different tools function in the creation of CIMI models.
Regardless of the tools, each group was asked to provide:
1. A CIMI logical model of the Skin and Wound domain, expressed in the Archetype Description Language (ADL) and Basic Metamodel (BMM) formalism.
2. Optionally, FHIR profiles corresponding to the CIMI logical model, and a description of the mapping logic and approach.
3. Optionally, a FHIR Implementation Guide (IG).
4. Optionally, additional information such descriptions of how the requirements were formally captured and transformed into outputs, class diagrams, lessons learned, etc.
The ballot package contains five output packages:
This package was created starting with Federal Health Information Model (FHIM), expressed in UML, exporting from FHIM to MITRE’s Clinical Information Modeling and Profiling Language (CIMPL), and then using the MITRE toolchain to produce ADL/BMM, FHIR profiles, FHIR Logical Models using StructureDefinition, and a FHIR IG. The package includes:
1. FHIM UML analysis model
2. Generated Model and Constraints (BMM and ADL), with browser
3. Generated FHIR implementation guide, including Logical Models, Generated FHIR Profiles, Generated FHIR Extensions, Value Sets, Code Sets, and Implementable FHIR artifacts (in JSON, XML, Turtle)
This package was created starting with an implementation of CIMI base classes in CIMPL, and then using the MITRE toolchain to produce remaining artifacts. This package includes:
1. CIMPL source code
2. Generated Model and Constraints (BMM and ADL), with browser
3. Generated FHIR implementation guide, including Logical Models, Generated FHIR Profiles, Generated FHIR Extensions, Value Sets, Code Sets, and Implementable FHIR artifacts (in JSON, XML, Turtle)
This package was produced from a highly simplified set of base classes. It is offered as an alternative that avoids some complexities inherent in CIMI. This package includes:
1. CIMPL source code
2. Generated Model and Constraints (BMM and ADL), with browser
3. Generated FHIR implementation guide, including Logical Models, Generated FHIR Profiles, Generated FHIR Extensions, Value Sets, Code Sets, and Implementable FHIR artifacts (in JSON, XML, Turtle)
This package was produced using a UML modeling tool (Magic Draw), exporting to BMM format, translating to ADL format, and then editing the ADL to produce the Skin and Wound artifacts. This package includes:
1. Magic Draw source code
2. BMM and ADL files
This package was created starting with Intermountain’s Clinical Element Modeling Language (CEML) and transforming into ADL. This package includes:
1. CEML Models source code
2. Generated BMM and ADL
We wish to answer the following questions:
1. Do the analysis models accurately reflect the requirements for the domain?
2. Do the generated BMM & ADL accurately reflect the requirements for the domain?
3. Do the FHIR profiles accurately reflect the requirements for the domain?
4. For any identified issues, where do they first occur?
5. Are the models and modeling process easy to understand and reproduce?
We expect the results to influence further refinement of the BMM/ADL formalism, both to support the generation of FHIR implementation artifacts and to support practical approaches for capturing and expressing requirements. We also emphasize that the focus on FHIR is circumstantial, and we invite comments on possible issues or opportunities for supporting other formalisms (V2, CDA, X12, NCPDP, NIEM, etc.).