By: Liron Shahar-Atia

The following article is about to give you a peek into how to handle the representation of a single FHIR resource that is fed data from multiple legacy systems at the design stage. 

***

Ok, you are all set to go.

Your organization, in collaboration with our HL7® FHIR® expert, has decided on a FHIR® resource to implement next as part of a chosen use case or project to implement. We have reviewed together the influences and consequences of their choices (like maturity of the data, the scope of the project etc.) and agreed on which resource is the most appropriate to take to the next level 

A new FHIR resource is on the way!

Deciding on which data to implement by FHIR is a great start, but now we need to know which systems are involved.

Most health organizations use several legacy systems for the data required for each FHIR resource, and often these systems are stand-alone and are not connected to others.

At this point our analytical skills are required!

First, we need to find all the key people holding the appropriate knowledge which can assist us to understand the data flow, from a business and of a technical aspect.

We can think of this step as an interview and try to get all the information regarding the resource. Even if at first, not all the information looks relevant – we might find it useful later on.
The goal is to concentrate all the data for further analysis, which can educate us towards decisions on how the source data will be incorporated into the single FHIR resource.

For each system which stores some or all of the data elements of our FHIR resource we must ask the following:

• What is the source of the data?
• Where is the data stored? DB, flat files, XML..?

• What is the purpose of the data managed in the specific system?
• What is the scope of the data regarding the specific resource?
• How often is the data synchronized?
• Which coding systems are used? Internal or global?
• What is the process for updating and deleting data?

• Are there any rules or logic involved?
• What is the relationship between the different systems?

Another possible idea is to represent the relationship between all the legacy systems by a Venn diagram and to emphasize what percent of the data is covered by more than one system.

For example, imagine we have the following 4 legacy systems, as shown in the diagram below:

Systems A and C each contain separate data. System D data exists in its entirety within system C. System B contains data that also exists in systems A and C. Each system holds its own copy of the data, and each data point might be stored a little differently. The challenge with such legacy systems is – how do retrieve all the required data from the different systems. For example – if both B and C contain the same datum we require (meaning we would have data duplications), which one do we choose? Do we set clear rules for such cases or assess them case by case?

Another important consideration is understanding exactly what data is stored in each system, its formats and restrictions. This can be particularly important for making decisions on which system each datum is taken from.

Even after we have established the relationships between the different systems and created out Venn diagram, we must be extremely careful not to just assume that these relationships are always correct. Tread with caution.

There are more issues to consider, like what is the quality of the data, does it contain 100% of the cases we are trying to retrieve, how to identify the multiple records and what should be done with them (for example, should we combine them or prefer one of the systems over the other?)

In case the organization decides on multiple IT systems, the analysis and specification will be performed for each of them with the aim of organizing and mapping the data in an appropriate fashion.

Once we have established all the above, and characterized each system, we can now move forward.

Are you ready? We are. Let’s do it!

Moving forward, these are the considerations that will enable us to define and implement our FHIR resource:

1. Mapping the identifiers and making sure they correspond correctly to the identifiers found in the legacy source. This can be very tricky as they do not always align as 1 to 1 identifiers, for all sorts of possible reasons.
2. Defining search parameters – it I imperative to carefully consider and coordinate with our business partners to make sure that searches search parameters are compatible of business logic and rules.
3. Particular care must be afforded to making sure that the entire resource-update processes are clearly mapped out and properly handled. This is especially important in case there are several data sources that might lead to an update.
4. An important rule in general – it is imperative to keep track and document the entire design process for future reference, for traceability and operational issues.

A discussion of all these issues, along with a detailed example – coming soon to our “resources” section, so don’t forget to come back from time to time!

We at Outburn will be delighted to answer any questions regarding this or any other FHIR issue.