HL7v2 with HL7 FHIR - It Works

FHIR
1

Have just done a sprint converting v2 to FHIR and it wasn’t that painful. I can’t emphasise enough how useful these spreadsheets are https://docs.google.com/spreadsheets/d/1PaFYPSSq4oplTvw_4OgOn6h2Bs_CMvCAU9CqC4tPBgk/ though.

Initial work can be found here CARECONNECT-MESSAGING-STU3\HL7v2 to FHIR Conversion - FHIR v3.0.2 (it’s not official careconnect work… should it be?).

So from a technical point of view it looks very possible we can exchange DiagnosticReports, Patient Demographics and Encounters in either xml, json, turtle and pipe+hat (pipe and hat being HL7v2).

It does have some niggles and benefits, which are mostly around models and support.

Conversion

Converting v2 to FHIR creates compact FHIR Messages. I really like this but it is style of FHIR different to what we are seeing in specifications. I.e. the example below doesn’t have a reference to an Organization (surgery) resource instead it uses an ODS code and this is a direct mapping from PD1 segment XON datatype.

        <managingOrganization>
          <identifier>
            <system value="https://fhir.nhs.uk/Id/ods-organization-code"/>
            <value value="Y06601"/>
          </identifier>
          <display value="MALTON GP PRACTICE"/>
        </managingOrganization>

In many UK FHIR specifications we would see this expanded into a full Organization resource with a reference in the Patient resource. I believe the v2 (UK HL7v2 specification) way is better. It’s probably easier for the receiver to handle, in most cases they only need the name and the ODS code (if extra details are needed they can be looked up).

Patient and Encounters

CareConnect Patient and Encounter does not contain many of the CodeSystems/ValueSets we need for conversion. Some of the missing (required in England) Code Systems includes

  • Admission Method (Encounter.type)
  • Discharge Method(Encounter.hospitalization.dischargeDisposition)
  • Admit Source (Encounter.hospitalization.admitSource)
  • Healthcare Service (Encounter.type)

They can be found outside CareConnect and UK STU3.

I’m not sure why the UK FHIR equivalents of v2 tables are FHIR version or specialty specific?
In my examples, I’ve used these CodeSystems.

Interestingly I only used one extension in my examples and that may be an issue with the CareConnect Patient profile. English HL7v2 has a rule that NHS Number can only be present if it has been verified and its tracing status is optional. So the extension in the example below should be optional (trace status is always going to be traced)

    <identifier>
          <extension
                     url="https://fhir.hl7.org.uk/STU3/StructureDefinition/Extension-CareConnect-NHSNumberVerificationStatus-1">
            <valueCodeableConcept>
              <coding>
                <system
                        value="https://fhir.hl7.org.uk/STU3/CodeSystem/CareConnect-NHSNumberVerificationStatus-1"/>
                <code value="01"/>
              </coding>
            </valueCodeableConcept>
          </extension>
          <system value="https://fhir.nhs.uk/Id/nhs-number"/>
          <value value="3333333333"/>
        </identifier>

Giving this HSCIC HL7v2 compliant version

 <identifier>
          <system value="https://fhir.nhs.uk/Id/nhs-number"/>
          <value value="3333333333"/>
  </identifier>

Far more compact and readable.

DiagnosticReports and Observations

I’m interested ORU^R01 both from taking in LabReports into a FHIR System but also sending out Observations from a FHIR system as HL7v2. So I’ve looked at this from HL7v2 to/from FHIR.

Unlike Patient and Encounters we don’t have a UK standard for these clinical types. The closest we get is the use of ORU^R01 messages in labs/hospitals. So I had to make some assumptions:

  • HL7v2 version 2.4 - So same as HSCIC ITK HL7v2
  • PID, PD1, MSH segments formats - same as HSCIC ITK HL7v2
  • OBX and OBR formats - Followed US examples and included CodeSystems (v2 CE.NameOfCodingSystem). This is a required change, FHIR needs to know what system a code belongs to.
  • Use SNOMED where possible/practical
  • Use Units of Measure units where possible/practical

An example following this convention can be found here CARECONNECT-MESSAGING-STU3\HL7v2 to FHIR Conversion - FHIR v3.0.2

This conversion had opposite problems to Patient and Encounter, I wasn’t missing details in FHIR but v2. If you look at the example you will see I’ve been following CareConnect NEWS2(/VitalSigns) Profiles.

This compatibility may be very powerful tool for interop, some applications:

  • PHR Device to EPR. You can use either v2 or FHIR. v2 being the compact form.
  • It’s not just for pathology - any system that produces obs can use this
  • Interfacing to GP Systems - not sure on how to the transport the obs (MESH or via OrderComms) but I believe UK GP systems accept HL7v2 ORU^R01?
  • Pathology/Observation query API - converting to FHIR lends itself to a simple RESTful API, one of FHIR’s raison d’etre

It does have some issues, I’ve not been able to work out how to support Blood Pressures in v2. Correctly in FHIR Blood Pressures use components see CareConnect - Blood Pressure Profile. I’ve listed systolic and diastolic as two separate observations (OBX) in HL7v2 but they should be one (clinically and in FHIR). Is this correct?

Conclusion

For health admins (esp Patient and Encounter) resources - HSCIC HL7v2 ITK specification sets out clear rules.
For clinical resources - Care Connect FHIR profiles does likewise.

Both sets of rules SHOULD apply (where possible/practical) to both HL7v2 and FHIR. The difficulties in conversion are with the rules, not in the standards.

Ways Forward?

We are missing some terminology support. I’ve not been able to say convert speciality from the v2 (NHS Data Dictionary) codesystem to a newer SNOMED based ValueSet (and vice versa). Hopefully that will come with the NHS Digital Terminology Server (currently in beta/alpha).

The FHIR Messages I generated are not following a standard, they should be based on a MessageDefinition and associated GraphDefinition. This is probably more important for the ORU^R01 Unsolicited Transmission Of Requested Information, this is probably required as FHIR Message (due to its potential application outside of Pathology which is likely to remain as a HL7v2 standard).

This is a technical post ‘missing’ a use case, for background on the use cases please see Clinical Notifications (Da Vinci Alerts)
There are use cases which needs business support, otherwise getting this interop going is answering questions which haven’t been asked.

2 Likes