LCC Long Proposal - wiki
Proposed Work Item: Laboratory-Clinical Communications (LCC)
Proposal Editor: Jim Harrison, College of American Pathologists and University of Virginia
Work Item Editor: Jim Harrison
Date: 09/20/2011, last updated 10/11/2013
Version: 1.0 (draft)
Domain: Clinical Laboratory
Status: Work in progress Fall 2013. Order Replacement and Result Fulfillment are complete in preliminary form with alternative implementations for discussion. See the descriptions of the LAB-6 and LAB-7 transactions for the alternatives, and Breakdown of tasks 2013-2014 and Change proposals and open issues for current work items.
Summary
The communication and resolution of needs for order replacement, result verification, and result interpretation are integral parts of quality laboratory service that are currently managed on an ad hoc basis outside of information systems. Communications can be delayed or lost and summary data about ordering and resulting problems is difficult to compile. Thus recognition and correction of the immediate or systemic problems indicated by these communications is time consuming and error prone. This new profile will enable rapid, standardized, automated capture of and response to problems related to orders and questions about results, and will allow this information to be logged, tracked, and included in QA studies and process improvement projects.
The Problem
The current order-result paradigm supported under HL7 v. 2 includes ordering, order cancellation, replacement of issued orders by the Order Placer or Order Filler, and result reporting. It does not encompass other clinically-important interactions related to ordering and resulting laboratory tests, such as recommendations for order replacement by the Order Filler or additional work after resulting required for fulfillment of the original clinical need. The former occurs when a laboratory has information indicating that one or more ordered tests may be inappropriate due to patient characteristics, but does not have prior permission to replace that order without clinical input. The latter occurs when a result may need to be verified or interpreted before being acted upon.
Communications satisfying these needs are typically carried out by phone, fax, or other manual methods, which is inefficient for the laboratory and clinicians, is not amenable to automation and decision support, prevents the laboratory from communicating through the EHR as a full member of the patient’s care team, and does not create structured documentation useful in quality assurance and process improvement. The LCC Profile defines workflows, messages, and data elements to support automated communications between the LIS and EHR about orders and results. It is intended to carry enough information about an existing order or result that systems can implement very convenient, targeted displays to support replacement of orders prior to testing or issuing new orders for additional work related to particular results.
Use Cases
Order replacement prior to testing
- Test prioritization. A set of laboratory tests is ordered but the patient is a difficult draw and inadequate volume is obtained to run all tests. The selection of the most useful of the ordered tests depends on the patient's clinical status. An LCC message is returned to the ordering EHR that provides notice of the volume problem and presents a suggested prioritization of tests with an option to modify the priority. Using the message display, the clinician quickly prioritizes the tests to run immediately and schedules a follow up blood draw to provide specimens for the remaining tests. The information is returned to the LIS where the initial order is amended, the follow up blood draw is scheduled as a new procedure, and the problem and its resolution are captured into a QA database.
- Optimizing diagnostic yield for individual patients. A set of orders is received by the laboratory that is expected to have poor diagnostic yield for the patient based on an individualized Bayesian analysis including demographics, prior diagnoses, and prior testing results. The laboratory issues an LCC message recommending replacement of some or all of the ordered tests with tests that are expected to have a higher diagnostic yield in this context, and includes explanations in the message along with the recommendations. The clinician can consider the recommendations and either accept or decline them in the returned message.
- Reference laboratory order modification. Specimens are drawn by a local clinical laboratory and shipped to a reference laboratory, with a testing order transmitted via their reference laboratory interface. On arrival it is found that the specimen is inadequate (incorrect type, volume, tube type, etc.). An LCC message is returned to the local laboratory via the interface that indicates the problem, the tests that can be carried out on the available specimen, and the amount and type of additional specimen needed. If appropriate specimens are available, the local lab can elect to ship them immediately to complete the original order. Otherwise, the laboratory can pass the message back to the ordering EHR for amendment of the original order and/or additional sampling.
- Proactive follow-up of inconclusive testing. A fine needle biopsy is sent to pathology but proves to be inconclusive. Rather than report an essentially negative result with a recommendation for resampling, an LCC message is sent to the clinician indicating that the sample was inadequate for diagnosis and presenting an order for repeat sampling. If the clinician chooses to repeat the test, the results of both tests are reported together with a definitive diagnosis. If no further specimen is provided, the results of the initial specimen are reported. This potential use of the LCC with inconclusive specimens in AP allows initial and follow up specimens to be reported together rather than reporting potentially misleading negative results.
- Handling future order timeout. A physician seeing a patient for hyperlipidemia writes a future order for a lipid panel in 4 months and asks the patient to return in 6 months for follow up. When the patient has not visited the lab by 5 months, the order expires and an LCC message is returned to the physician's EMR indicating no-show expiration and allowing extension of the order with notification to the patient, or cancellation of the order. It often matters clinically whether a test has expired due to a no-show or has been canceled for other reasons. Current systems do not do a good job of providing this information to clinicians and queuing up their likely responses.
- Proactive correction of incorrect test orders. A laboratory receives an order for an expensive genetic test. Other test results and a check of the clinical history indicate that a different genetic test is indicated. An LCC message is returned to the clinician with the correct test presented for ordering and an explanation for the substitute order. The clinician can quickly order the replacement test. Incorrect test orders are not uncommon and the problem is especially acute with new genetic tests according to studies in the past two years by academic centers and major reference laboratories. These errors yield unnecessary cost, delays in diagnosis, and incorrect diagnoses. Currently there is no good way to communicate this information within the order/result transactions.
- Promotion of test utilization goals and guideline adherence. A laboratory receives an order for an expensive confirmatory test without a history of the appropriate screening test. An LCC message is returned to the physician that recommends replacement of the ordered test with the screening test and provides the option to order the latter or confirm the previous order. The physician quickly orders the screening test from within the message display. Though this is a simple example, a similar mechanism might provide decision support related to test utilization and testing guidelines. In settings where a lab supports multiple small ambulatory EHRs, maintenance of decision support rules individually in those EHRs may be difficult. Future standardization of decision support rule format will help, but certain forms of sophisticated or laboratory-specific decision support may be best managed in the LIS. The LCC will provide one mechanism for the results of LIS-based order filtering or decision support to be communicated back to the EHR and ordering physicians.
- Capture or correction of data required for testing. A test is ordered with required data that is missing or erroneous. An LCC message is returned to the ordering system indicating the omission or error and requesting replacement with a similar order that contains the required data. The message display queues up the order with a heading describing the problem and the missing or incorrect fields easily accessible for correction. The physician quickly enters the new data and submits the replacement order. Limited rules-based processing of orders received in the lab might be used to detect errors, omissions, and other data problems that could be followed up quickly for correction.
- Results-dependent test ordering in extended testing algorithms (tentative). At some locations, clinician orders are required for all tests in a complex reflex algorithm, where the nature of the downstream testing is unknown at the time of the initial order. This situation may occur in AP or CP; an extreme example might be ER/PR/HER2 testing in evaluation for breast cancer, which may extend over multiple specimens (see the upcoming ASCO/CAP HER2 guideline). The communication process around these algorithms is currently awkward; the availability of the LCC would allow intermediate orders based on "results so far" to be queued up for the clinician, with an explanation. The official result would be communicated as a single report at the end of the algorithm. This use case can be addressed currently using pending and final results, but that approach requires the clinician to switch to the order entry module and manually find the correct followup order. The LCC allows the order to be queued up by the lab so that it is ready to execute in the context of the preliminary result.
Result fulfillment (post-result action to fully meet the individual and collective clinical need)
- Identification and follow-up of results with unusual patterns or lack of clinical support. A patient in the ER with substernal chest pain and a non-diagnostic EKG initially has a cardiac Troponin I (cTnI) below the level of detection but the second value is elevated, prompting the patient’s admission to the acute cardiology service. The third cTnI value is again undetectable. Verification of the previous elevated value and the current normal value are requested through the EHR via an LCC message, yielding a corrected result of “undetectable” for the previously elevated specimen. The patient is discharged without catheterization. Routine monitoring of verification requests reveal an elevated number for cTnI since a new test formulation was deployed several months previously. Reports of these results to the test vendor from multiple sites lead to reformulation of the assay with improved performance. This scenario is derived from actual events and is representative of multiple examples of feedback to test kit vendors from practical use settings. Such test performance monitoring is currently done manually with significant effort, cost, and delay in reporting.
- Interpretation of unusual or complex results. A patient with joint pain, fever, and sudden onset deep venous thrombosis showed an elevated PT and PTT with otherwise normal coagulation tests. An interpretation was requested of the PT and PTT results from the EHR via an LCC message. The interpretation added as an addendum to the test panel indicated that the results were consistent with a lupus anticoagulant and recommended the appropriate evaluation strategy.
- Identification of local test performance problems. A mechanical problem develops in an analyzer such that the next scheduled recalibration results in inappropriately low cortisol values in patients while controls and other parameters remain within defined ranges. Physicians receiving results that seem clinically inconsistent can easily request verification of those results directly from results review, yielding faster recognition of problems and correction of results. This scenario is derived from actual events in which the analyzer had an unrecognized mechanical problem and all check parameters were within specifications. The discrepancy was phoned in by a single endocrinologist who was known to be a demanding client. Verification on a second analyzer yielded a normal cortisol and immediate service performed on the first analyzer revealed the problem. Multiple results required correction.
- Identification of test performance problems across populations. An endocrine service that performed IGF-1 testing for pituitary evaluation found occasional instances where mildly-to-moderately elevated levels of IGF-1 occurred in patients who did not have pituitary disease. This discrepancy between lab and clinical findings was reported on an ongoing basis when it occurred, with a brief LCC message that could be sent from the EHR to the LIS with only a couple of clicks to note the lack of clinical correlation. No technical problems with the test were found locally, but ongoing statistical analysis of these responses across multiple tests revealed a higher-than-expected rate for IGF-1 and this was reported to the test vendor. Similar performance monitoring reports from multiple locations led the vendor to review the use of a reference range established in Scandinavian populations with US patients, and design a reference range study for the US. This scenario is derived from actual events. A standard method to simply and easily capture clinical assessment of test performance would allow automated performance monitoring and much faster reporting and response to performance issues than is currently possible. Ultimately, this capability would promote performance improvement at both the local laboratory and national vendor levels.
- Local process improvement. A local quality or process problem in testing, for example, the wrong test was done, the turnaround time was excessive, the interaction with the patient or ordering physician was problematic, etc., is noted as a request for follow up by the physician at results review, yielding a coded and/or free text problem flag attached to the original order and result. The outcome of quality assurance followup can be reported as a result of this request. This capability allows development of data sets that directly support and monitor local laboratory performance improvement. The ability to flag a result quickly for a quality issue would encourage reporting of problems, as opposed to the more typical incident reports which are handled externally and are awkward to manage within the clinical workflow, and the ability to return a result on quality assessment followup could improve collaboration between a laboratory and its clients.
- Annotation of interesting test results. An endocrinologist with a busy practice sends testing to an academic center in a nearby city, and collaborates with faculty there in clinical research studies. When a patient displays an interesting result suggesting benefit from future research follow up, or inclusion in a clinical trial, the clinician can quickly flag the result with a pre-defined code that allows it to be retrieved easily in subsequent searches. The academic center scans their results on a weekly basis and takes appropriate action for flagged results (e.g., inclusion in registries or follow up for trial participation). This mechanism repurposes the fulfillment mechanism to allow arbitrary flagging of results.
Standards & Systems
This proposed profile incorporates and extends concepts from the HL7 v. 3 laboratory ordering behavioral model into HL7 v. 2 so that they may be available to the laboratory community prior to broad implementation of HL7 v. 3. The v. 3 behavioral modeling is ongoing and the LCC profile will track that work as it continues. The current IHE Laboratory Technical Framework and the ONC laboratory ordering and reporting initiatives are based on HL7 v. 2.5.1. LCC development will initially focus on repurposing existing HL7 2.5.1 messages and data elements to carry the data that LCC transactions require. Where extension of field definitions, new fields, new codes, or new messaging patterns are required, they will be proposed for HL7 2.9 in cooperation with the HL7 Orders & Observations workgroup, and those 2.9 features will be "pre-adopted" individually into the overall v. 2.5.1 environment of the Laboratory Technical Framework.
The focus of communication for LCC is between LIS and EHR, and the project will attempt to attract LIS and EHR vendors to the Laboratory Domain to contribute to the work. In addition to the communication standard, we anticipate that the workflow and use cases from this project will be beneficial to both separate and integrated LIS/EHR systems through the definition of a more comprehensive order-result workflow that addresses clinical needs.
Specific HL7 standards referenced:
Order replacement (LAB-6):
HL7 v. 2.5.1, Ch. 4 Order Entry
HL7 v. 2.7, Ch. 12 Patient Care (REL segment)
Results fulfillment (LAB-7):
HL7 v. 2.5.1, Ch. 4 Order Entry
HL7 v. 2.7, Ch. 7 Observations (OBX-21)
HL7 v. 2.7 Ch. 12 Patient Care (REL segment)
LOINC (codes for verification, interpretation, etc.)
Technical Approach Overview
Introduction
The LCC Profile will work in tandem with the Laboratory Testing Workflow (LTW) Profile in support of the use cases described above. Currently the LTW defines five transactions (LAB-1 to LAB-5) that flow between four actors to support laboratory test ordering and resulting (see Existing Actors below). Orders that cannot or should not be carried out may be refused or cancelled directly, or the Order Filler may contact the Order Placer outside the system and ask that replacement orders be issued. There is no available response to results that do not completely fill the clinical need. The LCC defines two additional transaction types (LAB-6 and LAB-7, see below) for the LTW with new triggers that increase the flexibility of the order-result interaction within the system.
Currently, Order Placers may send replacements for existing orders to Order Fillers as part of the LAB-1 transaction (referred to in the IHE Lab TF as "order update") and Fillers may create new orders and send them to Placers using the LAB-2 transaction. The LTW "order update" concept is derived from the HL7 v. 2.5.1 order replacement pattern, which includes order replacement by either the Placer or the Filler (though the latter is not described in the LTW). The new LAB-6 transaction blends elements of these existing transactions and uses new order control and status codes to support a transaction starting with the Filler that recommends replacement of one or more specific existing orders with one or more new orders. The transaction uses the message structure of the HL7 Filler order replacement message, identifying the orders to be replaced and defining replacement orders. This message structure is also similar to the Placer order update currently covered by the LTW. The new control codes indicate that the replacement is a recommendation rather than a completed act. The Placer may accept, decline, or modify the replacement orders and return an order replacement message to the Filler with control codes indicating those responses. LAB-6 also introduces a time window during which orders with pending recommendations are held and recommendation responses can be accepted. If no responses are received by the end of the window, order processing proceeds as it would have without the transaction. Data about this time window does not fit into current HL7 segment fields and several alternatives for handling it are described below in the LAB-6 discussion.
Orders for additional work on one or more results are carried in a new LAB-7 transaction. This additional work may include, for example, verification or interpretation, follow up of a process problem, an assertion of error, or a request for annotation, from the Order Result Tracker to the Order Filler. The order includes the patient identity and results to be interpreted or annotated, and may incorporate results from multiple tests as well as observations entered at order time. The transaction does not assume that the Order Filler system originally provided the results to be interpreted. The response by the Order Filler may be in the form of an addendum or amendment to the original result, or may yield a report or other result associated with the LAB-7 order. These orders are called "fulfillment orders" because the requested additional work is required for the result to fulfill its intended clinical purpose.
In addition to communicating the recommendations and orders, LAB-6 and LAB-7 messages allow replaced and replacement orders to be linked, or results to be linked with fulfillment orders, so that the frequency, context, and performance quality of recommendation and fulfillment activities can be monitored.
Figure 6.1.1. New transactions (LAB-6 and LAB-7) proposed in the LCC profile with responses using existing transactions
Actors
The LCC uses existing actors defined in the LTW (see below).
Existing actors and transactions
The LTW Profile defines four actors, the Order Placer, the Order Filler, the Automation Manager, and the Order Results Tracker. Communications defined by the LTW are shown in the diagram below. In integrated EHR that offer both order entry and results display, the Order Placer and Order Results Tracker are modules of the same system. Communications shown in blue in the diagram are required only if the Order Placer and Order Results Tracker are separate systems and thus require external coordination. New LCC communications (see New Transactions below) will fit into the LTW communications framework between the Order Placer, Order Filler, and Order Results Tracker (if separate) without requiring modification of existing LTW transactions.
Figure 6.3.1. Current LTW transaction sequence diagram showing the existing transactions LAB-1 through LAB-5
(from Vol 1 of the IHE Lab Technical Framework, Fig. 4.5.1-1 on p. 34)
New transactions
The LCC defines two new transactions, LAB-6 and LAB-7, to support order replacement and post-result follow-up, respectively. These transactions are shown in red in the LTW sequence diagram below.
Figure 6.4.1. Proposed LTW and LCC combined transaction sequence diagram showing the new transactions LAB-6 and LAB-7 in red
LAB-6 will be triggered in the Order Filler after ordering but prior to testing, when an order cannot or should not be carried out based on information available to the laboratory. It will carry information to the Order Placer on why the order cannot be completed, and a recommendation for one or more replacement orders and/or order cancellation. The response to LAB-6 will be carried in the current LAB-1 Placer Order Management unsolicited order "update" transaction defined by the LTW (essentially returning the completed message, with or without modification to the replacement orders, to the Filler).
LAB-7 will be triggered when test results are clinically or operationally problematic. It will yield a new fulfillment order that is created in the context of an existing result in the Order Result Tracker, will automatically include references to that result and its order, and will allow additional information to be entered by the clinician; additional results may be included in the transaction. The transaction will be sent from the Order Results Tracker to the Order Filler and will have the form of an unsolicited order message. The response from the Order Filler will be returned to the Order Results Tracker in the current LAB-3 Order Results Management transaction as an addendum or amendment to the original result, and/or as a separate result of the fulfillment order.
Impact on existing integration profiles
LCC profile development will not modify the LTW and other profiles, except for the definition of a limited number of new codes/terms/fields and minor modifications of code and segment usage specifications affecting only LCC messages. These modifications will be submitted to HL7 and IHE as change proposals, as appropriate.
New integration profiles needed
The LCC will be a new integration profile.
Order Replacement (LAB-6)
A preliminary depiction of the LAB-6 Order Replacement Recommendation is shown in red within the LAB-1 sequence diagram below, based on Figure 4.4.1-1 in the IHE Lab Technical Framework, Vol. 2.
Figure 7.1. Order replacement recommendation transactions (LAB-6 transactions and codes shown in red) within the LAB-1 ordering sequence.
LAB-6 consists of 4 transactions: 1) an order replacement recommendation sent from Filler to Placer, 2) an immediate acknowledgement of the recommendation, sent from Placer to Filler, 3) a later order replacement message sent from Placer to Filler, which must be received within the recommendation time window to be valid and which may accept, reject, or modify the replacement recommendation, and 4) an acknowledgement of the order replacement message from the Filler to the Placer. The last two transactions are similar to the current order replacement transactions except for the addition of several order control codes (shown in red). Transactions shown on the diagram in blue are required only if the Order Placer and Order Result Tracker are separate systems.
Goal of LAB-6
This transaction will occur when the Order Filler receives testing orders and has information about either the specimen or the patient indicating that one or more of the orders may be impossible to carry out or may not represent optimal care. The purpose of the transaction is for the Filler to recommend to the Placer one or more replacement orders for one or more existing orders (see Use Cases, Order Replacement), and it may occur any time from immediately after the order is placed until the initiation of the technical testing workflow. Replacement orders must be returned within a defined recommendation time window (see diagram above) to be accepted. LAB-6 differs from existing Filler order replacement in that it solicits replacement orders from the Placer instead of canceling the Placer's orders and creating new orders without Placer input. Thus it supports collaborative agreement between the Placer and Filler on a final order set in a variety of contexts where test selection may be challenging. Recommended orders, replaced orders, accepted recommendations, and declined recommendations are denoted with specific order control codes so that they may be archived and tracked to evaluate the performance and impact of order recommendation. While LAB-6 is intended to be consistent with and an optional addition to the LTW, some extension of HL7 v. 2.5.1 will be required and would need to be pre-adopted from later versions of the standard into the IHE profile, as outlined below. An overview of the LTW is provided in the IHE Laboratory Technical Framework, Vol. 1, and LAB-1 is defined in detail in the IHE Laboratory Technical Framework, Vol. 2 (p. 68 and Fig. 4.4.1-1 on p. 70).
LAB-6 message and transaction details
Order replacement recommendation and response extends the current order replacement messaging pattern to allow an order Filler to recommend order replacement and wait a defined period for a response from the order Placer. Order replacement recommendations use the current Filler-to-Replacer unsolicited replacement message except that modified or new codes for order control, order status, and order control code reasons identify the original orders, recommended replacements, and responses to the recommendations. Current messages do not have an appropriate location for recommendation acceptance window timing, and several approaches to handing that information are outlined below.
Alternative 1: Status update instead of a specified response time window
This approach is based on the existing order replacement patterns defined in v. 2.7 Ch. 2, pp. 33-35 (in HL7 v. 2.5.1 this material is in Ch. 4, pp. 30-32). When the Order Filler receives orders from the Order Placer that should be replaced, the Filler sends a replacement request to the Placer in which the orders to be replaced have the control code RP (ORC-1) and the recommended replacement orders have the new control code RC. This replacement request is similar in structure to the unsolicited replacement notification that is currently supported from the Filler to the Placer except that the RP control code is used in the original orders to indicate a replacement request rather than the control code RU, which indicates that an unsolicted replacement has occurred, and RC is used in the recommended orders rather than RO. In the recommendation message, the ORC/OBR of the recommended replacement orders follow the ORC/OBR of the orders to be replaced as is the case now with the unsolicited and solicited replacement messages. The Placer responds immediately to indicate that the request has been received (see below) and then issues a replacement request using control codes RP or UM in the orders to be replaced and new control codes RA or RD in the recommended replacement orders, indicating whether the recommendations are accepted or declined, respectively.
In addition to control codes, the replacement recommendation message sets the order status (ORC-5) of the existing orders to HR (Hold for Revision), and provides a code indicating the reason for the replacement recommendation in the control code reason field (ORC-16). There are no fields in the existing message that fit the response time window, so this first and simplest alternative does not transmit a specifc time-out for response and instead if the response window closes without a response a status update message is transmitted from the Filler changing HR to IP (In Process) or other status update as appropriate, and the recommendations are canceled.
If specimens are available and appropriate for analysis, proposed orders should include SPM segments referring to those specimens. If more than one order can be fulfilled by a specimen, its SPM segment should be repeated for each order to be assigned to it. It is the responsibility of the Filler to ensure that the assigned specimens are appropriate and have the capacity (e.g., volume) to support the proposed testing. If a proposed order does not contain an SPM segment the order will require a new specimen. Because order replacement is inherently an order-centric process, specimen- and container-centric ordering patterns (O33 and O35 events) are not supported by the LCC. Instead, the message should be oriented around the orders, and specimens should be assigned to them as noted above.
Advantages of Alternative 1: No message structure or segment changes
Disadvantages/changes: Does not transmit a time window for recommendation acceptance to the Filler system, which limits automated communication escalation, etc. Requires extension of some control code definitions, and definition of new control and status codes
Listing 7.2.1. Single Order Replacement Without Time Window
Initial message from Placer to Filler (Lab order OML^O21): ... ORC|NW|1234||... New order with Placer order number OBR|... ... Begin LCC -- Filler recommends a change in this order (Filler to PlacerOML^O21): ... ORC|RP|1234|5678||HR|||||||||||PY|... Filler order number, recommends replacement (RP), order on hold for revision (HR) with reason (PY) OBR|... ORC|RC||5679||HR|... Recommended replacement order (RC) with new Filler order number, on hold for revision (HR) OBR|... NTE|... May contain additional information about the reason for replacement ... Placer immediately acknowledges the recommendation (Placer to Filler ORL^O22): ... ORC|RR|1234|5678||HR|||||||||||PY|... Request received (RR) for orders with RP, otherwise the message is reflected OBR|... ORC|RC|1504|5679||HR|... New placer order number, on hold for revision (HR) OBR|... NTE|... ... If the Placer does not respond within the required time, a status update message is sent changing ORC-5 HR to IP and continuing processing according to default procedures, otherwise... Placer accepts recommendation within the time window (Placer to Filler OML^O21): ... ORC|RP|1234|5678||HR|||||||||||PY|... Replace order (RP control code), order has been replaced in Placer system (RP status) OBR|... ORC|RA|1504|5679|||... Replacement order recommendation accepted (RA) OBR|... ... Filler confirms replacement (Filler to Placer ORL^O22): ... ORC|RQ|1234|5678||RP|||||||||||PY|... Replaced as requested (RQ), order has been replaced in Filler system (RP status) OBR|... ORC|RA|1504|5679|||... OBR|... ...
Listing 7.2.2. Multiple Order Replacement, Partially Declined Replacement, and Added Replacement Orders
Placer sends three new orders (not shown)... Filler recommends replacing the three orders with two orders (Filler to Placer OML^O21): ... ORC|RP|1234|5678||HR|||||||||||PY|... First order to replace (RP control code, HR status, PY reason) OBR|... ORC|RP|1235|5679||HR|||||||||||PY|... Second order to replace (RP, HR, PY) OBR|... ORC|RP|1236|5680||HR|||||||||||PY|... Third order to replace (RP, HR, PY) OBR|... ORC|RC||5690||HR|... First replacement order (RO, HR) OBR|... NTE|... ORC|RC||5691||HR|... Second replacement order (RO, HR) OBR|... NTE|... ... Placer returns immediate ORL^O22 acknowledgement with placer order numbers (not shown)... Placer accepts one recommendation, declines one, and adds an additional replacement order (Placer to Filler OML^O21): ... ORC|RP|1234|5678||HR|||||||||||PY|... First order to replace (RP control, order still HR, PY reason) OBR|... ORC|RP|1235|5679||HR|||||||||||PY|... Second order to replace (RP) OBR|... ORC|RP|1236|5680||HR|||||||||||PY|... Third order to replace (RP) OBR|... ORC|RA|2236|5690||HR|... Accepted recommendation (RA) OBR|... NTE|... ORC|RD|2237|5691||HR|... Declined recommendation (RD) OBR|... NTE|... ORC|RO|2238||||... New replacement order (RO) added by Placer OBR|... NTE|... ... Filler confirms replacement (Filler to Placer ORL^O22): ... ORC|RQ|1234|5678||RP|||||||||||PY|... First is replaced (RQ, status replaced RP) OBR|... ORC|RQ|1235|5679||RP|||||||||||PY|... Second is replaced (RQ) OBR|... ORC|RQ|1236|5680||RP|||||||||||PY|... Third is replaced (RQ) OBR|... ORC|RA|2236|5690|||... Accepted recommendation (RA) OBR|... NTE|... ORC|RD|2237|5691|||... Declined recommendation (RD) OBR|... NTE|... ORC|RO|2238|6123|||... New replacement order (RO) now with filler order number OBR|... NTE|... ...
Listing 7.2.3. Declined Replacement
Placer places the initial order (not shown)... Filler recommends replacement of the order (Filler to Placer OML^O21): ... ORC|RP|1234|5678||HR|||||||||||PY|... Order to replace (RP control code, HR status, PY reason) OBR|... ORC|RC||5690||HR|... Replacement order (RO, HR) OBR|... NTE|... ... Placer declines replacement, original order stays in effect (OML^O21): ... ORC|UM|1234|5678||HR||||||||||||... Replacement declined (UM control) OBR|... ORC|RD|2236|5690||HR|... Declined recommendation (RD) OBR|... NTE|... ...
Alternative 2: Recommendation time window information in a TQ1 segment
This approach uses a TQ1 segment to carry the time window for Placer response to the recommendation. The TQ1 segment is associated with each order to be replaced, and it contains the start and end timestamps for the window, a text instruction indicating that the order is held for revision until the end timestamp, and a new TQ1-15 "role" field containing a new code, HR (hold for revision). The latter is required because TQ1 segments implicitly carry service times and the new field would allow the segments to serve additional purposes. Otherwise, the messaging structure and pattern is similar to Alternative 1.
Advantages of Alternative 2: Allows transmission of recommendation time window to the Filler system.
Disadvantages/changes: Similar to Alternative 1 except that a new field and new codes must be defined for the TQ1 segment in v. 2.9 and then pre-adopted for use in v. 2.5.1 (2.5.1 does support the TQ1 segment itself).
Listing 7.2.4. Single Order Replacement with TQ1 Segment
Initial message from Placer to Filler (Lab order OML^O21): ... ORC|NW|1234||... New order with Placer order number OBR|... ... Begin LCC -- Filler recommends a change in this order (Filler to Placer OML^O21): ... ORC|RP|1234|5678||HR|||||||||||PY|... Filler order number, recommends replacement (RP), order on hold for revision (HR) with reason (PY) TQ1|||||||<start>|<stop>||||||HR|... Time window for response, timing role is "Hold for revision" (HR) OBR|... ORC|RC||5679||HR|... Recommended replacement order (RC) with new Filler order number, on hold for revision (HR) OBR|... NTE|... May contain additional information about the reason for replacement ... TQ1 segments are not required in the remaining messages.
Alternative 3: Recommendation time window information in an REL segment
This alternative uses the REL (clinical relationship) segment defined in Ch. 12 of the HL7 v.2.6 (and 2.7) standard to define a replacement recommendation relationship between the existing order and a recommended replacement order. The REL segment contains fields for the relationship type (REL-2), source and target of the relationship (REL 4 & 5), identification and contact information for the party that asserts the relationship (REL 6-10), an assertion date range (REL-11), and priority (REL-14). Thus REL carries most of the information needed for order replacement. REL is relatively new and has no specific use cases or examples defined in the HL7 specification, thus this would be the first documented use case.
Advantages of Alternative 3: Allows transmission of recommendation time window to the Filler system without requiring modficiation of existing segments. Carries additional potentially useful information such as the asserting party and contact information. Links orders explicitly for replacement.
Disadvantages/changes: REL is not widely used and thus it may be a problem for common HL7 parsers. While its use would avoid the need for segment modification, the message definition for OML^O21 would need to be updated to include it. REL was initially defined in v. 2.6, so the segment would need to be pre-adopted into 2.5.1 to be included in IHE profiles. Need to check to see if order numbers are acceptable as entity identifiers (required for fields 4 & 5). Since REL would explicitly link orders, one to one, one to many, and many to one replacements would be straightforward, but many to many replacements would be awkward. Would require definition of an appropriate relationship type.
Listing 7.2.5. Single Order Replacement with REL Segment
Initial message from Placer to Filler (Lab order OML^O21): ... ORC|NW|1234||... New order with Placer order number OBR|... ... Begin LCC -- Filler recommends a change in this order (Filler to Placer OML^O21, reverse the usual direction): ... ORC|RP|1234|5678||HR|||||||||||PY|... Filler order number, recommends replacement (RP), order on hold for revision (HR) with reason (PY) OBR|... ORC|RC||5679||HR|... Recommended replacement order (RC) with new Filler order number, on hold for revision (HR) OBR|... NTE|... May contain additional information about the reason for replacement REL||RP|999|5679|1234 5678|<FillerID>|||||<startTime>^<endTime>|... Replacement relationship (RP) with order numbers, Filler info, time window ... REL segments are not required in the remaining messages
Proposed code usage
The table below contains a draft list of codes for use with recommendation messages and their responses. Codes marked with "*" are new.
| ORC-1, Order control code | ||
|---|---|---|
| RP | Order to be replaced | Recommendation and replacement messages for orders to replace |
| RC* | Recommended change | Recommendation and replacement messages for proposed replacement orders |
| RA* | Recommendation accepted | Recommendation, ack, and replacement messages for accepted proposed orders |
| RD* | Recommendation declined | Recommendation, ack, and replacement messages for declined proposed orders |
| RO | Replacement order | Replacement messages for replacement orders added by Placer |
| UM | Unable to modify | Replacement messages for orders that should not be modified |
| RR | Request received | Ack (ORL) messages for orders to replace indicating receipt of replacement proposal |
| ORC-5, Order status | ||
| HR* | Hold for revision | Recommendation, ack, and replacement messages for orders to be replaced and proposed replacements, indicating hold status |
| ORC-16, Control code reason (reason for change recommendation) | ||
| SD* | Specimen Damaged | Available specimen inadequate for tests ordered |
| SV* | Specimen Volume | Specimen volume inadequate for requested testing |
| ST* | Specimen Type | Incorrect specimen type for requested testing |
| UN* | Unavailable | Requested test unavailable, alternative testing proposed |
| SR* | Screening Required | Screening test required prior to confirmatory test |
| IT* | Indicated testing | Indicated follow up testing based on initial results |
| CO* | Cost | Lower cost testing strategy proposed |
| FO* | Future Order | Future order timed out without specimen |
| IN* | Inappropriate | Requested testing not appropriate in this patient |
| KI* | Known Interference | The requested testing will yield inaccurate results in this patient |
| IY* | Improved Yield | Recommended testing improves diagnostic yield |
| TQ1-15 (new TQ1 field), Role. Defaults to service timing ("ST", the current meaning) if empty. | ||
| ST* | Service timing | TQ1 data refers to the timing of the order action (default) |
| HR* | Hold for revision | TQ1 data refers to the timing of a hold on the order |
Result Fulfillment (LAB-7)
LAB-7 supports the ability of clinicians using an Order Tracker (results review) application to issue orders for further work on a result that by itself may not be understandable or fully meet the clinical need, or may appear to be in error. In an abstract sense, LAB-7 asks that an existing result be annotated with the outcome of additional work. That annotation may be an amendment, addendum, or correction to a previous result, or may be expressed as the result of the LAB-7 order itself. These annotations are necessary for the result to fulfill a clinical purpose and thus the LAB-7 order created by the Tracker application is referred to below as a fulfillment order. The primary result of interest for the fulfillment order is referred to as the target result, and the original order that produced this result is called the target order.
Goal of LAB-7
The LAB-7 transaction will normally be triggered by the clinical staff during results review, when results do not fully meet the clinical need, are inconsistent or confusing, or indicate a process problem. LAB-7 may also provide a general mechanism for attaching annotations to results for a variety of purposes. A primary goal of the transaction is to allow a request for additional work related to an existing order/result to be issued quickly from the results review workflow and to automatically incorporate a reference to the patient and targeted order/result. This capability avoids the current disruption in workflow required to issue orders for interpretation or results review (exit results review, open order entry, create order, describe which order/result to target, describe problem). A LAB-7 transaction will create a fulfillment order that targets a particular result, and it may include other results for additional context. The target result may or may not have been created by the Filler of the fulfillment order. The fulfillment order may yield an addendum, amendment, correction, or annotation of the target result, and it may also yield its own result or a reference to the update of the target.
The service ID for fulfillment orders may represent concepts such as result verification, result interpretation, service process problem, or incorrect test, which are applied to the target result. Since the presence of the fulfillment order itself linked to the parent result represents a form of annotation, the mechanism could be used with an Ask at Order Entry and a generic annotate service ID for arbitrary annotation of results from Tracker/Placer systems. In the future, LOINC will be the usual source for standard service IDs and it should be reviewed to determine whether useful service IDs for these concepts exist or whether new concepts should be submitted for coding.
The results of LAB-7 orders will yield information useful in the clinical management of patients. In addition, LAB-7 is intended to enable aggregate queries that support process monitoring and process improvement. For example, an unexpectedly high rate of verification requests for a particular test result might prompt a review of that test's performance under conditions associated with the requests. To support this capability, fulfillment orders are linked to the target results and their orders in a consistent way such that the targets can be retrieved in either the Filler or the Placer/Tracker system using structured data contained in the fulfillment order.
LAB-7 message and transaction details
The fulfillment order is carried in a standard OML^O21 laboratory order message. It includes information that makes a link to the prior order and result (target result). Two strategies for linking fulfillment orders to target results are under discussion, as described below. The prior order and target result are included in the prior results section of the order message, and other results may be included in this section for context. The acknowledgement of the fulfillment order from the Filler is a standard ORL^O22. The result of the fulfillment order may be coded or text, and the order may trigger confirmation, correction, or amendment of the previous result. If the annotation use case is supported, the fulfillment order could also result in addition of an arbitrary Placer annotation to a previous result. The illustrations below use result verification as a fulfillment example; other examples include result interpretation and result annotation.
Alternative 1: Fulfillment Target Identified by Parent-child Linkage
The link between a fulfillment order and its target order and result is made through an HL7 parent-child order relationship. The fulfillment order is created as a child order of the prior order and contains a reference to the target result as its parent result. In the order section, the message carries the ORC of the parent order followed by the segments of the child (fulfillment) order. The parent order ORC-1 contains control code PA. The child order ORC-1 contains CH and ORC-8 contains the Placer and Filler numbers of the parent. The child OBR-4 contains the service identifier indicating the type of follow up needed (see below). OBR-26 (Parent Result) contains an observation identifier and subidentifier referencing the parent (target) result, and may contain the textual result. OBR-29 contains the Placer and Filler numbers of the parent order, identical to ORC-8.
Advantages of Alternative 1: Does not require changes in HL7.
Disadvantages/changes: Not the typical use of a parent-child order relationship. Establishes the relationship between the verification order and the order associated with the result to verify, but not the result directly, and then uses the observation identifier/subidentifier in its OBR-26 to indicate the result to target.
Listing 8.2.1. Example Fulfillment Order (Parent-Child)
Clinician working from order review requests verification of a serum porcelain test (OML^O21): ... ORC|PA|1234|2208|... Parent ORC = target order ORC|CH|1567||||||1234^2208|... New child ORC (fulfillment order) OBR||1567||99999-1^Verify^LN|...|88888-2&Serum porcelain&LN^^45|||1234^2208|... New child OBR (fulfillment order) OBX... Additional detail and description from clinician PID... Start of previous results PV1... OBR||1234|2208|... Target OBR = parent order OBX|3|NM|88888-2&Serum porcelain&LN||45|... Target OBX = parent result OBR... Additional orders/results for context OBX... ...This is a simplified fulfillment order representing a request for verification of a serum porcelain result. The initial ORC is the parent order, which is also the order for the target serum porcelain result. It has the control code PA for parent, followed by its existing Placer and Filler numbers. The second ORC is for the new fulfillment order for verification. It has control code CH (child), a placer order number, and the parent order Placer and Filler numbers in ORC-8. The child OBR has the same Placer number, an imaginary LOINC code for verification as its service ID, an imaginary LOINC code representing the observation ID of the target result to verify (Serum porcelain) in OBR-26, and the parent order Placer and Filler numbers in OBR-29. The following OBX contains clinician-entered detail about the verification request. After the verification order, the message contains previous results as OBR/OBX. The first prior result is the OBR and OBX for the target order and result, which in LAB-7 is the same as the parent order and result. The following OBR/OBX are optional additional results to provide context for the request. The establishment of the parent-child order relationship embeds the target order/result identifiers in the fulfillment order so that, in this case, a query for verification requests will also reveal the tests for which those requests were made. Note that PID in previous results is required in HL7 v. 2.5.1 but isn't included in the IHE Lab Vol. 2 static definition of O21
Alternative 2: Fulfillment Target Identified with Observation Instance Identifier
This approach uses the OBX-21 Observation Instance Identifier rather than a parent-child relationship to link the fulfillment order to the prior order and target result. The Observation Instance Identifier is not defined in HL7 2.5.1 but is defined in v. 2.6 and later as a unique identifier for a result. This approach requires that Filler and Placer systems assign an Observation Instance Identifier to all results, which is not routinely done now. The identifier is assigned by the Filler at the time of result reporting and is therefore present in the Filler and Placer systems. When the fulfillment order is created, the Observation Instance Identifier is transmitted in OBR-46, Placer Supplemental Service Information. As above, the prior order and target result are included in prior results, and other prior results may be included for context. When the result is transmitted, the Observation Instance Identifier is included in both OBR-46 and OBR-47 (Filler Supplemental Service Information).
Advantages: Links the verification order directly to the result to verify.
Disadvantages/changes: Placer Supplemental Service Information (OBR-46) isn't an ideal location in the verification order for the target result. Requires use of an Observation Instance Identifier in OBX-21 and OBR-46 to identify and target the result. OBX-21 is available but undefined in HL7 2.5.1, and OII was introduced in v. 2.6, so this would require pre-adoption for use in IHE profiles.
Listing 8.2.2. Example Fulfillment Order (Observation Instance Identifier)
Clinician working from order review requests verification of a serum porcelain test (OML^O21): ... ORC|NW|1567|... New fulfillment order OBR||1567||99999-1^Verify^LN|...|HL-9876|||| Observation Instance Identifier in field 46 OBX... Additional detail and description from clinician PID... Start of previous results PV1... OBR||1234|2208|... Target OBR OBX|3|NM|88888-2&Serum porcelain&LN||45|...|HL-9876|... Target OBX with Observation Instance Identifier in field 21 OBR... Additional orders/results for context OBX... ...This is a simplified fulfillment order representing a request for verification of a serum porcelain result. The fulfillment order's OBR has an imaginary LOINC code for verification as its service ID and the Observation Instance Identifier for the serum porcelain result in OBR-46. The following OBX contains clinician-entered detail about the verification request. After the verification order, the message contains previous results as OBR/OBX. The first prior result is the OBR and OBX for the target order and result, with the Observation Instance Identifier in the target result OBX-21. The following OBR/OBX are optional additional results to provide context for the request. The inclusion of the Observation Instance Identifier allows a query for verification requests to also reveal the results for which those requests were made. Note that PID in previous results is required in HL7 v. 2.5.1 but isn't included in the IHE Lab Vol. 2 static definition of O21
Alternative 3: Fulfillment target identified in an REL Segment
This approach uses an REL segment (v. 2.7, Ch. 12) to establish a target relationship between a previous order and a result for verification or interpretation. The REL segment includes a variety of fields defining a clinical relationship and the identity of the asserting party. For this use, the required fields would be the relationship type (REL-2), the source identifier (REL-4, verification order number), and the target identifier (REL-5, identifier of the result to verify). As above, this assumes use of the Observation Instance Identifier to provide an entity identifier for the target.
Advantages: Links the verification order directly to the result to verify. All fields are used as intended.
Disadvantages/changes: Requires use of an Observation Instance Identifier in OBX-21 and REL-5 to identify and target the result. OBX-21 is available but undefined in HL7 2.5.1, and OII was introduced in v. 2.6, so this would require pre-adoption for use in IHE profiles. REL would need to be pre-adopted for use in IHE profiles. No specific use cases or examples are defined for REL; this any any use for LAB-6 would be the first.
Listing 8.2.3. Example Fulfillment Order (REL segment)
Clinician working from order review requests verification of a serum porcelain test (OML^O21): ... ORC|NW|1567|... New fulfillment order OBR||1567||99999-1^Verify^LN|... LOINC code for result verification OBX... Additional detail and description from clinician REL||T|9999|1567|HL-9876|... Target relationship between this order and the OBX below PID... Start of previous results PV1... OBR||1234|2208|... Target OBR OBX|3|NM|88888-2&Serum porcelain&LN||45|...|HL-9876|... Target OBX with Observation Instance Identifier in field 21 OBR... Additional orders/results for context OBX... ...
Order fulfillment actions
The code system and codes for order fulfillment actions remain to be defined, though presumably LOINC will be used in keeping with other laboratory orders. Additional actions may be added to this list.
| Service | Example |
|---|---|
| Verify observation values | Results inconsistent with clinical impression |
| Interpret observation values | Meaning of results not clear in this context |
| Annotate observation values | Attach information about the result or testing process to the result |
| Annotation | Example |
|---|---|
| Process problem | Sample handling, reporting, turnaround time issues |
| Error | Wrong test carried out |
Breakdown of tasks 2013-2014
Order replacement tasks (LAB-6)
- Completion of proposed LAB-6 message structure and transaction strategy [Feb 2013]: Done
- Create alternative implementation proposals for LAB-6: Done
- Review of alternative implementations for LAB-6 by HL7 O&O, Fall 2013 In progress
Result fulfillment tasks (Lab-7)
- Extraction of data elements, actors, and transaction patterns from use cases and mapping to existing HL7 data elements for LAB-7 [April 2013]: Done
- Create alternative implementation proposals for LAB-7: Done
- Review of alternative implementation proposals by HL7 O&O: In progress
LCC Profile tasks (LAB-6 and LAB-7)
- Final documentation [Jan-Mar 2014]
- Initial balloting [Fall 2014]
- Initial Connectathon implementation [N.A. Connectathon, Winter 2015]
Change proposals and open issues
Order replacement (LAB-6)
- Vet proposed messaging strategy with HL7 O&O to verify consistency with and optimal use of the spec
- HL7 CP, if necessary add TQ1 segment "role" field with ST and HR codes (ST is default): The TQ1 segment needs a "role" or "usage" field to distinguish its use in order handling (the revision time window) from its usual use for service timing. It's possible that an order replacement recommendation might be made based on changing service timing and thus several TQ1 segments for different purposes might coexist in an order recommended for replacement. Role codes, ST: service timing, HR: hold for revision.
- IHE LTW CP: Allow usage of more than one TQ1 segment if different roles.
- HL7 & IHE LTW CP, reverse direction for RP and UM codes
- HL7 & IHE LTW CP, new control codes: RC, RA, RD
- IHE LTW CP, correct control code table to include RO (needs to be done anyway)
- HL7 & IHE LTW CP, new order status code: HR, hold for revision
- HL7 & IHE LTW CP, reason for replacement recommendation codes: SD, SV, ST, UN, SR, IT, CE, FO, CI, PY, IY
Result fulfillment (LAB-7)
- Vet proposed transaction with HL7 O&O, IHE, API to verify consistency with and optimal use of the spec.
- Choose parent-child or OII or REL strategy for linking fulfillment orders with target results.
- Verify message structures (Listing 8.2.1/8.2.2)
- How are orders from third party fillers handled? Filler order numbers may conflict (may not be a problem with OII).
- Define order fulfillment actions, e.g., result verification, result interpretation, service process problem, incorrect test
- Review LOINC for service identifiers appropriate for fulfillment action orders, and determine whether new codes need to be requested.
- Could the order message do without ORC in the previous results, as I've shown here (it's optional in the spec)?
- Does IHE Lab O21 static definition need to be updated to include PID as a required segment in previous results?