Stream: implementers
Topic: CapabilityStatement limits profile to one per resource
Eric Haas (Dec 14 2016 at 16:31):
CapabilityStatement (CS) limits profiles to one per resource. There is an invariant cpb-9 in the CS that limits using one Resource per instance. This is an issue when you want to use for defining Profile search parameters and you may have several profiles of the the same type. For example in US-Core - Smoking, Vitals, and Lab Results are all observations. We have defined separate search combinations for each profile. Our only options now are to create a CS for each profile individually which is not IMO ideal would be better to describe all the profile's for an IG in a single CS.
Eric Haas (Dec 14 2016 at 16:37):
I think that should change the invarient to say "A type + profile can only be described once per RESTful mode."
Grahame Grieve (Dec 14 2016 at 20:07):
I think we need to talk about this quite a bit. What do you mean when you specify different search parameters for different profiles?
Eric Haas (Dec 14 2016 at 20:12):
1. Smoking we search by patient and (fixed) code
2. vitals we search by category, date, code and patient
3. lab results we search by category, date, code and patient with different conformance (SHALL vs SHOULD) for certain combos.
Eric Haas (Dec 14 2016 at 20:12):
No way to do that in a single CS
Eric Haas (Dec 14 2016 at 20:14):
In DSTU2 We use CarePlan for CareTeam and CarePlan. Different things different documentation and search params too.
Grahame Grieve (Dec 14 2016 at 20:17):
GET [base]/Observation?subject=Patient/X&code=Y
Grahame Grieve (Dec 14 2016 at 20:18):
you search on the resource, not on a profile on the resource. And SHALL and SHOULD are already extensions. So I think this is more extension space: combinations for purposes
Eric Haas (Dec 14 2016 at 20:24):
There is a 1:1 Resource: Profile in CS ( so can't list Smoking, Vitals and Labs without using extensions). And I am aware of the standard extensions. But there is no way to represent that profile A uses serach combination b in CS. Are you saying list em all at the resource level and list all the profile at the metadata level and not to associate profiles with the searches?
Grahame Grieve (Dec 14 2016 at 20:26):
- list all the search parameters on the resource. That's where they actually are
- list all the profiles in CS.profile
- define an extension that associates a search parameter with a particular profile
Eric Haas (Dec 14 2016 at 20:29):
I was thinking the same. But I don't understand the CS.resource.profile max as 1 . In any lab guide I profile I'll have >1 profile on Observationn. Am I misunderstanding that element?
Grahame Grieve (Dec 14 2016 at 20:34):
it's the common denominator - all Observations handled by this system will conform to X
Eric Haas (Dec 14 2016 at 22:22):
I'll post a GForge to explain the difference between the CS.Profiles vs CS.Resource.Profiles a little more clearly. [#12471]
Paul Knapp (Dec 15 2016 at 05:31):
The limits of one profile per resource, and in the messaging limit of type of response to each request is not right, they need to be able to be multiple.
Grahame Grieve (Dec 15 2016 at 05:36):
those are 2 very different issues. I agree with the second, but not the first
Paul Knapp (Dec 15 2016 at 05:39):
So for each profile you want to accept on a resource you expect people to set up a different endpoint?
Paul Knapp (Dec 15 2016 at 05:40):
or are people misinterpreting the point to specifying the profile?
Grahame Grieve (Dec 15 2016 at 05:40):
yes i think that is the case - confusion between CapabilityStatement.rest.resource.profile and CapabilityStatement.profile
Grahame Grieve (Dec 15 2016 at 05:41):
http://build.fhir.org/profiling.html#profile-uses
Paul Knapp (Dec 15 2016 at 05:42):
Side note, the alphabetical resource list is no longer alphabetical, CapabilityStatement needs to move up.
Grahame Grieve (Dec 15 2016 at 05:45):
fixed
Paul Knapp (Dec 15 2016 at 05:45):
So in the root profile you expect a list of all profiles supported by the endpoint, and it's multiple, and for each resource just a base profile - that seems fine.
Grahame Grieve (Dec 15 2016 at 05:46):
yes
Paul Knapp (Dec 15 2016 at 05:49):
Yes, its the event request and response profiles which are 1..1 and that's not workeable - could have multiple requests which get a common response or multiple, or pairs. Better for capability to express what can go in and out, and in IGs explain how those work together.
Grahame Grieve (Dec 15 2016 at 05:50):
so there's outstanding tasks in that area, deferred waiting for feedback from implementers. Personally, I think it should not just be response 0..*, but something extra like ('kind of response | profile' ) 0..* but we wait to see
Eric Haas (Dec 15 2016 at 05:57):
thanks for the link. I'll keep myu gforge intact because it refers to the element comments which probably should point to this section which is much clearer.
Lloyd McKenzie (Dec 15 2016 at 16:08):
We've defined a MessageDefinition resource that really should replace the CapabilityStatement.messaging stuff. Question is whether we can/should do that as part of the STU3 release
Eric Haas (Dec 20 2016 at 04:40):
I am squarely in the REST part. :-)
Last updated: Apr 12 2022 at 19:14 UTC
