This wiki has undergone a migration to Confluence found Here

Difference between revisions of "Conceptual BF Document"

From HL7Wiki
Jump to navigation Jump to search
Line 33: Line 33:
 
==Storyboards and Discussion==
 
==Storyboards and Discussion==
 
Below follows storyboards and discussion immediately after each to highlight relevant points from that particular use case or set of use cases.  To start, the simplest use case:
 
Below follows storyboards and discussion immediately after each to highlight relevant points from that particular use case or set of use cases.  To start, the simplest use case:
* [[Lab UV SB Simple|Universal Storyboard – Simple]]
+
===[[Lab UV SB Simple|Universal Storyboard – Simple]]===
* [[Lab UV SB Revise|Universal Storyboard – Revise, Hold, Abort]]
+
===[[Lab UV SB Revise|Universal Storyboard – Revise, Hold, Abort]]===
  
  

Revision as of 21:56, 16 September 2010

Link back to project page BF Alpha Project

Laboratory Ordering and Fulfillment

The Architecture Review Board (ArB) in conjunction with the Orders & Observations Work Group selected the Laboratory Domain to challenge the new SAIF Behavioral Framework and methodology. OO and the former Lab SIG/WG were stuck for years in balloting by a negative vote which Lab itself was unable to solve (and therefore, Lab eventually withdrew the Lab Order topic ever since). That negative was in it's basis a negative-major comment regarding the lack of the current dynamic model and balloted artifacts to sufficiently communicate the Laboratory Ordering interoperability behaviors.

Document Status

Note that this document is in development, so pre-draft. It’s being circulated amongst a few HL7 work groups to socialize the discussion topics which lead to the foundation of the SAIF behavioral model requirements. Feel free to provide feedback; with that understanding (this is pre-draft). To find unfinished parts, search for <???> and for Discussion point: The <???> denote places where the core authoring team is adding content. Discussion point: items are so tagged to initiate places for OO, et. al. to discuss

Document Purpose

The purpose of this document is to highlight and discuss requirements for the SAIF behavioral model (aka dynamic model) as well as recommended business and technical artifacts needed to support this new model. The basis or source of business information for this document is healthcare services storyboard narratives, specifically those about lab ordering and resulting, collected from the International HL7 Standard, Canada, United Kingdom, and Australia. The intended audience for this paper is the Health Level 7 International Organization (HL7).

Overview

The HL7 Architecture Review Board is proposing that HL7 use a new framework for developing standards. The framework, called Services-Aware Interoperability Framework (SAIF), is based on principles from a few industry standards (e.g. RM-ODP, SOA) customized for the specific standards environment which is the business of HL7. This framework is defined and described by four components:

  • Enterprise Conformance and Compliance Framework (ECCF)
  • Governance Framework (GF)
  • Behavioral Framework (BF)
  • Information Framework (IF)


The Behavioral Framework includes a behavioral model which documents the ‘actions’ during the exchange of information between systems. In the current HL7 methodology, this is referred to as the dynamic model.

The key concepts in the current dynamic model are trigger events (what is the receiving system to ‘do’ with the information communicated), receiver responsibilities (what other activities does the receiving system perform in response to receiving a communication), triggering events (what happened on the sender side that caused this exchange of information), and status codes (represents the ‘state’ of objects within a communication). See Appendix B for a list of dynamic model requirements as seen through a MIF (model interchange format) viewpoint.

In SAIF, the behavioral model is the definition and description of expected behaviors the sender is requesting the receiver to perform with the included information model. Prior to SAIF, this was called the dynamic model and included trigger events and receiver responsibilities. To determine and discuss the requirements for the SAIF behavioral model, this document will start with simple use case narratives (storyboards) and progress towards more complex use cases with discussion after each narrative to elaborate behavioral model, information model, and governance model impacts unique to that narrative focusing on the behavioral aspects.

This discussion document initially frames behavioral requirements via HL7 storyboard narratives from the Laboratory domain which describe increasingly complex behavioral interoperability paradigms. The Lab domain is the most complex set of behavioral/process flows owned by the Orders and Observations Work Group and was chosen as the basis for behavioral model discussions in this document.

