3 ms·

Very cool and impressive work! One question I have is how you think about handling custom data fields. FHIR has the `extension` attribute on all DomainResources

Very cool and impressive work! One question I have is how you think about handling custom data fields. FHIR has the `extension` attribute on all DomainResources that allows you to store any non-standard information, but building code and value sets to properly map this data can be cumbersome and time-consuming. Do you have any happier/easier paths for extending the core data model to handle custom data?

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 ago
  Thanks 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 ago
  Your 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 ago
    Thanks. 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]
xcskier56 4y ago
Another question that I can't quite figure out from your docs is if your bots functionality works with non-AWS hosting?
- brown 4y ago
  At present, Bots are AWS-only. We have an active enterprise customer who is exploring porting Bots to Google Cloud Functions. Azure Functions are on the longer term roadmap too.

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 ago
Thanks 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 ago
Your 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 ago
  Thanks. 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]

xcskier56 4y ago

Another question that I can't quite figure out from your docs is if your bots functionality works with non-AWS hosting?

brown 4y ago
At present, Bots are AWS-only. We have an active enterprise customer who is exploring porting Bots to Google Cloud Functions. Azure Functions are on the longer term roadmap too.