Open robs16 opened 7 years ago
In the HL7 Decision Support Service specification, this information is communicated with an organization id as part of the request. When we expressed that in the clinical reasoning module, we made it part of the parameters sent to the $evaluate operation. I think the analog here would be just to add organizationId as one of the parameters that can be sent to the request, in the same way that patientId is passed now. That identifier could be a top-level organization, or a sub-organization, the FHIR Organization resource supports that through the partOf element.
The distinction between an organization that hosts an EHR versus the organization where a patient receives care has also been a challenge in our organization, especially for affiliated clinics that use our EHR, but do not share subscriptions to the same CDS resources. The infobutton standard makes that distinction. There are two parameters: organization provides and ID of the requestor organization, while careSetting provides the identifier of the patient care setting (e.g., a specific clinic, a specific hospital). This approach would work well for us, but not all EHR vendors implemented the careSetting parameter.
For a CDS service provider, it is necessary to know which organization (or client) and potentially sub-organization is requesting the service. For example, it may be that a given client purchased only a subset of CDS Service’s capabilities and CDS Service needs this information to properly handle the request. Another example is that the client could be a cloud-based EMR, which encompasses many practices, each with their own organizational structure.
We believe it would be beneficial to add a required organization field to the the CDS service request which would provide the FHIR id of the organization (or sub organization) requesting CDS.
There are at least a few other ways to provide this information, but each has a downside:
FhirServer Url can include an identifier that indicates which organization (or hospital or practice, etc) is requesting the service. The primary issue with this approach is that the CDS service has to parse out the relevant identifier, thereby hardcoding assumptions about how the Url is structured. If those assumptions are ever violated, the process breaks down.
Context could reference the relevant FHIR resources, such as Organization to establish the context. However, the spec and examples currently focus the context on the triggering orders.
Service URL could include a prefix which identifies the organization. However with sub-organizations and sub-sub-organizations this could become unwieldy.