WIXLIB

Building Bridges: Mapping HL7 V2 to FHIRSimone Heckmann, Gefyra GmbH / HL7 GermanyAmsterdam, 15-17 November @fhir furore #fhirdevdays17 www.fhirdevdays.comFHIR 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.

Who we are„gefyra“ is the Greek word for „bridge“We offer FHIR training,consultancy for FHIR projectsprofessional toolingintegration services (j/w Health-Comm,based on INfOR Cloverleaf )We have been involved with FHIR since2014,have tested our V2 mappings on 7Connectathons,and have them running in productionenvironments

FHIR-ServerIntegration EngineV2-based EHR?ADT-MessagesFHIR-Clients

FHIR als Daten-HubIntegration Engine6

Scenario Mapping a V2 ADT A01 messagehttp://wiki.hl7.org/index.php?title Version 2- FHIR Mapping Scenarios

MSH \& LegacyEHR SPARK 20150502090000 ADT A01 00000002 P 2.5EVN 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 20150502090000 AL1 1 DA 1605 acetaminophen L MO Muscle Pain hair lossAL1 2 DA 1558 Oxycodone L MO Muscle Pain hair lossAL1 3 MA 2221 Peanuts L SV Anaphylactic Shock

MSH \& LegacyEHR SPARK 20150502090000 ADT A01 00000002 P 2.5EVN 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 20150502090000 AL1 1 DA 1605 acetaminophen L MO Muscle Pain hair lossAL1 2 DA 1558 Oxycodone L MO Muscle Pain hair lossAL1 3 MA 2221 Peanuts L SV Anaphylactic Shock

so, it‘s a Bundle of Resources! Yes. But there are multiple typesof Bundles.Is it a message, a batch, atransaction or a document ?http://build.fhir.org/bundle.html

A message, obviously! True, but which event? Whichstructure? What‘s the logicassociated with the event? Doesthe server know all this? Do we really want to re-implementV2 messaging with FHIR?http://build.fhir.org/messagedefinition.html

So what do we do? We (the integration engine) knowwhat the events mean and whichactions we expect the server toperform. So we can tell the serverwhat to do. Let‘s try Transactions!

whathow

MSH \& LegacyEHR SPARK 20150502090000 ADT A01 00000002 P 2.5EVN 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 20150502090000 AL1 1 DA 1605 acetaminophen L MO Muscle Pain hair lossAL1 2 DA 1558 Oxycodone L MO Muscle Pain hair lossAL1 3 MA 2221 Peanuts L SV Anaphylactic ShockPatient - create/update?Encounter - createAllergyIntolerance(s) - purge/create

Now, let‘s REST-ify that!

How do I update/create? We need to check if the Patientalready exists. If it does, we wantto PUT, if it doesn‘t we want toPOST. Enter the „Conditional 0.2

So what‘s the criteria? The Conditional UPDATE will fail ifit matches multiple resources, soour criteria must identify thePatient uniquely. Sounds like „identifier“, right?http://build.fhir.org/search.html#token

PID 1 345345412312345 10 NHS NH 456756756745 TCPAS MR g/identifiers

How do I purge/create? First, we need to DELETE allpreviously submittedAllergyIntolerances, then POST thenew ones. But wait! We need tomake sure, we only delete theones we (the integration engine)created! Enter the „Conditional 2.1

So what‘s the criteria? Somehow we need to be able torecognize the AllergyIntoleranceswe submitted.This can be achieved by either adding tags to the resourcemetadata (simple) or using Provenance resources (notso simple, but more ttp://build.fhir.org/provenance.html

So, if we use tags, our criteria is:DELETE [base]/AllergyIntolerance?patient.identifier [?]& tag [?]„chained search“„token parameter“

These are our resources!That‘s us!

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 anAttachment. ( yes, we need to create that resource, too )

Does that really work? Well, we made it work (at least,with tags)after changing the processingorder for Transactions toDELETE POST PUT GEThttp://build.fhir.org/http.html#2.42.0.16.2

Now: the field mapping! Check the „mapping“ tab at thetop of each resource There‘s no „one-size-fits-all“ – V2structures and FHIR serverrequirements will vary! look at the FHIR mappinglanguage and StructureMapresource! look at ConceptMap resourceand the d.fhir.org/terminology-service.html#4.6.8

How do I reference a resource that doesn‘t have a url(yet)? Assign a UUID to everyBundle.entry.fullUrlThen reference the associatedresource by this uri.The server must replace UUIDswith the actual urls whenprocessing the ences

But what if I don‘t want to touch the resource I need toreference? Conditional Update will update thematching resource,Conditional Create will create anew resource if none matches.Both can get us into trouble, if wedon‘t have permission tocreate/update specific resources. Solution: Use ConditionalReferences es

Limitations! V2 Source will overwrite all changes and additions to Resources onthe 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?

The MERGE hack Create two Patient resource from the A40‘s PID, one with the good, onewith 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 goodpatient! - try to PATCH the link into the good Patient instead

What if the server doesn‘t support Transactions? Basically, the Transaction Bundle constitutes a list ofindividual, atomic REST interactions. We can run themthrough „post processing“ and split them up. But remember: we have to handle the replacing of theUUIDs with the actual URLs ourselves! We can even split the Conditional interactions up into aGET and PUT/POST/DELETE interaction,But then we have to deal with the errors on our side.

You can move complexity around,but you can‘t make it go away(Grahame Grieve)

ClientClientServerServerComplexityTransactionPlain RESTComplexityMessage

FHIR-ServerIntegration EngineV2-based EHRTransaction-BundlesADT-MessagesFHIR-Clients

FHIR-ServerIntegration EngineV2-based EHR?/Observation/ historyORU-MessagesSearchset BundleFHIR-Clients

history reliability simple to implement repeatable (if something wentwrong)- not selective/high traffic- delay- second interaction for includesSubscription realtime selective low bandwidth- no queueing- no trigger if a resource drops outof your selection

What next? Tell us about your use case and join the Hands OnGive feedback at RJoin the discussion on how to handle mergeJoin the next connectathon in San Antonio and help us toevaluate Subscription and history interactions to transferResources from a FHIR server back to a V2 systemhttp://wiki.hl7.org/index.php?title 201701 Resource Subscription Track

we make fhir work

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 Connec