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
The `medication-refill` hook fires when a medication refill request for an existing prescription of a specific medication is received. A refill request may be made as part of an encounter or out-of-band through a pharmacy or patient portal. Since a prescription refill is requested outside of the prescriber's workflow, there often is not a user in context. Similarly, the encounter may be an auto-generated refill encounter or there may not be an encounter in context when the refill request is received. A CDS service may use this hook to deliver medication refill protocol guidance to a clinician. Given the asynchronous workflow of refill requests, the guidance returned by the service may be viewed immediately, or not.
13
+
14
+
This hook does not fire for an initial prescription (see order-sign). "Re-prescribing" or replacing a previously active prescription with a new perscription for the same medication does not fire the medication-refill.
15
+
16
+
## Context
17
+
18
+
The set of medications in the process of being refilled. All FHIR resources in this context MUST be based on the same FHIR version. All FHIR resources in the medications object MUST have a status of _draft_.
19
+
20
+
Field | Optionality | Prefetch Token | Type | Description
21
+
----- | -------- | ---- | ---- | ----
22
+
`userId` | OPTIONAL | Yes | *string* | In the case when this field is empty, consider the FHIR resource's requestor and recorder elements. <br />The id of the current user entering the refill request within the CPOE. For this hook, the user is expected to be of type Practitioner or PractitionerRole. For example, PractitionerRole/123 or Practitioner/abc.
23
+
`patientId` | REQUIRED | Yes | *string* | The FHIR `Patient.id` of the current patient in context
24
+
`encounterId` | OPTIONAL | Yes | *string* | The FHIR `Encounter.id` of the encounter associated with the refill of the prescription.
25
+
`medications` | REQUIRED | No | *object* | R4 - FHIR Bundle of _draft_, _order_ MedicationRequest resources
The `order-dispatch` hook fires when a practitioner is selecting a candidate performer for a pre-existing order that was not tied to a specific performer. For example, selecting an imaging center to satisfy a radiology order, selecting a cardiologist to satisfy a referral, etc. This hook only occurs in situations where the order is agnostic as to who the performer should be and a separate process (which might be performed by back-office staff, a central dispatch service, or even the ordering clincian themselves at a later time) is used to select and seek action by a specific performer. It is possible that the same order might be dispatched multiple times, either because initial selected targets refuse or are otherwise unable to satisfy the order, or because the performer is only asked to perform a 'portion' of what's authorized (the first monthly lab test of a year-long set, the first dispense of a 6 month order, etc.)
11
+
The `order-dispatch` hook fires when a practitioner is selecting a candidate performer for a pre-existing order or (set of orders) that was not assigned to a specific performer. For example, selecting an imaging center to satisfy a radiology order, selecting a cardiologist to satisfy a referral, etc. This hook only occurs in situations where the order is agnostic as to who the performer should be and a separate process (which might be performed by back-office staff, a central dispatch service, or even the ordering clincian themselves at a later time) is used to select and seek action by a specific performer. It is possible that the same order might be dispatched multiple times, either because initial selected targets refuse or are otherwise unable to satisfy the order, or because the performer is only asked to perform a 'portion' of what's authorized (the first monthly lab test of a year-long set, the first dispense of a 6 month order, etc.). Note that the order isn't updated to include the performer in this situation, as the authorization of who could theoretically perform the order isn't changed by seeking fulfillment by a specific provider.
12
12
13
13
This "request for fulfillment" process is typically represented in FHIR using [Task](http://hl7.org/fhir/task.html). This resource allows identifying the order to be acted upon, who is being asked to act on it, the time-period in which they're expected to act, and any limitations/qualifications to 'how much' of the order should be acted on.
14
14
@@ -19,25 +19,26 @@ Decision support that may be relevant for this hook might include information re
19
19
Field | Optionality | Prefetch Token | Type | Description
20
20
----- | -------- | ---- | ---- | ----
21
21
`patientId` | REQUIRED | Yes | *string* | The FHIR `Patient.id` of the current patient in context
22
-
`order` | REQUIRED | Yes | *string* | The FHIR local reference for the Request resource for which fulfillment is sought E.g. `ServiceRequest/123`
22
+
`dispatchedOrders` | REQUIRED | Yes | *array* | Collection of the FHIR local references for the Request resource(s) for which fulfillment is sought E.g. `ServiceRequest/123`
23
23
`performer` | REQUIRED | Yes | *string* | The FHIR local reference for the Practitioner, PractitionerRole, Organization, CareTeam, etc. who is being asked to execute the order. E.g. `Practitioner/456`
24
-
`task` | OPTIONAL | No | *object* | DSTU2/STU3/R4 - Task instance that provides a full description of the fulfillment request - including the timing and any constraints on fulfillment
24
+
`fulfillmentTasks` | OPTIONAL | No | *array* | DSTU2/STU3/R4/R5 - Collection of the Task instances (as objects) that provides a full description of the fulfillment request - including the timing and any constraints on fulfillment. If Tasks are provided, each will be for a separate order and SHALL reference one of the dispatched-orders.
Copy file name to clipboardExpand all lines: docs/hooks/order-select.md
+15-9Lines changed: 15 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,18 +8,19 @@
8
8
9
9
## Workflow
10
10
11
-
The `order-select` hook fires when a clinician selects one or more orders to place for a patient, (including orders for medications, procedures, labs and other orders). If supported by the CDS Client, this hook may also be invoked each time the clinician selects a detail regarding the order.
12
-
This hook is among the first workflow events for an order entering a draft status.
13
-
The context of this hook may include defaulted order details
14
-
as it first occurs immediately upon the clinician selecting the order from the order catalogue of the CPOE, or upon her manual selection of order details (e.g. dose, quantity, route, etc). CDS services should expect some of the order information to not yet be specified.
15
-
Additionally, the context may include previously selected orders that are not yet signed from the same ordering session.
16
-
The `order-select` hook occurs after the clinician selects the order and before signing.
11
+
The order-select hook occurs after the clinician selects the order and before signing.
17
12
18
-
This hook is intended to replace (deprecate) the `medication-prescribe` hook.
13
+
This hook occurs when a clinician initially selects one or more new orders from a list of potential orders for a specific patient (including orders for medications, procedures, labs and other orders). The newly selected order defines that medication, procedure, lab, etc, but may or may not define the additional details necessary to finalize the order.
14
+
15
+
`order-select` is among the first workflow events for an order entering a draft status. The context of this hook may include defaulted order details upon the clinician selecting the order from the order catalogue of the CPOE, or upon her manual selection of order details (e.g. dose, quantity, route, etc). CDS services should expect some of the order information to not yet be specified. Additionally, the context may include previously selected orders that are not yet signed from the same ordering session.
16
+
17
+
This hook is intended to replace (deprecate) the medication-prescribe hook.
Decision support should focus on the 'selected' orders - those that are newly selected or actively being authored. The non-selected orders are included in the context to provide context and to allow decision support to take into account other pending actions that might not yet be stored in the system (and therefore not queryable).
23
+
Decision support should focus on the 'selected' orders - those that are newly selected or currently being authored. The non-selected orders are included in the context to provide context and to allow decision support to take into account other pending actions that might not yet be stored in the system (and therefore not queryable).
23
24
The context of this hook distinguishes between the list of unsigned orders from the clinician's ordering session, and the one or more orders just added to this list. The `selections` field contains a list of ids of these newly selected orders; the `draftOrders` Bundle contains an entry for all unsigned orders from this session, including newly selected orders.
24
25
25
26
Field | Optionality | Prefetch Token | Type | Description
@@ -28,9 +29,14 @@ Field | Optionality | Prefetch Token | Type | Description
28
29
`patientId` | REQUIRED | Yes | *string* | The FHIR `Patient.id` of the current patient in context
29
30
`encounterId` | OPTIONAL | Yes | *string* | The FHIR `Encounter.id` of the current encounter in context
30
31
`selections` | REQUIRED | No| *array* | The FHIR id of the newly selected order(s).<br />The `selections` field references FHIR resources in the `draftOrders` Bundle. For example, `MedicationRequest/103`.
31
-
`draftOrders` | REQUIRED | No | *object* | DSTU2 - FHIR Bundle of MedicationOrder, DiagnosticOrder, DeviceUseRequest, ReferralRequest, ProcedureRequest, NutritionOrder, VisionPrescription with _draft_ status <br/> STU3 - FHIR Bundle of MedicationRequest, ReferralRequest, ProcedureRequest, NutritionOrder, VisionPrescription with _draft_ status <br/> R4 - FHIR Bundle of DeviceRequest, MedicationRequest, NutritionOrder, ServiceRequest, VisionPrescription with _draft_ status
32
+
`draftOrders` | REQUIRED | No | *object* | A Bundle of FHIR request resources with a draft status, representing orders that aren't yet signed from the current ordering session.
32
33
34
+
### A Note Concerning FHIR Versions
33
35
36
+
CDS Hooks is designed to be agnostic of FHIR version. For example, all versions of FHIR can represent in-progress orders but over time, the specific resource name and some of the important elements have changed. Below are some of the mosty commonly used FHIR resources for representing an order in CDS Hooks. This list is intentionally not comprehensive.
37
+
* DSTU2 - FHIR Bundle of MedicationOrder, ProcedureRequest
38
+
* STU3 - FHIR Bundle of MedicationRequest, ProcedureRequest
39
+
* R4 - FHIR Bundle of MedicationRequest, ServiceRequest
0 commit comments