If you Google FHIR validation you’ll find a lot of articles and posts about the $validate operation, others that touch on profile validation, and others still talking about the various open source tools that help with validation.
No one talks about custom business validation.
This is an extra level of deep validation unique to a particular use case. Just about every FHIR project of any size and maturity ends up implementing custom business validation in one form or another.
What do I mean by custom business validation?
Let’s say a transaction Bundle comes in containing a set of FHIR resources. All the required elements are populated and all the codes match up to expected values in ValueSets. The bundle will pass basic FHIR and profile validation and the server will happily accept the request.
But the data itself might still be invalid or problematic in some way. Not from a FHIR perspective but from a business perspective.
Let me share a couple of examples.
Example 1
A data provider sends a create request for a new Patient. It contains the patient name, address, date of birth and a couple of identifiers — one of which is a brand new MRN created by the source. The core system needs to be sure the request will not create a duplicate patient.
The FHIR sever doesn’t care. The request will be actioned regardless of whether or not a similar patient already exists with the same date of birth, name and social security number.
Custom business validation is required here to prevent a duplicate being created.
Example 2
A similar create request is received by the FHIR server for a MedicationRequest resource. A downstream application wants an important prescription to be filled immediately. The patient is on her way.
Sounds straight forwards. Why would we need custom business validation here?
If it’s that important and time sensitive, the business might want an extra validation step to be sure that the medication is in stock and available before allowing the request to be accepted and completed.
Again, only custom business validation can do this. The FHIR server doesn’t care if the medication is in stock.
How is this level of validation achieved?
By now you may have realized that we’ve moved beyond the abilities of a “run of the mill” FHIR server. The FHIR sever can validate against the FHIR standard and against any profiles specified in the request. But it doesn’t care or know about our special business requirements.
We need an ability to perform an extra layer of business logic or rules on a request body before it reaches the FHIR server.
For this, we need to build a proxy or “wrapper” around the server. We need to intercept the incoming request, direct it down a particular channel depending on the contents of the request and in that channel perform our custom business logic.
Here’s an example of what we might do for Example 1, the potential duplicate patient.
- Identify the request as a create request for a new Patient
- Extract the important resource elements (name, DOB, identifiers)
- Make a call to a patient $match operation if we have one
- Or make a call to an external service that looks for duplicate patients
Depending on what comes back from our checks, we either allow the create request on into the FHIR server or we stop the request in its tracks and return an OperationOutcome with an error message telling the data provider the patient already exists.
We could also decide to return the existing patient if one were found — but that’s a business decision.
Example 2 might be treated a little differently.
- Extract the Medication and dosage from the incoming request
- Call a “MedicationWarehouse” service we maintain to check availability
- Return an OperationOutcome if the Medication is unavailable
The above examples illustrate the level of validation that can be carried out when a FHIR request body is intercepted before it reaches the FHIR server. The ability to do this is crucial to almost all real-world projects where incoming create or update requests come from a variety of sources.
You cannot depend on your data providers performing business validation for you. It’s your FHIR server and ultimately your responsibility to ensure its integrity.
---