This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Conceptual BF Document

From HL7Wiki
Revision as of 22:03, 15 September 2010 by Ployd (talk | contribs)
Jump to navigation Jump to search

Link back to project page BF Alpha Project

Laboratory Ordering and Fulfillment

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: [[|Lab UV SB Simple|Universal Storyboard – Simple]] Universal Storyboard – Revise, Hold, Abort Eve Everywoman, a 27-year-old female, as an inpatient at Good Health Hospital and is attended by Dr. Patricia Primary. Dr. Primary checked Eve into the hospital yesterday when Eve lost consciousness during a routine exam in the Doctor’s office. Eve reports a history of Anemia and recent, excessive tiredness. Dr. Primary enters a request to check the iron levels in Eve’s blood into her care system. Dr. Primary’s care system then sends the test requests to the Good Health Hospital’s Laboratory service. A few minutes later, Dr. Primary determines to add a CBC (twice a day for the next 3 days) to the prior ordered iron level test. Dr. Primary updates the request and Dr. Primary’s care system send the updated request to the lab system. The laboratory service collects the appropriate specimens (2) on the first day and enters the results into the lab which communicates them to Dr. Primary’s care system. Dr. Primary determines on the second day, to hold all future testing and collection of blood for the CBC tests. Dr. Primary determines to discharge Eve on the third day (since the original CBC order) so the order is cancelled (aborted). Business Process The business processes shown in the storyboard above are meant to show the primary business triggers for information exchanges between care sites and laboratory testing services. This storyboard illustrates additional request object states:

Though each of the two new states is relatively simple in concept, they add a few more state transitions to/from those states. Note that all request states are just that, requested. There are a number of reasons for a place to request cancellation of an order. However, the laboratory does not always honor the request to cancel the request; whether it does so depends on a combination of whether the specimen has already been collected, the expense of the testing process, and how the laboratory is paid. Note that the repeating request is actually broken into individual requests, each of which is processed separately and each go through the same request/fulfillment pattern (therefore the result object state machine doesn’t change as a function of these request object states). 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.

Appendix B - HL7 Dynamic Model Methodology

The HL7 methodology includes two parts needed for communication of information between systems, the static model (information content itself and any wrappers) and the dynamic model which describes the circumstances under which that information is sent and how that exchange fits into an overall pattern of communication. "Dynamic model" refers to a set of interrelated artifacts that together define the behavioral portion of an HL7 v3 specification. The artifacts include: Trigger Events: When is information exchanged? Application Roles: Who are the participants in an exchange? Interactions: What are the characteristics of a single exchange, including its place in an overall communication pattern? Requirements Trigger Events Requirement There needs to be a means of defining and standardizing the definition of the 'real world' occurrences that result in a need for information to be exchanged. Rationale Part of interoperability is not only what information will get shared but also the circumstances where it will be shared. A system that does not share the appropriate information at the correct time will not achieve interoperability. MIF mif-model-dynamic.xsd/TriggerEvent

Requirement Each trigger event must have a unique name Rationale The trigger events must be able to be precisely referenced in human-to-human communication. MIF mif-model-dynamic.xsd/TriggerEvent/@name

Requirement Each trigger event must identify, as formally as possible, the real-world occurrence that causes information to flow. Rationale The purpose of a trigger event is to give a standardized label to a particular type of real-world event so that it can be referenced. If the real-world event isn't defined or is defined only loosely, the trigger event's purpose won't be met. Methodology There are three categories:

	interaction-based - An interaction caused by the receipt of another interaction. For example query response. Interaction based trigger events reference the interaction that triggers them. 
	state transition-based - An interaction caused by a change in status. For example, putting a repeating order on hold (to suspend action on that order). State-based trigger events reference the static model, class and state transition they are associated with 
	environment-based - An interaction caused by a user interacting with a system or some other environmental occurrence. For example, user deciding to query a system; daily notification sent out at 2am. Environment based trigger events include a textual description of the real world event, as there is no more formal way of defining them. 

