Edition: Real-world problems and solutions

For an intro we suggest to brush up on some reading from our part 1:  READ HERE

Creating a puzzle

Tuning our thinking to the granularity of resources defined in FHIR wasn’t enough. Very soon we encountered our first challenge – making them work together. This is a very important notion in FHIR since the standard considers resource combination as an integral tool in representing healthcare use-cases.

Searching through extensive documentation we identified mechanisms in place providing this function:

• Reference data type + contained resources
• Infrastructural resources

Every resource in FHIR has a unique identity and as such a unique URL. Utilizing the reference data type gives us a chance to combine resources by having them refer to each other’s identities. To represent these connections we used absolute/relative URL and internal fragments. Former works with independent information, while the latter deals with contained (placed in-line) resources.

The following infrastructural resources support the grouping of content:

• Bundle
• List
• Group
• Composition

Extensibility

The true power of FHIR comes from acknowledging the resources system as an informational baseline of requirements across healthcare. Recognizing this they created a vital part of the interoperability ecosystem – extensions. Now everyone is free to append new information to existing elements. But keep in mind a set of rules exists to keep the usage of extensions safe and manageable. As we found ourselves in a situation where Redox and FHIR don’t recognize the same values in their information systems, extensions came as a natural solution to us. These are the guidelines we followed:

• search if an extension already exists in FHIR managed registry
• to create a new extension define it using a StructureDefinition resource
• use this definition in a resource via inherited extension element

Custom parameter search

At one point our client defined a new objective: add a new property to the Patient and make it searchable in accordance with FHIR standard. The new situation already started spelling out “trouble” when we stumbled upon a resource able to resolve it for us – SearchParameter.

The first part of the problem was taken care of using something we already learned about on our journey – an extension. That allowed us to take a deep dive into the complexity of FHIR search framework. SearchParameter defines a search parameter that may be used with REST to search or filter on a resource.

Once again a well-documented standard helped us win the battle.

Redox on FHIR

Many of the first queries done while researching returned R^FHIR – an effort done by Redox to add FHIR to a list of supported message formats. Although it helped to know someone already handled this translation situation, we could use only a few pointers since only two Data Models had appropriate translations and fate would have it that those were not the ones our client requested.

Big lessons learned from this effort:

• under no circumstances can we allow to lose any information
• don’t be afraid to get creative

Surprisingly – FHIR itself

FHIR is an evolving standard and it will take a few years before it shines in its brightest. Resources are still being modeled and envisioned for a palette of real-world requirements and all we can do is try and be in every dynamic picture of well-balanced health care and be ready for the world on FHIR.