![So, if we use tags, our criteria is:
DELETE [base]/AllergyIntolerance?patient.identifier=[?]&_tag=[?]
„chained search“ „token parameter“](https://image.slidesharecdn.com/buildingbridges-devdays2017-powerpointtemplate-171117144745/85/Building-bridges-devdays-2017-powerpoint-template-21-320.jpg)
![So, in our case:
GET [base]/AllergyIntolerance?patient.identifier=[?]&_has:Provenance:agent:device=[?]
We also need to create a Device resource!
Advantage: the Provenance Resource also gives us an chance to store the original message for traceability as an
Attachment. (…yes, we need to create that resource, too…)](https://image.slidesharecdn.com/buildingbridges-devdays2017-powerpointtemplate-171117144745/85/Building-bridges-devdays-2017-powerpoint-template-23-320.jpg)
Building bridges devdays 2017- powerpoint template
- 1. FHIR® is the registered trademark of HL7 and is used with the permission of HL7. The Flame Design mark is the registered trademark of HL7 and is used with the permission of HL7. Amsterdam, 15-17 November | @fhir_furore | #fhirdevdays17 | www.fhirdevdays.com Building Bridges: Mapping HL7 V2 to FHIR Simone Heckmann, Gefyra GmbH / HL7 Germany
- 2. Who we are „gefyra“ is the Greek word for „bridge“ We offer • FHIR training, • consultancy for FHIR projects • professional tooling • integration services (j/w Health-Comm, based on INfOR Cloverleaf®) We have been involved with FHIR since 2014, have tested our V2 mappings on > 7 Connectathons, and have them running in production environments
- 4. FHIR als Daten-Hub 6 Integration Engine
- 5. Scenario • Mapping a V2 ADT_A01 message http://wiki.hl7.org/index.php?title=Version_2_ -_FHIR_Mapping_Scenarios
- 6. MSH|^~&|LegacyEHR||SPARK||20150502090000||ADT^A01|00000002|P|2.5 EVN|A01|20150502090000| PID|1||345345412312345^10^^NHS^NH~456756756745^^^TCPAS^MR||Gefyra^Alpha^F^^Ms^ ^L||19280524|F|||Bridge Street 22^^Bridgetown^^^12345^^^^P||277543^PRN|||U|| NK1|1|Gefyra^Beta|FTH|||+44 201 12345678|| PV1||I|INT^0001^02^GENHOS||||0100^ANDERSON,CARL|0148^ADDISON,JAMES||SUR||||||| 0148^ANDERSON,CARL|S|234637^^^GENHOS|A|||||||||||||||||||GENHOS|||||2015050209 0000| AL1|1|DA|1605^acetaminophen^L|MO|Muscle Pain~hair loss AL1|2|DA|1558^Oxycodone^L|MO|Muscle Pain~hair loss AL1|3|MA|2221^Peanuts^L|SV|Anaphylactic Shock
- 7. MSH|^~&|LegacyEHR||SPARK||20150502090000||ADT^A01|00000002|P|2.5 EVN|A01|20150502090000| PID|1||345345412312345^10^^NHS^NH~456756756745^^^TCPAS^MR||Gefyra^Alpha^F^^Ms^ ^L||19280524|F|||Bridge Street 22^^Bridgetown^^^12345^^^^P||277543^PRN|||U|| NK1|1|Gefyra^Beta|FTH|||+44 201 12345678|| PV1||I|INT^0001^02^GENHOS||||0100^ANDERSON,CARL|0148^ADDISON,JAMES||SUR||||||| 0148^ANDERSON,CARL|S|234637^^^GENHOS|A|||||||||||||||||||GENHOS|||||2015050209 0000| AL1|1|DA|1605^acetaminophen^L|MO|Muscle Pain~hair loss AL1|2|DA|1558^Oxycodone^L|MO|Muscle Pain~hair loss AL1|3|MA|2221^Peanuts^L|SV|Anaphylactic Shock Patient Encounter AllergyIntolerance(s) MessageHeader
- 8. …so, it‘s a Bundle of Resources! • Yes. But there are multiple types of Bundles. Is it a message, a batch, a transaction or a document…? http://build.fhir.org/bundle.html
- 10. A message, obviously! • True, but which event? Which structure? What‘s the logic associated with the event? Does the server know all this? • Do we really want to re-implement V2 messaging with FHIR? http://build.fhir.org/messagedefinition.html
- 11. So what do we do? • We (the integration engine) know what the events mean and which actions we expect the server to perform. So we can tell the server what to do. • Let‘s try Transactions!
- 12. how what
- 13. MSH|^~&|LegacyEHR||SPARK||20150502090000||ADT^A01|00000002|P|2.5 EVN|A01|20150502090000| PID|1||345345412312345^10^^NHS^NH~456756756745^^^TCPAS^MR||Gefyra^Alpha^F^^Ms^ ^L||19280524|F|||Bridge Street 22^^Bridgetown^^^12345^^^^P||277543^PRN|||U|| NK1|1|Gefyra^Beta|FTH|||+44 201 12345678|| PV1||I|INT^0001^02^GENHOS||||0100^ANDERSON,CARL|0148^ADDISON,JAMES||SUR||||||| 0148^ANDERSON,CARL|S|234637^^^GENHOS|A|||||||||||||||||||GENHOS|||||2015050209 0000| AL1|1|DA|1605^acetaminophen^L|MO|Muscle Pain~hair loss AL1|2|DA|1558^Oxycodone^L|MO|Muscle Pain~hair loss AL1|3|MA|2221^Peanuts^L|SV|Anaphylactic Shock Patient -> create/update? Encounter -> create AllergyIntolerance(s) -> purge/create
- 14. Now, let‘s REST-ify that!
- 15. How do I update/create? • We need to check if the Patient already exists. If it does, we want to PUT, if it doesn‘t we want to POST. • Enter the „Conditional UPDATE“! http://build.fhir.org/http.html#2.42.0.10.2
- 17. So what‘s the criteria? • The Conditional UPDATE will fail if it matches multiple resources, so our criteria must identify the Patient uniquely. • Sounds like „identifier“, right? http://build.fhir.org/search.html#token
- 19. How do I purge/create? • First, we need to DELETE all previously submitted AllergyIntolerances, then POST the new ones. But wait! We need to make sure, we only delete the ones we (the integration engine) created! • Enter the „Conditional Delete“! http://build.fhir.org/http.html#2.42.0.12.1
- 20. So what‘s the criteria? • Somehow we need to be able to recognize the AllergyIntolerances we submitted. This can be achieved by either • adding tags to the resource metadata (simple) or • using Provenance resources (not so simple, but more powerful) http://build.fhir.org/resource.html#Meta http://build.fhir.org/provenance.html
- 21. So, if we use tags, our criteria is: DELETE [base]/AllergyIntolerance?patient.identifier=[?]&_tag=[?] „chained search“ „token parameter“
- 22. These are our resources! That‘s us!
- 23. So, in our case: GET [base]/AllergyIntolerance?patient.identifier=[?]&_has:Provenance:agent:device=[?] We also need to create a Device resource! Advantage: the Provenance Resource also gives us an chance to store the original message for traceability as an Attachment. (…yes, we need to create that resource, too…)
- 24. Does that really work? • Well, we made it work (at least, with tags) after changing the processing order for Transactions to DELETE > POST > PUT > GET http://build.fhir.org/http.html#2.42.0.16.2
- 25. Now: the field mapping! • Check the „mapping“ tab at the top of each resource • There‘s no „one-size-fits-all“ – V2 structures and FHIR server requirements will vary! • + look at the FHIR mapping language and StructureMap resource! • + look at ConceptMap resource and the $translate-Operation! http://build.fhir.org/mapping-language.html http://build.fhir.org/structuremap.html http://build.fhir.org/conceptmap.html http://build.fhir.org/terminology-service.html#4.6.8
- 26. How do I reference a resource that doesn‘t have a url (yet)? • Assign a UUID to every Bundle.entry.fullUrl Then reference the associated resource by this uri. The server must replace UUIDs with the actual urls when processing the Transaction http://build.fhir.org/bundle.html#references
- 28. But what if I don‘t want to touch the resource I need to reference? • Conditional Update will update the matching resource, Conditional Create will create a new resource if none matches. Both can get us into trouble, if we don‘t have permission to create/update specific resources. • Solution: Use Conditional References instead! http://build.fhir.org/bundle.html#references
- 30. Limitations! • V2 Source will overwrite all changes and additions to Resources on the Server (-> Patch) • There is no „trigger“ to invoke additional actions on the server (-> Message/Operations) • „Merge“ is tricky (-> Operations) • Doesn‘t work in the absence of REST Protocol (-> Message) • Is it PV1 actually an Encounter or rather an EpisodeOfCare?
- 31. The MERGE hack • Create two Patient resource from the A40‘s PID, one with the good, one with the bad identifier. • Create the conditional update URLs accordingly • Add a link (type=„replaces“) from the good to the bad Patient • Add a link (type=„replaced-by“) from the bad to the good Patient • Set the bad Patient to „inactive“ • Downside: we‘re losing the NK1 information when updating the good patient! -> try to PATCH the link into the good Patient instead
- 32. What if the server doesn‘t support Transactions? • Basically, the Transaction Bundle constitutes a list of individual, atomic REST interactions. We can run them through „post processing“ and split them up. • But remember: we have to handle the replacing of the UUIDs with the actual URLs ourselves! • We can even split the Conditional interactions up into a GET and PUT/POST/DELETE interaction, But then we have to deal with the errors on our side.
- 33. You can move complexity around, but you can‘t make it go away (Grahame Grieve)
- 36. V2-based EHR Integration Engine FHIR-Server FHIR-Clients ORU-Messages /Observation/_history Searchset Bundle ?
- 37. _history Subscription + reliability + simple to implement + repeatable (if something went wrong) - not selective/high traffic - delay - second interaction for includes + realtime + selective + low bandwidth - no queueing - no trigger if a resource drops out of your selection
- 38. What next? • Tell us about your use case and join the Hands On • Give feedback at https://chat.fhir.org/#narrow/stream/v2.20to.20FHIR • Join the discussion on how to handle merge • Join the next connectathon in San Antonio and help us to evaluate Subscription and _history interactions to transfer Resources from a FHIR server back to a V2 system http://wiki.hl7.org/index.php?title=201701_Resource_Subscription_Track
- 39. we make fhir® work