Stream: implementers
Topic: ONC Cert g.10: Multiple profiles in one resource
Daniel Tam (Dec 28 2021 at 06:56):
In the ONC Certification (g)(10) testing, we are seeing multiple profiles in a single resource in the Inferno tool's test data. This is causing the validation criteria on our FHIR server to fail, as we were not expecting a resource with multiple profiles.
Couple questions
1) Do we expect to see a resource tied to multiple profiles in real life? I didn't think so, as there could be conflicts between two profiles, and even if there weren't, wouldn't you just go with the more restrictive profile?
2) If this is expected in real-life, how did you program your FHIR server to validate a resource against multiple profiles?
3) If this is not expected in real-life, how did you end up passing the Inferno tests? Did you simply assume that the data in the Inferno test should be taken as-is, and did you simply shut off validation checks when running the Inferno tests?
Example from the Inferno test data -- notice that the "profile" data element contains two listings:
{
"fullUrl": "urn:uuid:76e297f9-9269-5b73-28d0-03a035bcd08c",
"resource": {
"resourceType": "Observation",
"id": "76e297f9-9269-5b73-28d0-03a035bcd08c",
"meta": {
"profile": [
"http://hl7.org/fhir/StructureDefinition/bodyheight",
"http://hl7.org/fhir/StructureDefinition/vitalsigns"
]
},
@Anna Liu
Vassil Peytchev (Dec 28 2021 at 18:34):
I think there are two independent issues here:
- Tying validation to meta.profile - while meta.profile can be used as an indicator of what profile requirements are met by the resource, it should not drive validation, or constrain the number of profiles a resource may satisfy
- Resources are expected to be valid with respect to multiple profiles, regardless of the presence of meta.profile.
Paul Church (Dec 28 2021 at 18:36):
I'm surprised that this is even a question - of course a resource could be tied to multiple profiles. If the server is feeling very helpful it could validate against a whole library of profiles and tag every one that fits.
Daniel Tam (Dec 28 2021 at 19:05):
Thanks Paul, can you tell me more about when a resource would be tied to multiple profiles in real life? How have you come across this?
Paul Church (Dec 28 2021 at 19:15):
For starters you get profiles derived from things like US Core, so resources would generally conform to both US Core and the more narrow profile. There can be multiple versions of profiles, so meta.profile might list the versions explicitly if the resource is valid across more than one.
In general I don't think of specific profiles at all. Someone could come along and author a new one tomorrow that breaks previous assumptions about what is "in the wild". It's just a tool.
John Moehrke (Dec 28 2021 at 19:44):
in addition to the point Paul makes. I have also seen institution defined profiles that are derived off of FHIR-Core Vital-Signs or US-Core profiles, in some cases with divergent expectations (not invalid, but specifically different).
Daniel Tam (Dec 28 2021 at 20:34):
I think I see my misunderstanding.
I previously believed that having two profiles listed in the "profile" data element meant that you had to satisfy all requirements of each profile simultaneously. In my example above, I believed that I had to simultaneously allow all the vital signs LOINCs in the code element, and also only allow the body weight LOINC, which sounded paradoxical to me.
Instead, it sounds like a resource should conform to any individual profiles listed in the "profile" data element. So in my above example, I could easily have an Observation resource that conformed to height, but also to the looser vital signs profile (as the height LOINC of 8302-2 is included in the list of vital signs LOINCs).
Thanks for explaining this -- this makes a lot more sense now -- and my group will adjust our validation rules based on this info.
Really appreciate the explanation. Thanks all.
-Dan
Stephen MacVicar (Dec 29 2021 at 13:35):
In the ONC Certification (g)(10) testing, we are seeing multiple profiles in a single resource in the Inferno tool's test data.
I would like to clarify that Inferno does not provide test data. Additionally, Inferno contains a separate sequence of tests for each required profile. Within one of those sequences, resources are validated against that sequence's profile, not the the profiles specified in meta.profile. If you encounter cases where Inferno seems to be validating a resource against a different profile, please let us know.
Richard Townley-O'Neill (Dec 30 2021 at 12:06):
I could create a Patient resource with no meta.profile entries that satisfied many different companies profiles of Patient. No problem. I could even list in meta.profile several of them. I would be claiming that it did satisfy every one of the listed profiles.
Lloyd McKenzie (Jan 03 2022 at 05:00):
Programming a server to validate against multiple profiles is pretty easy - take the code you use to validate against one profile and run it repeatedly, iterating for each profile. Where you run into problems is if you have decision logic that drives off profile declaration - which is why you generally shouldn't do that. Drive logic off explicit elements in the data, not what profiles the instance does or doesn't declare.
Last updated: Apr 12 2022 at 19:14 UTC
