Stream: IG creation
Topic: US Core
Grahame Grieve (Aug 28 2019 at 06:34):
@Eric Haas the US core IG has this pattern:
Grahame Grieve (Aug 28 2019 at 06:35):
<type value="Medication"/> <profile value="http://hl7.org/fhir/StructureDefinition/Medication"/> <supportedProfile value="http://hl7.org/fhir/us/core/StructureDefinition/us-core-medication"/>
Grahame Grieve (Aug 28 2019 at 07:02):
what's the idea here? Why unrestricted on the base profile?
Eric Haas (Aug 28 2019 at 16:15):
the CapabilityStatement.rest.resource.profile definition:
A specification of the profile that describes the solution's overall support for the resource, including any constraints on cardinality, bindings, lengths or other limitations. See further discussion in Using Profiles.
the CapabilityStatement.rest.resource.profile comment:
The profile applies to all resources of this type - i.e. it is the superset of what is supported by the system.
Eric Haas (Aug 28 2019 at 16:17):
When I am creating a CapabilltyStatement in an IG that describes the expectations, I interpret 'the superset of what is supported by the system.' as the base resource.
Eric Haas (Aug 28 2019 at 16:18):
Since I am making no assumptions about the system implementing US Core
Grahame Grieve (Aug 28 2019 at 19:21):
but you are making statements about the way the system behaves. What the statement above says is:
- some resources might conform to us-core
- the rest, the don't have to.
Is that what USCore is saying? because I don't think it is (or should be)
Grahame Grieve (Aug 28 2019 at 19:22):
take the case of Observation: there's multiple different use cases - so that's what supportedProfile is for. But there's also a set of base expectations for all uses of Observation (derived from the set of supported use cases).... and that's worth telling people about. (All observations will...)
Eric Haas (Aug 28 2019 at 20:39):
I believe you are saying the base profile should be 'US Core [Resouce X]'. :
- I think this conversation is more appropriate for some future version of a 'Must support free' variant of US Core.
- I did not attach a conformance expectation on the base profile and if I did it could say SHOULD and then the having it '[US Core [Resouce X]' would make more sense to me. But I still don't think that US core can possibly cover all a system's use cases for Resource X, and in the example of Observation there are 4 US Core profiles, none of them are base.
Grahame Grieve (Aug 28 2019 at 23:14):
but we should have that discussion - what can a client know about the server's resources?
Grahame Grieve (Aug 28 2019 at 23:14):
nothing?
Eric Haas (Aug 29 2019 at 01:24):
You bring up a good point about an implementers CapStatement, but I think in the context of an IG capability Statement this is not about client discovery but rather expectations for a server using the IG. So looking at the US Core CapabilityStatements I think it would be appropriate to remove the CapabilityStatement.rest.resource.profile elements from the IGs Capstatements.
Eric Haas (Aug 29 2019 at 01:29):
(deleted)
Grahame Grieve (Aug 29 2019 at 02:06):
I think it would be a lot better to describe the base expectations that apply to all resources that cross the API. Is every patient going to be a US core patient? or not? if not... what's a client expected to do?
Eric Haas (Aug 29 2019 at 03:22):
OK so we have not had that conversion in the context of this IG which is more geared towards ONC cert and search API, so right now I think what we have now is unclear and so I think is better to either remove this element altogether or attach an expectation extension of 'MAY' and then have that discussion when we discuss how to remove the Must Supports in a more generic version of the guide.
Last updated: Apr 12 2022 at 19:14 UTC
