The Migration of HL7v2 to FHIR is very essential. As it is important to have the control of data in the end system.

Usually what happens with the HL7v2?

• The data needs to be fetched from the source. Now this source can be a EMR or it can be a PMS system.
• So, there involves a lot of paper work. We need to know what data source is going to send. How they’re going to send in what field.
• Then we need to get the data based on what they’re sending. For example: you man need provider information with more details, but EMR might not send all the details of a provider.
• It is difficult to get what you need. For example: You may need only medication information. But they might be sending all the patient information in PID, MSH and lot of other information which will be of no use to us.

How FHIR solves the problem?

• FHIR gives the end user the control. You can fetch what you want. Instead of asking from the EMR BA team. Whatever you need you make a GET call.
• It is essential that the EMR needs to expose their API for this. And there can be any of the 139 total resources defined by FHIR standards be used there.
• If you need medication, you call only the medication statement resource. If you need patient, you ask for only GET /patient resource.
• FHIR has a standard defined in open source. There need not be a separate document needed to identify what is sent from source. Less paper works.
• I do cautiously tell you that FHIR is not only a GET. There is also a subscription model available that allows the source to push the data to you. But I believe the major advantage of using FHIR is that, you have the ability to ask (GET) what you need.

Why there is a need to migrate?

• Well, realistically speaking the big business challenge is that, not many hospitals have purchased EMR with the FHIR capability. They’ve EMR only with HL7v2 capability. Now, the EMR’s charge are huge to purchase them with FHIR capability.
• That’s why many in industry are preferring to have their own repository (mere personal opinion). The goal is to continue getting the source feeds with HL7v2 until the hospitals migrate.
• But once a HL7v2 is received from the source, it will be converted to FHIR standards as individual resources and get saved in FHIR repository.
• This FHIR repository will be used as a source of truth for the future. Anybody who needs any data, all they need to do is use the API’s of FHIR repository.

Why Repository is the future?

• Imagine you need to fetch data from 10 different EMR system. What we need to understand here is, FHIR is not providing any guidelines what resources needs to be mandatory for exposing to these EMR.
• So, each EMR may have their own different resources. EMR 1 may have location as separate resource. EMR 2 may send location information as a part of Encounter resource.
• For Every EMR you need to make a different GET call and segregate the Data. If you’re developing the app, it’s painful as you dont have a fixed format to GET data from these EMR’s.
• This is why FHIR repository is essential, this repository will provide a single source of truth for performing the data extraction.

• Here is a sample Mapping of HL7v2 & FHIR that’s been provided by FHIR themselves. Said that, migrating is not a easy task. Migration requires a lot of mapping work. The easy way to perform the migration is to create a solid,robust HL7 template on your end.

• Which ever HL7 message comes to your system, your first work is to migrate that into the standard HL7 template. This can be tedious but it works like Gem.

• This gives you a relief that you don’t need to alter your HL7 to FHIR resource code often. You can freeze them. You need to lay hands on the code that does the conversion of the source HL7 to the standard template HL7 format.