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.