Stream: conformance
Topic: Matching profiles to resources
Eeva Turkka (Nov 26 2019 at 13:28):
Today we had discussions at Finnish PH SIG meeting about confomance, profiles and validation of resources and @Grahame Grieve mentioned "don't declare profile on resources" (as in put it in the meta tag of the resource).
There are multiple ways of matching a profile to a resource, but really no way to describe this in a profile. Obvious solution would be to create a mapping table in the software receiving there resouce with rules: "if there's this code, then use these profiles", but that mapping information still would need to be stored somewhere - code or properties etc.
Could there be a place to describe this in a StructureDefinition in a future version of FHIR? An extension would be a way to do this right away, but matching a resource to a profile seems for general cases to be quite a complex problem.
Kevin Mayfield (Nov 26 2019 at 14:09):
I'm seeing this from a different angle, maybe this is from v2 experience but I would have routed on resource data (not profile).
As a receiving system I may expect and mandate the resources follow XYZ profile and validate them accordingly.
Eeva Turkka (Nov 26 2019 at 14:15):
I believe this is close to the viewpoint we discussed, but the case is that there are many profiles for each resource type so there needs to be a set way to match between resources and profiles.
Grahame Grieve (Nov 26 2019 at 14:56):
I think that this would be a good thing to resolve. I suspect it needs to be expressed a search criteria - if the resource meets this search criteria, then this profile is applicable. But I wonder whether it belongs in the capability statement rather than the structure definition - is it a property of the profile itself, or of the system?
Jens Villadsen (Nov 26 2019 at 17:38):
You are entering a hornets nest here. Whether or not profiles should be stated or not and by whom has not been discussed in detail. At least I haven't heard about the resulting silver bullet
Jens Villadsen (Nov 26 2019 at 17:41):
I consider profile statements in ressources as the same as interface declarations in object oriented languages
Lloyd McKenzie (Nov 26 2019 at 17:44):
The difference is that the number of relevant interface declarations is pretty small and will generally be by intention by whoever creates the class. On the other hand, the number of potentially relevant profiles when you consider all possible consumers is extremely large - and is unknowable at the time the instance is created. You can't count on instances declaring the profiles you care about.
Jens Villadsen (Nov 26 2019 at 18:50):
The keyword here is: "potentially relevant profiles" - and the conformant profiles can be changed in meta without affecting the version of the resource. It entirely depends on the intention of what you are trying to communicate. While a Patient resource instance can be conformant to e.g. an IPS Patient profile at some point, it is probably plausible that the same resource may be conformant to a US core patient profile at some point. You don't necessarily have to state that information if that is not of importance/relevant to you.
Grahame Grieve (Nov 26 2019 at 18:57):
we don't need to buy into this argument to see that it may be useful to be able to declare: 'for resources that meet this criteria the server will enforce this profile'
Jens Villadsen (Nov 26 2019 at 19:00):
Ain't that very close to just stating a profile in meta of the resource? I get that there's a difference but what happens afterwards that criteria? Is the profile then added to the resource meta?
Grahame Grieve (Nov 26 2019 at 19:02):
it might be. I would recommend against that, but would also recommend against recommending for or against it in the spec
Jens Villadsen (Nov 26 2019 at 19:04):
recommend against recommending for or against it in the spec
In general?
Grahame Grieve (Nov 26 2019 at 19:04):
in this case, if we add something like this as an element or an extension
Jens Villadsen (Nov 26 2019 at 19:06):
I really can't see the problem here - maybe my scope or perspective on this subject is too narrow? I can't see why and how this is a problem in general to state the profile that a resource conforms to.
Grahame Grieve (Nov 26 2019 at 19:07):
I will write a blog post about it
Jens Villadsen (Nov 26 2019 at 19:53):
@Grahame Grieve let me know when it's done
Grahame Grieve (Nov 27 2019 at 12:55):
back to the question. I think it makes sense to define an extension (for now, at least) to CapabilityStatement.rest.resource like this:
"extension" : [{ "url" : "http://hl7.org/fhir/StructureDefinition/capabilitystatement-applied-profile", "extension" : [{ "url" : "criteria", "valueString" : "?code=1234-5" },{ "url" : "profile", "valueCanonical" : "http://myuri/something" }] }]
Grahame Grieve (Nov 27 2019 at 12:58):
I propose it here because I think that it's a system thing, to decide when to apply the profile. And because I think it's actually more useful to do this than CapabilityStatement.supportedProfile which we use but I don't think people conform to the full details. This is a lesser statement.
On the other hand, @Eeva Turkka proposed this as a feature of StructureDefinition, and I can see it being useful there also - this StructureDefinition is intended to apply to resources that meet the following criteria:
"extension" : [{ "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-appliesTo", "valueString" : "?code=1234-5" }]
Eeva Turkka (Nov 27 2019 at 13:42):
I guess my feeling about putting it to the profile is based on having criteria and profile existing in sync with each other and existing as an removable or addable item as is ("just add a profile and it's matching criteria and then resources matching that will pass validation"). Is there a difference between using searchparameters or a fhirpath expression for the match?
Grahame Grieve (Nov 27 2019 at 13:43):
search parameters are a call out to scalable criteria based on indexing, where as FHIRPath implies that you (a) have FHIRPath and (b) can apply it to one resource at a time.
I don't want to have to iterate all profiles running FHIRPath for each - I want some indexed list of profiles I have to test against
Rob Hausam (Dec 11 2019 at 19:09):
@Grahame Grieve I'm sure you haven't had time to get to it yet, but any update on the blog post?
Last updated: Apr 12 2022 at 19:14 UTC
