Stream: implementers
Topic: REST request and specifying a particular profile
Joe Paquette (Aug 16 2019 at 12:08):
Given a REST endpoint for Observation where numerous profiles exist, what are the expected ways for the various interactions to specify the desired profile for the interaction?
I know the CapabilityStatement provides the 0..* supportedProfiles data element to document the supported profiles. I know the Meta.profile can be used in returned content to assert conformance to a specific profile. I know that the _profile search parameter can be used to search for resources that are tagged as to conforming to a specifc profile.
Given a FHIR server that is a facade for a datastore (legacy EHR, legacy database, etc.) where data is NOT stored as FHIR objects, and where data for "vital signs" data is stored in different tables than "bmi" data. What are the recommended or best practices for handling these different profiles?
I understand that we should use Meta.profile in the response and that for search that we can use _profile search parameter in the request.
How should the read/update/patch/create interactions specify the desired/intended profile (e.g. observation-vitalsigns vs observation-bmi) for data validation purposes and for the endpoint to make the correct decisions about which tables to use?
Grahame Grieve (Aug 16 2019 at 13:20):
generally, you should do this sort of thing by code, rather than by profile
Grahame Grieve (Aug 16 2019 at 13:21):
profiles tend to be rather exclusive and not re-usable. So we recommend that you use them as little as possible
Joe Paquette (Aug 16 2019 at 13:40):
We know we need to handle this in code, but US Core has 2 DiagnosticReport profiles and 3 Observation profiles for which we must be conformant. We're trying to understand how a requester can communicate their intent for the data they are providing/requesting, for example, is for "Pediatric Weight for Height" vs "Smoking Status" observations? In this particular example, we can probably discern which is which by looking at the provided code data elements, but we cannot be sure the provided codes are valid or uniquely identify which profile to use for validation purposes. And. we're not sure this approach can be used universally for all resources based on various IGs/Profiles against which we must be conformant.
Grahame Grieve (Aug 16 2019 at 13:44):
well, you get to circular logic this way. if the client claims that it's conforming to a profile, you can check that. If it doesn't... then you don't validate it. So what did you achieve?
Grahame Grieve (Aug 16 2019 at 13:45):
if you have an actually functional server, then it knows what it needs for the different observations - by code - and can enforce appropriately
Joe Paquette (Aug 16 2019 at 14:21):
I understand that for Observation, we can discern by code. For DiagnosticReport, we can discern by category.
For the general case, we were wondering if there was a "best practices" way for requesters to indicate intent about the data they are providing when profiles are required for conformance.
It appears the answer is that there is not a "best practices" way. Instead, we will need to look at all supported profiles for a specific resource to figure out how to distinguish among them.
Grahame Grieve (Aug 16 2019 at 19:53):
well, there are two definite best practices I can state:
- "intent" should never be derived only from the profile
- hanging processing off a profile makes for easy implementation in the short term but fragile implementation in the long term, and you're trading between those
Rob Hausam (Aug 16 2019 at 21:36):
@Joe Paquette I'm not sure why you're thinking of determining this by code for Observation and category for DiagnosticReport? Both elements are present and function essentially the same in both resources - code provides the specific observation or report, and I would think you would want to use code for both.
Last updated: Apr 12 2022 at 19:14 UTC
