Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 7 additions & 9 deletions input/pagecontent/cds-service-spec.md
Original file line number Diff line number Diff line change
Expand Up @@ -133,19 +133,17 @@ The words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMM

* Here is a list of FHIR tools that might be of interest to implementers:

* [Public](http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing)

* Local (preferred)
* [Public](http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing)

<b> The HAPI links DO NOT work </b>
* [HAPI RESTful Server](http://hapifhir.io/doc_rest_server.html)
* Local (preferred)

* [HAPI JPA Server](http://hapifhir.io/doc_jpa.html)
* [HAPI RESTful Server](https://hapifhir.io/hapi-fhir/docs/server_plain/server_types.html)

* [HAPI JAX-RS Server](http://hapifhir.io/doc_rest_server_jaxrs.html)
* [HAPI JPA Server](https://hapifhir.io/hapi-fhir/docs/server_jpa/introduction.html)

* [.NET Server](https://github.com/ewoutkramer/fhir-net-api)

* [HAPI JAX-RS Server](https://hapifhir.io/hapi-fhir/docs/server_plain/jax_rs.html)

* [.NET Server](https://github.com/ewoutkramer/fhir-net-api)


#### CDS Function
Expand Down
2 changes: 1 addition & 1 deletion input/pagecontent/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,7 @@ PDDIs are, to an extent, theoretical due to knowledge gaps in the literature. Th
##### Technical
{:.no_toc}

An important requirement of CDS is that it provide clinically relevant information to the clinician at the right time. This implementation guide assumes that CDS is provided as a real-time remote service which the EHR (client) subscribes to at various points in the workflow of clinicians. The service requests clinical decision support based on the current patient context. The EHR client sends relevant contextual information as part of the request and receives clinically relevant suggestions describing potential actions to be taken. The CDS service must run efficiently to meet clinician expectations and not interrupt from the clinical workflow. Delays in presenting CDS information may lead to unsuccessful CDS adoption and clinician frustration. Note that the remote service would not a component of the EHR, would use API and web standards for communication, and could be a servlet container hosted within the organization's data architecture / firewall or hosted offsite. HIPAA privacy and data protection rules would apply to all aspects of the interaction between the EHR and the CDS service.
An important requirement of CDS is that it provide clinically relevant information to the clinician at the right time. This implementation guide assumes that CDS is provided as a real-time remote service which the EHR (client) subscribes to at various points in the workflow of clinicians. The service requests clinical decision support based on the current patient context. The EHR client sends relevant contextual information as part of the request and receives clinically relevant suggestions describing potential actions to be taken. The CDS service must run efficiently to meet clinician expectations and not interrupt from the clinical workflow. Delays in presenting CDS information may lead to unsuccessful CDS adoption and clinician frustration. Note that the remote service would not be a component of the EHR, but would use an API and web standards for communication, and could be a service hosted within the organization's data architecture / firewall or offsite. HIPAA privacy and data protection rules would apply to all aspects of the interaction between the EHR and the CDS service.

To address workflow considerations, this implementation guide describes two complementary PDDI CDS scenarios: 1) CDS at the time that an ordering clinician selects a drug to add to an order (“order-select”), and 2) CDS at the time an ordering clinician signs a drug order (“order-sign”). It is possible for a stakeholder to implement both scenarios. In such case, the CDS service might trigger highly similar alerts at both order-select and order-sign. For example, if a clinician decides to ignore/over-ride a CDS suggestion presented at order-select, the CDS service might detect the same PDDI issue upon order-sign. This implementation guide defines a stateful approach where various resources returned from the order-select service are used to determine if an alert has been seen before while simultaneously allowing client EHRs to choose how to handle apparently repeat CDS suggestions. Note that it might not be possible to develop CDS Logic to evaluate a candidate order at the "order-select" stage.' In these cases, appropriately, there would be no ability for the EHR to subscribe to a service specific to the drug-drug interaction that triggers at order-select.

Expand Down