Capability Statement questions


#1

Hi Team ,

I would like validate my understanding on the certain concepts and hence this post

There are multiple implementation guide available like DAF , MedMij , etc .Now these implementation guide refers to many use cases like Patient Summary , Extraction of data from source system and loading them in target systems . Each of these use cases may refer to atleast one or more capability statement .

Implementation guide (IG1) --> Capability Statement 1 (C1) & Capability Statement 2 (C2)

Implementation guide (IG2) --> Capability Statement 1 (C3)

Now these capability statements consists of one or more resources who contributes to this use case .
e.g C1 --> Patient --> Conforms to profile /base/StructureDefinition/Patient1
—> Observation --> Conforms to profile /base/StructureDefinition/Observation1

     C2 --> _Patient_ --> Conforms to profile _/base/StructureDefinition/Patient2_

Question

  1. Is the above example is correct ? Can a multiple capability statement refer to same resourceType which themselves would conforms to multiple profiles ? In above example Patient resource

In FHIR specs here it refers to profile at system level and other in resource level .

Question 2) How the resource level profile i.e in CapabilityStatement.rest.resource.profile is the superset of all use cases implemented by the system ? If a given resource is contributing/part-of multiple use case(capabilities) then how it can conform to single profile as at resource level the cardinality of profile is 0…1 .?


#2

CapabilityStatements can’t impose more than one profile on a given resource (CapabilityStatement.rest.resource.profile) though they can declare “support” for searching on/storing declarations of multiple profiles (CapabilityStatement.rest.resource.supportedProfile). In the situation where a system complies with multiple CapabilityStatements (from different IGs or from a single IG), their system’s CapabilityStatement would need to meet the requirements of all of the CapabilityStatements. This means that for all “shall” requirements (or all requirements if the SHALL/SHOULD/MAY extension isn’t used), the system would need to meet those requirements. The system’s profile for a given resource would need to meet union of the requirements of all of the profiles. So if one profile said minOccurs = 0, another said minOccurs = 1 and another said minOccurs = 2, the system’s base profile would need to send at least two. If combined, the profiles expected codes from SNOMED, ICD9 and ICD10, then the system’s profile would need to include slices of Coding supporting each of those code systems. In general, it’s possible to comply with numerous profiles with different requirements simultaneously so long as those profiles only enforce data that must be sent, rather than data that must be absent. (If one profile prohibits an element and another profile mandates its inclusion, then it’s not possible for a system to generate instances that meet both sets of requirements - configuration would be needed to expose different interfaces (and potentially different capability statements) to the different client systems - and obviously this imposes costs on the server.


#3

Thanks Lloyd; your explanation was very helpful.

One follow up question on your above quote;
Does different interfaces (diff capability statements) to different client systems always technically enforces separate data stores (tables/databases)?

Or it could be served from from data store provided data model supports superset of resource structure definition from all profiles from all these different capability statements?

Thanks!


#4

For most systems, it would be the same data store. Configuration of who’s allowed to send or receive what would filter/manipulate inbound and outbound data.