Question: Extending systems to deal with non-#FHIR type content
Sep 8, 2017Question
What has your experience been with developers, developing on a FHIR model that requires FHIR resources – but also has a need for non-standard FHIR data (something like supply chain data or Blockchain external hashed data). Is the recommendation to shoe horn this into extensions or have data models that live side-by-side with FHIR?
Answer
There’s no single answer to this question, because it depends on the other kind of data. Generally, there’s 3 approaches I’ve seen:
- Use extensions in existing resources (particularly Basic). This approach is only good while the extensions are pretty narrow and limited, and closely related to the existing FHIR functionality
- Use some other content model, and figure out how the functionality links. This approach is good where there is another content model. For example, in my server, I useSCIMfor managing the user accounts. I use the SCIM content to link a user account to a FHIR resource like “Patient” so that I know which patient the user represents (if any) and I refer to the SCIM user identity in AuditEvent resources (as a URL)
- Make up your own content but follow the FHIR patterns - effectively, custom FHIR resources. Use extensions to reference them. This approach is good where you have quite a bit of content/functionality, but there’s no external standard to follow
Which is best depends on what you’re doing.
A note about the custom resources idea: this is legal - you can do whatever you want with the names the FHIR doesn’t define. e.g. [base]/User. And if you choose to put something there, that happens to look a bit like a FHIR resource.. that’s still whatever you want. But things like ‘can I describe it from the CapabilityStatement’ and ‘can I search into the space’ are not technically legal, and there’s always a risk that HL7 will use the name in the next version of FHIR, making your solution locked in to being non-conformant. We’ve investigated making some policy around these questions to make custom resources manageable, but we’ve never managed to get the energy to push agreements over the line.