Light My FHIR

I can’t count the number of gripe sessions on how a certain FHIR resource does this, while other does that, or how one resource calls something foo, and another calls the exact same thing bar, etc. I guess that’s because I hang out with modelers, a bunch of Felix Ungars with an obsession to make everything as neat-and-tidy as Marie Kondo’s closet. If that’s a character flaw, I’ll embrace it. I like information models to be consistent, because in real life, it’s much easier to work with predictable patterns.

Chris Moesel, my esteemed MITRE colleague, produced for me a list of every FHIR resource and its attributes in R4, STU3 and DSTU2. Here’s a tiny sample:

It was quick work to produce a couple of informative pivot tables that give a unique perspective on FHIR. The caveat on this analysis is that it is only able to look superficially at how things are named, not at the underlying semantics. Also, I’m looking primarily at horizontal consistency across resources, which is NOT a stated goal of FHIR.

You can download the dataset here. 

A few immediate observations (R4 unless noted):

• FHIR has grown. DSTU2 had 95 resources with 3454 attributes, STU3 had 118 resources with 5155 attributes and R4 has 148 resources and 7004 attributes.
• FHIR has an extremely long tail. More than 90% of attributes in FHIR are completely unique. Less than 1% of attributes recur in more than 10 resources.
• Many resources might missing important attributes. 30 resources don’t have an identifier attribute, only 101 of 148 have status, and only 23 have author. I’m not claiming this is right or wrong, but it does make you wonder…is it possible or appropriate that 125 resources don’t have an author?
• Some attributes are used consistently, but others aren’t. Almost every time an identifier attribute is used, the cardinality is 0..* and the data type is Identifier. Great! But other attributes, like author and performer, are implemented inconsistently. Again, I’m not saying if this is right or wrong, but I have to wonder why purpose is consistently markdown, while comment is mostly string, and description is a bit of both worlds.
• Some resources are enormous. 10 resources have over 100 attributes, and 45 have more than 50 attributes. The champion is ExplanationOfBenefits, weighing in at 255 attributes. I find that bitterly ironic — it’s supposed to be an explanation of benefits, i.e., something a consumer can understand. 

I also looked at the top 50 commonly-occurring attributes in terms of the consistency of data types and cardinality. The full table is in the spreadsheet. Here’s a sample:

The Bottom Line

I encourage you to download and play with the data yourself and reach your own conclusions. I have done a very shallow analysis. 

From my perspective, FHIR’s extremely long tail emphasizes the degree to which each resource is a domain unto itself. The consequence is that, for the most part, implementers cannot leverage code written for one resource on another resource. There are potentially useful abstractions that could be created around FHIR. FHIR patterns is an attempt in this direction; so is this model. Claude Nanjo has also undertaken a horizontal consistency analysis of FHIR (I don’t know if Claude is ready to share those results.)

I also noticed several cases of the “many-names-for-the-same-thing” phenomenon. One that stuck out for me is the date associated with authoring a resource, which goes by several names in FHIR, including authoredOn, recordedDate, date, created, issued, dateRecorded, dateAsserted, authored. But that’s a story for another day.

Last time, I explained why the Standard Health Record (SHR) is based on data elements. Primarily, clinicians think in terms of data elements, and there are many preexisting libraries of data elements that we can use. Data elements are reusable building blocks that help SHR scale up most effectively.

In this post, I’m going to explore conversions between a data element-style model and more typical class-attribute models. Here’s the bottom line up front: not only is the data element model more parsimonious (smaller) than class-attribute model, but the larger the system, the greater the advantage.

FHIR is a class-attribute model, and so are the V3 Reference Information Model (RIM), CIMI, and FHIM. In an class-attribute model, you might see something like the following definition of FHIR’s Location Resource (for brevity, several attributes are removed):

Class: Location 
Parent class: DomainResource
Description: "Details and position information for a physical place"
Attributes:
  name: string [0..1] // Name of the location as used by humans
  type: CodeableConcept [0..1]  // Type of function performed
  telecom: ContactPoint [0..*]  // Contact details of the location
  address: Address [0..1] // Physical location
  position: [0..1]  // The absolute geographic location
    longitude: decimal [1..1] // Longitude with WGS84 datum
    latitude: decimal [1..1]  // Latitude with WGS84 datum
    altitude: decimal [1..1]  // Altitude with WGS84 datum