Following each storyboard narrative is a breakdown of the represented business process, objects for exchange, and the state or status of each object if appropriate. From these data points, requirements will be abstracted and documented.

Storyboards and Discussion

Below follows storyboards and discussion immediately after each to highlight relevant points from that particular use case or set of use cases. To start, the simplest use case:

Universal Storyboard – Simple

Universal Storyboard – Revise, Hold, Abort

Australian Storyboard – Result Report Eve Everywoman, a 27-year-old female, presents at Good Health Hospital Outpatient Clinic and is seen by Dr. Debbie Dermatologist. Eve reports a history of skin problems and Dr Debbie does an evaluation of a few ‘spots’ on Eve’s face and nose. Dr. Debbie takes a skin scraping for analysis of one of the spots. Dr. Debbie enters the requested test into her care system, which sends the tests to the Good Health Hospital’s Laboratory service. When the laboratory service accepts the tests and promises to perform them, the promise is communicated to Dr. Debbie’s care system. The lab performs the analysis on the received specimen and formats the results into a clinical report. The results meet the established criteria for releasing the report, but not for automatically authorizing the report, so the Lab system sends an interim or provisional report to Dr. Debbie’s Care System. Later, the report is reviewed by a qualified Pathologist who approves it, and the lab system sends a final report to Dr Debbie’s Care System. Business Process This is a more complex business process as it adds two more objects and potentially many more exchanges of information between systems. In this use case, a Promise is communicated from the fulfilling system to the requesting system with an ‘intent to perform’ an action or set of actions in response to the request. Note that there is a different object for the report in addition to a result object. A report is a document, captured at a point-in-time, authenticated, which contains results and a human-readable representation of the results. Storyboard Objects From this storyboard and the implied business process, we can derive six objects that the interactions that occur are concerned about:

The request, fulfillment, and result objects are the same as the simple use case. However, the more complex use case introduces three new objects: Promise, Reporting and ReportDocument. Additionally, introduction of these three objects does increase the number of states (or statuses) for the fulfillment object itself. The Promise object is created on the Lab Information System when that system communicates that the lab intends to perform testing in response to the request. It will have an identity of its own, and it will contain some link to the patient Eve, the request identity, the requested tests, and the promised test(s). Note that the list of promised test(s) is not always the same as the requested test(s). There are circumstances where the lab cannot perform the test as ordered (for example, lab intends on using a different method vs. the requested method). The Reporting objects are tied directly to the Results objects and asserts whether a particular result is preliminary, final, or corrected. The Reporting object is associated with the reporting process step for each result. In addition, each of these objects has a status. We can derive the following states and transitions from the storyboard for the Promise object:

For the Promise, initially the Lab receives a request for fulfill diagnostic testing for a patient on a specimen. Whether the specimen has already been collected, or is expected to be collected, is a relevant point to what the lab is promising to perform. There are, therefore, separate states to represent the difference between communicating an ‘intent to collect’ vs. an ‘intent to fulfill’ the request. Once resulting is complete, the promise is expected to be completed similarly. Once a request arrives, the lab system decides whether it’s going to promise to perform the request, depending on configuration. This might a simple decision – automatically yes; or it might require confirmation from a human potentially somewhere else to grant financial approval. If the lab does communicate the intent to perform the requested tests, a promise is sent and the lab system moves into a ‘working’ state. Note that the working state of the lab system isn’t represented in the object status diagrams as this state is internal to the lab system and isn’t a concern of interoperable functionality. Interoperable functionality is about interactions between the externally observable states of the systems which cause information exchange. Some state models, particularly internal models, would not have the state ‘working’ instead using the state ‘intent to fulfill’ meaning an intent to fulfill was communicated but not yet resolved or completed. We can derive the following states and transitions for the Reporting object:

The Reporting object communicates the business status of the result. Specifically, whether the report has been finalized (implying all QA is complete, the result is ‘signed’ by the Medical Director), prior to finalized (so, preliminary), or corrected. Although all three states are not covered in this scenario, all are presented as a complete list for brevity. A later scenario details the usage of the corrected Reporting status. Finally for this storyboard, we have the report documents themselves. We can derive the following states and transitions for the ReportDocument object:

