I recently listened to an informative webinar from Mulesoft: Unlocking Electronic Health Records (EHRs) with Application Programming Interfaces (APIs). I learned a lot (and also generated a lot of questions) and thought I’d share a few notes from the webinar. I had hoped to make this more of a comprehensive review but my notes will have to suffice. I’ll update this topic with more posts over time as I further synthesize what it all means.
Here’s the link to the webinar:
I’ll skip over the general info material on why APIs are important in modern commerce (surely you already know that part…), and get right to some of the healthcare specific info that caught my attention.
Why has healthcare not seen as much API-driven innovation as other industries?
1. The large number of entrenched EHR and healthcare infotech vendors (over 1200). That’s a very fragmented market, more than I realized even after working on the fringes of it during my time at Intel (probably because we focused on a dozen big EMR vendors).
2. HL7 Version 2 currently dominates the industry, but under this standard the data structure & meaning can change for every trading partner relationship, so the opportunity to “code once – connect to many” is missing.
3. HL7 V3 -has been slow to implement due to complexity.
4. Healthcare systems have traditionally relied on VPN connections for authentication – very non-consumer friendly, and requires custom point to point implementations. Just as the modern enterprise has become more flexible with cloud services that don’t require VPN, and which are mobile friendly, healthcare will do the same.
A 2014 JASON report details why a fundamentally different architecture is needed.
– “CCD” – continuity of care documents require it, and
– SSO, authentication, and improved user experience are becoming more important
Environmental changes that make the adoption of a new standard important:
1. Consumer expectations – both in app quality and in the ability of the clinician to utilize all the data available
2. Transition to value based care, not fee for service, as driven by legislation – here’s a reference on MACRA.
Meaningful Use Stage 3 requirements are driving greater patient access to data and greater exchange of data, which means APIs will be even more important.
The goal of SMART on FHIR is to allow a developer to write an app once and expect that it will run anywhere in the healthcare ecosystem. Think of it as an enabling protocol for an “app store” for health apps.
FHIR = Fast Healthcare Interoperability Resources – defines resources (e.g., allergies, care plans, medications), exposed as semantic RESTful APIs. Formalized, computable mechanism for extensability to resources which are not part of the core definition. Developed by HL7.
SMART = Substitutable Medical Apps and Reusable Technologies –
– OAuth 2.0, based on HTML & other standard, familiar web technologies
From an API management standpoint, SMART and FHIR are a subset of the overall API management function.
OK that’s enough notes, more synthesis to follow…
A few references:
ICOE Group – API focused consulting group, a Mulesoft partner
Mulesoft – API management and system integration solution, a leader in the market
WS Security : https://en.wikipedia.org/wiki/WS-Security