Exploring the Use of HL7 FHIR

[jeremi]

I wanted to bring up HL7 FHIR for discussion and gather some feedback. Although I've never used it myself, I've noticed it being utilized in various projects, including OpenCRVS ( @euanmillar ).

For those who may not be familiar, HL7 FHIR (Fast Healthcare Interoperability Resources) is a standard for exchanging healthcare information electronically. It has been widely adopted by numerous healthcare organizations and systems. While it was primarily designed for healthcare data, its flexible nature allows for potential adaptation to other sectors, such as social protection and G2P payments.

I'm curious to know if anyone has had experience with HL7 FHIR. If so, what are your thoughts on its applicability to our use case? Additionally, are there any potential challenges or limitations in using HL7 FHIR for our needs?

[euanmillar]

100% @jeremi !

I'm a huge advocate for FHIR and our contributions to G2PConnect will revolve around FHIR compatible payloads. FHIR is globally adopted by governments (e.g. U.S., India - p21 "FHIR Release 4 (in a highly condensed form), SNOMED CT and LOINC are among the standards recommended.", U.K, Australia) and already adopted by all major IT companies (Apple, Microsoft, Google, Amazon). This is why we adopted FHIR as our standard in OpenCRVS to seamlessly connect civil registration services to healthcare locations where births and deaths occur.

FHIR is the installed standard on thousands of healthcare systems cross-cutting industries and functional verticals. FHIR has a well established API and allows healthcare to have de-duplicating "Master Patient Indexes", "Client Registries", infinite identifiers to link and de-duplicate services. FHIR supports interoperability across disciplines and functionalities such as pharmaceuticals, chronic and acute conditions in all healthcare settings, insurance, consent, task management, audit trail, jurisdictional structure, physical facilities and devices, payments and payment reconciliation (useful for social protection right?!).

One of the best things about FHIR is that it is extensible for your use case. We have used FHIR extensions for some minor civil registration and vital statistical demographics. We cant wait to document our full extensions.

You name it, FHIR has a documented standard for it.

[jeremi]

Thank you. Do you have examples of its usage beyond the Healthcare industry (apart from OpenCRVS, of course)?
Also, in regards to deduplication, does the platform offer any implementation or solely provide APIs?

[vvujjini]

@jeremi @euanmillar Current proposed G2P Connect specs is aligned with Open ID which is another popular standard to define personal information. Open ID extension also covers other record types like birth, death, union etc., and same have be enumerated here.

We should also look into this as well and take an informed call.

[euanmillar]

@jeremi regarding de-dupe, that is done in implementation. As each FHIR resource has an identifiers array, potential duplicate ids can be stored in a related extension to show where duplicates may exist. If they are deemed in future not to be duplicates for any reason (manual or automated), the ids can be removed.

[euanmillar]

@jeremi @vvujjini one of the problems I came across today was mapping OpenID address to a FHIR address.

As you are aware, OpenID does not determine an address standard, making exchanging address line break logic bespoke for every integrating system:

FHIR offers a line break approach for address structure as there is a "line" array.

Indexes could then be pre-agreed between systems. There are also more properties for locality levels that you can use.

In OpenCRVS we have decided that certain indexes in the "line" array could be reserved for up to 5 levels supporting complex hierarchies.

We reserve other indexes to support international addresses (hierarchy 2) with local addresses (hierarchy 1) in the same model.

Each index can point to a FHIR Location ID that offers many more flexible properties as you can see here. You can use descriptions for locations or even What3Words if you wanted to, if the person lives in an unstandardised, rural location.

In FHIR Location, we can multiple identifiers for the same location such as geocodes, statistical IDs, Humdata ids etc:

I totally understand why OpenID has been adopted currently. But there are other ways to share location demographics that give us more control.

[euanmillar]

I would prefer it if "line" was an array of objects, as hardcoding indexes is an ugly solution

[vvujjini]

@euanmillar

As you are aware, OpenID does not determine an address standard, making exchanging address line break logic bespoke for every integrating system...

When it comes to integration between systems adopting different standards there is need for handshake to fit in each attribute. Both OpenId and FHIR specs have mechanisms to pack multiple address lines as "\r\n" and "array of lines" respectively.

G2P Connect spec scope is to enable integrations with foundational ID, other functional registries and all the other components in the blueprint. Additionally, like any specification G2P Connect spec should also allow additional capabilities for implementing systems through extensions.

As you rightly called out, FHIR has additional capability to differentiate address types and additional locations types. If enhancing the openId address attribute with additional optional fields helps, can you take a stab at it and propose? Are there another attributes like birth, death etc., records that needs a review?

@gsasikumar and others your views please.

[euanmillar]

I dont think that separating address lines using /n/r is n effective approach to be honest, as different systems may order the lines in different ways.

Additionally you cannot ensure databases can be searched effectively with text strings to find exact matches even if you break apart the lines. As we have seen in the past, typos exist in the text representations of places between systems thus stopping us from finding a standardised match.

Instead, I think that we should share universal geocode identifiers, such as ADMPCodes you find in Humdata tabular data for administrative structures. What do you think @jeremi ?

If line was an actual array of objects with the following format, then standardisation and identifiers could be guaranteed. In my opinion, this would be an improvement on FHIR's Address line array that we could incorporate into OpenID.

"streetAddress": [{
    "text": "Adjumani",
    "use": "ADDRESS_LINE_2", // e.g. ADDRESS_LINE_1, HOUSE_NUMBER, DESCRIPTION
    "identifier": "UG3064" // Humdata geocode if applicable - could be also identifier(s) array so any system can use multiple ids as well as a humdata standard: [{ "use": "HUMDATA", "value", "UG3064"}, { "use": "OPENCRVS", "value", "af552e50-f628-11ed-b67e-0242ac120002"}]
}]

I think we could incorporate some of the other properties in FHIR Location for better identification, descriptions and geocoding. Similar props exist in this schema, which I know @gsasikumar is also investigating. I will propose this in a P.R.