In an interim result report, the data is available but not all the QA processes are complete on it (usually human review); so the Result is made available on a provisional or preliminary basis. The result ReportDocument may be recorded and communicated; but the document is not yet authenticated. For some results, the Result and ReportDocument are not made available until all QA is perform based on clinical risk assessment, while for other occasions the timely availability of unQA’ed results is actually the lower clinical risk (usually there’s a time urgency involved). Once the QA is complete for any result reported as preliminary and all additional processing complete (for example, micro-biology testing), the result is reported as final, the document authenticated, recorded, and usually communicated. Note that the lab processes of resulting and reporting continue after the request/promise cycle has been finalized. For instance the lab system may advise the care system that the tests it requested are now complete (final), and then subsequently an error is discovered, leading to the issuance of a corrected (Reporting) result and an amended report. It must not be necessary to re-activate the Request, the Fulfillment, or the Promise in order to send a correct Result and an amended ReportDocument. There’s no business process reason for the Request, Fulfillment and Promise status to change – the lab simply sends the amended report. In addition, there may be other business workflows that lead to the lab sending reports to the care system which had no care system request associated with them at all. So it’s both easier and more faithful to real life to treat the Reporting object and ReportDocument object as separate entities. Universal Storyboard – Microbiology Result Report (Corrected Result) A 24-year old female, Eve Everywoman, presents at Community Urgent Care with severe headaches, numbness and tingling. Dr. Harold Hippocrates examines the patient and learns that she is employed in the Manufacturing Industry where she is exposed to Lead based products. Dr Hippocrates wants to rule out Lead poisoning. Dr. Harold Hippocrates places the order for a STAT Lead Level test. The order fulfillment request is sent from the Clinical Information System to the Laboratory. The laboratory system receives the order fulfillment request and determines that it meets its requirements. It immediately responds with a promise to the clinical information system. Eve Everywoman goes to the laboratory one week later. Rita Receptionist finds the order for a Lead Level. The system assigns the accession number and prints the specimen label. Boris Bleeder collects the specimen in a tan top (EDTA) tube. He enters the collection date/time (0700 on December 24, 2003) and specimen type into the laboratory system. He delivers the specimen to be processed. The laboratory system sends a status message indicating “Specimen in Lab” process step of its promise to the clinical information system. The clinical information system receives the promise status message from the laboratory system. It updates the process step of its order to “Specimen in Lab” and responds to the laboratory system with an order status response message. Bill Beaker performs the test and determines that the level is within OSHA guidelines. He releases them for final reporting and faxes the report to Dr. Hippocrates in accordance with STAT protocol. . Chemistry Observation/Test Name: Lead Level Result Value/Flag: 30 ug/dL Normal Range: 40 ug/dL Date/Time of Observation: December 24, 2003 0900 The laboratory system sends the final result to the clinical information system. The clinical information system determines that the result meets its requirements for confirming it. It sends a message to the laboratory system indicating that it has confirmed the final result. The clinical information system sets its order status to complete. Dr Hippocrates reviews the result on December 27, 2003 and questions the result because it does not appear to correlate with his diagnosis. He calls the laboratory and asks for the test to be performed again on the initial specimen.

Corrected Result

