FHIR Workflow Discussion

FHIR Workflow Issues

Discussion Scope

Spans clinical, administrative, financial, etc. Includes synchronous and asynchronous exchanges. Focus is REST but needs to work in Messaging and services (Operation) approaches too.

Relevant Resources

• “Workflow” resources – manage requests for action and responses to requests for action:
  • Order, OrderResponse,
  • ProcessRequest, ProcessResponse (these resources include a mixture of action request, query and transport-level actions)
  • MessageHeader
• “Definition” resources – Define what can be done:
  • Questionnaire
  • DataElement
  • At least one more is needed to cover the notion of Protocols (study protocols, chemotherapy protocols, order sets, etc.) Performed protocols?
• “Request/Intent” resources – resources that define proposals, plans or requests for action:
  • ReferralRequest, ProcedureRequest, NutritionOrder, VisionPrescription, MedicationOrder, DiagnosticOrder, Appointment, DeviceUseRequest, SupplyRequest – These all mostly work the same way
  • CarePlan – this acts as a grouper for other proposals/plans and can’t be instantiated as a request
  • ImmunizationRecommendation – this also can’t (currently) be instantiated as a request
• “Action” resources - resources that capture the record of some action (possibly based on a proposal/request):
  • Procedure, MedicationAdministration, MedicationDispense, Immunization, Encounter, EpisodeOfCare, Communication, SupplyDelivery, Coverage, PaymentNotice, PaymentReconcilliation, ExplanationOfBenefit, DeviceUseStatement
• “Confirmation” resources – resources that provide information while also satisfying workflow requirements
  • AppointmentResponse, EligibilityResponse, EnrollmentResponse, ClaimResponse
• “Finding” resources – Information that has been gathered about a subject, possibly in response to a request:
  • FamilyMemberHistory, RiskAssessment, Observation, DiagnosticReport, ImagingStudy, QuestionnaireResponse
  • AllergyIntolerance, Condition, MedicationStatement

Use Cases

1. Need to differentiate between existence of records and “request to action” the record. I.e. Posting a prescription to a server shouldn’t cause pills to start being counted to fill the prescription, but there does need to be a mechanism to trigger the counting of pills.

1. 1. Might be able to use workflow “tags” to indicate that an Order record (or possibly even a Request record) is not actionable. Some sort of “archival” flag that says “this is a record/copy of a request that is not itself actionable”.
   2. Need to decide whether fulfillment requests are always done using Order/OrderResponse or whether in some cases they can be done directly using the [x]Request resources.
      1. Advantage is that this is simpler/more natural where the target of fulfillment is intrinsic in where it’s posted to or the data present in the order
      2. Disadvantage is that there’s now many different things that can trigger workflow and it may overload the ‘request’ resource with information that’s important in some workflows and is a duplicate of what’s in Order in other workflows.

2. Most important “please action” is around creation of an order. However, can have similar requirements for “order is suspended” or “order is aborted”

1. 1. This is really about any type of change to the order – where to deliver results, what to do, when to do it, etc.
   2. Candidate solution: Extend the Order resource to have an “action” or something like that that allows the Order to be used for purposes other than just “please fulfill” – e.g. “fulfill change” or “request status” – look at v2 order control codes as candidate list. (Note that don’t need to deal with request for changes to order as those can be handled directly via REST – need to consider whether that’s needed for messaging)
      1. Need to decide whether messaging needs the ability to be able to invoke “fine-grained” changes – change bed, suspend, resume, stop, etc. as opposed to a simple “update resource”.

3. Need a way to tie the responses to an “action” request to the request, particularly where not all actions will be tied to the same request. E.g. multiple “requests to dispense” against a single prescription – the dispense record would be tied to the individual requests.

1. 1. How do we identify which order components fulfillment is being sought for (or agreed to)?
      1. Order with multiple components
      2. Order with multiple repetitions
      3. Order with multiple quantities
   2. Need to update both Order and OrderResponse with the ability to identify the “activity types” within the overall order being requested/agreed to as well as the number of repetitions agreed to
   3. Sometimes multiple orders are fulfilled by a single response. Do we want to have a single OrderResponse pointing to multiple Orders or multiple OrderResponses each linked to their own Order but each OrderResponse refers to the same “result” (DiagnosticReport, Encounter, etc.)
   4. Picture:

Order from Dr. Smith (test A, test B, test C, test D)

