9. How many resources?
Currently: about 60
• Administrative
– Patient, Location, Encounter,
Organization,
• Clinical Concepts
– AllergyIntolerance,
Questionnaire, Observation
• Infrastructure
– ValueSet, Composition, Profile,
Conformance
Next up…still about 60 to go
• Scheduling
- Appointment, Availability, Slot
• Financial
- Claim, Account, Coverage
• Consent
• Devices
– Metric, DeviceComponent
• Care Transfer
Full support for C-CDA
10. Flexibility vs. useability
Generic Specific
openEHR RM
HL7v3 RIM
HL7v2
HL7 CDA
openEHR
Templates
C-CCD
IHE PDQ
openEHR
Archetypes
FHIR
HL7v3 CMETS
Re-useable Single purpose
11. Cover the 80% out of the box…
Race
Middle
name
+ =
Lunar Hijri
birthdate
12. FHIR Repository
Standard
FHIR REST
Custom
Operations
Read
Update
Search
Check Drug
Interaction
Merge
Patient
15. Packaging & transport
Yes, v2 style messaging
√is also supported!
Yes, v3 CDA style
documents
are also supported! √
16. Document from the resource to the wire
HTTP/1.1 200 OK
Content-Type:
application/json;charset=utf-8
Content-Length: 627
Content-Location:
/fhir/person/@1/history/@1
Last-Modified: Tue, 29 May 2012
23:45:32 GMT
ETag: "1“
"Person":{"id":{"value":"1"},"identifi
er":[{"type":{"code":"ssn","system":"
http://hl7.org/fhir/sid
17. What’s Next?
• Februari 2014 First Draft Standard for Trial Use (DSTU)
– Semi-stable platform for implementers Additional DSTU versions
roughly annually to make fixes, introduce new resources
• June 2015 Second Draft Standard for Trial Use (DSTU2)
• Normative – 2016?
– We want *lots* of implementation
experience before committing to
backward compatibility
17
18. 18
International HL7 FHIR Developer Days
November 24-26, 2014 in Amsterdam
Education
– 14 tutorials
Connectathon
– Meet fellow developers
– Put FHIR to the test
Networking
– FHIR experts and authors on hand
http://fhir.furore.com/devdays
It’s been said before by the “wise” Steve Ballmer….”developers, developers, developers”….
…unfortunately we at HL7 were not at that point AT ALL
- People were looking for comparable familiar solutions at HL7…..for mobile, for cloud….we could not offer them that…..
Documents are not compatible with how mobile and interactive apps work.
If you want to find the lab results for all patients showing up tomorrow at your desk, how to you do that?
“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?”
Base spec has lots of optionality…..You can constrain away stuff you don’t need
But you can also add stuff to the basic models for your usecase
“Remove and add bricks as necessary”
Who’s 80%?
But allow publication & discovery of extensions
How bad is it that not the whole world speaks Esperanto?
That we use English for our basic needs? For the generic context
In fact, even in your mother tongue, you don’t know much jargon….only of interest when you need to communicate in a certain context
So, if a doctor talks jargon to his colleagues, and the IT guy does the same to his colleagues, why can they still converse when having a beer? You only need to learn each others jargon depending on your communication needs. Likewise chaos won’t automatically occur when everyone uses extensions within his own context of exchange.
That moment either of you have to flex: you learn some jargon, he uses lay-man or you end up in something between
In the mean time, our mother tongue evolves too and develops new words for new concepts….bottom up AND top down
“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
A profile can be published on a FHIR (based) server (it’s a Resource, after all)
Or in a version-management system, or by e-mail, or…
As long as people can *find* them, because publishing your profile should help others to find & adhere to it.
Document every resource, every attribute
Provide examples
Define how to use in REST, Document and Message
Manageable by a project lead in a weekend, or you’ll be ignored (in favor of local solutions)