Bill Beaker re-runs the Lead Level on the initial specimen. The result is 110 ug/dL. Just to confirm, he performs QA on the instrument. He analyzes the specimen again due to the large discrepancy between the initial reported result and the new result. The result this time is 112 ug/dL. He averages the two results and reports out 111 ug/dL. He reviews the result and reports it out as corrected. Chemistry Observation/Test Name: Lead Level Result Value/Flag: 111 HH Normal Range: 40 ug/dL Date/Time of Observation: December 27, 2003 1200 He notifies Dr. Stan Slide, Laboratory Pathologist of the discrepancy. The laboratory system sends the corrected result to the clinical information system. The clinical information system determines that the corrected result meet its requirements for confirming it. It sends a message to the laboratory system indicating that it has confirmed the corrected result. The clinical information system updates its order status to reflect the corrected order completion date. Bill Beaker initiates the panic value protocol which includes releasing the corrected result with note attached indicating that Dr. Hippocrates was notified on December 27, 2003 at 1200. The information is sent to the appropriate regulatory agencies governing Lead testing. Business Process This business process doesn’t introduce new objects, just new states for those objects and a few new transitions. The new states are ‘corrected’ for one or more Reporting objects and a new Fulfillment status ‘specimen received’. Diagrams will follow with these two additions, later in this document along with succeeding additions. Australian Storyboard – Withdrawn Report <???> A 24-year old female, Eve Everywoman, need withdrawn report storyboard narrative. Reports may be withdrawn at any time if the laboratory discovers an error in the work that was done for some reason. Withdrawal implies a somewhat active process, hunting down any existing copies of an erroneous report and speaking to anyone who may have made clinical decisions based on the report – though this is not always possible. After an error is corrected (if possible), a corrected report may be issued – this is considered to be an amended report. Discussion point: withdrawn reports are an Australian concept. In the US, Labs do not ‘withdraw’ lab results. For clinical lab – result is corrected. For pathology – result report is amended. If we want to talk about withdrawn reports, then create a storyboard to illustrate and introduce the concept before discussing. Universal Storyboard – ReportDocument Events Incomplete ReportDocument A pathology resident performs a gross dissection examination of the tissue submitted from a surgical procedure to remove the gall bladder of a 37 year old female patient. The pathologist assigns a surgical case number to the study and dictates his observations into a central dictation system. A transcriptionist keys the text into a document application. This application exchanges the document from the Transcription Manager to the surgical pathology system. Since a complete surgical pathology exam contains microscopic findings and conclusions the Document Completion Status of the document is marked as "Incomplete". Pre-Authenticated ReportDocument Later, another junior pathology resident performs the microscopic exam and dictates the remainder of the pathology report. A transcriptionist keys the text additional text into a document application. This application exchanges the document from the Transcription Manager to the surgical pathology system with the document completion status of 'pre-authenticated'. Now that the content is presumed complete, the information exchange includes the pathology examination notification as well as the findings. Authentication Later a staff (board certified) pathologist "over-reads" the slides and the text of the report and agrees that the junior resident's findings were correct. This pathologist has sign-out authority. He thus legally authenticates this surgical pathology exam document. Based on the business rules of an information exchange, the document is generated from the document application and communicated to the surgical pathology system containing the full report content and an authentication status of "legally authenticated". The above narratives are the basis for the increasingly complex narratives which follow. Document Addendum Notification During the initial gross dissection of the gall bladder tissue, the prosector discovered a small, hard, 4mm brownish green inclusion that the pathology resident felt was consistent with a gall stone. This "stone" was removed and sent out to a reference laboratory for X-ray Crystallography analysis to confirm that the inclusion is indeed a gallstone and to determine the composition of the stone. In preparing the specimen for submission to the reference laboratory, a requisition is filled out where the surgical case number assigned to the gallbladder surgical pathology exam is listed as the parent document ID together with the patient demographics and identifiers and the exam requested. The reference lab performs the steps of the specimen intake process for requested study with the original surgical case number being used as the parent document ID and their own reference laboratory assigned accession number being used as the report identifier. The reference laboratory document manager application generates a document addendum notification exchange to the referring hospital's surgical pathology document manager application indicating the assigned document ID with a document completion status of "in progress". Document Addendum Notification and Content The reference lab performs the analysis and confirms the presence of a gall stone and identifies the chemical composition of the crystals that make up the stone. The text is verified by the X-ray Crystallography technician who then reviews the text online and authenticates its accuracy. In the reference laboratory the technician has, by institutional policy, the authority to sign out reports. The reference laboratory document manager application generates a document addendum notification and content exchange to the referring hospital's surgical pathology document manager application indicating the assigned document ID with a document completion status of "legally authenticated". Document Edit Notification Only documents that have not been released for patient care (i.e. have a statusCode of "new") can be edited. Once a document is "active" or "completed", it needs to be formally revised. The pathology resident has authenticated the original full text of the gall bladder surgical pathology exam, but because of institutional business rules, the document remains "new" until it is legally authenticated. The need for a change is discovered by the staff pathologist "over-reading" the case findings. The pathologist dictates the changes that will be subsequently keyed into the transcription manager application. An information exchange containing the notification of the intended edit is generated by the transcription manager application and sent to the Document Manager application. Note that the ID and Set ID field values do not change during edits. Local business rules in each application domain dictate whether a document's version number is incremented with successive edits. Document Edit Notification and Content The pathologist over-reading that surgical pathology exam identifies additional benign morphologic changes to the gall bladder and dictates the changes that are now keyed into the transcription manager application. Once the edited modification to the gall bladder surgical exam has been applied, a message will be generated. An information exchange containing the modified content is generated by the transcription manager application and sent to Document Manager application. Because the content has not been released for patient care the Document Manager receiving the document via exchange over-writes the original content with the content supplied. Document Replacement Notification Only documents that have not been released for patient care (i.e. have a statusCode of "new") can be edited. Once a document is "active" or "completed", it needs to be formally revised. The pathology resident has authenticated the original full text of the gall bladder surgical pathology exam, and at the resident's institution, the policy is to make documents available for patient care before they are legally authenticated, so the document is advanced to "active" status. The need for a change is discovered by the staff pathologist "over-reading" the case findings. The pathologist dictates the changes that will be subsequently keyed into the transcription manager application. An information exchange containing the notification of the intended revision is generated by the transcription manager application and sent to Document Manager application. In this case there is an earlier document available for patient care that has been found to be inaccurate. Document Replacement Notification and Content The pathologist over-reading that surgical pathology exam identifies additional benign morphologic changes to the gall bladder and dictates the changes that are now keyed into the transcription manager application. Once the revision to the gall bladder surgical exam has been applied, a message will be generated. An information exchange containing the notification and content of the change is generated as a replacement document by transcription manager application and sent to Document Manager application. Document Cancel Notification The gall bladder surgical pathology exam document was inadvertently assigned to the wrong patient. While an original document was generated it contained a status code value of 'new' (because it had not been made available for patient care). The document can be cancelled. If a document has been made available for patient care, then this interaction cannot occur. Once any form of a document has been released for patient care it must be replaced or repudiated. An information exchange containing the cancellation is generated by the document management application and sent to any and all previous recipients of Medical Document Management messages for this document. Document Repudiation Notification The gall bladder surgical pathology exam document was inadvertently assigned to the wrong patient, and the document was subsequently made available for patient care. An original document was generated and has acquired a status of 'active', so can no longer be canceled. Instead, the original document is repudiated, and its status is changed to 'nullified'. Business Process This business process shows how document objects are different than the result object itself. The document is a point-in-time artifact and has properties as such. Therefore there are document-specific trigger events which are captured above. Roles and Interactions <???> We can derive a set of roles and exchanges from the state machines, and use this information to build a set of business services. The first thing is to identify the roles. So far, we have: Order Requestor (Placer in v2) Places the original request, and waits for it to be complete Request Fulfiller Accepts the request, and then carries out the activities to fulfill what was asked Fulfillment Manager Monitors the Order Requestor as it receives activities which fulfill the original request and determines when the fulfillment activities ‘complete’ the request. The state transitions in the request and promise class are linked by exchanges between the systems that play the two roles. They can be presented in a tabular form: Initiator Name Information Request State Transition Promise State Transition Before After Before After OrderRequestor Request Request identity Patient identity Clinician Identity Test list Initial Active Initial Request to Fulfill Fulfiller Refusal Request Identity Patient Identity Reason for Refusal Initial Refused Request to Fulfill Rejected Fulfiller Accept Request Identity Patient Identity Predicted Delivery Time? Initial Promised Request to Fulfill Intent to Collect or Intent to Fulfill Fulfiller Complete Request Identity Patient Identity Active Complete Intent to Fulfill Complete Fulfiller Failed Request Identity Patient Identity Reason for Failure Active Aborted Intent to Fulfill Aborted

