Replies: 5 comments 18 replies
-
I would also specifically call out a couple other things that FHIR profiles commonly do using examples from the US Core Blood Pressure profile on
Based on a cursory search of the Medplum codebase, we'll need to implement validation of both of those for profiles to function correctly. |
Beta Was this translation helpful? Give feedback.
-
We have a pretty decent starting point: https://github.com/medplum/medplum/blob/main/packages/core/src/schema.ts Gaps:
I propose we reject with a 400 and
I don't know if the spec mandates anything here? The two options I would consider:
Yes, good callout, US Core being an obvious case. Similar to the Terminology Service discussion, I assume that we will need to support a "view" that combines multiple Medplum
(These are gut instinct guesses, need to measure) The validation itself shouldn't be too bad, depending on the complexity of the FHIRPath expressions. The more expensive part will be constantly loading the I think? Need to measure. We can optimize as necessary. The user benefits definitely justify some degree of performance hit.
Yes, I think this is pretty critical. Also extremely powerful for helping customers to create the configuration they want. It will be so much better than "create resource, check with a bot, and clean up post facto". Instead it's just 400, nothing created, db stays clean.
Agree. Our
👍 |
Beta Was this translation helpful? Give feedback.
-
I think I agree with this - there's a lot of data hygiene that can be taken care of at this level. This brings up a few more considerations though:
|
Beta Was this translation helpful? Give feedback.
-
Another question is how we would we want to deal with validating references? For example, a USCore MedicationRequest refers to a USCore Patient. So in a sense, a reference to a vanilla When a |
Beta Was this translation helpful? Give feedback.
-
I put together a more detailed design document (below) for how we might want to approach building out support for profile validation, and would love any feedback that folks have on it! https://gist.github.com/mattwiller/7e39f09561f5b6771ca3aac98a411ec8 |
Beta Was this translation helpful? Give feedback.
-
FHIR Profiles
In this post, I'll describe what FHIR profiles are, how I think they could be useful for Medplum, and what I see as the high level work needing to be done.
What are profiles?
FHIR profiles are essentially a way of specializing a FHIR resource into a "subclass." Specifically they:
How are implemented?
The data object that FHIR uses to define the schemas of resources is called a
StructureDefinition
, which is itself a FHIR resource (🤯). The profiles-resources.json file contains the definitions for the FHIR base resources. Medplum Resources are also defined using theseStructureDefinitions.
A profile is defined as a
StructureDefinition
that extends a base resource, using thebaseDefinition
field. Profiles can also.The cool thing is that Medplum generates all of our DB schemas and TS type definitions directly from the
StructureDefinition
resources. This opens up some interesting technical possibilities down the road.How are profiles used?
Each resource has a
meta.profile
that describes what profiles this resource claims to conform to. It's up to the server implementation to decide how to handle those claims.Most FHIR implementation guides publish a set of profiles to enforce the data model they describe.
name
onPatient
)PlanDefinition
, that enforces the use of LOIINCOrganization
to represent an insurance network.Opportunities for Medplum
The main opportunities I see for Medplum are:
Simplify user onboarding: Right now users define their data model using our documentation, FHIR documentation, and consultation with the medplum community to make sure they're modeling their data properly in FHIR. I envision a future in which our best practices can be encoded as profiles, that we can share with users when they start a Medplum deployment. The server could then enforce these best-practices programatically. I see the onboarding flow as something like:
Streamline integrations: We can define profiles to ensure all the relevant fields are populated when sending data to a 3rd party API. E.g. a CandidHealthEncounter profile.
Implementation Notes
I'm probably missing a bunch of stuff here
Low hanging fruits
server
package, we just need to move it and clean it up.Open Questions
Nice to haves, but not required
StructureDefinitions
. Then, we can also create the same form of documentation for any custom profiles created for a specific use case.Reference
https://www.devdays.com/wp-content/uploads/2021/12/DD21US_20210608_Mirjam_Baltus_Introduction_to_Profiling.pdf
https://hl7.org/fhir/profiling.html
Beta Was this translation helpful? Give feedback.
All reactions