There’s often a disconnect between business expectations around FHIR and the technical implementation. Addressing that disconnect is a book in itself, but here are a few questions I recommend you ask your technical architect.
Hopefully the answers will reassure you. If not, they should highlight work that needs to be done or discussions that need to be had.
My experience suggests the latter.
1. Are we capturing the right information in the Provenance resource?
The Provenance resource answers the question: “Who did what and when?”
Whenever a FHIR resource is created or updated a Provenance resource should be included identifying the parties responsible. This might be a HIS, a background process running overnight or a third party application feeding data into the FHIR server.
The Provenance should be created by the agent performing the update and it should accompany the resource or bundle of resources being updated.
This is where problems pop up.
Because the server or “Platform” application is not responsible for creating the Provenance, it’s often not populated as richly as it could be.
Ask your architect if these key fields are fully populated:
Provenance.agent.who
A resource reference identifying the agent or agents who are responsible for the change. There may not be a FHIR resource to link to, but at the very least an Identifier or display string should be populated with enough information to uniquely identify the source.
Provenance.target
This should contain a list of all resources created or updated. If a transaction Bundle is being sent, each resource inside that Bundle should be listed as a target, as the Bundle itself is usually transient.
Make a point of asking your architect or tech lead if the target element references a particular version of each resource. The answer may well be “No”, because the Provenance is usually created by the agent before a version ID is available.
Correctly updating each target with a version ID, and correctly creating a target for each resource inside a transaction bundle almost always requires work on the server side. This often means your devs need to write code to intercept the response after the FHIR resources have been created or updated.
Ask if they’ve done this.
If they haven’t and you’re not capturing this information, the value of the Provenance is reduced as it does not identify the precise change that was made.
More about the Provenance resource: http://hl7.org/fhir/R4/provenance.html
2. How do we keep the foundational resources in our servers up to date?
What do I mean by foundational resources?
Fixed resources that are added to your FHIR server by you and maintained by you. Examples include but are not limited to:
- ValueSet
- SearchParameter
- StructureDefinition
Over time you will make changes to ValueSets and to profiles. You’ll add new SearchParameters. These changes need to be reflected in all of your FHIR servers: Dev, Staging and each Production instance.
Ask your architect how this is managed. Pay particular attention to SearchParameters, as making changes to or creating new parameters usually involves some form of re-indexing of the underlying database. This can be VERY time consuming, often taking hours or days on well populated servers. Query results while this is ongoing can be inconsistent.
Chances are your team will have an update mechanism in place for your FHIR servers, possibly a script. But how are the results of this process verified?
Does someone eyeball the FHIR server to check that each update happened correctly and that each new SearchParameter is working, or is there an automated verification step?
This whole area is prone to human error and has real potential for going wrong and leading to downtime for apps using Production servers.
3. Does every consumer understand the OperationOutcome resources that might be returned?
Many different apps may consume data from your FHIR server. Chances are your team is not responsible for all or any of these apps.
Ask if there is clear and unambiguous documentation that tells consuming applications which error, warning and informational messages are produced via OperationOutcomes.
Different apps will respond to OperationOutcome resources differently, and it’s crucial that every app knows what to expect here from your server.
Example: If an invalid or misspelled search parameter is passed in a query, is it clear to the consumer what will happen?
Don’t assume they’ve all read the FHIR documentation in detail and know which request header to set to enforce particular query behaviours. For many consuming applications your FHIR server may be only one of many data sources.
You need to be precise and detailed in explaining and documenting what each OperationOutcome means and how significant it is. You need to explain in detail what the presence of a particular OperationOutcome means for a query response, especially Informational messages.
If you’re not, you will find consuming applications using or displaying data they should not be using or displaying.
More about OperationOutcome: http://hl7.org/fhir/R4/operationoutcome.html
---
Download my “FHIR Architecture Decisions” book
FHIR Weekly
Join 1,100+ business and technical leaders.