The difference between a great FHIR developer and one who just gets by is how comfortable they are with raw FHIR data.
FHIR SDKs (software development kits) exist for most common programming languages. They make it possible — and easy — to create or update FHIR resources without ever looking at the data in its true form.
This is great for productivity, but not so great for understanding the data.
Without looking at the raw data it’s easy to miss things you were not expecting.
- Extensions in unusual places
- Contained resources
- Reference URLs that point to different servers
- Multiple codings in a CodebleConcept
- Unanticipated data types (Period / DateTime)
- Populated elements that are not in a profile
- “entered-in-error” statuses
- Identifiers as references
- Multiple elements when you expected only one
Without a proper understanding of the data, manipulating or debugging that data becomes next to impossible.
I’ve worked with developers who don’t understand the internal resource connections inside a FHIR transaction Bundle. This after many months or years working on FHIR projects.
I’ve worked with developers who struggle to create complex test data scripts. All because they can’t create FHIR resources outside of an SDK.
All new FHIR developers should start by creating and updating FHIR resources using Postman. They should become familiar with what the data really looks like, and with how resources connect to each other.
Here’s the JSON data for an Encounter resource in FHIR. All FHIR developers should be able to look at this and understand it.
https://server.fire.ly/Encounter/7bb62b14-21b8-47cb-92ca-b0da134e78f7?_format=json
---