Stream: implementers
Topic: Multiple profiles for a resource in the CapabilityStatement
Martin Grundberg (Jan 29 2020 at 13:10):
We will likely have several profiles for many different resources. One example of that is Observations where we can support a BP profile as well as a lab/pathology result profile, or having different types of Encounters ranging from IP to different types of OP which all have different information model requirements (hence different profile requirements).
Another requirement we have is that depending on profile, we want to allow/support different interactions, ie Read, Create etc. This seems supported, and we can implement multiple profiles. But this does not seem to be possible to represent in the CapabilityStatement as resource.interaction is parallel to resource.profile.
Is this a known limitation in the CapabilityStatement? Or is it not intended to support different interaction types per profile rather than resource?
What we seem to need is in the CapabilityStatement relate interactions to the profile rather than resource.
Martin Grundberg (Jan 29 2020 at 13:35):
Realized I mentioned resource.profile instead of resource.supportedProfile, but hopefully you got the point :)
Lloyd McKenzie (Jan 29 2020 at 16:25):
It's a known limitation. If you support create on vitals, but not on lab, there's no way to distinguish that computably. You could consider using extensions if you can agree on a simple enough way to define the expectations in your interoperability space. Trying to do that generically has proved too complex.
Grahame Grieve (Jan 29 2020 at 20:09):
I'm intending to discuss this in Sydney next week. It's a topic that bubbles away...
Last updated: Apr 12 2022 at 19:14 UTC