FulfillmentRequest 1 (Order) to Lab A to run tests A, B & C

FulfillmentResponse (OrderResponse) to #1 agreeing to do tests A & B & W

Order from Dr. Jones (test A, test Z)

Fufillment Request 2 (Order) to Lab A to run tests A

FulfillmentResponse (OrderResponse) to #2 agreeing to do tests A

FulfillmentResponse (OrderResponse) providing results for A

DiagnositicReport showing results of test A

FulfillmentResponse (OrderResponse) to #1 pointing to DiagnositicReport saying A is complete and fulfillment request is partially complete

FulfillmentResponse (OrderResponse) to #2 pointing to DiagnosticReport saying complete

1. 1. Will probably need to be able to track statuses for each item within a fulfillment request/response as well as the overall fulfillment request
   2. When identifying child items in a fulfillment request, will identify by “code” – on presumption that item code will be unique within a given “request” resource.
   3. Hans to investigate whether this might be violated by Microbiology orders
   4. Alternative is to create a "derived" request resource that identifies exactly what is to be done by a particular fulfiller

4. What should we name Order/OrderResponse

1. 1. Candidates: Fulfillment[Request]/FulfillmentResponse; Event[Request]/Event[Response/Acknowledgment]; Action[Request]/Action[Response/Result/Acknowledgement]; Requisition[Request]/RequisitionResponse; Request/Response
      1. 1"Fulfillment" is a bit awkward and long
      2. 10"Action" - may cause confusion w/ v3, shorter
      3. 2"Requisition" not as intuitive, really applies to the order rather than the change of it
      4. 1"Event" - may be too broad - not specific to orders necessarily, aligned with v2 trigger events

Action[Request]/Action[Response/Result/Acknowledgement/Reply]

Decision: Go with ActionRequest and ActionResponse

5. Need to handle the cascade of requests and fulfillments. For example: Decision support engine creates a proposal for a patient to be on a medication protocol. Clinician adds a planned use of the medication therapy adjusting for patient weight and other factors. Intern creates a draft order. Physician activates the order. Pharmacy encodes the order. Pharmacy dispenses the medication to the ward. Pharmacy generates a MAR indicating the nursing administration schedule. Nurse administers the medication. So need to relate: Protocol, Proposal, Plan, Draft Order, Activated Order, Encoded Order, Administration Order, Dispense and Administration. At present, all italic artifacts would use the MedicationOrder resource. Need a way to tell them apart and also link them together (so plan can point to proposal, etc.)

1. 1. This includes relationships created through delegation and transfer

1. 1. Add a [request|baseRequest] element 0..* Reference([all 'relevant' request resources]) to all 'Request' resources with a definition "Indicates proposal, plan or higher-level order/requests that this [request resource] is actioning"
      1. Would love a better name . . .
   2. Add a 0..1 "[class|category]" CodeableConcept element to distinguish between proposals, plans, encoded, original, etc. Extensible binding

6. In the messaging world, at least, need to be able to submit requests for action on status that don’t necessarily echo back the entire structure. E.g. “Suspend this order” – “Ok, suspended” or “No, can’t suspend”. Or even “What’s the current status of this order?” – “In progress” – need to convey where within the business steps a given request is at. (Need some level of support for this in REST/services too.)

1. This could be done using an operation. Could also use Patch
   1. Some operations could be defined by expressing a sequence of "patch" operations to be performed on receiving an operation (some might be conditional)
2. Should we be using Operation for "What's the current status of this request?" rather than ActionRequest/ActionResponse?
3. ActionRequest implies that action (and more important, the decision) isn't necessarily immediate. With PUT, the change is either made immediately or rejected immediately
4. Operations can be defined in such as manner that the "response" to an operation might be "I'll consider it - i.e. deferred approval
5. May be necessary to use ActionRequest/ActionResponse for a status change if the decision on the status change won't be immediate
6. So 3 mechanisms - Patch, Operation or ActionRequest - each with different capabilities and guidance on when it should be used.

7. Need to be able to propose and plan status changes of other resources. E.g. “You should stop medication X”, “You should suspend blood draws for the next 12 hours”. (And need to have audit and provenance around the proposals and plans, as well as responses that say “I will” or “I won’t”.)

1. Will meet this by allowing ActionRequest to be a proposal or a plan using whatever mechanism we land on for distinguishing plan/proposal/order