These interactions can be assembled into services using either request/response, publish/subscribe, or implemented using synchronous or asynchronous messages. But whatever the architecture, these are the essential information exchanges that need to occur. Missing from this table are other obligations that the order requestor and fulfiller have. Some of these obligations are shared in all the various incarnations of the lab request/report cycle, while others vary wildly. The most obvious obligations pertain to the fulfiller: • Carry out the work that is promised (if possible – i.e. can’t do it if the patient doesn’t turn up) • Ensure that either a complete or failed exchange actually happens in the end

Other obligations might be to validate that the request is valid, or to inform other systems, or to perform some further business processing. These obligations are out of scope when building an interoperability standard, as are the obligations on the placer such as ensuring that the order is one it is allowed to submit.

However, this is not all there is to lab orders. There are several key additional requirements that need to be provided for.

Order Brokers Canadian Storyboard – Jurisdictional Lab Information System Dr. Patricia Primary orders a set of tests on Eve Everywoman. Dr. Primary’s care system sends the order to the local-area lab repository. Dr. Primary’s care system prints a paper copy of the order requisition that tells her where she can have specimens collected and the testing performed. Eve can attend any laboratory to have the tests done – whichever one she chooses. When Eve actually presents at the laboratory of her choice, the laboratory system connects to the central broker and retrieves the order. The lab information informs the central broker that it is performing the tests (promise). The broker system sends the performing lab information to Dr Primary’s care system. Note this storyboard is just a fragment to document a specific process issue. Australian Storyboard – Test Challenge When Dr. Patricia Primary orders a set of tests on Eve Everywoman, her system contacts a central broker, requesting a test. The broker offers the test to multiple laboratories that may either accept or reject the test. If they accept the test, they must nominate a cost. The broker picks the cheapest offer received within a limited time, and returns that promise to Dr Primary’s system. It cancels the promises received from any other laboratories. Dr. Primary prints a paper copy of the request to hand to Eve, where it serves as a reminder and provides instructions for how to find the correct laboratory collection center, and perhaps also details some preparation instructions. Note this storyboard is just a fragment to document a specific process issue. Business Process Order brokers can also be known as clearing houses or order registries (or other names), and are growing in popularity, though there are also controversial aspects to their existence and operation. If we are going to have a standard that relates to laboratory orders, then it should allow the use of brokers without being too intrusive. The diagram below shows the request state machine for the test challenge storyboard.


