The Terminology Modeling architecture is designed to support implementers with multiple target
implementation specifications – FHIR, CDA, HL7 V2, and NIEM.
The first layer of support is the FHIM data types. The coded types use a UML profile that supports a variety of metadata elements. All target properties can be supported by FHIM types. Note that certain properties have not been implemented, e.g., the FHIR “user-selected” flag. The second layer is bindings – specifications of allowed values for coded elements. As you browse the FHIM, you will see links to bound value sets; clicking on the links will retrieve the permitted values.
These bindings support multiple implementations, and they are classified by the technical use case: e.g., do I want to implement FHIR or CDA? In the FHIM immunization diagram, you can see both the FHIR and C-CDA bindings for Allergy criticality. These links also support research for harmonization – the effort to bring diverse specifications into alignment.
Note that the FHIM has evolved over time. Early in the FHIM program, effort was made to define new value sets that harmonized the diverse requirements of the respective specification families. Some of these value sets have been published in VSAC; some remain in draft state and can only be reviewed in the working spreadsheets. Later, it became clear that this authoring work was not the best use of resources, and most effort since then has focused on ensuring that extant specifications are identified correctly. Harmonization decisions may be made more effectively using this resource, but the program determined not to make these decisions prospectively. One tactic in the early phase was to support both V2 value sets, which often contain negative and null values (“none,” “not applicable”) with their V3 counterparts, which defer those values to “null flavor” model properties. We did this by creating sets of “proper” values, sets of null values, and composite sets containing both kinds of values. A specification can use either the proper values only, if it manages nulls in some other way, or all values, if it does not.
Engagement with the HL7 Clinical Information Model Initiative (CIMI) prompted the team to address the question of “model binding” – the practice of defining not only semantic codes for data element contents, but also semantic codes for the elements themselves. This approach allows a client application to understand that the “left arm” concept relates to the “injection” action as a “body site” where the injection occurred, without having to know the database column definitions of the server application. Since this practice is uncommon, the only manifestation of this idea in the FHIM is in the “topic code” concept of the clinical statement class in the CIMI-inspired Detailed Clinical Model package.
