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:
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.