Storyboard Objects The broker adds another object to the system: Discussion point: JK’s comment.

The Broker object doesn’t have a particular identity – we’re not interested in it as an entity in its own right (though of course the broker itself will have an identifier for the actual object it uses internally). But we do think of the status of the broker, and it does have a state machine that is of interest externally:

This is a more complicated state machine because it’s more dependent on the process that the broker is involved in, and because it is inserted between the placer and the fulfiller. The first dependency is the choice point for whether the broker is acting as an auction house, or just holding the request. If the broker is just acting to hold the request, it will hold the request until a lab contacts it for details when Eve actually turns up at the lab, at which time it will send the fulfillers promise to the placer. Under some circumstances, it will decide that it has held the request for too long, and time it out if Eve does not attend the lab within a specified time period. Whether this happens depends on business arrangements; for instance, there may be a legal requirement that the request is only legal for a limited period. This also applies to the lab system too, though this was not accounted for above. If the broker is acting as an auction house, it will conduct an auction by sending the request on two some registered list of lab systems. Once they have all responded, or some specified time period has been exceeded, or some other business decision is made, the broker can either decide that no lab is willing or able to provide the service, and it has failed, or it will pick a lab and return the promise. What happens next depends on whether the broker is mediating communications between the lab that is acting as a fulfiller and the placer. This choice is purely dictated by implementation details, whether it is practical for the placer and the fulfiller to communicate directly. If they do communicate directly, the broker’s involvement is complete, otherwise the broker status tracks the fulfiller status. The Broker acts as a façade for the fulfiller; in principle, the placer has the same exchanges with the broker as with a fulfiller, though the timing of the interactions could be very different, along with the technical communications architecture. Australian Storyboard - Follow-up Testing (Revise Order) One week after the initial consultation, Eve is again seen by Dr Patricia. After review of the results and the course of Eve’s condition, Dr Patricia decides that another lab test would be useful. Rather than asking Eve to go to the collection center again, Dr Patricia types the test into her system as a follow up test. Dr Patricia’s care system sends this request to the lab system, which replies, promising to perform this new test and whether the remaining volume of the current specimen is sufficient to complete the follow-up test(s). Note this storyboard is just a fragment to document a specific process issue. You could simply say that this is a new request, with a new promise. But in Australia there are legal requirements in many jurisdictions about this, and some specify that such follow up testing is logically done as a modification of the previous request. In these circumstances, it is much simpler to treat the follow up test as changing the status of the original test and adding new order components. And this can happen at any time, even after the request has been completed.

