Embed Size (px)
DESCRIPTION
Presentation given at HL7 Norway on april 1st, 2014. Subjects are: why a new standard? what are the basic building blocks of FHIR? What are profiles? How do we make documents out of resources? Also contains some example architectures.
Citation preview
Our common problem
• Avoid speaking between lunch and afternoon coffee
• No one is interesting to listen to for more than 45 minutes
So….Please…
• I’ll break the presentation in 45 minutes
• State your questions at anytime
• Read your e-mail if you need to
Fast(well, that’s relative)
HealthcareInteroperability(that’s what we need)
Resources(the web technology bit)
STARTING A FHIRWhy have something new?
Why something new?
“How can I get data from my server to my iOS app?”
“How do I connect my applications using cloud storage?”
“How can I give record-based standardized access to my PHR?”
If your neighbour ‘s son can’t hack an app with <technology X> in a weekend…..
you won’t get adopted
10
REST
WHAT’S IN THE BOX?
Slice & dice your data into “resources”
MedicationPrescription Problem
Cover 80% - Context independent - Unit of exchange/storage
Consistent documentation
Organization “ACME Hospital”National Drive 322Orlando, FL
Organization “ACME Hospital”National Drive 322Orlando, FL
PatientMRN 22235“Olaf Olafsson”01-01-1994Bergen
PatientMRN 22234“Ewout Kramer”30-11-1972Amsterdam
Thousands of examples
Structure of a Resource(XML example)
Human Readable
• CDA taught HL7 a very important lesson– Even if the computers don’t understand 99% of what you’re
sending, that’s ok if they can properly render it to a human clinician
• This doesn’t just hold for documents – important for messages, services, etc.
• In FHIR, every resource is required to have a human-readable expression– Can be direct rendering or human entered
How many resources?Currently: about 40
• Administrative– Patient, Location, Encounter,
Organization, • Clinical Concepts
– AllergyIntolerance, Questionnaire, Observation
• Infrastructure– ValueSet, Composition, Profile,
Conformance
Next up…still about 100 to go
• Scheduling- Appointment, Availability, Slot
• Financial- Claim, Account, Coverage
• Consent
Everything to cover C-CDA
Generic Specific
Cover all usecases - (n)ever
HL7v3 RIMHL7 CDA
C-CCD
openEHR RM
HL7v2
IHE PDQFHIR
openEHR Archetypes
openEHR Templates
HL7v3 CMETS
+ =
Cover the 80% out of the box…
Organization “ACME Hospital”National Drive 322Orlando, FL
PatientMRN 22234“Ewout Kramer”30-11-1972Amsterdam
+ Haircolor BROWN
+ Taxoffice Id NLOB33233
You can extend:- Resources- Elements of Resources- FHIR Datatypes
Extending a multiple birth
Key = location of formal definition
Value = value according to definition
3.x
?
Package & publish: The Profile
“My First Profile”V1.0 by Ewout
Support “Bottom-up re-use”
Document from the resource to the wireHTTP/1.1 200 OKContent-Type: application/json;charset=utf-8Content-Length: 627Content-Location: /fhir/person/@1/history/@1Last-Modified: Tue, 29 May 2012 23:45:32 GMTETag: "1“
"Person":{"id":{"value":"1"},"identifier":[{"type":{"code":"ssn","system":"http://hl7.org/fhir/sid
Message
Document
REST
CORBA
SOAP ?
Packaging & transport
Yes, v2 style messagingis also supported! √Yes, v3 CDA style documentsare also supported!
√
IN SUMMARY…
FHIR Manifesto (abridged)
• Focus on implementers• Keep common scenarios simple• Leverage existing technologies• Make content freely available
Implementer support…
In Summary…
• Basic “80%” Resources• Extension mechanism• Publication mechanism for specs (profiles)• Package as Message, Document or “REST”• XML/JSON/HTTP protocol for transport• Examples, documentation, API’s, connectathons
What’s Next?• January 2014 First Draft Standard for Trial Use ballot (“DSTU1”)
– Semi-stable platform for implementers Additional DSTU versions roughly annually to make fixes, introduce new resources
• May 2015 Second Draft Standard for Trial Use ballot (“DSTU2”)– Additional (C-CDA) resources, more workflow support, work on validation, community
feedback
• Normative is around 3 years out– We want lots of implementation
experience before committing to backward compatibility
31
Questions?
INTERLUDE: SOURCE OF FHIR
“Source” of FHIR
Straight from the HL7 SVN “code” respositoryat gforge.hl7.org
Publication process
.INI
Publication tool(org.hl7.fhir.tools.jar)
Java, C#,Delphi eCoreDefinitions.xml
Website
ValidationSchema’s
Examples
DictXml Resource profiles
ResourceUML
examples
PLAYING WITH FHIRCombining resources into useful exchanges
It’s all about combining resources . . .
37
Patient
Practitioner
Observation
Organization
http://pat.registry.org/Patient/223
http://hospitalA.org/Practitioner/87
http://lab.hospitalA.org/DiagRep/4445
http://lab.hospitalA.org/Observation/3ff27
http://hospitalA.org/Organization/1
Practitioner
Patient
Observation
FHIR server @ hospitalA.org
PractitionerPractitioner/87
Organization
Organization/1
FHIR server @ lab.hospitalA.org
DiagnosticReport
DiagnosticReport/4445
Observation
Observation/3ff27
result
In REST: Possibly distributed…
39
FHIR server @ pat.registry.org
PatientPatient/223
managing
subject
perfo
rmer
http://fhirblog.com/2014/01/24/modelling-encounters-with-fhir/
FHIR server
Patient ObservationOrganization
PatientPatient Observation
Observation
“Repository” model of healthcare
CreateUpdate Query
Lab System
CreateUpdate
Hospital System
CreateUpdate Query Subscribe
“Atom”: New reports in the mail
FHIR Document
43
Dr. BernardPractitioner Patient Mary
Patient
Discharge Medslist
Vital Signslist
PulseObservation
BPObservation
DyclofenacMedicationPrescription
TamsulosinMedicationPrescription
Kidney StonesCondition
DischargeSummary
Composition
Chief Complaintsection
Physicalsection
Medicationssection
subjectauthor
content
content
content
entry
entry
FHIRRepository
Regardless of paradigm the content is the same
Lab System
Receive a lab result in a message…
FHIR MessageFHIR Document
…Package it in a discharge summary document
NationalExchange
REST
http://fhirblog.com/2014/03/31/referrals-orders-and-fhir/
CONTROLLING THE FHIRVery short intro to Profiles
The need for Profiles
• Many different contexts in healthcare, but a single set of Resources
• Need to be able to describe restrictions based on use and context
• Allow for these usage statements to:– Authored in a structured manner– Published in a repository– Used as the basis for validation, code, report and UI generation.
Constraining cardinality
48
Limit cardinality to 1..2(e.g. to at maximum your organizations’ identifier + the national one)
1..21..1
Limit names to just 1 (instead of 0..*)
Forbid any telecom elements
0..0
Note: something that’s mandatory in the core definition cannot be made optional in a profile
Limit value domains
49
Fix value: Only allow “active” Patients
=“true”
If deceased is given, it must be a dateTime, not a boolean
Use our national codes for MaritalStatus
Use another profiled Resource
OrganizationNL
“Basic” Document
50
Practitioner
Patient
Any Resource
Composition
0..* Section0..1 subject
0..1 author
content
Document-NO Profile!
51
Practitioner-NO
Patient-NO
MedicationPrescription-NO
Discharge Medslist
Vital Signslist Observation
Condition
DischargeSummary-NO
Composition
1..1 Complaintsection
0..1 Physicalsection
1..1 Medicationssection
1..1 subject1..1 author
content
content
content 0..* entry
0..* entry
0..1 Home situationsection
What’s in a profile?
MetadataIdentifierName, VersionPublisherDescription, CodeStatusDate (of publication)
Constraints
ExtensionDefn
Conformance
ValueSet
Resource
Extension
supports
binding
urlta
g
http://hl7.no/Profiles/patient-no
Tagging a Resource
Patient
MRN 22234“Ewout Kramer”30-11-1972Amsterdam
http://hl7.org/fhir/tag/security“I’m a VIP - My information cannot yet be disclosed”
http://hl7.org/fhir/tag“This is TEST data! Don’t use!”
http://hl7.org/fhir/tag/profile“I’m an Organization as defined in the Norwegian Profile – see http://hl7.no/Profiles/patient-no”
(Distributed) validation
App’s server
Store &Validate
Country validation serverValidate Y
Profile X
Profile Y
Profile YD
ownload &
Validate
Profile X
Profile Y
THE FHIRSTARTERSSome examples from early-adopters
Form Filler
Form Repository
EmptyQuestionnaires
1. Form Request+ Patient data in FHIR
Form Client
2. Prepopulated
Questionnaire
3. Filled out form
CompletedQuestionnaires
FHIR
FHIR
Patient & Provider registry
CCD Documents
Hospital System
Resources
FHIR Documents
National Patient Portal
References
PDF Documents
INTEROP WITH V2/V3
V2 to FHIR bridge FHIR message processor
Hospital System
FHIRRepository
FHIRREST
FHIRMessages
Note: Messages are events,REST exposes a “repository” Model of data…
v2
Messages
Migration – v2 and FHIR
• Already have an integration engine that supports translation between v2 and FHIR messages
• Resources map to segments reasonably well• As always, the challenge with v2 mapping is the
variability of v2 interfaces– “Common” mappings can be created, but they won’t
be one size fits all
…and v2 mappings
Every Resource has v2 mappings specified, e.g.:http://www.hl7.org/fhir/patient-mappings.html#http://hl7.org/v2
Patient identifier PID-3 name PID-5, PID-9 telecom PID-13, PID-14, PID-40 gender PID-8 birthDate PID-7 deceased[x] PID-30 address PID-11 maritalStatus PID-16
CDA to FHIR Document bridge
Hospital System A
FHIRDocuments
Note: Documents are compositions,• No update semantics• Context?• Wholeness?
V3 CDA
Documents
FHIRRepository
FHIRREST
FHIR Document processor
Migration – CDA and FHIR
• Made more complex by human-readable nature– Need to ensure text <-> entry linkages are retained
• Will best be handled on a template by template basis– Likely start with important ones like C-CDA
…and v3 mappings
Every Resource has v3 mappings specified, e.g.:http://www.hl7.org/fhir/patient-mappings.html#http://hl7.org/v3
Patient Patient identifier ./id name ./name telecom ./telecom gender ./administrativeGender birthDate ./birthTime deceased[x] ./deceasedInd address ./addr maritalStatus ./maritalStatus multipleBirth[x] .multipleBirthInd
66
FHIR & C-CDA
• C-CDA is mandated by Meaningful Use• FHIR is a new specification• FHIR is not a replacement for C-CDA (yet)• Project to migrate C-CDA content to FHIR• In the future, FHIR may gradually replace C-
CDA
(XDS) references
• CDA documents in FHIR systems• FHIR documents stored elsewhere (i.e. registry/repository following the XDS
model)• PDF documents, and even digital records of faxes where sufficient information is
available• Other kinds of documents, such as records of prescriptions.
A DocumentReference resource is used to describe a document that is made available to a healthcare system.
It is used in document indexing systems, and are used to refer to:
IHE MHD
“This winter (…) the Volume 2 part of Mobile Health Documents (MHD) will be replaced with the appropriate content describing a profile of DocumentReference to meet the needs of MHD and the family of Document Sharing in XDS, XDR, and XCA.”
John Moehrke, august 16, 2013
So why use anything else?
• FHIR is brand new– No market share– Only recently passed DSTU ballot– Little track record
• Business case– No-one dumps existing working systems just because something
new is “better”– Large projects committed to one standard won’t change direction
quickly (or even at all)
Simple message
• Yes, FHIR has the potential to supplant HL7 v3, CDA and even v2• However
– It’s not going to do so any time soon
• No one's going to throw away their investment in older standards to use FHIR until1. The specification has a good track record2. It’s clear the new thing provides significant benefits
• HL7 will support existing product lines solong as the market needs them
http://www.forbes.com/sites/danmunro/2014/03/30/setting-healthcare-interop-on-fire/
SMART DEMO
http://smartplatforms.org/smart-on-fhir/
BlueButton
SMART
SMART
FHIR
FHIR
AnyFHIR
Server(PHRs!)
FHIR
Let’s run a demo!
Next Steps for you
• Read the spec at http://hl7.org/fhir• Try implementing it• Come to a (European?) Connectathon!
• [email protected] • #FHIR• Implementor’s Skype Channel• FHIR Developer Days (November 24 – 26), Amsterdam• StackOverflow: hl7 fhir tag
