Stream: implementers
Topic: Profile conformance
Sadiq Saleh (Jan 24 2017 at 20:35):
I read the page on conformance for profiles and had two question regarding this.
1) For a profile that only defines how two existing fields (A and B) are to be used, I add an extension (C). Does this resource with A, B, and C still conform to the parent resource.
2) If I create a profile on DomainResource with a new attribute that does not exist in other resources, can I pass this profile tag to any other resource and expect it to conform to both it's parent resource and to my profile.
E.g. If I create a DomainResource to include a computer-timeStamp attribute, can I add this to any base resource or profile and expect it to conform to both the parent resource/profile and my own defined profile?
Lloyd McKenzie (Jan 24 2017 at 21:27):
1. So long as the parent profile doesn't constrain out the generic extension element, then the child profile complies. When we profile, we don't really "add" extensions - extensions are already explicitly allowed in all the locations where they can possibly appear. Instead, we're just constraining the extension element by documenting how a particular extension should appear - by constraining cardinality, mustSupport, etc. The only time you'll run into a problem is if a parent profile decides to "close" the slicing on extension or constrain it out entirely. If that happens, then child profiles can't allow the use of additional extensions.
Lloyd McKenzie (Jan 24 2017 at 21:27):
2. You can't define new attributes
Lloyd McKenzie (Jan 24 2017 at 21:28):
(The set of permitted elements in a resource is fixed as part of resource definition. The easiest way to think about this is "there's one schema throughout the world for a given version of FHIR.
Sadiq Saleh (Jan 24 2017 at 22:01):
Thank you for your prompt reply @Lloyd McKenzie
I don't think I phrased my second question properly. What I meant was that if I create an extension on a DomainResource, can all Resources that inherit from that DomainResource also use that extension?
Lloyd McKenzie (Jan 24 2017 at 22:13):
So the context would be "DomainResource"? In theory, yes that should work for all resources. In practice, I'm not sure if the code for the existing validators is that smart. I'm not sure we've had a usecase where anyone has wanted that. What sort of extension were you thinking of?
Sadiq Saleh (Jan 24 2017 at 23:56):
Our particular usecase involves an extension to allow us to assign an ID to track the location of a resource in a guideline. Thus we need an extension which works with any type of resource.
Lloyd McKenzie (Jan 25 2017 at 00:26):
The "location" of a resource? How is that distinct from its URL?
Sadiq Saleh (Jan 25 2017 at 14:37):
As far as I understood, the URL is to identify the type of resource. Our use is to tag on a common set of internal information to any resource before sharing data with a consuming system.
Based on your response that this should be acceptable in theory, I would like to confirm that setting
context: "DomainResource"
in the extension should allow the extension to be used by all resources. And that this does not break the FHIR specs.
Lloyd McKenzie (Jan 26 2017 at 01:41):
@Sadiq Saleh The URL identifies the specific instance of the resource - and the network location at which the resource can be queried, updated or otherwise manipulated. As to whether defining an extension on DomainResource will work or not, you'll have to try it. If I had to guess, I'd bet on it not working - as I doubt it's ever been tested. However, we may be surprised. If it doesn't work, feel free to submit a change request to fix the validator as it seems like something that should be legal.
Sadiq Saleh (Jan 26 2017 at 14:34):
Thanks for taking the time to reply @Lloyd McKenzie. I will try building and testing as you suggested, and put in a change requrest if it does not work.
I don't think I understand the full use of the URL, and will spend some more time looking into that. Thanks for the feedback.
Last updated: Apr 12 2022 at 19:14 UTC
