Stream: argonaut
Topic: EHRs certified for API access
Michele Mottini (Jun 20 2018 at 14:32):
US vendors are in the process of certifying their systems for API access with the ONC - the list of certified systems to date is at https://chpl.healthit.gov/#/collections/apiDocumentation
Michele Mottini (Jun 20 2018 at 14:34):
I went through the published documentation and the results are not very encouraging: only 6 or so implementing SMART (out of 100+), only a handful implementing FHIR - and using different versions
Michele Mottini (Jun 20 2018 at 14:35):
If anyone is interested I can share the Google sheet with the details
Isaac Vetter (Jun 21 2018 at 17:11):
Hey Michele, that sounds really interesting. Mind sharing your spreadsheet with me?
Michele Mottini (Jun 21 2018 at 17:29):
Here it is: https://docs.google.com/spreadsheets/d/1C9faN7Ne0DIgrmXbMVBcff9KTotuejIEbpr4ZPE3tUE/edit?usp=sharing
Abbie Watson (Jun 21 2018 at 21:20):
There’s still at least 2 dozen that are FHIR based. That’s definitely a start. And seems to be approxImating an 80/20 rule.
Michele Mottini (Jun 22 2018 at 02:50):
The sticking point is authentication - that is all over the place
Michele Mottini (Jun 22 2018 at 02:50):
...and four different (incompatible) FHIR versions
Eric Haas (Jun 22 2018 at 03:08):
4? DSTU2, STU3 and what else?
Michele Mottini (Jun 22 2018 at 13:33):
Ballot versions: 0.5 and 1.6
Isaac Vetter (Jun 24 2018 at 04:24):
wow, Michele, your spreadsheet is awesome!
To summarize your spreadsheet:
- FHIR DSTU2 and SMART is only supported by Allscripts, CareEvolution, Cerner, CPSI, Epic and (probably) GE.
Only Epic has production endpoints published, but it doesn’t support refresh_token without joining dev program ($$). Athena supports DSTU2, but only the OAuth2 client credentials flow. eCW and McKesson supports STU3 and SMART. MEDITECH supports DSTU2 and OAuth (not SMART).
Analysis:
- As Michele suggests, a large number of certified systems are using existing proprietary APIs to meet regulation. likely these APIs are the shortest path to meeting regulation. If supporting FHIR, developers aren’t sure which version to support. Where FHIR is used, DSTU2 is the primary version, followed by STU3.
- FHIR is more prevalent than SMART, although the dominant auth standard is OAuth (there’s not SAML at all!). Why aren’t developers using SMART?
Conclusion:
- The Common Clinical Data Set of FHIR resources should be normative to standardize patient API access and provide a straightforward path to API (and therefore app) developers.
- Likely the existing OAuth2 libraries don’t support SMART, so neither do developers. HL7 SMART should perform outreach to API developers to assist.
Michele Mottini (Jun 25 2018 at 01:06):
Thanks Isaac
Michele Mottini (Jun 25 2018 at 01:08):
The GE sandbox uses a 'custom' version of SMART - and so is not really SMART compliant. It seem that their new version fix that, but it is not available in their sandbox (details at https://github.com/GEHealthcare/apiserver.gehealthcare.com/issues/7#issuecomment-392949351 and following messages)
Michele Mottini (Jun 25 2018 at 01:08):
I was not able to test CPSI - could not find test servers or sandbox
Michele Mottini (Jun 25 2018 at 01:10):
Athena is a bit of a mystery: their published documentation mention only OAuth client credentials and not SMART, but Apple Health _can_ connect to Athena systems using SMART - so maybe they support it but it is not documented? I asked in their forum but got no answer
Michele Mottini (Jun 25 2018 at 01:13):
Not sure about why SMART is not more widely implemented. I know that IdentityServer3 - that is widely used to implement OAuth in the .NET world does not support it. We wrote our own OAuth implementation to support SMART
John Moehrke (Jun 25 2018 at 16:18):
This all seems very expected to me. The MU requirement for 'any kind of API' has been around for a long time, and it is very easy to standup 'any kind of API' as there is no one that can say your API is not compliant with your proprietary definition.
What would be far more interesting is to see a trend over time. Any snapshot can be viewed positive or negative, but a trend would be more declarative. Seems this trend is what the FHIR community survey is trying to gather, so encourage everyone to fill it out, especially those not in the core of argonaut today.
John Moehrke (Jun 25 2018 at 17:19):
Does anyone that supports FHIR as their API, support "download" of $everything to meet the MU "download" requirement? https://healthcaresecprivacy.blogspot.com/2018/06/fhir-patient-extensible-data-portability.html
Michele Mottini (Jun 25 2018 at 20:41):
The Argonaut way to 'get everything' is to use the $docref operation (http://www.fhir.org/guides/argonaut/r2/OperationDefinition-docref.html) - that gives you the data as a CDA
Michele Mottini (Jun 25 2018 at 20:42):
Cerner and CareEvolution implements it, not sure about the other implementation (our app do not use it so I was not looking explicitly for it)
John Moehrke (Jun 26 2018 at 12:43):
understood... but that is CDA format, not FHIR...
Michele Mottini (Jun 26 2018 at 12:45):
Yes, that's what meaningful use certification require - an API call to download all the data (or the data for a date range) as CDA
John Moehrke (Jun 26 2018 at 12:49):
the background for my point is that there is a FHIR API, but that the app I want to use is not approved by my provider... so I just want all my data in FHIR so that I can feed it to my app myself. It is a mashup of the MU requirement for API, and the MU requirement for download... I recognize I am assembling them in a different way than the chronological way they were written into regulation.
Michele Mottini (Jun 26 2018 at 12:52):
Got it...to the best of my knowledge none support that
John Moehrke (Jun 26 2018 at 12:55):
Might be nice to have an app written that does only this, and see if it could be accepted into everyones app store?
Michele Mottini (Jun 26 2018 at 12:56):
That does only what? Download all the data?
John Moehrke (Jun 26 2018 at 13:05):
requests $everything, and puts the resulting Bundle into a ZIP that is saved locally... yes. very basic, yes.. but if this isn't down yet, then an app could do it... that app is more likely to be approved into an app store, than any-random-app..
Michele Mottini (Jun 26 2018 at 13:10):
You cannot use $everything - no server supports it. An app could get all the data using separate queries for the various resources - and then make that data available to _other_ apps using FHIR + SMART (that's what our myFHR app can do actually)
John Moehrke (Jun 26 2018 at 13:19):
I didn't think $everything worked, I was using that as a shorthand for a more robust design that would work with all systems. Spelling out the full robust design each message is not human readable.
Michele Mottini (Jun 26 2018 at 13:29):
Developers tend to be literal
Last updated: Apr 12 2022 at 19:14 UTC