MIF Interaction-based: mif-model-dynamic.xsd/TriggeringEvent/interaction

	State-based: mif-model-dynamic.xsd/TriggeringEvent/stateTransition 
	User-based: mif-model-dynamic.xsd/TriggeringEvent/environmentalOccurrence/text 

Requirement EnvironmentalOccurrence may have a related state transition. Rationale Some events that aren't directly caused by a state transition might still have an association to a transition. There are two common situations where this occurs:

	Request for a state transition to occur; and 
	Request for fulfillment of a state transition 

In the first case, the triggering action is usually some user or system decision, but not the actual state transition (because it hasn't happened yet - it's just being asked for. For example, when a user requests info to be posted to a patient's EHR (related state transition is to 'complete' an observation) In the second case, the state transition happened some time ago (possibly seconds, possibly days). A decision has been taken to ask another system to "action" that state transition. For example, "please fill this prescription". MIF mif-model-dynamic.xsd/EnvironmentalOccurrence/relatedStateTransition

Requirement Trigger Events may have a number of different types of annotations Rationale See rationales for individual annotations types Implementation Usage Constraint

	Usage Notes 
	Rationale 
	Requirements 
	Design Comments 
	Stability Remarks 
	Other Annotation 
	Mapping 
	Open Issue 
	Ballot Comment 
	Change Request 
	Deprecation Information 


Interations Requirement HL7 v3 specifications must be able to define each possible "exchange" of information including the structure and type of information to be sent, the circumstances in which it is sent and expectations on the receiver. Rationale A single exchange is the lowest possible unit of actual interoperability. While an exchange is made up of multiple components, there is no interoperability without at least one successfully completed exchange. To have interoperability, the characteristics of that exchange must be fully defined and agreed to by both parties. MIF mif-model-dynamic.xsd/Interaction

Requirement Each interaction must have a unique name Rationale Interactions must be able to be referenced in human communication MIF mif-model-dynamic.xsd/Interaction/@name

Requirement Each interaction may have an interaction type. Rationale Interactions typically fall into one of a set of stereotypical behaviors. Each of these stereotypes have distinct expectations for the types of trigger events and receiver responsibilities associated with them. Methodology Query - Solicits data from the receiver</xs:documentation>

	QueryResponse - Returns requested data to the query initiator, or an indication that requested data is unavailable.</xs:documentation> 
	EventNotification - Informs the receiver about the occurrence of a trigger event, along with full or partial data related to that trigger event. 
	RequestForAction - Solicits a specific action (trigger event) from the receiver. Must be an action the receiving Role is theoretically capable of performing. 
	RequestResponseAccept - Notification of the agreement or conditional agreement to perform the requested action (trigger event) or a varient thereof. I.e. the accept may propose an alternative to the initial request. 
	RequestResponseRefuse - Notification of the refusal to perform the requested action (trigger event). 
	UntriggeredNotification - Transmission of data that is independent of the occurrence of any state-transition event or other interaction.E.g. auto-publish, broadcast, backload 

MIF mif-model-dynamic.xsd/Interaction/@interactionType

Requirement Each interaction must identify the type of event that causes the exchange defined by the interaction to occur. Rationale The same set of data might be exchanged for many different purposes and in many different circumstances. Agreement on a specific reason for a given exchange is important to shared interpretation of the information. For example, a structure defining a prescription might be sent when asking for the prescription to be created in some central system, when asking a pharmacy to fill the prescription, or as a response to a query. The same data is sent, but the triggering event (and thus the semantic interpretation of the information and what internal business process should be invoked) is different. MIF mif-model-dynamic.xsd/Interaction/invokingTriggerEvent

Requirement Each interaction must have a definition of the content allowed to be conveyed as part of the exchange defined by the interaction. Rationale A key part of standardizing communication is standardizing the data content to be exchanged and how that data will be structured. Without knowledge of the data to be conveyed, interoperability cannot be achieved. Methodology Refer to Bound Models

MIF mif-model-dynamic.xsd/Interaction/argumentMessage

Requirement Interactions must be able to define the communication flow expectations on a receiver of the exchange Rationale Frequently in response to an interaction, one or more 'response' interactions are triggered. There can be multiple responses. For a simple, two-part example, a 'transaction' is not complete until both a request trigger event is and information is communication and it's confirm response is receiver. The confirm response is the 'receive responsibility'. These responsibilities are communicated by the sender and are intended to 'complete' a business function. In other cases, there is an expectation that an "event" will occur within the receiving system that will result in additional communications. Methodology HL7 does not standardize the 'internal' behavior of applications as that is outside the scope of the organization's mandate. However, behavior around expressed communications is part of interoperability and is therefore defined.

	Receiver responsibilities are defined as a set of 0..* mutually exclusive alternatives. The receiver is expected to perform one and only one of the listed set of responsibilities. (It is possible for a defined responsibility to be "do nothing". 

MIF mif-model-dynamic.xsd/Interaction/receiverResponsiblities

Receiver Responsibilities Requirement Each receiver responsibility must have a reason. Rationale Indicates the conditions under which this receiver responsibility should be chosen. Should be mutually exclusive with the conditions of all other receiver responsibilities for this interaction. Also, the combined reasons for all receiver responsibilities should be complete. I.e. There should be no circumstance that doesn't fit into the reason of one and only one receiver responsibility. This set of conditions ensures that the allowed communication behavior of the receiver is fully defined. For example, one responsibility might be invoked if a request is accepted, another if the request is not accepted but an alternative is proposed, and a third responsibility invoked in all other circumstances. MIF mif-model-dynamic.xsd/ReceiverResponsibly/reason

Requirement A receiver responsibility may have one or more 'response' interactions. Rationale A common pattern of communications is to send some sort of response when a piece of information has been received. This type of receiver responsibility allows interactions to be chained together. Supports acknowledgements as well as query responses. MIF mif-model-dynamic.xsd/ReceiverResponsibly/invokingInteraction

Requirement A receiver responsibility may have one or more 'response' trigger events. Rationale Some interactions may result in a defined "real world event" occurring in the receiving application. For example, if a request for fulfillment of an order is 'accepted', there may be a requirement that the receiver 'activate' a 'Promise' object. That trigger event would then fire all interactions having that state transition as the initiating trigger event MIF mif-model-dynamic.xsd/ReceiverResponsibly/invokingTriggerEvent

Requirement Interactions may have a number of different types of annotations Rationale See rationales for individual annotations types Implementation Usage Constraint

	Usage Notes 
	Rationale 
	Requirements 
	Design Comments 
	Stability Remarks 
	Other Annotation 
	Mapping 
	Open Issue 
	Static Example 
	Ballot Comment 
	Change Request 
	Deprecation Information 


Application Roles Requirement There is a need to define groupings of exchanges that systems might choose to support Rationale Applications that choose to implement random combinations of interactions will not interoperate. For example, a system that can send a query but cannot receive the response is useless. For true interoperability there needs to be a collection of interactions defined that a particular system can send and/or receive. That application would then be able to communicate with any system that supports the paired grouping. Application roles serve many purposes:

	They can be the foundation for formal specifications and RFPs 
	They provide an idea of desired/expected behavior 
	They form a foundation for conformance testing 

MIF mif-model-dynamic.xsd/ApplicationRole

Requirement Each application role must have a unique name Rationale There's a need to reference interactions in human-to-human communication MIF mif-model-dynamic.xsd/ApplicationRole/@name

Requirement Each application role may have related application roles. Rationale When defining conformance structures, it's useful to allow composition of common combinations into more complex structures. For example a "Pharmacy system" application role might be composed of "Prescription filler", "Dispense notifier", "Medication profile querier" and similar roles. Methodology Two types of composition are defined:

	AtLeastOne - The container application role must implement at least one, possibly more (including all) contained application roles. 
	Includes - Defines the relationship where the container contains the contents. 

MIF mif-model-dynamic.xsd/ApplicationRole/relatedApplicationRoles

Requirement Each application role may be either or both sending interactions and/or receiving interactions. Rationale Application role is about the functional capability. Need to document for each role what the application is capable of receiving and sending. MIF mif-model-dynamic.xsd/ApplicationRole/sendsInteractions

	mif-model-dynamic.xsd/ApplicationRole/receivesInteractions 

Requirement Each application role may either create or consume documents. Rationale In addition to sending and receiving messages (services), applications may also create and consume documents, which don't have an associated dynamic model. This capability also needs to be bound into the definition of a system's characteristics. MIF mif-model-dynamic.xsd/ApplicationRole/createsDocuments

	mif-model-dynamic.xsd/ApplicationRole/consumesDocuments 

Requirement Interactions, Trigger Events, Application Roles and Structured Documents may have a number of different types of annotations Rationale See rationales for individual annotations types Implementation Usage Constraint

	Usage Notes 
	Rationale 
	Requirements 
	Design Comments 
	Stability Remarks 
	Other Annotation 
	Mapping 
	Open Issue 
	Ballot Comment 
	Change Request 
	Deprecation Information 


Structured Documents Requirement HL7 v3 specifications need to support defining information structures without any accompanying dynamic model Rationale Some standards do not involve any behavioral aspects. The definitions of any behavior are outside the scope of the standard. While this may reduce chances of interoperability, it does allow for increased flexibility on the usage of the standard MIF mif-model-dynamic.xsd/StructuredDocument

Requirement Structured document definitions must have a unique name Rationale Structured document definitions need to be referenced in human-to-human communication MIF mif-model-dynamic.xsd/StructuredDocument/@name

Requirement Structured documents must have defined information structures Rationale Seeing as there's no dynamic model, the only thing left to standardize is the data content and structure. Methodology Refer to Bound Models

MIF mif-model-dynamic.xsd/StructuredDocument/documentDefinition

Requirement Interactions, Trigger Events, Application Roles and Structured Documents may have a number of different types of annotations Rationale See rationales for individual annotations types Implementation Usage Constraint

	Usage Notes 
	Rationale 
	Requirements 
	Design Comments 
	Stability Remarks 
	Other Annotation 
	Mapping 
	Open Issue 
	Ballot Comment 
	Change Request 
	Deprecation Information 


Bound Models Requirement Static models need to be able to be combined at run-time Rationale Sometimes static models need to be constructed in such a way that they have associations that point to variable "un-defined" content. Before the model can be used, these "stub" locations need to be resolved. For example, a model that defines the transport information for a message might be capable of conveying many types of messages. However, when referenced in a particular interaction, the specific message content needs to be defined Methodology HL7 models can contain named stubs or "template parameters" [To do: insert reference]. These parameters are then bound to other static models when the static model is referenced in a document or interaction definition. MIF mif-model-dynamic.xsd/BoundStaticModel/parameterModel

Future Requirements (not complete) Note that HL7 is currently re-developing and replacing the current dynamic model methodolgy. Below are SOME of the requirements. Requirements are still being determined and documented as part of the HL7 Enterprise Architecture Framework Alpha implementation projects. Future Requirement Communicate conformance of receiver responsibilities. It is necessary to know which receiver responsibilities must happen (mandatory), should happen (required), may happen (optional), and must not happen (usually based on a previous elaboration of a receiver responsibility). Rationale It is necessary to know which receiver responsibilities must happen (mandatory), should happen (required), may happen (optional), and must not happen (usually based on a previous elaboration of a receiver responsibility). MIF TBD