Since 2010, the SMART team has been privileged to work on an exciting frontier of health data liberation, exposing structured patient-level data through an open API. We’ve striven for simplicity, with a constrained set of well-described data models, fixed vocabularies, a clean REST API, and Web-based UI integration. And we’ve endeavored to use existing standards where they fit the bill: that is, when existing standards were openly available and met our own subjective criterion of developer-friendliness.
When we launched our first preview of the SMART API back in 2010, there was no structured data content standard that fit the bill, so we rolled our own. We started with simple models for Patient, Medication, and Fulfillment, and over time we’ve expanded the collection to encompass over a dozen top-level clinical statements. Building and maintaining these data models was never our core goal, but until recently, there hasn’t been a suitable alternative on the horizon.
But that’s starting to change. This summer and fall, we’ve eagerly followed the progress of a new contender in health data standards space: Fast Healthcare Interoperability Resources (FHIR) from HL7. FHIR is a specification that includes data models, serialization formats in XML and JSON, and a RESTful API for querying clinical data. It’s still in its early days. It hasn’t yet even been designated by HL7 as a “draft standard”—but we’re excited about the approach that FHIR is taking.
The FHIR community has made rapid progress in developing a clean, open, developer-friendly specification for granular data access, along with a consistent means to provide for document retrieval. FHIR provides a compelling scope of data models out-of-the-box, along with a principled framework for resource extension and resource constraints (“profiling”). Together, these characteristics provide a forward-thinking standard whose benefits should facilitate effective—and cost-effective—implementation. As conceived, the FHIR standard could provide a powerful way forward for remediating a long list of informational bottlenecks in HIT.
To support the FHIR effort and highlight its potential for providing a robust, open health API, the SMART Project has built a prototype that we’re calling SMART-on-FHIR. SMART-on-FHIR builds on the SMART aesthetic and philosophy (simple, developer-friendly) using standards-based components. It includes two key components:
|
Demo |
Source |
|
|
FHIR API Server |
||
|
FHIR Starter Apps (Includes: Patient Selector, Growth Charts, BP Centiles, and Cardiac Risk) |
Login/pass: [create a new account] |
These components are still early-stage prototypes and they’re unstable as we keep up with changes in the FHIR spec. But we encourage you to poke around the demos and source code, and share your feedback on Twitter (@SMARTHealthIT or @JoshCMandel) or in our Google Group.
Behind the scenes, authorization takes place using a customized version of the MitreID Connect. For more background on how the pieces fit together, see the Blue Button REST API, a Standards and Interoperability Framework project that applies the same authorization approach to achieve patient-facing data liberation. (I’m the community lead for Blue Button REST; if you’re interested in learning more, please checkout our Pilots Workgroup.)
You must be logged in to post a comment.