Perception and reality are at odds when it comes to FHIR profiles.
Perception — Profiles are an advanced FHIR feature. They’re difficult to understand and difficult to use.
Reality — Profiles make it easier to work with FHIR resources. They make data stored in FHIR servers consistent.
FHIR is permissive. Very few elements are mandatory and there are many different ways to present the same data.
This is often problematic. It makes it difficult for consuming applications to know what they’re getting. And it makes it difficult for apps creating FHIR data to know how to populate that data.
Which is where profiles come in.
They restrict a resource in a good way
- Optional elements are made mandatory
- Cardinality (how many of something) can be is tightened
- Elements are bound to smaller and more relevant ValueSets
- Complicated data structures are simplified with clearly defined “slices”
- The importance of data elements is signaled through “must support” flags
They expand a resource through extensions
- By defining which extensions must be used
- By defining an extension’s contents
- By defining where an extension must go in a resource
They make validating resources easy
- Incoming resources must conform to the profile
- Every consumer knows what they’re getting
So why are profiles perceived as difficult or advanced?
Creating them can be difficult — especially the complicated parts such as “slicing” and ValueSet definitions. But unless you’re building an Implementation Guide, you won’t be creating profiles.
Using them is not difficult.
---
Download my “FHIR Architecture Decisions” book
FHIR Weekly
Join 1,100+ business and technical leaders.