FHIR SDKs hide things from us.
Not intentionally. There’s no malicious agent at work here.
But SDKs are built in such a way that they mask the underlying data and how that data is accessed. Couple this with a lack of FHIR experience from devs and problems pop up.
An SDK is a Software Development Kit whose purpose is to wrap the functionality of a particular domain or area into one neat code library that devs at different organizations can use off-the-shelf.
FHIR SDKs manage access to FHIR APIs and often come with pre-defined objects for all FHIR resources and elements.
They make it easy for those without FHIR knowledge to write code that uses FHIR.
Your devs are all using a FHIR SDK.
So where’s the problem?
They make FHIR look easy when it’s not always easy. They make it possible to miss things without realizing. They can lead to bad code and to bugs that aren’t found until data starts flowing into production servers.
Here’s an example.
A new dev builds a query using an SDK. He sends the request to the FHIR server and gets a bundle of resources back — two lines of code thanks to the SDK.
The bundle contains a list of perfectly formed MedicationRequests and various included resources.
The dev writes code to extract the MedicationRequests from the bundle so that he can populate a screen.
He’s confident that he hasn’t missed anything because the SDK didn’t throw an exception and all the resources are populated.
What did he miss?
- An OperationOutcome telling him the result set was truncated
- An unanticipated resource type in included results for MedicationRequest.performer
- A Modifier element that he didn’t know to look for
The end result of the above is that he populates a screen with MedicationRequests that are incomplete or incorrect.
He checks in his code and marks the story as complete.
The SDK wasn’t the problem here. The problem was that an inexperienced dev with almost zero knowledge of FHIR got this far without realizing how many mistakes he’d made.
If he’s lucky, these errors would be caught by a robust QA process. If not, they turn up in production.
The combination of FHIR inexperience with amazingly efficient SDKs makes this a common occurrence. I’ve seen it first hand many times.
The fix?
Your devs need to understand FHIR. No shortcuts.
---