search

cds-hooks / docs

CDS Hooks website & specification
http://cds-hooks.org
Apache License 2.0
166 stars 61 forks source link

CapabilityStatement/Conformance in CDS Hooks #71

Open robs16 opened 7 years ago

robs16 commented 7 years ago

One of the issues we have be grappling with is how to let our consumers know in detail what our CDS Service needs from the EHR to ensure integration is as smooth as possible. This is relevant to the FHIR resources found in the context, preload, or requested from the FHIR Server. For example, what fields in ProcedureRequest do we utilize and are they required? What code systems are supported by the CDS service? The FHIR way of doing this is a CapabilityStatement (Conformance in DSTU2) with associated profiles. While CapabilityStatements are not perfect, they go a long way towards ensuring compatibility in an integration.

At the beginning of an integration with a CDS Service, the EHR provider (or other consumer) might ask ‘What data do we need to provide to your service?’. As it stands, the CDS Hooks spec does not address this, so this specification must be provided out-of-band and will probably be inconsistent between various service provider. We propose that on a per-hook basis in the discovery endpoint, the CDS Service may provide a CapabilityStatement (or link/url to one) which better describes the data expected by the service. It should include all resources utilized, fields used, required fields and/or cardinality modifications, code system constraints, and potentially documentation where the CapabilityStatement/profile cannot adequately constrain the solution.

With this, the EHR Provider could request the CapabilityStatement from the CDS Service and run validation against their own FHIR server to identify any gaps to be addressed. The CDS Service provider could similarly run the validation against the EHR’s FHIR server during the integration process to determine gaps. This will also help during maintenance and upgrades to ensure that the service and the EHR remain compatible.

kpshek commented 7 years ago

@robs16 - Are you creating SMART apps today? The same questions you've posed here apply to SMART apps as well. If we're going to try and solve this, it should be done in SMART too.

Similar discussions around this topic can be seen in #15.

Personally, I don't see this as being something we should tackle anytime in the near future. We've been dealing with this with SMART app integrations for two years now (in production) and it hasn't been a pressing problem such that we've raised the need to address it in the SMART spec.

robs16 commented 7 years ago

No - I am not creating SMART apps at this point. I'm not against solving it in SMART as well as CDS-Hooks and keeping the solutions similar, but SMART is not my focus.

I had seen the discussion in #15, but it seemed to drive in an entirely different direction. I'm not looking to interrogate the FHIR server or similar, just provide conformance requirements of my service that can be addressed in a manual or automated manner by any consumer.

kpshek commented 7 years ago

Yeah, I realize #15 is approaching a different problem but both discussions hit on the same topic -- the desire to automate integration and compatibility between an EHR and CDS Service.

AlexTatiyants commented 7 years ago

@kpshek to clarify, your suggested approach to this issue is to encourage offline discussions between CDS services and EHRs, right? That seems to be where #15 landed.