A couple of months ago, The President’s Council of Advisors on Science and Technology issued its Report to the President on Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans. We want to tell you how SMART fits in.
At a high level:
- PCAST very eloquently identifies lack of interoperability as the central problem of healthcare IT. To spark innovation, PCAST proposes a universal exchange language, with atomic data elements and a strong metadata philosophy for privacy and provenance. We wholeheartedly agree.
- One of PCAST’s suggestions is to eschew efforts to define universal semantics, leaving to the market the task of semantic harmonization. While we agree that the market will significantly contribute to semantic harmonization, our experience indicates that an organized initial foray into standardizing semantics for common, well-understood health data is critical to getting the ball rolling.
- With SMART, we are building such a universal health language — inspired by existing standards and built on existing coding systems — and empowering with it a modern, web-based application ecosystem. We specifically address PCAST recommendations of data atomicity, metadata tagging, and semantic extensibility, while simultaneously addressing what some have identified as weaknesses in the PCAST report, notably the risk of incomplete patient context when working with disaggregated atoms of data.
Now for some detail.
we agree: interoperability, better yet substitutability, is key
The PCAST report diagnoses a clear problem with current health IT:
The market for new products and services based on health IT remains relatively small and undeveloped compared with corresponding markets in most other sectors of the economy, and there is little or no network effect to spur adoption.
The Presidential Advisors recommend a clear course of action:
What is needed is a […] universal data exchange, able to unleash the power of the competitive market, to produce increasingly better and less expensive systems, and to create the “network effect” that spurs further adoption.
We agree, and propose that this data exchange language more specifically support substitutability, where one component of an EMR can be easily — and without significant technical effort — replaced by another competing component. In the words of the journal article that paved the way for the SMART Platform project:
[Electronic Medical Record systems should support] substitutability of applications. The system should be sufficiently modular and interoperable so that a primary care provider could readily use a billing system from one vendor, a prescription-writing program from another, and a laboratory information system from yet another.
With substitutability of components against a common datastore, new features can be built and deployed quickly and easily on existing EMRs. The significance of this is difficult to overstate: large hospitals and individual practices alike would be able to deploy significant new features in a matter of days or even hours, opening up an opportunity for tremendous innovation. PCAST’s universal exchange language is indeed the first necessary step to achieving substitutability and thus a thriving health IT ecosystem.
Some specific properties of this common language are required: it should be precise enough that new EMR functionality (i.e. “apps”) can be built once and deployed automatically against multiple EMRs. This property — write-once, deploy everywhere — must be emphasized. If apps need significant technical tuning before a new deployment, the market flexibility necessary for rapid innovation simply won’t materialize.
a (small) disagreement: investing early in semantics pays off
So, what does it take to build a universal exchange language that supports substitutability? The PCAST report, in one of its more specific recommendations, is lukewarm about standardizing health data semantics:
As a related issue, ONC’s current approach has the effect of postponing the development of a genuinely universal “syntax” (that is, the formatting of data that are exchanged and the details of exchange protocols) until after the government has harmonized the “semantics” (that is, the clinical or operational meaning of the data, or its human understanding) from many different health IT-related realms. […] We urge reconsideration of this approach.
On this point we have a minor disagreement. Semantic harmonization has escaped the healthcare IT market to date, even though XML has been the agreed-upon syntax for all newer standards. Indeed, even individual standards, like CCD, have internally “flexible semantics” that result in incompatibilities between CCDs produced by different systems. How can apps be built in a true plug-and-play fashion if data fields don’t have stable meanings across EMRs, e.g. if date” means “date of visit” in one EMR, but “date of entry” in another? To achieve true plug-and-play substitutability, we need a beachhead of common semantics, at least for common medical events.
Again, this is, in our opinion, only a small disagreement: PCAST and SMART agree that semantic harmonization is important for interoperability, and that the market will play a significant role. We just think harmonization needs a solid organized nudge before it crystallizes.
what we’re doing to accomplish PCAST Objectives
- a semantic beachhead: we are proposing a clear data model for common health data, starting with medications and fulfillments, problems, allergies, and simple blood labs. We are using existing standards like CCR and CCD for semantic inspiration, and of course we are using as-is existing coding systems like SNOMED and RxNorm.
- atomic datapoints, with metadata and context: our modeling approach allows for expressing atomic datapoints such as single allergies, problems, or single blood lab value, exactly as recommended by PCAST. Though we have not yet explored detailed provenance and privacy metadata, our approach also allows for flexible and extensible annotation of data. Importantly, because our data model is entirely graph-based, individual datapoints can be assembled into complete medical records and eventually connected to additional datasets we haven’t yet modeled. Individual data atoms can eventually be combined and related in ways we have not yet defined. This flexibility enables us to define precise semantics for data atoms, while retaining the flexibility of composing them into appropriate contexts that may well differ depending on clinical, personal, or research use.
- extensible semantics: our modeling approach allows for adding additional semantics over time, without affecting existing data or existing software that relies on this data. In other words, our approach is as future-proof as possible without weakening the semantics of data we understand today.
- a modern, web-based application platform: in addition to this extensive data modeling work, we’re building a modern web-based platform for app developers to build features using the SMART data model. With a little bit of JavaScript and HTML knowledge, developers can get started building truly interoperable applications for SMART-enabled EMRs, PCHRs, and data-mining platforms. In parallel, we’re working with EMR vendors to help them expose the SMArt API and platform architecture.
The technology underlying these attractive features is the W3C’s Resource Description Framework (RDF). RDF allows us to precisely model the semantics of well-understood health data while leaving open-ended the modeling of more advanced, less standardized cases. Because everything is modeled as a graph, it is easy to scale down and consider a very small subgraph representing only a single lab value, while also connecting all of these data atoms together into a coherent, fully contextual patient record.
minimalist precision
We think SMArt has a strong chance of succeeding because we’re tackling a tractable subset of health data exchange. We’re considering only the most common health datasets, enabling interoperability for roughly 80% of medical use cases. You probably won’t use the SMArt platform for particularly intricate medical records just yet. Also, we’re considering, for now, only very localized health data exchange between an EMR and its installed apps. This further reinforces the point that we do not (yet) need to exchange the patient’s full medical record. With this more tractable scope, we anticipate making significant progress in standardizing the semantics of core health data. Over time, with the help of others, we’ll expand this model to cover less common health cases and provide health data exchange on a larger scale, both in scope and distance. Within this minimalist setting, we can make health data more precise and thus more actionable, useful, and interoperable.
a vibrant health IT ecosystem
In the end, we all seek a vibrant health IT ecosystem. We find much to rejoice about in the PCAST report, and we believe SMArt will play an important role in defining the universal exchange language that forms the foundation of an interoperable ecosystem of features and services.