Stream: conformance
Topic: Implementation Guide with globalprofile constraint
Corey Spears (Mar 25 2016 at 00:08):
I am trying to put together an Implementation Guide that had a number of Composition level Constraints (each representing a different document type). I wish to apply a common set of global constraints across all of these Compositions. In C-CDA speak, I want to apply some global header constraints for all of these document templates. I see in the Implementation Guide resource, there is a <global> element used to identify "Profiles that apply globally". I have tried to do this, but it seems these constraints do not show up in the profiles. Does the build currently support this? Is there something I specifically need to do, or are there some inheritance or other requirements I should be aware of? Here is what I am including in my Implementation Guide, just under the package element
<global>
<type value="Composition"/>
<profile>
<reference value="StructureDefinition/ccda-us-realm-header-composition"/>
</profile>
</global>
Lloyd McKenzie (Mar 25 2016 at 05:15):
They won't show up in the profiles, but they'll apply when validating occurs.
Corey Spears (Mar 25 2016 at 19:27):
Thanks for the response Lloyd. Is there any way I can verify that it works?
If the requirements don't show up in the documentation how are implementers supposed to know about them?
Lloyd McKenzie (Mar 25 2016 at 19:38):
They're declared in the implementation guide. At present, that's the only way. We could potentially look at allowing a profile to point to the ImplementationGuide that declares defaults for it - and use that information when we calculate the snapshot. It seems like a good idea to me (worthy of a change request), but it may already have been considered and rejected in some way.
Michel Rutten (Mar 29 2016 at 11:22):
@Lloyd McKenzie in theory, a profile can be referenced by many ImplementationGuides, each defining a separate global profile. If a profile would need to provide backreferences to containing IG's, then this would imply that when you reference profiles from an IG, you'd have to update those profiles to define backreferences. So an IG could no longer reference external profiles from other authors - as the IG author is not allowed to update those external profiles. That doesn't seem very helpful.
Michel Rutten (Mar 29 2016 at 11:26):
I've been thinking about this use case. Maybe, instead of referencing a global profile, tools could provide functionality to initialize a profile based on some kind of template with default values. E.g. you could create a template profile on DomainResource with some default values for common elements. Then when you create a concrete resource profile (e.g. on Patient), the tool could copy property values from the template profile to the new user profile. If we implement this as "apply defaults", then this would also allow an author to update defaults in an existing profile. Would this be a useful feature to implement?
Michel Rutten (Mar 29 2016 at 11:27):
This could even be implemented as a profile on StructureDefinition...
Lloyd McKenzie (Mar 29 2016 at 13:54):
@Michel Rutten I think it's the intention that when a profile is defined within the context of an IG, that the global profiles must always apply. A DAF Condition must always point to a DAF Patient if it's going to be a valid DAF Condition. The purpose of the IG trick is to reduce developer maintenance effort, not to give users flexibility in the use of the profile. If you want to reference a profile from a different author and assert an IG's defaults, you're effectively creating a new profile. If you declare a profile in your instance, the id of the one that inherits the IG defaults would be different than the one that didn't.
Lloyd McKenzie (Mar 29 2016 at 13:55):
It would however be nice if there was a way to easily define a new profile saying "take this base profile and apply the defaults of the profile from this IG". I don't have a sense of how complicated that would be in practice though.
Michel Rutten (Mar 29 2016 at 14:24):
@Lloyd McKenzie that makes sense, thank you for the background info.
Concerning the suggested functionality of applying default values to a (new or existing) profile, it seems feasible to implement. If we define the "default/template profile" as a StructureDefinition on (Domain)Resource, then it is possible to apply these values on any existing profile on a concrete type. In a profiling tool such as Forge, the command "apply defaults" would let the user select an existing profile on (Domain)Resource and recursively copy all the defined values to the selected profile.
If you would find this useful, then I can try and implement such a feature in Forge.
Michel Rutten (Mar 29 2016 at 15:14):
@Lloyd McKenzie I've created a new Jira issue to describe this feature request (FRG-306)
Last updated: Apr 12 2022 at 19:14 UTC
