Stream: conformance
Topic: Query re the Conformance resource
Richard Kavanagh (Mar 18 2016 at 08:50):
In the conformance resource here http://hl7-fhir.github.io/conformance-definitions.html#Conformance.rest.resource it states that you can only have one entry per "resource type" (Max of one repetition per resource type.)
If I have multiple profiles for a resource type , how do I cater for that?
Grahame Grieve (Mar 18 2016 at 08:51):
the current intent is that the profile you list in the .rest.resource.profile is the super set profile - the basic statement of what your system can do
Grahame Grieve (Mar 18 2016 at 08:51):
in Conformance.profile, that's where you list your multiple profiles for different use cases
Richard Kavanagh (Mar 18 2016 at 08:56):
So if I have two profiles of "Organsation" - profile01 and profile02 - then I would put both of those in 'Conformance.profile' - that's not a problem
But are you saying that I then need to create a new "super set" profile which then goes in '.rest.resource.profile' ?
Grahame Grieve (Mar 18 2016 at 08:57):
that's the idea, yes
Richard Kavanagh (Mar 18 2016 at 08:58):
Ahh ok - that's interesting, will need to change our thinking on a few things then
Grahame Grieve (Mar 18 2016 at 08:58):
I have code that can produce the super set from a set of profiles
Grahame Grieve (Mar 18 2016 at 08:59):
though it's not packaged
Richard Kavanagh (Mar 18 2016 at 09:54):
That may be useful - the issue is that then the properties in '.rest.resource.profile' are then shared for each "type" of Organisation (in this case). Which is not necessarily what we want. We may need to expose different FHIR endpoints which then makes referencing an issue. Need to ponder on this one.
Grahame Grieve (Mar 18 2016 at 10:38):
How many
Grahame Grieve (Mar 18 2016 at 10:38):
sorty.
Grahame Grieve (Mar 18 2016 at 10:38):
sorry. How do the types differ?
Ewout Kramer (Mar 18 2016 at 13:17):
Also, Richard, the Conformance.rest.resource.profile, I've always regard this as a kind of "hard limit", it expresses the shape of the resource the underlying system (database) could maximally support. So, even though the number and shape of profiles in Conformance.profile can vary rapidly, rest.resource.profile would be way more static. And thus I'd rather say Conformance.profile (combined) must be a subset of rest.resource.profile, rather than rest.resource.profile being a superset of Conformance.profile.
Then again, how important this difference is is dependent on whether the Conformance is expressing a logical interface description, or an interface of an actual production system.
Josh Mandel (Mar 18 2016 at 14:03):
I continue to think that requiring custom generated arbitrary supersets is going to be an incredible barrier. Developers will just not populate this field (or will populate it meaninglessly).
Grahame Grieve (Mar 18 2016 at 18:14):
there's no reason it sholud be a barrier since it can be auto-generated from a series of more specific profiles. The barrier is likely to be profiling at all
Lloyd McKenzie (Mar 19 2016 at 20:50):
Well, the simple "combination profile" is to create a profile that only constraints the "profile" element and says that all inbound instances must declare one of x profiles. No need to define constraints on anything else as any instance that declares it conforms to a profile must in fact conform to that profile. Simple and easy :)
Grahame Grieve (Mar 19 2016 at 20:51):
lol. a very short term definition of 'simple and easy'
Lloyd McKenzie (Mar 19 2016 at 21:03):
Well, if you do that, you're saying "you can't talk to me unless you declare these profiles". I'm not advocating that as a good solution in general, but for places that do want to enforce such a requirement (and it won't be uncommon), I'm not sure a more descriptive profile adds much value.
Last updated: Apr 12 2022 at 19:14 UTC
