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 9/19/2016
Version: 1.0 (draft)
Domain: Clinical Laboratory
Status: Work in progress Fall 2016. Order Replacement and Result Fulfillment are complete and HL7 Change Proposals are in progress. See Breakdown of tasks 2016-2017 and Change Proposals for current work items.
Summary
The communication and resolution of needs for order replacement, result confirmation, 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/followup
- 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. Confirmation 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 confirmation 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 confirmation 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. Confirmation 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.
- Request for storage or banking of residual specimen for future use. Test results and clinical characteristics of a patient indicate that a particular specimen would be useful for research or quality-related work. At results review, a physician or pathologist may request that a specimen be captured for these purposes. This mechanism may be useful to identify particular specimens for specialized followup, e.g., heterophile antibody analysis, quality activities, e.g., creating quality control specimen pools, or research. Such specimens are often lost to followup due to lack of ability to annotate them for capture during their residence in the lab.
- 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.1, Ch. 4 Order Entry
HL7 v. 2.7.1, Ch. 2C, Code Tables (Tables 38 and 119)
Results fulfillment (LAB-7):
HL7 v. 2.5.1, Ch. 4 Order Entry
HL7 v. 2.7.1, Ch. 4 Order Entry
HL7 v. 2.7.1, Ch. 7 Observations (OBX-21)
HL7 v. 2.7.1, Ch. 12 Patient Care (REL segment)
LOINC (Universal Service Identifiers for fulfillment actions like confirmation and interpretation)
SNOMED CT (Universal Service Identifiers for fulfillment actions like quality review and specimen storage)
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, confirmation 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
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-Placer unsolicited replacement message except that modified and 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. Discussions in the IHE Technical Laboratory Committee and the HL7 O&O workgroup resulted in a recommendation to add a new field to the ORC segment, ORC-34 (Order Status Date Range), to carry the recommendation timing information.
Structure and transaction details
This proposal is based on the existing order replacement patterns defined in v. 2.7.1 Ch. 2C, Table 0119, pp. 34-37 (in HL7 v. 2.5.1 this material is in Ch. 4, pp. 30-32). The transaction has four components (also see the example message fragments in listings 7.2.1-3 below):
- Replacement recommendation. When the Order Filler receives orders from the Order Placer that it wishes replaced, the Filler sends a replacement recommendation 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 generally similar in structure to the unsolicited and solicited replacement messages (OML^O21) that are currently supported between the Filler and Placer, with the following features:
- As in the existing order replacement messages the ORC/OBR of the original orders are grouped first, followed by the ORC/OBR of the recommended replacement orders. This pattern supports 1:1, 1:many & many:1, and many:many order replacements.
- An RP ORC-1 Order Control code is used in the original orders to be replaced. Currently unsolicited replacement notifications (Filler to Placer) use RU in the original orders and solicited replacement requests (Placer to Filler) use RP in the original orders. The use of RP here in the Filler to Placer direction indicates a replacement recommendation rather than notification. The original orders are expected to have both Placer and Filler order numbers.
- The ORC-5 Order Status of the original orders is set to a new status code HR (hold for review).
- The ORC-16 Control Code Reason may contain a code indicating the general reason for the replacement recommendation. A list of example replacement control code reasons is shown below. Additional information may be provided in an NTE segment associated with the original orders.
- A new RC ORC-1 Order Control code is used in the recommended replacement orders rather than RO. The recommended replacement orders do not contain placer or filler order numbers.
- Start and stop times for the HR (hold for review) status are contained in a new ORC-36 Order Status Date Range (DTM^DTM). This interval represents the time window during which the Filler will wait for a response to the replacement recommendation message.
- Immediate acknowledgement. The Placer responds immediately with an acceptance acknowledgement (MSA) to indicate that the replacement recommendation has been received.
- Replacement request. After consideration of the recommendation, the Placer issues a replacement request with a structure similar to the replacement recommendation (OML^O21) and also to the current solicited replacement request, with the following features:
- The ORC/OBR of the original orders are grouped first, followed by the ORC/OBR of the recommended replacement orders.
- The original orders contain control codes RP (replace) or UM (do not replace) depending on the Placer's desired outcome.
- The recommended replacement orders contain control codes RA (replacement accepted) or RD (replacement declined) based on the Placer's desired outcome. Orders with control code RA contain Placer order numbers.
- Additional orders may be added by the Placer to the replacement order list. These additional replacement orders contain control code RO and Placer order numbers. They are handled as solicited replacements that are in addition to the recommended replacements.
- Replacement confirmation. If a replacement request is received from the Placer before the HR Order Status stop time, the Filler responds with an ORL^O22 confirmation message similar in structure to the confirmation of a solicited order replacement, with the following features:
- The ORC/OBR of the original orders are grouped first, followed by the ORC/OBR of the accepted replacement orders. Declined replacement orders are not included in the confirmation.
- The original orders contain RQ (replaced as requested) Order Control codes and RP (replaced) Order Status, similar to the response to a solicited order replacement.
- Accepted replacement orders echo their RA or RO Order Control codes, are assigned both Placer and Filler order numbers, and have an appropriate Order Status such as IP (in process).
- Any Placer-specified replacement orders (RO) that cannot be executed are included in the replacement order list with an Order Control code UA (unable to accept).
- If the HR Order Status Date Range stop time is passed without a replacement request from the Placer, a status update message is transmitted from the Filler to the Placer changing the HR Order Status to an appropriate value such as IP (In Process), the recommendations are canceled, and processing proceeds along a default path.
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.
Listing 7.2.1. Single Order Replacement
Initial message from Placer to Filler (Lab order OML^O21): ... ORC|NW|1234||... New order with Placer order number OBR|... ... Replacement recommendation -- Filler recommends a change in this order (Filler to Placer OML^O21): ... ORC|RP|1234|5678||HR|||||||||||IY|...|<start>^<stop>| Recommend replace (RP), on hold for revision (HR) with reason (IY) OBR|... Hold duration start and time times are in ORC-34 ORC|RC||||... Replacement order (RC) OBR|... NTE|... May contain additional information about the reason for replacement ... Immediate acceptance acknowledgement (Placer to Filler MSA) If the Placer does not send an acceptance or rejection message within the required time, a status update message is sent changing ORC-5 HR to IP and continuing processing according to default procedures, otherwise... Replacement request within the time window (Placer to Filler OML^O21): ... ORC|RP|1234|5678||HR|||||||||||IY|... Replace order (RP control code), order has been replaced in Placer system (RP status) OBR|... ORC|RA|1504||||... Replacement order recommendation accepted (RA), now with Placer order number OBR|... ... Replacement confirmation (Filler to Placer ORL^O22): ... ORC|RQ|1234|5678||RP|||||||||||IY|... Replaced as requested (RQ), order has been replaced in Filler system (RP status) OBR|... ORC|RA|1504|5679||IP|... Replacement order now with Filler order number, status 'in process' 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|||||||||||IY|...|<start>^<stop>| First order to replace (RP control code, HR status, PY reason) OBR|... ORC|RP|1235|5679||HR|||||||||||IY|...|<start>^<stop>| Second order to replace (RP, HR, PY) OBR|... ORC|RP|1236|5680||HR|||||||||||IY|...|<start>^<stop>| Third order to replace (RP, HR, PY) OBR|... ORC|RC|||... First replacement order (RO) OBR|... NTE|... ORC|RC|||... Second replacement order (RO) OBR|... NTE|... ... Placer returns immediate acceptance acknowledgement (MSA)... Placer accepts one recommendation, declines one, and adds an additional replacement order (Placer to Filler OML^O21): ... ORC|RP|1234|5678||HR|||||||||||IY|... First order to replace (RP control, order still HR, PY reason) OBR|... ORC|RP|1235|5679||HR|||||||||||IY|... Second order to replace (RP) OBR|... ORC|RP|1236|5680||HR|||||||||||IY|... Third order to replace (RP) OBR|... ORC|RA|2236||... Accepted recommendation (RA) with Placer order number OBR|... NTE|... ORC|RD|||... 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|||||||||||IY|... First is replaced (RQ, status replaced RP) OBR|... ORC|RQ|1235|5679||RP|||||||||||IY|... Second is replaced (RQ, RP) OBR|... ORC|RQ|1236|5680||RP|||||||||||IY|... Third is replaced (RQ, RP) OBR|... ORC|RA|2236|5690||IP|... Accepted recommendation (RA), now with Filler order number and IP status OBR|... NTE|... ORC|RO|2238|6123||IP|... New replacement order (RO) now with filler order number and IP status 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|||||||||||IY|...|<start>^<stop>| Order to replace (RP control code, HR status, PY reason) OBR|... ORC|RC||||... Recommended replacement order (RC) OBR|... NTE|... ... Placer declines replacement, original order stays in effect (OML^O21): ... ORC|UM|1234|5678||HR||||||||||||... Replacement declined (UM control) OBR|... ORC|RD||||... Declined recommendation (RD) OBR|... NTE|... ... Filler confirms return of original order to active status ... ORC|SC|1234|5678||IP||||||||||||... Order control SC (status change), order status IP (in process) OBR|... ...
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 for HL7, codes in parentheses will be defined in the IHE profile as an extension of the HL7 spec.
| ORC-1, Order control code (HL7 Table 0119) | ||
|---|---|---|
| RP | Order to be replaced | Recommendation and replacement messages for orders to replace (existing HL7 code) |
| RC* | Recommended change | Identifies that this OBR represents a recommended replacement order; used in the recommendation message sent to the Placer |
| RA* | Recommendation accepted | Identifies that this previously recommended replacement order has been accepted. Placer application: used in the Recommendation Accepted message; includes the assigned placer order number for the accepted replacement order. Filler application: used in the acknowledgment response message to the Recommendation Accepted message. |
| RD* | Recommendation declined | Identifies that this previously sent recommended replacement order has been declined by the Placer. Placer application: used in the Recommendation Declined message. Filler application: used in the acknowledgment response message to the Recommendation Declined message. |
| RO | Replacement order | Replacement messages for replacement orders added by Placer (existing HL7 code) |
| UM | Unable to modify | Replacement messages for orders that should not be modified (declined replacement; existing HL7 code) |
| ORC-5, Order status (HL7 Table 0038) | ||
| HR* | Hold for revision | Indicates that the order is not currently being worked on but has been placed on hold waiting for additional communication. Filler application: used in the recommendation message sent to the Placer. |
| ORC-16, Control code reason (reason for change recommendation, CWE, new HL7 table) | ||
| SV* | Specimen Volume | Specimen volume inadequate for requested testing, recommend a subset of tests appropriate for available volume |
| ST* | Specimen Type | Incorrect specimen type for requested testing, recommend testing that can use the submitted specimen type |
| UN* | Unavailable | Requested test unavailable, alternative testing proposed |
| CO* | Cost | Lower cost testing strategy proposed |
| (SR) | Screening Required | Screening test required prior to confirmatory test |
| (IT) | Indicated testing | Indicated follow up testing based on initial results |
| (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 |
Result Fulfillment/Followup (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 confirmation, 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 confirmation 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
The fulfillment order is carried in a modified OML^O21 laboratory order message. It includes information that makes a link to the prior order and result (target result). 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 confirmation as a fulfillment example; other examples include result interpretation and result annotation. Extensive discussions in the IHE Laboratory Technical Workgroup and the HL7 O&O Workgroup yielded a recommendation to refine the general mechanism for linking orders to use the REL clinical relationship segment from HL7 v.2.7 Chapter 12, Patient Care. This will require modification of the OML Message Specification (HL7 v. 2 chapter 4) to allow inclusion of the REL segment.
Structure and transaction details
This is a simplified fulfillment order representing a request for interpretation of a pre-existing result. The ORC and OBR are the new fulfillment order requesting confirmation of a previous result. The REL segment (v. 2.7, Ch. 12) establishes a target relationship between the new order and a previous order/result requiring additional action such as confirmation 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 are the relationship type (REL-2), the source identifier (REL-4, new order number), and the target identifier (REL-5, previous order group, order, or result identifier). Targets may be order or order group identifiers, in which case the target encompasses the entire order or order group and all results, or may include results identifiers (OBX-21, Observation Instance Identifier), in which case the target is restricted to the specific result.
Listing 8.2.3. Example Fulfillment Order (REL segment)
Clinician working from order review requests review of a blood test result (OML^O21): ... ORC|NW|1567|... New fulfillment order OBR||1567||14869-2^Pathologist review of blood tests^LN|... LOINC code for review REL||SVTGT|9999|1567|1234|... Fulfillment Target link to existing order or result (Placer 1234) ...
Notes:
- REL-2 contains the relationship type code and REL-3 carries the EI for this relationship.
- The REL segment uses EI datatypes for the source and target of the link, which carry a single identifier. REL-4 (source) will carry the Placer order number for the current order and REL-5 (target) will carry either the Placer order group number, Placer order number, or Observation Instance Identifier for the prior order group, order, or result. The target of the action with be the group results, single order results, or single result, respectively.
- The OML message is modified to add one or more REL segments as the last segment of each OBR group.
- If the fulfillment message is sent to the Filler who processed the prior order, the prior order does not need to be included in the message. If the message is sent to a third party Filler, the pertinent orders and results must be included in the message as prior results with Placer group, order, or result EIs matching the EI named as the target of the relationship.
Order fulfillment actions
Codes that might be used as Universal Service Identifiers (OBR-4, CWE) in LAB-7 are listed below in Table 8.3.1. Additional codes might be identified for other types of fulfillment actions or annotations.
| Code | Code System | Description |
|---|---|---|
| 56850-1 | LOINC | Interpretation and review of laboratory results |
| 80970002 | SNOMED CT | Medical evaluation, quality of care, review of exception case |
| 123038009:108252007=440276004 | SNOMED CT | Specimen:Laboratory Procedure=Storage (specimen storage, post-coordinated) |
| C93374 | NCI Thesaurus | Defined specimen storage (alternative single code for specimen storage) |
Fulfillment actions and result annotations are likely to be specified by a limited number of Universal Service Identifiers as above. More information about the purpose of a fulfillment request that could be useful for identifying particular types of quality problems or specific specimen handling instructions might be communicated as structured data in OBR-31 Reason for Study, using the following proposed codes. Currently there is not a code table supporting OBR-31.
| Code | Context | Description |
|---|---|---|
| CR | Lab review | Confirm results value; requests verification of previously reported results |
| IN | Lab review | Interpret results, requests interpretation of previously reported results |
| IR | Lab review | Review clinically inconsistent results, requests comparison of previously reported results amongst themselves |
| SI | Lab review | Suspected interference, requests verification of previously reported results due to suspected interference |
| OP | Quality of care | Test ordering problem, for process improvement work this code can be used to identify orders and the respective results, where problems occurred during ordering |
| SP | Quality of care | Sampling problem, for process improvement work this code can be used to identify orders, where problems occurred during sample collection |
| TP | Quality of care | Specimen transport problem, for process improvement work this code can be used to identify orders, where problems occurred during sample transport |
| TT | Quality of care | Turnaround time problem, for process improvement work this code can be used to identify results with excessive reporting delay |
| IT | Quality of care | Incorrect test performed, for process improvement work this code can be used to identify when an incorrect test was performed for the target order |
| PI | Quality of care | Patient identification problem, for process improvement work this code can be used to identify when a patient identification issue has occurred on the target order |
| XR | Quality of care | Incorrect results, for process improvement work this code can be used to identify when incorrect result were reported for the target order |
| BS | Specimen storage | Bank residual specimen, requests that the specimen should be stored long term, provides instructions for specimen storage in OBR-46 |
| TS | Specimen storage | Transfer residual specimen, requests that the specimen should be moved to a different location, provides instructions for specimen storage in OBR-46 |
| FP | Specimen storage | Store residual specimen pending followup, requests that the specimen should be saved for a short duration until a follow up contact, provides instructions for Specimen storage in OBR-46 |
| Code | Name | Explanation |
|---|---|---|
| SVTGT | Service target | Target universal service identifier is the object of the service identified by the source universal service identifier. Example: An order requests clarification or interpretation of a previous clinical laboratory test result. |
Breakdown of tasks 2016-2017
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 Done
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: Done
LCC Profile tasks (LAB-6 and LAB-7)
- HL7 v. 2.9 Change Proposal Submission [in progress Fall 2016]
- Initial HL7 balloting [2016-2017]
- Draft HL7 implementation guides/updates [Fall/Winter 2016]
- IHE LTW Change Proposals on completion of HL7 balloting
- IHE balloting [Fall 2017]
- Initial Connectathon implementation [N.A. Connectathon, Winter 2018]
Change Proposals and Harmonization Requests
Order replacement (LAB-6)
- HL7 Harmonization: New & Modified Order Control Codes (ORC 1, Table 0119), submitted July 2016
- HL7 Harmonization: New Order Status Code (ORC 5, Table 0038), submitted July 2016
- HL7 CP: Add Order Status Date Range (#36) to ORC, in progress
- IHE LTW CP: Pre-adopt ORC-36, new order, status codes, and messaging pattern from HL7 v. 2.9, planned
Result fulfillment (LAB-7)
- HL7 Harmonization: Define Relationship Type Table and Code (service target), submitted July 2016
- HL7 Harmonization: Define Control Code Reason Table and Codes, submitted July 2016
- HL7 CP New Reason for Study Table and Codes (OBR 31), submitted July 2016
- HL7 CP Add REL segments to OML, in progress
- IHE LTW CP, Pre-adopt REL and Relationship FT from HL7 v. 2.9, planned