This adds two state transitions to the request object, and there are similar additions to the promise state machine. Order Manager The most common end state for the request cycle is that the laboratory or fulfiller claims that request has been completed. An important question is whether the placer agrees that whatever was requested has actually been performed. There are several reasons why the placer may not agree: Clerical error The whole point of this request cycle is that there should be no capacity for clerical error Configuration Error The mapping between the request code and the lab system test code may be in error Clinical Interpretation The lab applies clinical judgment when deciding what to do; there may be disagreement between the clinician and the lab in this area. For this reason, many clinical systems that place lab requests provide functionality to check what was performed against what was requested; this is known as an “Order Manager”. It also tracks the requests so that some clinical user can be alerted in the case that requests are not progressing or completed – for instance, if the patient does not attend any lab to have their specimen(s) collected. In order for the Order Manager to function, it must be able to track the laboratory reports and compare the list of reports received, along with their status and contents, against its own expected list. To enable the Order Manager to track the reports, all the reports that the lab sends to the placing system must identify the request(s) that the report is considered to be fulfilling. As discussed above, this may occur even after the request/promise cycle is complete. When the order manager detects an issue, it must notify a human. There are no request or promise state transitions related to the order manager. However there is an exchange related to the order manager: the order manager may inform the laboratory that it has detected an issue as well as informing its own users through some process that is out of scope for this analysis. In order to treat this consistently, we can define an order manager object, along with a laboratory equivalent.

Again, these objects do not have an explicit identity of their own that we interested in, and they do not need to directly exist in that form – all this is saying that from an external perspective, the systems behave as if these objects exist.

These are very simple state transition diagrams. There are many other potential states related to the interaction of the logical trackers with humans (review, mark-off, etc), but these are not relevant to the request/promise cycle. <???> do we need the storyboard where lab A can’t do all the tests, so the specimen is split and lab B does some of the testing. Sometimes, lab B reports back to the original orderer, other times lab B reports to Lab A; who compiles all reports and communicated <???> add Austin’s public health storyboard? Namely CDC requests specimen, local lab system ‘places’ order – public health entity is the fulfiller. <???> Standing order tracking fulfillment story board <???> other pending order (np orders, md student orders) which require supervision <???> order authorization? <???> what other storyboards do we need to fill out the requirements for lab fulfillment? Putting it all together Taking all these extra factors gives us final state transitions for request and promise that look like this:


John's alternate state machine for fulfillment:

The broker object gets its own set of suspend and cancel related states as well (not shown). From these state transitions, we can derive a new set of roles and exchanges. Roles: Placer Places the original request, and waits for it to be complete. May have an order manager Broker Chooses a lab, or holds the request until the patient chooses a lab. May mediate communications subsequently Fulfiller Accepts the request, and then carries out the activities to fulfill what was asked

