“Imagine you are trying to build a house, but you have bricks of varying sizes and materials to build the foundation– this is analogous to the situation that occurs when we don’t have common data elements.”  —  Julia Skapik of ONC at DoD/VA Town Hall Meeting, April 2016

In past posts, I’ve argued for the necessity of faster development of healthcare standards. Our current way of doing things doesn’t scale. We need a complete and highly-usable tool chain that provides a rapid way to capture clinical information requirements and produce implementable technologies, such as FHIR profiles.

Typically, when an HL7 work group considers a new use case, the first step is to create a domain analysis model (DAM). This is a relatively free-form exercise where modelers work with domain experts to create a conceptual information model. The HL7 Reference Information Model (RIM) is supposed to help shape these conceptual models, but more often than not, mapping to the RIM is an afterthought, not an organizing principle.

FHIR is beginning to provide a pathway from logical models to FHIR profiles, using the FHIR mapping language. The challenge is that many healthcare objects cluster around just a few resources, such as Observation and Condition. Many extensions will be created around these resources, and without an overall modeling framework, it will be very easy to proliferate duplicate definitions and structures. Clinical decision support won’t work very well if every new FHIR profile marches to a different drummer.

How do we hold things together? Julia Skapik (formerly of ONC and now Cognitive Medicine) said this: “In my mind, CDE/Ms (common data elements/models) are the “glue” that’s needed to take all the pieces of our fragmented system and transform them into a coherent continuum that supports both a patient-centered care team model and a learning health system (might make a nice slide).  Right now a significant proportion of our resources are devoted to low value activities like mapping, extracting data formatted for a single purpose, reviewing poorly usable data, and repeating both information gathering and actual care activities (evaluation, testing, even therapy) that aren’t improving health or providing new information. CDE/Ms could virtually eliminate many of these activities and allow clinicians to develop an intrinsic mental model of the information they encode and receive and the way the system interacts with that information.”

We’ve engineered the Standard Health Record exactly this way. Data elements can be defined and reused, combined into groups, and the groups into reusable data objects. In addition to providing maximum reuse, using consistent data element building blocks helps to achieve consistent data definitions, and makes it easier to map to FHIR, which produces a consistent and coherent set of FHIR profiles.

Another reason we went in this direction is that when clinicians talk about exchanging data, they invariably talk about data elements. There are vast libraries of data elements waiting to be tapped. The more directly we connect with these sources, the easier our domain modeling job will be.

Never define the same thing twice 

What are data elements? Wikipedia defines a data element as “an atomic unit of data that has precise meaning or precise semantics”. That’s a good place to start when the goal is semantic interoperability.  ISO 11179 specifies that data elements should have:

• A unique name within a defined scope,
• A clear definition,
• A defined data type that constrains its value, and
• A linkage to a formal taxonomy that allows the meaning of the data element to be related to the meaning of other data elements.

Postal code is a classic example of a data element. The data type is string, which could be selected from an enumeration of valid postal codes. Postal code can be linked to a definition in a formal taxonomy (e.g., Unified Medical Language System Metathesaurus (MTH) code C1514254).

Element: PostalCode
Concept: MTH#1514254
Description: "A sequence of letters and digits used as part of a postal 
address, often designating a geographic region."
Value:  string

Another example is anatomic directionality. The data type should be a coded text, selected from an enumeration (such as the CDISC SDTM Directionality Terminology).  The term can be linked to formal taxonomies (e.g. NCI Thesaurus code C99074).

Element: AnatomicDirectionality
Concept: NCI#C99074 
Description: "A term indicating a direction relative to an imaginary 
body plane." 
Value: CodeableConcept from AnatomicDirectionalityVS

The AnatomicDirectionalityVS (value set) will have codes representing concepts like lateral, medial, anterior, posterior, distal, proximal, dorsal, etc.

SHR builds off data elements that define different types of quantities, dates and times, identifiers, demographic elements, elements associated with  general concepts like medications, encounters, and conditions, as well as specific concepts associated with medical domains like oncology and social determinants of health.

How does this contrast with FHIR, or the models being created by the Clinical Information Modeling Initiative (CIMI)?

• In FHIR, there is a DataElement resource, but that resource describes a data element, rather than actually being a data element. The smallest re-usable structures are data types such as code, oid,  CodeableConcept, Address, and Signature. But FHIR data types are part of a closed system, meaning a data modeler or profiler cannot create new data types. The smallest user-definable unit of reuse are extensions, which are only valid in certain contexts, and are intentionally not applicable in the most common use cases (the 80% captured in “core” FHIR).  However, once defined, FHIR extensions are reusable, and in SHR-on-FHIR, we exploit this fact to implement reuse at the data element level.
• In CIMI, the smallest reusable unit is the CLUSTER, an “abstract class representing a reusable structure in a model such as an address or an entity such as a device.” A CLUSTER is much like a FHIR complex data type, essentially a mini-class with attributes. While reuse of complex data structures is useful, there is no equivalent in CIMI to a reusable “atomic” data element.

In FHIR and CIMI, therefore, atomic concepts like “length”, “description”, “reason”, and “effective time” must be defined over and over. In practice, those basic definitions turn out to be not always consistent. Building on SHR and automatically translating to FHIR, the data element orientation of SHR can be realized in FHIR. With SHR moving toward alignment with CIMI, we hope to realize the best characteristics of each model.

Next time, I’ll discuss how to transform typical Object-Attribute-Value models like FHIR or CIMI to data element-oriented models, and how to use composition of data elements to express complex healthcare objects. It’s nothing particularly original, but it is pretty fundamental to the SHR.