You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/hooks/index.md
+9-7Lines changed: 9 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -111,13 +111,7 @@ All fields defined by the hook's context MUST be defined in a table where each f
111
111
- Type: The type of the field in the context JSON object, expressed as the JSON type, or the name of a FHIR Resource type. Valid types are *boolean*, *string*, *number*, *object*, *array*, or the name of a FHIR resource type. When a field can be of multiple types, type names MUST be separated by a *pipe* (`|`)
112
112
- Description: A functional description of the context value. If this value can change according to the FHIR version in use, the description SHOULD describe the value for each supported FHIR version.
113
113
114
-
### FHIR resources in context
115
-
116
-
When potentially multiple FHIR resources value a single context field, these resources SHOULD be formatted as a FHIR Bundle. For example, multiple FHIR resources are necessary to describe all of the orders under review in the `order-review` hook's `orders` field. Hook definitions SHOULD prefer the use of FHIR Bundles over other bespoke data structures.
117
-
118
-
Often, context is populated with in-progress or in-memory data that may not yet be available from the FHIR server. For example, `medication-prescribe` and `order-review` define context fields containing FHIR resources that represent draft resources. In this case, the EHR should only provide these draft resources and not the full set of orders available from its FHIR server. The CDS service MAY pre-fetch or query for FHIR resources with other statuses.
119
-
120
-
All FHIR resources in context MUST be based on the same FHIR version.
114
+
The below illustrates a sample table.
121
115
122
116
Field | Optionality | Prefetch Token | Type | Description
123
117
----- | -------- | ---- | ---- | ----
@@ -127,6 +121,14 @@ Field | Optionality | Prefetch Token | Type | Description
127
121
`moreObjects` | OPTIONAL | No | *array* | A clear description of the items in this array.
128
122
`allFHIR` | OPTIONAL | No | *object* | A FHIR Bundle of the following FHIR resources using a specific version of FHIR.
129
123
124
+
### FHIR resources in context
125
+
126
+
When potentially multiple FHIR resources value a single context field, these resources SHOULD be formatted as a FHIR Bundle. For example, multiple FHIR resources are necessary to describe all of the orders under review in the `order-review` hook's `orders` field. Hook definitions SHOULD prefer the use of FHIR Bundles over other bespoke data structures.
127
+
128
+
Often, context is populated with in-progress or in-memory data that may not yet be available from the FHIR server. For example, `medication-prescribe` and `order-review` define context fields containing FHIR resources that represent draft resources. In this case, the EHR should only provide these draft resources and not the full set of orders available from its FHIR server. The CDS service MAY pre-fetch or query for FHIR resources with other statuses.
129
+
130
+
All FHIR resources in context MUST be based on the same FHIR version.
131
+
130
132
### Examples
131
133
132
134
Hook creators SHOULD include examples of the context.
An EHR calls a CDS service by `POST`ing a JSON document to the service
105
-
endpoint, which can be constructed from the CDS Service base URL and an
106
-
individual service id as `{baseUrl}/cds-services/{service.id}`. The CDS Hook
107
-
call includes a JSON POST body with the following input fields:
104
+
An EHR calls a CDS Service by `POST`ing a JSON document to the service as described in this section. The CDS Service endpoint can be constructed from the CDS Service base URL and an individual service id as `{baseUrl}/cds-services/{service.id}`. The request includes a JSON `POST` body with the following input fields:
108
105
109
106
Field | Optionality | Type | Description
110
107
----- | ----- | ----- | --------
@@ -113,7 +110,7 @@ Field | Optionality | Type | Description
113
110
`fhirServer` | OPTIONAL | *URL* | The base URL EHR's [FHIR](https://www.hl7.org/fhir/) server. If fhirAuthorization is provided, this field is REQUIRED. The scheme should be `https`
114
111
`fhirAuthorization` | OPTIONAL | *object* | A structure holding an [OAuth 2.0][OAuth 2.0] bearer access token granting the CDS Service access to FHIR resources, along with supplemental information relating to the token. See the [FHIR Resource Access](#fhir-resource-access) section for more information.
115
112
`user` | REQUIRED | *string* | The FHIR resource type + id representing the current user.<br />The type is one of: [Practitioner](https://www.hl7.org/fhir/practitioner.html), [Patient](https://www.hl7.org/fhir/patient.html), or [RelatedPerson](https://www.hl7.org/fhir/relatedperson.html).<br />For example, `Practitioner/123`
116
-
`context` | REQUIRED | *object* | Hook-specific contextual data that the CDS service will need.<br />For example, with the `medication-prescribe` hook this will include [MedicationRequest](https://www.hl7.org/fhir/medicationrequest.html) being prescribed. For details, see the [Hooks specification](http://cds-hooks.org/hooks/).
113
+
`context` | REQUIRED | *object* | Hook-specific contextual data that the CDS service will need.<br />For example, with the `medication-prescribe` hook this will include [MedicationRequest](https://www.hl7.org/fhir/medicationrequest.html) being prescribed. For details, see the Hooks specification page.
117
114
`prefetch` | OPTIONAL | *object* | The FHIR data that was prefetched by the EHR (see more information below)
118
115
119
116
#### hookInstance
@@ -354,7 +351,7 @@ Field | Optionality | Type | Description
354
351
----- | ----- | ----- | --------
355
352
`summary` | REQUIRED | *string* | One-sentence, <140-character summary message for display to the user inside of this card.
356
353
`detail` | OPTIONAL | *string* | Optional detailed information to display; if provided MUST BE represented in [(GitHub Flavored) Markdown](https://github.github.com/gfm/). (For non-urgent cards, the EHR MAY hide these details until the user clicks a link like "view more details...".)
357
-
`indicator` | REQUIRED | *string* | Urgency/importance of what this card conveys. Allowed values, in order of increasing urgency, are: `info`, `warning`, `hard-stop`. The EHR MAY use this field to help make UI display decisions such as sort order or coloring. The value `hard-stop` indicates that the workflow should not be allowed to proceed.
354
+
`indicator` | REQUIRED | *string* | Urgency/importance of what this card conveys. Allowed values, in order of increasing urgency, are: `info`, `warning`, `critical`. The EHR MAY use this field to help make UI display decisions such as sort order or coloring.
358
355
`source` | REQUIRED | *object* | Grouping structure for the **Source** of the information displayed on this card. The source should be the primary source of guidance for the decision support the card represents.
359
356
<nobr>`suggestions`</nobr> | OPTIONAL | *array* of **Suggestions** | Allows a service to suggest a set of changes in the context of the current activity (e.g. changing the dose of the medication currently being prescribed, for the `medication-prescribe` activity). If used, the user MUST BE allowed to choose no more than one suggestion.
360
357
`links` | OPTIONAL | *array* of **Links** | Allows a service to suggest a link to an app that the user might want to run for additional information or to help guide a decision.
@@ -408,7 +405,7 @@ Field | Optionality | Type | Description
408
405
<nobr>`label`</nobr>| REQUIRED | *string* | Human-readable label to display for this link (e.g. the EHR might render this as the underlined text of a clickable link).
409
406
`url` | REQUIRED | *URL* | URL to load (via `GET`, in a browser context) when a user clicks on this link. Note that this may be a "deep link" with context embedded in path segments, query parameters, or a hash.
410
407
`type` | REQUIRED | *string* | The type of the given URL. There are two possible values for this field. A type of `absolute` indicates that the URL is absolute and should be treated as-is. A type of `smart` indicates that the URL is a SMART app launch URL and the EHR should ensure the SMART app launch URL is populated with the appropriate SMART launch parameters.
411
-
`appContext` | OPTIONAL | *string* | An optional field that allows the CDS Service to pass context regarding the launch of this SMART app from the CDS card to the SMART app. The `appContext` field should only be valued if the link type is `smart` and is not valid for `absolute` links. The `appContext` field and value will be sent to the SMART app as part of the [OAuth 2.0][OAuth 2.0] access token response, alongside the other launch context when the SMART app is launched.
408
+
`appContext` | OPTIONAL | *string* | An optional field that allows the CDS Service to share information from the CDS card with a subsequently launched SMART app. The `appContext` field should only be valued if the link type is `smart` and is not valid for `absolute` links. The `appContext` field and value will be sent to the SMART app as part of the [OAuth 2.0][OAuth 2.0] access token response, alongside the other [SMART launch parameters](http://www.hl7.org/fhir/smart-app-launch/scopes-and-launch-context/#launch-context-arrives-with-your-access_token) when the SMART app is launched. Note that `appContext` could be escaped JSON, base64 encoded XML, or even a simple string, so long as the SMART app can recognize it.
412
409
413
410
### Example
414
411
@@ -441,7 +438,7 @@ Field | Optionality | Type | Description
0 commit comments