Morning session at Vitalis 2016 - giving a high-level overview of the why what and how of HL7 and FHIR. These slides combine background information on the principles that shaped FHIR and the components of FHIR.
The big aggregator – the extreme case is Apple HealthKit
Dit wordt mogelijk gemaakt doordat systemen hun interne data en business processen aanbieden voor externe ontwikkelaars
Op een gecontroleerde wijze – via een goed ontworpen “API”
Dat was vroeger een term voor nerds, nu mag het in de board room: het is een manier van zakendoen
Niet langer lijm je mensen door ze naar je website te halen, en daar diensten aan te bieden
Maar steeds meer zorg je ervoor dat anderen apps kunnen bouwen waarmee zij jouw dienstenpakket versterken en aanvullen
Salesforce.com generates more than half of its $2.3 billion in revenue through its APIs, not its user interfaces. Twitter is said to process 13 billion transactions a day through its APIs. Google is around 5 billion transactions a day. For it’s part, Amazon is rapidly closing in on a trillion transactions. Not bad for an online bookseller.
Your portal becomes a small part of the total traffic to your sites
“API” was a low-level term, but now it is about how a larger part of patient/client facing software is depending on how business start to expose their data and processes to client-facing software so it can be integrated in a larger whole. Again: Don’t expect you or your portal to be the center of the world, be humble
Now I hear you say: well this is all about today newest and hottest, mobile. But we need to realize that although the conventional markets stay, a larger and larger part will be about these consumer facing devices and software, the rest just operates in the background. And HL7 really needed to get back into that part of the market.
We need these others to make FHIR popular. App developers will communicate with innovative health solution providers and the big EHR vendors and only then realize that they are using a standardized API called FHIR.
0:20
Readily useable, contain “the 80%” (What’s the 80%...what’s maximum reuse? That’s HL7’s core business!)
Independent of context, fixed defined behaviour and meaning
Can reference each other
Units of exchange – suggests units of storage for implementers
Addressed through HTTP or other methods
This is a critical concept in FHIR – the ability to reference between resources in a ‘web’ of relationships.
Also n
Save resources to EHR using REST (+/- transaction), package as a document for the
You can constrain away stuff you don’t need
You can add stuff to the basic models for your usecase
“Remove and add bricks as necessary”
Build a resource in clinFHIR
Build a resource in clinFHIR
For each one – when to use
“Standardize” medical data like “Patient”, “Order”, etc. These are resources
“Standardize” how to create/query/do notifications of this data
0:45
Though micro USB might be the exception ;-)
Why isn’t there a world standard for A/C plugs? They sprung up in different locations, the cost of using an adapter is small (220/110?).
These vendors (and the hipster connecting to them) have only one need: communication. We have to enable them to produce software that enables better healthcare. We just should not be in the way. We may have focused on the inherent value of standardization and universal semantic operability.
When the “standardizers” realize not many comply to the standards, a normal reaction is to ask an authority or government to force vendors to comply.
This works only incidentally, and is often costly. It would be better if the vendors have motives to comply, rather than a financial impetus.
True for whole countries too (“yeah, country X started with a pilot and then they produced their local dialect ”)
“Drive-by” or “bottom-up” operability: “Communicate first, standardize later”
First, business partners. Then, collaborations, communities. Maybe, finally, nation-wide
It’s a natural process that people will want to make it work first, then only coordinate what they really need to, and then realize they can broaden their approach to a community.
“Support”, of course top-down should still be possible! Maybe even a combi in the long-term
You don’t need a central authority to model your data, before you can start.
“Then again, we’re not Facebook or Twitter…..we do not write an API just for our own needs….we need to be everything to everyone…..now, how can we do that?”
FHIR standardizes “the 80%”, but embraces adaption so there’s 20% that can be used to invent your own models and functionality
Premise seems to be that all communication needs to be standardized or put into a framework before communication can be successful. I think that we just have to focus on enabling the software vendors to search each group. Even if that means they’ll all be talking dialects
What language need to be standardized, depends on the context of communication. Within colleagues (in outside the same hospital), with other specialties, with the patient. Each has a bit of shared language, and “specialized” terms – we call it “jargon”.
Wie nog verder geïnspireerd wil raken:
Een boek over eeuwenlang falen om talen te standaardiseren en minder dubbelzinnig te maken.
Verplicht leesvoer voor terminologen en kennisredeneerders.
John Wilkins 1686 (en de Grieken)
James Cooke Brown (1988)
0:10
Also: TestScript resource
Authoring workflow Publishing workflow
Demo!
0:25
Note that dates are subject to change based on resources and the standards process