Stream: implementers
Topic: Validating profiles
Brian Reinhold (Oct 13 2017 at 10:06):
When making a profile you create a StructureDefinition specifying restrictions on a given resource type. In the resource one is uploading that is to follow this profile, I assume you set the ResourceX.meta.profile element to the URL where the profile StructureDefinition is located.
Okay. If that is true, how are the StructureDefinition profile URL-related elements populated? I assume that the StructureDefinition.meta.profile element, if specified, means that the ResourceX.meta.profile element must have that value. Then the StructureDefinition.url element is where the profile can be found. So it seems to me that
StructureDefinition.meta.profile
StructureDefinition.url
ResoruceX.meta.profile
all have the same URL. Is this true? If not, can someone explain how I
1. specify in the profile that the resource meta.profile element shall be populated with the URL of the profile the resource claims to support
2. how to populate the StructureDefinition.url element
Once all these URLs are squared away, how does one register the URL so one can do some testing? So far I have almost everything done in my profiles but I have no valid URL for their homes, and all tests I try to do fail immediately because the URLs are placeholders and resolve to nothing.
Part of the problem is that I didn't know Forge hid the common elements so I was filling in the wrong meta data fields in an attempt to specify the Resource's metadata fields.
Thanks!
Lloyd McKenzie (Oct 13 2017 at 15:50):
StructureDefinition.meta.profile would be a profile that the StructureDefinition adheres to - i.e. a profile on how you create profiles - e.g. requiring that certain types of mappings be present or requiring examples or something. It has nothing to do with the URL of the profile
Lloyd McKenzie (Oct 13 2017 at 15:50):
StructureDefinition.url would be what you quote in ResourceX.meta.profile
Michel Rutten (Oct 16 2017 at 10:11):
Hi @Brian Reinhold, note that resource references to profiles are based on canonical urls. How to resolve these references depends on the context. For example, Simplifier will try to find the referenced profiles within your project. A typical FHIR server will try to resolve the references from it's internal database.
Generally, canonical urls are unique resource identifiers, but not always actual resource locators.
Brian Reinhold (Oct 16 2017 at 10:58):
Hi @Michel Rutten
Then how should I populate the meta.profile element? I am requiring that uploaders populate this element indicating the profile they support. I expected this URL to be fixed and to be used by all implementers. THis would also be a way for consumers to identify the resource as belong to a profile.
Maybe I am not understanding your response??
Michel Rutten (Oct 16 2017 at 11:34):
A Resource can claim conformance to a profile by including the canonical url of that profile in the meta.profile element. Usually, this would be handled by the client software (i.e. I don't expect end users to manually specify specific profile tags).
Note that such a tag only represents a claim. A server can verify the claim by resolving the referenced profile and validating the instance. If validation fails, the server could reject the uploaded resource.
Michel Rutten (Oct 16 2017 at 11:42):
A FHIR server can also advertise profile constraints via the CapabilityStatement. For example, a certain FHIR server could only accept Patient resources that conform to DAF Patient. In that case, profile tags on uploaded Patient resource instances would be irrelevant/ignored, as the server would always validate against the DAF Patient profile.
Michel Rutten (Oct 16 2017 at 11:46):
So you should think about your specific use case and what it would mean to define mandatory profile tags on uploaded instances. Maybe this requirement isn't actually necessary?
Lloyd McKenzie (Oct 17 2017 at 00:00):
In most cases, resource instances won't declare any profiles at all - which means they're not claiming conformance to anything other than the underlying FHIR spec. In some cases, a resource instance might claim conformance to numerous profiles. I certainly wouldn't expect meta.profile to be populated with anything in particular unless you have a specific agreement with client systems.
Brian Reinhold (Oct 17 2017 at 10:15):
My intent for including the profile when creating and uploading the resource was just for the benefit of the consumer; not the server. I expected the server to leave that alone. Being a lazy programmer, knowing that this resource follows the PCHA PHD profile allows me to simplify my code on the consuming side. Do I need that information? No. Does it make life simpler? Yes if my intent is to make some kind of remote patient monitoring application or other application supporting remote patient monitoring in the context of the IHE/PCHA architecture.
So that was the purpose of including that information. Kind of like certain fixed and known xml namespaces one can check for in say, web services exchanges, that tell you lot about the version and content of your received package saving you parsing work.
So that is what I was looking for by making this requirement. A means of telling the consumer in a consistent and specified manner exactly under what context this resource was created. In this case it indicates that a PCHA compliant gateway created the resource from PHD data following the PCHA specification. I wanted that information in the resource for whoever can take advantage of it for whatever purpose. Apparently, using the meta.profile ain't the way to do it! I guess I took too quick of a read of the description in the FHIR spec "Profiles this resource claims to conform to". Who would know better than the creator of the resource?
I will need another means ... though I am not exactly sure what.
Michel Rutten (Oct 17 2017 at 11:51):
Hi @Brian Reinhold, typically such requirements are specified in an Implementation Guide. And if you want the implemented system to enforce interface contracts, you need validation anyway, regardless of profile claim tags on resource instances.
Ewout Kramer (Oct 17 2017 at 14:01):
Brian, I think you are looking for Resource.implicitRules ("A set of rules under which this content was created")?
Lloyd McKenzie (Oct 17 2017 at 14:41):
The challenge is that the author of the instance may not be aware of the profiles the consumer knows and cares about and vice versa. It's certainly not bad practice to declare known profiles, but making it mandatory may not be appropriate - not all instances will necessarily be crafted against a profile (or at least not one that isn't specific to the authoring system that no-one else cares about or understands). meta.profile really only starts to provide benefit when there's agreement between client and server about which profiles are "relevant" and the client agrees to assert those. That will happen in some environments, but not all.
Mounika (Dec 04 2017 at 12:18):
Hi @Michel Rutten When I am validating a profile using command line, getting the below error.
Capture3.PNG
Michel Rutten (Dec 04 2017 at 14:36):
This indicates a runtime issue in the Java validator. Apparently the validator cannot resolve some external profiles. Looks like connectivity or firewall issues.
Mounika (Dec 05 2017 at 05:43):
@Michel Rutten I got the error fixed.
Thanks
Last updated: Apr 12 2022 at 19:14 UTC