Initiator Name Information Request State Transitions Promise State Transition Before After Before After Placer Request Request identity Patient identity Clinician Identity Test list Initial Seeking Initial Deciding Placer Modify Request identity Patient Identity New Test list No change No Change – either Accept or Reject needed Placer Suspend Request identity Patient Identity Waiting Suspended In Progress Suspended Placer Unsuspend Request identity Patient Identity Suspended Waiting Suspended In Progress Placer Cancel Request Identity Patient Identity Reason No change No Change – either Accept or Reject needed Fulfiller Refusal Request Identity Patient Identity Reason for Refusal Seeking Refused Deciding Rejected Fulfiller Accept Request Identity Patient Identity Predicted Delivery Time? Seeking Waiting Deciding Working Fulfiller Accept Modify Request Identity Patient Identity Waiting | Complete Waiting In Progress | Complete In Progress Fulfiller Reject Modify Request Identity Patient Identity Reason No Change No Change Fulfiller Accept Cancel Request Identity Patient Identity Waiting Canceled In Progress Canceled Fulfiller Reject Cancel Request Identity Patient Identity Reason No Change No Change Fulfiller Complete Request Identity Patient Identity Waiting Complete Working Complete Fulfiller Failed Request Identity Patient Identity Reason for Failure Waiting Aborted Waiting Failed

The broker plays the roles of both placer and fulfiller. It has the same exchanges, though the state transitions and the consequential workflow differ. However there are few broker specific exchanges. In the mode where the broker holds the request waiting for a patient to attend a laboratory, we need an exchange to allow the laboratory to find any outstanding requests for that patient. For the broker mode where the broker holds an auction for the request, we could implement it using the exchanges described above, but that leads to an odd workflow. Given the exchanges above, when the broker receives a request, it would hand the request on to all participants of the auction, who would all then ‘accept’ the request. The broker would pick the best offer, and cancel all the others. Perhaps the others may refuse to cancel, but that would be pretty pointless. This is possible, but it doesn’t really match what’s going on, and it’s going to at least cause confusion for the implementers. So it’s better to define specific exchanges. Initiator Name Information Promise State Transitions Broker State Transition Before After Before After Fulfiller Query Patient identity Initial Searching No Change Broker Query Response Patient identity (Request Info)n No Change No Change Broker Auction Request identity Patient identity Clinician Identity Test list Initial Costing No Change Placer Bid Request identity Cost Costing Bid Wait for outcome of Auction


Appendix A - Comments, Questions, Concerns Summary

Two-step request/fulfillment breakdown works nicely (no next step, just confirmation of the general architecture). Need to handle minimal use case which is order, then result (report) with no promise. (review doc again with this idea in mind, some of the wording does need to change, I think). Next step (JK to ensure promise isn’t mandatory throughout) Storyboards need work. What’s included is a good start but many need clarification. Next step: AJK and PEL to suggest modifications to included storyboards and create new ones if needed. Need storyboard which shows minimal path (request with specimen included, result report), a good complex path (let’s use micro since this also shows prelim vs. final reporting, include corrected with this storyboard), a repository path (order broker), and order manager (edge use case, I think). Redo state machines (JK) – do we need another view or do we wait until next, more detailed iteration? This doc is more of a DAM for a behavioral framework. That’s in next step. Need to ensure messaging, services, and documents are in scope of the solution. Framework concept model for OO including down a notch into services (JK) Think introducing the idea of a broker in this particular doc is implementation-specific? Need to support the bf of brokering. May need to add variety of accountability paradigms (JK). GG to review.

We realize this is early in the process, but both Austin and I were surprised that we didn’t see more of the ‘new’ language of behavioral framework (words like collaborations, exchanges, contracts, etc).  Of course, could be this is too early and that’s the next step (or a step after).

We are seeing new ‘states’ as they relate to services which break down differently than messaging (of course). But it’s difficult to tell how the various HL7 state machines map to the service states. In one of the last diagrams, we do see the suspend state (so that’s a start). Next step: Austin and Patrick to review current state machine, lab result and bring back any that are not addressed in current doc. Need to buffer up use case re: order manager. One of the peculiarities of order management is that of recurring orders. Both the BF and the information model needs to handle. Need a storyboard which illustrates this requirement. Next step: Austin and Patrick to create storyboard Need to review, in gory detail, all the state machines for request and for fulfillment. Review on a call with Austin, Patrick, Grahame, John K