8. Compensating actions: Some resources allow the action to be “undone” by changing the status on the resource to “cancelled” or “entered in error” or equivalent. Other resources are reversed by introducing a new resource that “undoes” the action of the previous resource (e.g. reversing a claim). This second approach is a "compensating action". Workflow will need to support both approaches (and it will need to be obvious which approach gets used when

1. Compensating actions are necessary when the thing to be reversed is something that has "happened" and can't be undone. Entered in error can only be used when no real-world action has occurred.

9. Order has timing information, including complex schedule information. Why is this needed and how does it relate to the timing information present on the order itself.

10. Composite orders: How do we handle orders for multiple types of things (drugs + devices + procedures)?

1. 1. Includes fulfillment of pieces
   2. Ability to independently manipulate child components (e.g. status changes)

11. We have overlap in some spaces E.g. SupplyRequest vs. DeviceUseRequest vs. VisionPrescription

12. Consistency

1. 1. Naming of resource – Request vs. Order vs. Prescription
   2. Naming of resource elements
   3. Order of resource elements
   4. Nesting capability within requests (DiagnosticOrder vs. ProcedureOrder) – what’s the boundary between what’s in a request vs. what’s handled by Composite Order?
      1. At what level of granularity can you identify the components
   5. Whether “ordering” information is present – who should perform
   6. Whether intended “fulfiller” information is present
   7. What statuses are used – workflow statuses such as accepted/rejected; whether proposed and planned are included
      1. Need to support for “business” statuses – how much can be fixed and should there be an explicit place for business status.
   8. At what levels can status exist
   9. E.g. Can multi-item orders have different statuses for each item?
   10. Whether status history is present
   11. W5 element consistency in general (name, type, cardinality, etc.)

13. We currently use “Status” to differentiate Proposed/Planned/full order. However, Proposals and Plans can also be draft, suspended, cancelled – which means that when an instance takes on one of those statuses, we lose the fact it was a proposal or plan. (So do we need some sort of a “mood” type thing on Order? - Could also be used to distinguish things like placer order vs. filler order.)

14. The names “Order” and “OrderResponse” are really confusing to people. Need to rename – EventRequest? FulfillmentRequest? ActionRequest?

15. There are challenges with attempting to convey "orders/authorizations", proposals and plans using the same resource - differences in data element.

Discussion points

• Sometimes “Actions” can be driver for subsequent requests. I.e. Indication/Reason
• Sometimes the authorization for an event occurs after the event itself (e.g. emergency administration)
• With order statuses, the situation where the filler asserts a status change (e.g. this filler order is cancelled) is already covered through standard status/resource update mechanisms, but we will need to document how this fits into overall workflow.
• Fulfillment requests can exist for proposals and plans, not just full authorized orders
• Need to think about order replacement codes (e.g. Order 1, 2 and 3 are replaced by Orders A and B)
• Do we need to support a “bid response” model where a request is sent to multiple fulfillers, they all provide proposals and then one fulfiller/proposal is selected and authorized for action.
• Need to differentiate between what needs to be inside the resources to support inter-system workflow vs. what might be in a resource to manage internal workflow processes. Proper scope of the resource is the former, though implementers using for FHIR for persistence or other purposes may have a need for the latter

Historical precedents

• ORC (and a bit of OBR/OBX) segment in v2
• ControlAct in v3

Interested WGs

OO, PC, MnM, FM, II, Pharmacy, HSI, PA, FHIR-I

Deliverables for next meeting

1. Spreadsheet that compares resource contents in each category: Lloyd
2. Identify candidate connectathon use-cases (interesting from “how will this work” as well as interesting to implementers)
   1. Radiology remote read: Keith B.
   2. Cross-departmental (admission, eligibility, orders, observations): Mary-Kay
   3. Lab order w/ negotiation, delegation and cancellation: Eric H.
   4. Pharmacy process (decision support recommendation -> plan -> order -> encoding -> mar -> dispense -> administration): Scott R.
   5. Referral lifecycle (including negotiation): Keith B.
   6. Visit appointment: Brian Post.
   7. Charge capture: Kathleen C.
   8. Protocol -> Decision support -> order set -> composite order: Patrick L.
3. Primer on BPMN and related methodologies as they might apply to this problem space & resources: Keith
4. List of resource scopes: Lorraine
5. Candidate Protocol resource: Lloyd