Stream: conformance
Topic: Forcing resources to declare a profile
Morten Ernebjerg (Feb 06 2019 at 14:24):
We are modelling (in STU3) for a usecase in which only very well-defined types of data are exchanged and all clients have agreed on the associated constraints. We want to check that all data pushed to the server conforms to the relevant profiles, but blindly checking incoming resources against all applicable profiles would be very slow in some cases as we have a range of profiles for e.g. Observation. Hence, we would ideally like the server to
1. reject resources (irrespective of type) that do not declare a profile in meta.profile, and
2. reject resources that declare a profile which is not contained in a pre-defined set
Is there some way to declare such a constraint in CapabilityStatement (implying that the list of supported profiles is closed and that profiles must be declared)? E.g. could one declare one profile per resource type that only restricts meta.profile accordingly and put them in CapabilityStatement.rest.resource.profile?
We effectively want to force all incoming resources to conform to a profile that makes meta.profile required and binds it to a custom valueset, but I gather from this thread that profiling core types like DomainResource is not good practice.
Lloyd McKenzie (Feb 06 2019 at 15:04):
The simplest way to do this is to have the profiles for each resource declare that .meta and .meta.profile are mandatory (and perhaps have a mandatory slice on meta.profile that is bound to a value set of profiles the instance must match. However, be aware that doing this is saying that every client system will need to customize itself to talk to you, so make sure that you've got the funds to actually pay for that to happen :)
Morten Ernebjerg (Feb 07 2019 at 21:15):
@Lloyd McKenzie Thanks! - do you mean adapt our "normal" resource profiles? In that case, would that not only say that if you happen to satisfy any of these profiles then you must declare it explicitly? If so, it seems it would not rule out resources that do not declare (and maybe don't conform to) any profile at all. Or did I get that wrong?
Fair point about the interop burden - we happen to have quite specific business requirements for the data, but we're certainly keeping an ear on the ground :smirk:
Lloyd McKenzie (Feb 07 2019 at 21:47):
If you put it in the rest.resource.profile and include a mandatory slice, that would say that you only support resources that declare one of the profiles you've identified. Anyone who doesn't declare a profile at all or doesn't declare one of the ones you've listed wouldn't meet your profile and could therefore expect to be rejected. If you declare a profile, you're required to comply with it, so that bit is taken care of implicitly.
Morten Ernebjerg (Feb 08 2019 at 12:04):
Alright, thanks Lloyd!
Last updated: Apr 12 2022 at 19:14 UTC