To re-express this in terms of reusable data elements, each top-level attribute is converted to a separate data element. To distinguish an attribute from a data element, we use a leading capital letter (e.g., name [attribute] versus Name [data element]). In SHR, it looks like this:

Element:  Location
Based on: DomainResource
Concept:  MTH#C0450429
Description: "Details and position information for a physical place"
0..1  Name
0..1  Type
0..*  ContactPoint
0..1  Address
0..1  Geoposition // Re-named to distinguish from body position

Note that I’ve added a model meaning binding (the Concept keyword), so computationally, “location” is not just a word but a formal concept that can be related to other model concepts to support reasoning. (In SHR, codes are indicated using the syntax codesystem#code. In this case, MTH is an alias for the UMLS Metathesaurus code system, and C0450429 is the code from that system that means “location”.)

Each data element in the composite object Location now must be defined. Here’s how it is expressed in SHR:

Element:  Name
Concept:  MTH#C0027365
Definition: "The words or language units by which a thing is known."
Value:  string

Element: Type
Concept: MTH#C0332307
Description: "Something distinguishable as an identifiable class based on common qualities".
Value:  CodeableConcept

Element: ContactPoint
Concept: MTH#C2986441
Description: "An electronic means of contacting an organization or individual."
// data elements composing ContactPoint...

Element: Address
Concept: MTH#C1442065
Description: "A standardized representation of the location of a person, business, building, or organization."
// data elements composing Address...

Element: Geoposition 
Concept: TBD
Description: "The location on the surface of the Earth, described by a latitude and longitude (and optional altitude)."
1..1 Latitude
1..1 Longitude
0..1 Altitude

Element: Latitude
Concept: MTH#C1627936
Description: "The angular distance north or south between an imaginary line around a heavenly body parallel to its equator and the equator itself. Measured with with WGS84 datum."
Value: decimal

Element: Longitude
Concept: MTH#C1657623 
Description: "An imaginary great circle on the surface of a heavenly body passing through the poles at right angles to the equator. Measured with with WGS84 datum."
Value: decimal

Element: Altitude
Concept: MTH#C0002349
Description: "Height above sea level or above the earth's surface. Measured with WGS84 datum."
Value: decimal

The data element representation is more verbose (partly because I included model meaning bindings and full definitions), but actually, there are fewer entities defined in the data element approach:

• Class-attribute representation (11 definitions): Location, name, type, telecom, ContactPoint, address, Address, position, longitude, latitude, altitude
• Data element representation (9 definitions): Location,  Name, Type, ContactPoint,  Address, Position, Longitude, Latitude, Altitude

The difference? In the class-attribute representation, address and telecom are tautological attributes, expressing the same thing as their datatype, in slightly different words. The definition of Location.address is the same as Address; the definition of Location.telecom is the same as ContactPoint. The data element approach allows you (almost forces you) to eliminate tautological attributes.

When a class-attribute model is converted into a data element model, someone has to interpret the attributes across different objects and determine which attributes mean the same thing, and therefore can be represented with a single data element. We might find multiple “effectiveTime” attributes, but identical naming doesn’t assure identical semantics. Conversely, there could be attributes with different names (e.g., “validityInterval”) that do mean the same thing. Unless there are model meaning bindings on each attribute (usually not), the conversion to an accurate, non-redundant data element model requires hand-work. I did this for the entire CIMI model in the course of about 2 weeks for the September 2017 HL7 ballot cycle (what I learned during that process is another discussion that I might take up later).

What happens to the semantics of an attribute when it is liberated from its class context and converted to an independent data element? Location.type seems much more defined than the free-floating data element Type. That’s true. But when the data element Type is added to Location, as above, it literally means “Type of Location”, same as the attribute. But even that meaning is vague – if you do city zoning, then “Type of Location” could mean something entirely different than is meant in the FHIR context. What helps defines “type” – even within the location context – are the possible answers. In FHIR, the answer set for “type of location” includes codes from http://hl7.org/fhir/v3/RoleCode, which has answers like hospital, chronic care facility, addiction treatment center, and coronary care unit. We really aren’t done defining semantics until we associate a value set. Value set binding goes a long way to refine what we actually mean by a data element in a given context.

In SHR, we use the following syntax to apply a value set binding:

Element:  Location
Based on: DomainResource
Concept:  MTH#C0450429
Description: "Details and position information for a physical place"
0..1  Name
0..1  Type from http://hl7.org/fhir/v3/RoleCode if covered
0..*  Telecom
0..1  Address
0..1  Geoposition

The “from … if covered” syntax is the SHR’s equivalent of FHIR’s “extensible” binding. To say a value set is required, “if covered” is omitted.

The real payoff from a data element model is reuse. Data elements such as Name, Type, and Address can be used over and over. For example, we can use Type in other contexts, bound to different value sets:

Element:  Claim
...
0..1  Type from http://hl7.org/fhir/ValueSet/claim-type  // required binding
...

Element:  Encounter
...
0..*  Type could be from http://hl7.org/fhir/ValueSet/encounter-type  // example binding
...

Element: OralDiet  // from NutritionOrder
...
0..1  Type should be from http://hl7.org/fhir/ValueSet/diet-type  // preferred binding
...

Regardless of whether it is “type of claim,” “type of encounter,” or “type of oral diet,” the same data element, Type, works perfectly well. You don’t have to define Type more than once.

What about reversing the transformation, and going from a data element model to a class-attribute model? Because we have eliminated tautological attributes, some information necessary for the reversal is missing. We can, however, generate tautological names by taking the data element names, and writing them in leading lower case, e.g.:

Class: Location 
Parent class: DomainResource
Description: "Details and position information for a physical place"
Attributes:
  name: string [0..1] // Name of the location as used by humans
  type: CodeableConcept [0..1]  // Type of function performed
  contactPoint: ContactPoint  [0..*]  // Contact details of the location
  address: Address [0..1] // Physical location
  position: [0..1]  // The absolute geographic location
    longitude: decimal [1..1] // Longitude with WGS84 datum
    latitude: decimal [1..1]  // Latitude with WGS84 datum
    altitude: decimal [1..1]  // Altitude with WGS84 datum

That’s almost what we started with. Note that the position attribute is in-lined as a BackboneElement because in FHIR, we can’t create new complex data types. We don’t have to do that for ContactPoint and Address, because they refer to existing complex types.

So, we can go back and forth between the two forms, but when we use common data elements, redundant attribute definitions are eliminated, and they need to be regenerated in the other direction. Elimination of those redundancies is fundamentally why the data element approach is more parsimonious than the class-attribute approach, and why the advantage grows as the size of the model increases.

“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.

Over the past year, MITRE has been working on a domain specific language (DSL) for defining logical healthcare data models and producing FHIR profiles. By design, it is a very simple and compact method of describing a logical data model that can be directly translated into a FHIR profiles and then to a FHIR Implementation Guide. We call this language Compositional Approach to Modeling Data Elements for InterOperability, or CAMEO for short (this name is subject to change).

I’m pleased to announce that CAMEO Version 5 has just been released.

Why is a tool like CAMEO needed? Because FHIR gets you only part of the way to interoperability. You need profiles to say precisely how you will exchange information over FHIR. CAMEO is a scalable way to define profiles, most useful when you need to define a set of profiles for an entire clinical domain. Think genomics, breast cancer, skin and wound care, etc. Domains like this require numerous profiles. The profiles cross-reference each other, making it difficult to produce them one at a time. It would be difficult to model such a domain without the right tool. MITRE is using CAMEO to define a large, detailed set of clinical models we call the Standard Health Record.

Let’s do a “Hello, World” using CAMEO. First go to https://github.com/standardhealth/shr-cli/releases and download the latest release source code package as a zip file, and unzip it to any location on your machine (let’s call it rootdirectory). Follow the README instructions to set up your environment:

1. Install [Node.js](https://nodejs.org/en/download/)
2. Install [Yarn](https://yarnpkg.com/en/docs/install)
3. Execute the following command from rootdirectory: yarn

Now, create another directory (the sourcedirectory), to put our CAMEO files. Create a file called HelloWorld.txt with the following data element definitions:

Grammar:         DataElement 5.0
Namespace:       hello
Description:     "A simple example of CAMEO."

EntryElement:    HelloWorld
Description:     "A silly profile."
0..1             SayHello

Element:         SayHello
Description:    "An extension indicating whether to say hello"
Value:           boolean

Next, create a file called HelloWorld_map.txt that defines the mapping to FHIR. Since this doesn’t align with any particular resource, let’s map it to Basic. This file is even simpler:

Grammar:     Map 5.0
Namespace:   hello
Target:      FHIR_STU_3

HelloWorld maps to Basic:

Since we didn’t map the HelloWorld data element to an existing element inside this resource, it will automatically appear as an extension. Now, from a command prompt in rootdirectory, run:

> node app.js /sourcedirectory

When the program runs, it will output a warning message alerting you that mapping to Basic usually isn’t the best choice, but in this case, it is intentional. After the program runs, the generated profile (a FHIR StructureDefinition) will be found in /rootdirectory/out/fhir/profiles/.  StructureDefinitions are verbose, and this one clocks in at several hundred lines.

A friendlier view is created when we create an implementation guide (IG). To do this, we use the existing FHIR implementation guide (IG) publisher. In order to run the IG publisher, you must first install Java and Jekyll (Windows: Part 1 / Part 2, Mac/Linux). You may need to set up a proxy if you are behind a firewall, since the process tries to access external terminology servers. To generate the IG, run:

> yarn run ig:publish

The generated profile page will be located at /rootdirectory/out/fhir/guide/output/guide/StructureDefinition-hello-HelloWorld.html. The way we have set it up, the IG is automatically branded as part of the Standard Health Record (SHR). We are working on “de-branding” the IG, so ignore the SHR references, for now. To view the Hello World FHIR profile HTML web page, load /rootdirectory/out/fhir/guide/output/guide/StructureDefinition-hello-HelloWorld.html into your browser. It should look  like this:

Hello, World FHIR Profile

Some of you must be wondering – is MITRE’s Standard Health Record more than just a fanciful idea? I want to quickly summarize the top 10 things we’ve accomplished since the project launched a little more than a year ago:

1. We completed a landscape survey of other countries and historical attempts to standardize health records. We found that out of the 10 countries ranked above the US in overall health system effectiveness in the Commonwealth Fund 2014 report (there were only 11 in the study), nine have some form of standard health record, or are in the process of creating one.
2. We made the decision to align SHR to the overall health of individuals, as described in the determinants of health.  We created data definitions for physical environment, individual behavior, and social circumstances, factors that account for 68% of the overall health of the population.
3. We created a domain specific language (DSL) designed to help domain experts capture information requirements, and automatically convert those requirements into formal models, and FHIR profiles. We provisionally call this language “Compositional Approach to Modeling Elements for interOperability,” or CAMEO for short. The code, samples, and other information is found on Github.
4. Using CAMEO and associated tooling, we created a  SHR-on-FHIR Implementation Guide.  The SHR-on-FHIR IG currently contains over 200 FHIR profiles, making it the largest, most comprehensive, and integrated set of FHIR profiles yet created.
5.  In collaboration with Dana-Farber Cancer Institute, the American Society of Clinical Oncology, the Alliance for Clinical Trails in Oncology, and Brigham and Woman’s Hospital, we began a focused effort to apply the SHR approach to breast cancer. This oncology namespace in SHR now includes FHIR profiles for initial breast cancer diagnosis, cancer staging, histologic grading, receptor status, tumor size, metastasis, aggressiveness, genetic variants, progression, and toxicity.
6. My MITRE colleague Steve Bratt and I were on the organizing committee that launched the Clinical Information Interoperability Council (CIIC), an umbrella organization guiding clinical societies toward an integrated approach to data standardization.
7. With help from Richard Esmond, we founded a new HL7 group, the Cancer Diagnosis, Treatment and Research (Cancer DTR), to bring together a larger community of stakeholders to work on standardizing cancer data and bridging gaps between clinical treatment, disease registries, and clinical trials. This group has been convened both through HL7 and under the larger CIIC umbrella.
8. To realize the vision of 100x faster standards creation, we’ve begun to build an integrated ecosystem comprised of rapid data standards specification, clinician-facing data entry, creating test patients, populating FHIR servers, and testing exchanges, to vastly accelerate the process of standards development and deployment. In addition to CAMEO, the system uses MITRE’s synthetic data generator, Synthea, an advanced clinical user interface, Flux, and our FHIR testing software, Crucible.
9. We recently completed a detailed review of CIMI, to determine how SHR and CIMI might align or merge. We have created our own proof-of-concept, preliminary CIMI-on-FHIR Implementation Guide, for comparison purposes. The ideal outcome would be a merger that combines the best features of each.
10. We open sourced everything, and you can find all the code and data definitions on Github.

The Standard Health Record (SHR) is an ambitious standards development project. It seeks to standardize information in every area of a person’s health, with the goal of establishing a high quality, complete, computable, integrated health record. “One human, one health record” is our primary goal, but we know data standardization is the key to enabling ALL downstream information uses: healthcare data exchange, aggregation, care delivery, safety, decision support, analysis, reporting, and research.

It is a big job. ICD-10 distinguishes over 12,000 disease categories. There are approximately 100 medical specialties and numerous sub-specialties. But in the words of Dr. Stan Huff, if we have to boil the ocean, we’ll do it one bucket at a time. To this I might add: we need more buckets and bigger burners. By that I mean, not only do we need more parallel efforts, 10 or more at a time, but each effort must develop standards 10 times faster (not to mention, 10 times better) than the healthcare community has ever done, so collectively, we move 100 times faster than ever before.

Think about the traditional HL7 work group process and how it meanders and drags on for years at a time, often ending with a paper product, not a computable, testable artifact. While FHIR has moved the needle on this, FHIR profiling still depends on painful, one-at-a-time, hand crafting. That isn’t going to get us there.

The Clinical Information Interoperability Council (CIIC) is a new initiative to increase the number of simultaneous domain-specific standards efforts. That’s more buckets. There is a significant amount of clinical content already in SHR, and thousands of clinical models at openCEM.org, and that’s a significant amount of water that’s already hot.

What about bigger burners, capable of bringing all those buckets to a rapid boil? There is no doubt that the process of building consensus among a broad group of stakeholders takes time. But the glacial pacing of the 4-month ballot cycle is deadly. We need to accelerate the process of building and testing information models. The methodology needs to be aimed directly at domain experts, not informatics geeks (like myself). It must enable those experts to express their clinical information needs simply and directly. It must make that process fast, transparent, and agile. It must allow creators to see the implications of their choices, notice the shortcomings quickly, and make corrections trivially.

As a community, we’re terrible at discovering and stamping out bugs in our specifications. It’s 2017, and still our primary method of quality control is reading ballot documents and perusing class diagrams. In my experience, that’s almost totally ineffective. Actual hands-on use is the only effective way to understand our own creations, and find and fix flaws. To speed up standards development, prototypes must be automatically generated from specifications. Every proposal must be immediately turned into testable software. As humans, we will always make mistakes and take many iterations to get things right. If we can’t reduce the number of iterations, at least we can make the iterations faster.

If we really could capture and test out our ideas immediately, we might be able to do a model iteration per week, instead of one iteration per 4-month cycle between HL7 meetings. That’s 10x right there, and then we’re cooking with gas. And that’s the only way to boil the ocean.

The trouble with diets and blogs is that they often have a short half-life. I admire folks like David Hay, who publish interesting and useful material with great regularity. After a year of slacking off, I have accumulated a large backlog of content, and the main problem with getting re-started is deciding where to begin. So, do-re-me, we’ll start at the very beginning.

With MITRE colleagues, I have been working on the Standard Health Record (SHR) project since the spring of 2016. SHR began with a fundamental re-thinking of MITRE’s interoperability contributions, prompted by a shared frustration: despite decades of standards development work,  the US healthcare system was still far from tapping the vast potential of healthcare data to reduce cost, improve quality, and extend access to more consumers.

Taking our own “fresh look”, we quickly focused on the lack of a Common Operational Picture (COP) of each patient. In the homeland security context, a COP is “a single identical display of relevant (operational) information … shared by more than one Command” [Wikipedia]. SHR is the vision to establish a health-oriented COP for each person. My department head and healthcare visionary, Harry Sleeper, coined the phrase: One human, one health record — the antithesis of the siloed, episodic, text-heavy, fractional records that commonly exist today. The SHR must be a complete, computable, high quality health record, including everything that happens to the patient and all the factors that influence their health (the determinants of health), including patient-generated data. The SHR framework must also ensure that the patient is the owner and overseer of his or her own health record.

Even the introduction of FHIR, which is far better than anything we’ve had in the past, progress towards “one human, one health record” has been too slow. Clearly there are multiple reasons (technical, business, and social), but I believe a major reason is that exchange standards fail to address what health information is collected and stored at the source (usually the point of care). Once information is collected, the die is cast. If different sites collect different information, there is only so much that mapping to a common data exchange standard can do. Collecting standardized, high quality data at every point of care is the key to enabling ALL downstream uses: exchange, aggregation, care delivery, safety, decision support, analysis, reporting, and research. To even begin to get there, we need a target, i.e., a health record specification. SHR was born.

To be clear, SHR is not an exchange standard, although it can be used for that. It is a content standard, defining at a logical level what can be in a health record. It can be used to guide data collection and storage, and to generate artifacts that enable standards-compliant data exchanges.

During the summer of 2016, we surveyed countries outside the United States and learned how some had worked to standardize the contents of their medical records. Many nations have worked towards defining that content, with varying degrees of success. SHR’s ambition is to go far beyond where other countries, Argonaut, or the US Core profiles have gone. The goal is to capture a wide swath of healthcare information, and do it at a level of detail that will assure semantic interoperability. (I should mention that we share that goal with CIMI, openEHR, and others. I’ll pick up those threads later.)

To achieve that goal, SHR processes and technology must work at several levels:

• SHR must empower medical domain experts, working in many separate consensus groups (crowd sourcing of a particular sort), to create logical information specifications 10-100 times faster than in the past. Data standardization proposals must be expressed in a simple, transparent, and open way, to enable rapid iteration and improvement.
• SHR methodology and governance must assure whatever is proposed by one group will mesh with proposals from other groups, to enable sharing of common data elements across healthcare domain boundaries.
• SHR must automatically translate those integrated consensus logical specifications into practical implementations based on existing technology and standards.

In summary, SHR can be created only if there is a methodology to create a broad-based, consistent, coherent, scalable logical model; supporting maximal reuse of information structures; offering rapid, distributed, agile development; presenting in a transparent, easily understandable form; and outputting that model in implementable form, e.g., FHIR profiles.

That’s a tall order. Over the next few posts, I’ll take you through our approach.

When and how should resource validation happen in a FHIR-based information exchange?

Those familiar with the FHIR specification will know that FHIR provides several ways to validate whether a resource conforms to a FHIR Structure Definition, whether that StructureDefinition is a profile or a base resource definition. If the resource is in XML, the syntax can be validated against FHIR’s XSD. FHIR also provides a more in-depth procedural validator that checks additional factors, such as invariants.  Continue reading →

Last time, I mentioned the possibility of having different sets of profiles for producing and consuming resources. Since then, I have gotten questions about why a FHIR server might want to have two sets of profiles, and how these profiles relate to FHIR’s API. Although having separate sets of produce and consume profiles is not currently a feature of FHIR, having two sets of profiles would allow FHIR to follow a principle of interoperability called Postel’s Law.

Continue reading →