4 ms·
Good question. Custom data is tricky. The first thing we always try to do is dig deep into the FHIR spec to see if the data is truly custom, or if there is an
by brown 4y ago
Good question. Custom data is tricky. The first thing we always try to do is dig deep into the FHIR spec to see if the data is truly custom, or if there is an existing FHIR representation that will actually work. In many cases, there are good options, and it's nice to work within the spec.
If not, then falling back to extensions is the next logical step. FHIR extensions can be clunky to work with. Our client libraries provide a bunch of helper utilities to make it easier.
In extreme cases, we have created custom FHIR resources via custom StructureDefinition and SearchParameter resources to represent completely unique data elements (examples: https://github.com/medplum/medplum/blob/main/packages/definitions/dist/fhir/r4/profiles-medplum.json https://github.com/medplum/medplum/blob/main/packages/defini...).
- xcskier56 4y agoThanks for the thoughts! I agree that FHIR extensions are clunky and very commonly the data you're trying to store can be represented by a FHIR resource. Extensions are clunky, but for some of our projects have been the only way to store a couple pieces of data that we need.
- xcskier56 4y agoYour use of custom StructureDefinitions for the very non-FHIR models that you need is impressive. I don't think I've seen such a clear example out there of someone extending FHIR to this degree. Well done!
- brown 4y agoThanks. You might be the first person outside of the Medplum team to look at that file, happy to hear a positive review.
- deleted 4y ago[deleted]