SMART, CIMI, FHIR & Argonaut
Saw an interesting question and answer on the SMART support forum about the relationship between SMART and FHIR which Josh has allowed be to copy here (as it’s so topical might now). The question was:
Anyone who happens to know … I’d appreciate it if you could clue me in…
Other than the kick ass implementations done on the SMART-on-FHIR side of world, is there something that SMART adds definitionally to the pile of stuff at documented in a very scattered fashion (not a criticism – it’s the nature of what these things) over at HL7 FHIR? Or is it Boston Children’s/Harvard’s project working to implement the HL7 FHIR standards in a coherent way? Or … what?
Also, via CIMI (which I get the purpose of, I think), I came across Health Services Platform Consortium (HSPC). What are they doing that SMART-on-FHIR isn’t doing? Even all of the posted “apps” that “they” have developed that are running come from you. Do they (above and beyond what the mission is here) have a technical purpose? Or is it politics or marketing or something of the like that I don’t understand.
and Josh’s reply:
When we get to set context ourselves, we like to say “SMART is working to define an open-standards-based platform for health apps.” We use open standards under the hood, including FHIR for clinical data access, OAuth2 for authorization, and OpenID Connect for user authentication. One FAQ is definitely “doesn’t FHIR already provide an app platform out of the box?” — and the answer is, not quite. For good reasons, the HL7 FHIR community is working on a set of specifications that can be used in a broad set of contexts. There’s a lot that’s left open to interpretation — or, to say that better, open to downstream use-case-specific implementation guidance. So SMART effectively builds on FHIR to add:
1. Consistent, open-standards-based security (authorization, authentication)
2. Context-handling so apps can launch against existing EHR systems
3. Data profiling constraints to lock down modeling optionality and vocabularies (e.g. by specificy RxNorm for meds, or LOINC for labs).
We also provide examples, implementation guidance, sample apps, client libraries, a discussion forum, etc., to promote shared understanding, provide reusable components, and lower the barrier to entry for those looking to use the platform.
I should also point out that while we focus on the pragmatics of integrating with today’s EHR’s, we’re also engaged in forward-looking activities. For example, there’s a group focused on defining genomics APIs and building prototype clinico-genomic apps. We expect to eventually propose a few FHIR resources and profiles specifically for accessing gene and variant data acquisition from secondary systems, e.g., DNA sequencing systems.
(In terms of history: before FHIR, back in 2010-2013, SMART had our own take on the data models and REST API layers for a healthcare API — but we found it was an increasing maintenance burden and hard to get wide-scale buy-in to our modeling decisions. So we were thrilled to channel our energy and engineering efforts into the community process that is FHIR development. I’ve personally gotten involved with FHIR as a member of the core editorial team and the FHIR Management Group. The core SMART and FHIR teams have worked together very effectively, and to clear mutual benefit, over the past 18 months.)
—
It’s hard for me to exhaustively and correctly describe the (evolving!) landscape, but in a few words I can try to provide context about:
* CIMI. An open modeling initiative to produce shared repositories of detailed clinical data models. It’s an independent effort that I participated in for about 18 months back in 2011-2013, but frankly I haven’t had the time to stay engaged. One current direction that CIMI is pursuing is to try expressing their models in terms of FHIR using “profiles” on existing FHIR resources.
* HSPC. An group collection of clinical care organizations has convened a coalition, which systems integrators and app developers, to build out support for plug-in apps and services. There’s very strong alignment with SMART’s goals (and solutions) at least for the “basics” of what HSPC is looking to accomplish. HSPC is indeed using SMART on FHIR’s specs to support what they call their “tier 1” services. They also have ambitions to describe much broader orchestrations and compositions of services with richer functionality (“tier 2”), but I’m not sure whether work has proceeded in that direction.
* Argonaut. A collection of vendors and care organizations that came together in December 2014 to support development of specs that support plug-in health applications. Argonaut’s goal is to promote existing projects rather than invent something new. They’ve contributed funding to support HL7’s FHIR development process (including internal QA), and are also sponsoring a security review of the SMART on FHIR specs. You’ll see some traffic on this list from Argonaut participants around these goals. Argonaut is just kicking off an “implementation program”, too — so we expect to see more traffic as a growing set of EHR organization begins to try out these specs. (Also worth saying: part of Argonaut’s goal is to support development detailed FHIR profiles for the data in the MU common data set. I expect that SMART should be able to re-use these profiles directly, rather than maintaining our own — so over time, SMART should be able to shed aspects of the “data profiling” I described in item #3 of my list above.)
Like this:
Like Loading...
About David Hay
For release 3 of FHIR, there’s a decent chance that some of the OAuth profiling work that Smart/HSPC are working on will be included as part of the core FHIR spec.