FHIR and Version 2: the Location

So last week  Simone Heckman  (CTO of Gefyra GmbH) wrote a piece in the FHIR chat in response to a query about mapping data from an HL7 v2 message into FHIR – specifically about representing the location of a patient as shown in the PV1 segment of the message into FHIR resources. It was a great response so I asked her if I could repeat it here and she was kind enough to not only say yes, but also beef it up a bit!

Over to you Simone…

It’s all about Location, Location, Location!

Even though the design of FHIR has always acknowledged the requirement for compatibility to other Standards from the HL7 family, mapping HL7 Version 2 to FHIR (though pretty straightforward at first sight) poses some challenges, when going into detail.

PID-Segment maps to Patient resource
OBX-Segment maps to Observation resource
PV1-Segment maps to Encounter resource

so far, so obvious.

A couple of days ago, someone asked in the FHIR implementer’s chat about how to map PV1.#3 to FHIR. And the answer to that question is not as simple.

Quick explanation for all readers who are not deeply familiar with Version2:

PV1.#3 refers to the 3rd field of the Patient Visit segment (PV1), which is used to convey the current location of the patient.

The data type of this field is “PL”, a list of up to 11 subfields describing different attributes of the patient location. Here’s what it looks like:

However, what’s usually being communicated by V2 systems mostly boils down to something like this:

PV1|I||ICU_1^1.234^1.234A^CARD|…

The example message above holds information about the ward (ICU_1), the room (1.234 ) and bedplace (1.234A) the patient has been assigned to and as well as the department he’s associated with (CARD).

When translating V2-PV1 into FHIR-Encounter, suddenly there’s no longer a 1:1 relationship between segment and resource, since FHIR considers all physical locations and parts thereof as individual resources, that may have a hierarchical structure among them. Also, FHIR differentiates between physical locations (room, bed, ward) and their managing organizations (department).

So the FHIR representation of the PV1.#3 content in the example looks something like this:

It has to be noted though, that there is not always a 1:1 relationship between a ward and a department. Wards are sometimes interdisciplinarily shared between departments (especially ICUs), so the association between a case and a department has to be a direct reference, rather than an indirect one via location.

The obvious question when translating V2 to FHIR is: “Do I really need to create all of these resources and references just to convey that tiny bit of information in PV1.#3?”

Well, probably not.

It really depends on your use case. Or rather on:

“How much does your FHIR server care about Locations?“

Scenario 1: it cares very much

If the server is supporting a location aware application (e.g. patient transportation), creating Location resources from your V2 client doesn’t make much sense. Keep in mind, that all you know about the Location is its identifier ( eg “1.234A”). In this case, the locations relevant to the server, will probably have been created manually or imported from another data source to include information like building, floor, wing, accessibility and maybe even geo coordinates, and the servers job is to find the correct one to reference.

Under the assumption that the server is already aware of all the locations it serves, the challenge for the V2 mapping is to reference the proper instance. Without knowing the server assigned url (based on the resource Id) for the bed place “1.234A”, the integration engine can either search the server for a location that fits the identifier and then reference Encounter.location.location to the corresponding url or – much easier – use a conditional reference (a recent enhancement to the STU3 specification). Conditional reference moves the responsibility for searching for a matching resource and retrieving the proper url from the client to the server.

When using conditional references, instead of a url, the client provides a matching criteria, in our bedplace example: Encounter.location.location=/Encounter?identifier=1.234A

It has to be noted however, that conditional references will fail, if the server finds either more or less than one resource that matches the criteria. So this mechanism will only work if the strings provided in PV1.#3 constitute unique identifiers for the respective locations and the server uses the same identifiers as the V2 system.

Since all other information (in which room is the bedplace located, which ward does the room belong to) are already known to the server, they do not need to be included in the mapping. It will suffice to provide a reference to the lowest node in the hierarchy.

If the information of which organization is responsible for the encounter is also required by the server, it is encouraged to provide this information in the Encounter.serviceProvider reference. As noted above, wards are often not statically tied to just one department.

Scenario 2: It cares very little

If the FHIR application has no need for detailed patient location information (e.g. a lab system), the information required can often be reduced to department and ward, since these attributes are often used for filtering, statistics or billing, whereas room and bedplace are irrelevant.

Also, the server will not need to know any details about the locations other than their designation.

Such servers will probably not be prepopulated with Location resources but rather add them at runtime. In this case, any Bundle created from the V2 message should at least include the required resources for ward (Location) and department (Organization) and reference them from the Encounter resource by their locally assigned uuid.

Whether PUT or POST is the http method of choice, depends on whether the FHIR system may update or change these resources and which of the system is considered to be the “source of truth” for the location information.

If users of the FHIR system are allowed to edit Location resources and enter additional information, http PUT from the V2 system will perpetually override their changes and reset the Resources to what the V2 system sends.

In this case, to maintain the changes on the FHIR server, a conditional create would be the method of choice. With this mechanism, the FHIR server will only create a new Resource if the condition does not match. If a match is found, no update will be performed.

If the sending system however is considered the “master” of all location information, and overriding changes on the FHIR server is explicitly desired to keep the systems in sync, a conditional update is the better choice. This mechanism will update the matching resource or create a new one, if no match is found.

Of course, there is a large grayscale between scenario 1 and 2 and many use cases may be situated somewhere in between. However, FHIR has all the mechanisms required to cover that area.

And as always, the words of Grahame the Wise are true: “Complexity has to go somewhere, you can’t make it go away.”

Scenario 1 represents the classic FHIR approach, shifting the complexity of managing locations to the server side. But especially in the early days of FHIR adoption, the V2 system may represent a complex EHR system, while the FHIR server my just be a very simple FHIR implementation to deliver patient demographics to FHIR based devices or apps (like the FHIR equivalent of a DICOM worklist). The interaction between EHR and FHIR server will then presumably rather resemble scenario 2 with the complexity scale tipping to the client side. Since this particular client however is not a typical FHIR app but rather an agent acting on behalf of the EHR, the general idea of moving complexity towards the bigger fish in the pond remains intact.

Read more on

• Conditional References
• Conditional Update
• Conditional Create
• Resolving references in Bundles

(note that some of these links are to the ‘work in progress’ version of FHIR. When the STU-3 version is finalized, they will be in a similar location (sorry!) but not necessarily the same.