Change EHR to CDS Client (fixes #407)

Author: isaacvetter

docs/community.md

@@ -13,7 +13,7 @@ There are several ways in which you can get involved with the CDS Hooks communit
 
 ### Objectives
 
- * Promote creation of clinical-grade service integrations (EHRs + CDS Services)
+ * Promote creation of clinical-grade service integrations (CDS Clients + CDS Services)
  * Gain implementation experience with real-world systems
  * Refine the spec, balancing ease of use, flexibility, and stability
  * Drive toward pilot deployments with the ability to measure results

docs/index.md

@@ -2,7 +2,7 @@
 
 This specification describes a
 ["hook"](http://en.wikipedia.org/wiki/Hooking)-based pattern for invoking
-decision support from within a clinician's EHR workflow. The API supports:
+decision support from within a clinician's workflow. The API supports:
 
  * Synchronous, workflow-triggered CDS calls returning information and suggestions
  * Launching a user-facing SMART app when CDS requires additional interaction
@@ -12,13 +12,13 @@ decision support from within a clinician's EHR workflow. The API supports:
 
 ## How it works
 
-User activity inside the EHR triggers **CDS hooks** in real-time.  For example:
+User activity inside the clinician's workflow triggers **CDS hooks** in real-time.  For example:
 
 * `patient-view` when opening a new patient record
 * `medication-prescribe` on authoring a new prescription
 * `order-review` on viewing pending orders for approval
 
-When a triggering activity occurs, the EHR notifies each CDS service registered for the activity. These services must then provide near-real-time feedback about the triggering event. Each service gets basic details about the EHR
+When a triggering activity occurs, the CDS Client notifies each CDS service registered for the activity. These services must then provide near-real-time feedback about the triggering event. Each service gets basic details about the clinical workflow 
 context (via the `context` parameter of the hook) plus whatever
 service-specific data are required (via the `pre-fetch-template` parameter).
 
@@ -30,11 +30,11 @@ Each CDS service can return any number of **cards** in response to the hook.
 Cards convey some combination of text (*information card*), alternative
 suggestions (*suggestion card*), and links to apps or reference
 materials (*app link card*). A user sees these cards — one or more of each type
-— embedded in the EHR, and can interact with them as follows:
+— embedded in the workflow, and can interact with them as follows:
 
 * *information card*: provides text for the user to read.
 
-* *suggestion card*: provides a specific suggestion for which the EHR renders a button that the user can click to accept. Clicking automatically populates the suggested change into the EHR's UI.
+* *suggestion card*: provides a specific suggestion for which the CDS Client renders a button that the user can click to accept. Clicking automatically populates the suggested change into the clinician's UI.
 
 * *app link card*: provides a link to an app (often a SMART app) where the user can supply details, step through a flowchart, or do anything else required to help reach an informed decision.
 

docs/quickstart.md

@@ -1,23 +1,23 @@
 # Quick Start
 This quick start tutorial defines each of the actors and provides details for implementing the `patient-view` hook. 
 
-A CDS Hooks scenario typically includes two main actors: an EHR and a CDS Service. Below is an example interaction for the `patient-view` hook.
+A CDS Hooks scenario typically includes two main actors: an CDS Client and a CDS Service, where the CDS Client may be an EHR, CPOE or other clinical workflow system. Below is an example interaction for the `patient-view` hook.
 
 ![patient-view Hook Overview](images/patient-view-hook-launch_spec.png)
 
 ## Building a CDS Service
-A CDS Service is an external service that responds to EHR requests through cards. A card can optionally link to a SMART app. There are several steps to setting up a CDS Service: 
+A CDS Service is an external service that responds to CDS Client requests through cards. A card can optionally link to a SMART app. There are several steps to setting up a CDS Service: 
 
 1. Create an endpoint for discovery
 2. Develop a service
 3. Test the service with the [sandbox](http://sandbox.cds-hooks.org/)
 4. If applicable, create a SMART app (or [borrow one](https://apps.smarthealthit.org/apps/pricing/open-source))
-5. Test the service (and, if applicable, SMART app) with an EHR
+5. Test the service (and, if applicable, SMART app) with an CDS Client
 
 This tutorial recommends implementing the CDS Hooks [security model](specification/1.0/#security-and-safety) after successful open access testing.
 
 ### Endpoint for discovery
-The CDS Service must provide a stable endpoint for the EHR to discover the available services. A system must expose their services at `{baseUrl}/cds-services`. A service endpoint that supports the `patient-view` hook may return:
+The CDS Service must provide a stable endpoint for the CDS Client to discover the available services. A system must expose their services at `{baseUrl}/cds-services`. A service endpoint that supports the `patient-view` hook may return:
 
 ```json
 {
@@ -78,9 +78,9 @@ Select the configure hooks:<br>
 Delete the existing hooks, and then do a quick add with a reference to your CDS Service:<br>
 ![Patient View Hooks Launch from Sandbox](images/demo-quick-add.png)
 
-After testing with the sandbox, you are ready to connect with an EHR service.
+After testing with the sandbox, you are ready to connect with an CDS Client.
 
-## Integrating CDS Services into an EHR
+## Integrating CDS Services into a CDS Client
 Build out following sections:
 
 1. Call discovery endpoint 
@@ -94,7 +94,7 @@ Build out following sections:
 This tutorial recommends implementing the CDS Hooks [security model](specification/1.0/#security-and-safety) after successful open access testing.
 
 ### Call discovery endpoint 
-The CDS discovery endpoint provides the list of services a CDS provider supports, and the hooks a service should be invoked on. An EHR may configure their system to support a set of hooks at a certain location in their users work flow, or build a dynamic capability to interact with a CDS Service provider within a work flow. For the best end-user experience, this guide recommends a business analyst configure which hooks an EHR will support. 
+The CDS discovery endpoint provides the list of services a CDS provider supports, and the hooks a service should be invoked on. A CDS Client may configure their system to support a set of hooks at a certain location in their users work flow, or build a dynamic capability to interact with a CDS Service provider within a work flow. For the best end-user experience, this guide recommends a business analyst configure which hooks a CDS Client will support. 
 
 Below is an example work flow where a business analyst accesses this list of available services by calling 
 
@@ -107,10 +107,10 @@ and then configures them in the system.
 This image captures a business analyst reviewing services from one CDS provider. A business analyst may review services from multiple providers and configure appropriate services per user profiles.
 
 ### Invoke service on patient-view hook
-The `patient-view` hook is invoked when a patient chart is opened. It's one of the most basic since the logic doesn't have any prior workflow dependencies. The service called on the `patient-view` hook could be dependent on patient characteristics, for example: sex, problems in problems list, active medications, etc. The current version of the CDS Hooks specification allows the EHR to decide which characteristics to consider. 
+The `patient-view` hook is invoked when a patient chart is opened. It's one of the most basic since the logic doesn't have any prior workflow dependencies. The service called on the `patient-view` hook could be dependent on patient characteristics, for example: sex, problems in problems list, active medications, etc. The current version of the CDS Hooks specification allows the CDS Client to decide which characteristics to consider. 
 
 ### Support FHIR resource on CDS requests (context or pre-fetch)
-Often a CDS Service will require additional information from the EHR to perform the decision support logic, or determine the appropriate SMART app to return. Prefetch provides the EHR the capability to pass a resource when invoking a service. For example, with a patient resource included a service could do a geography search for potential environmental risk factors. Below is an example request invoked on patient-view with a patient included: 
+Often a CDS Service will require additional information from the CDS Client to perform the decision support logic, or determine the appropriate SMART app to return. Prefetch provides the CDS Client the capability to pass a resource when invoking a service. For example, with a patient resource included a service could do a geography search for potential environmental risk factors. Below is an example request invoked on patient-view with a patient included: 
 
 ```json
 {
@@ -141,10 +141,10 @@ In some cases, additional information beyond what is included in the prefetch ma
 It is recommended FHIR servers implement, and CDS Services follow, locale specific implementation guides. In the US, the recommended implementation guides to follow are the [Argonaut Data Query Guide (DSTU2)](http://www.fhir.org/guides/argonaut/r2/) or [HL7 US Core (STU3)](http://hl7.org/fhir/us/core/index.html). Each profile page within these implementation guides includes queries FHIR servers are required to support. 
 
 ### Expose non-secured FHIR server for testing
-A non-secured FHIR server is important to support testing with a CDS Service. When the EHR moves a hook to production the system is expected to follow the guidelines in the [security](specification/1.0/#security-and-safety) requirements.
+A non-secured FHIR server is important to support testing with a CDS Service. When the CDS Client moves a hook to production the system is expected to follow the guidelines in the [security](specification/1.0/#security-and-safety) requirements.
 
 ### Render card
-The CDS Service will provide a response in the form a of a 'card'. Your EHR needs to be able to display the card.
+The CDS Service will provide a response in the form a of a 'card'. Your CDS Client needs to be able to display the card.
 
 Example card JSON: