LCC Long Proposal - wiki

From IHE Wiki
Jump to navigation Jump to search

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 02/08/2013
Version: 1.0 (draft)
Domain: Clinical Laboratory
Status: Work in progress Winter 2013. Order replacement is complete in preliminary form; a tentative framework is being considered for Order Fulfillment. See Section 9, Change proposals and open issues in the contents above 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 does not support all the clinically-important interactions related to ordering and resulting laboratory tests. Two key aspects of this limitation are: 1) there is no standard way to convey information between the laboratory and clinicians when replacement of orders is indicated prior to testing, and 2) there is no standard way for the laboratory and clinicians to communicate about a test result that may require verification, clarification, interpretation, or additional work to fulfill the original clinical need.

These communications are typically carried out by phone, 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 documentation useful in quality assurance and process improvement. The LCC Profile will define 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 related to particular results.

Use Cases

Order replacement prior to testing

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.

Order fulfillment (post-result action to fully meet the individual and collective clinical need)

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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 includes a backporting of parts of the HL7 v. 3 laboratory ordering behavioral model to 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. If extension of field definitions, new fields, new codes, or new messaging patterns are required, those 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 will be 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.

Technical Approach Overview

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). The only available response to orders that cannot or should not be carried out is to refuse or cancel them. 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) with new triggers that increase the flexibility of the order-result interaction.

Currently, Order Fillers may send new orders to Order Placers via the LAB-2 transaction and Placers may send replacements for existing orders to the Fillers as part of the LAB-1 transaction (referred to in the IHE Lab TF as "order update"). LAB-6 blends elements of these transactions and uses new order control 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 takes the general form of a Placer order replacement message but it is sent initially from the Filler to the Placer, identifying the orders to be replaced and queuing up the replacement orders. The Placer may accept, decline, or modify the replacement orders and return the possibly modified message to the Filler as an order replacement message. This message is similar to the current order replacement message except for several new control codes, new "reason" codes, and a few other minor changes. LAB-6 also introduces a time window during which orders with pending recommendations are held and updates to them can be accepted. If no updates are received by the end of the window, order processing proceeds as it would have without the transaction.

LAB-7 carries an order for additional work on one or more results, 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 is in the form of an addendum or amendment to the result.

Simple schematic of the new transactions proposed in the LCC
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.

Current LTW transaction sequence diagram
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 will define two new transactions, LAB-6 and LAB-7. These transactions are shown in red in the LTW diagram below.

LCC transaction sequence diagram
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. Its content will be in the form of a partially completed unsolicited order update message transmitted in the reverse of the usual direction (i.e., Filler to Placer). The response to LAB-6 will be carried in the current LAB-1 Placer Order Management unsolicited order 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 be created in the context of a result in the Order Result Tracker, will automatically include references to the original order and the result, and will allow additional information to be entered by the clinician; additional orders 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 result.

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.

Breakdown of tasks that need to be accomplished

  1. Completion of proposed LAB-6 message structure and transaction strategy [Feb 2013]
  2. HL7 O&O review and proposal of HL7 CPs related to LAB-6 [March 2013]
  3. Proposal of IHE LTW CPs related to LAB-6 [April 2013]
  4. Extraction of data elements, actors, and transaction patterns from use cases and mapping to existing HL7 data elements for LAB-7 [April 2013]
  5. Message structure and transaction strategy for LAB-7 [May 2013]
  6. HL7 O&O review and proposal of HL7 Cps related to LAB-7 [June 2013]
  7. IHE LTW CPs related to LAB-7 [June 2013]
  8. Final documentation [July-August 2013]
  9. Initial balloting [Fall 2013]
  10. Initial Connectathon implementation [N.A. Connectathon, Winter 2014]

Order Modification (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.

"LAB-6 in LAB-1 sequence diagram"
Order modification recommendation transaction (LAB-6, shown in red) within the LAB-1 ordering sequence.
The clinical response to the recommendation is carried in the Replace Order transaction that is already part of LAB-1 (the last transaction above, shown in black). Transactions in blue are required only if the Order Placer and Order Result Tracker are separate systems.

Goal of LAB-6

In general, 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 our 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. LAB-6 is intended to be consistent with and an optional addition to the LTW. 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).

Message and transaction details

LAB-6 extends the existing LTW and HL7 2.5.1 laboratory order replacement mechanism based on the OML^O21 message structure by adding a new messaging pattern, new order control and status codes, new uses for previous order control and status codes, and a new set of order control code reasons. In the existing order update transaction, the Placer sends the Filler a message (OML^O21) in which orders to be replaced are indicated by order control code RP in ORC-1 and replacement orders are indicated by control code RO. One or more orders to be replaced (RP) are followed by one or more replacement orders (RO) and this positioning allows one-to-one, one-to-many, many-to-one, and many-to-many replacement patterns (HL7 v. 2.5.1, Ch. 4, pp. 30-32). There may be several sets of RP and RO orders (or replacement groups) in one message. The extensions to this messaging pattern described below essentially allow the Filler to create a similar message and send it to the Placer as an order replacement proposal or recommendation message that can be easily accepted or modified and returned as an order replacement message.

The recommendation message defined by LAB-6 is based on OML^O21 except that it travels from Filler to Placer, opposite the direction of the existing order replacement message. The Orders to be replaced have the control code RP in ORC-1, Placer and Filler order numbers in ORC-2 and -3, a new status HR (hold for revision) in ORC-5, and a code indicating the reason for replacement in ORC-16 (see Proposed code usage, below). Some orders may be recommended for cancellation only and in that case the control code CA is used instead of RP. A recommendation time window is defined in a TQ1 segment 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 "role" field containing a new code, HR (hold for revision). Orders to be replaced include all segments originally provided (ORC, TQ1, OBR, OBX, SPM, SAC, NTE) and are grouped such that the set of orders to be replaced are followed by their proposed replacements, as in the existing order replacement message. Proposed replacement orders have a new order control code RC (recommended change) in ORC-1 and new Filler order numbers. The NTE segments following the ORC/OBR of proposed orders may provide additional detail on the reason for replacement, or decision support information.

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.

Recommendation message
Structure of an order replacement recommendation message, derived from OML^O21.
Segments with LCC-specific data are shown in red; optional segments are shown in brackets for illustration and some messages may have additional optional segments not shown (e.g., additional NTE segments). Replacement groups contain orders to be replaced followed by the orders that are recommended to replace them (order cancellation is not shown).
1.Orders to be replaced contain control code RP in ORC-1, Placer and Filler order numbers in ORC-2 and -3 (not shown), status HR (hold for revision) in ORC-5, and a reason for replacement in ORC-16 (not shown).
2.Orders to be replaced carry a TQ1 segment containing start and stop timestamps for the recommendation time window. The asterisk indicates that this use of the TQ1 segment will require addition of a new attribute "Role" to the TQ1 definition to indicate the purpose of its time data. For this use the new attribute will contain HR (hold for revision).
3.Proposed replacement orders contain control code RC in ORC-1 and HR in ORC-5.
4.Proposed replacement orders may contain NTE segments with additional information about the reason for replacement.
5.If there is a specimen available from the initial order that can be used for a proposed order, an appropriate SPM segment is attached to the proposed order. More than one proposed order can contain the same SPM segment. In this illustration, some proposed orders have available specimen and some do not.

 

On receipt of the recommendation message, the Placer immediately returns an acknowledgement message (ORL^O22) containing the order(s) proposed for replacement with an RR control code (request received) and placer order numbers for the proposed replacement orders. Later, after consideration, the Placer may accept the proposed changes by returning the message within the recommendation time window as a Placer order replacement message. This message is similar to the existing replacement message except that it uses RA and RD control codes to indicate proposed orders that are accepted or declined, respectively, and a UM control code to indicate that an order should not be replaced. New replacement orders may be added by the Placer and indicated with control code RO, as in the existing order replacement message. TQ1 segments carrying the hold time should not be included in the replacement message. The Placer may indicate that an order should not be replaced by returning the order in the replacement message with UM (unable to modify) as a control code in ORC-1 and RD codes for the proposed replacement orders. An order proposed for replacement may be canceled without replacement by returning UM for its control code, RD for its proposed replacement orders, and then repeating the order after the replacements with CA for its control code. If the end of the recommendation time window is reached without an order update from the Placer, processing continues as it would have without the recommendation message (or if the message had been returned with UM).

Examples of these order replacement patterns are shown below.

Single Order Replacement

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)
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
...

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
TQ1|||||||<start>|<stop>||||||HR|... 
OBR|...
ORC|RC|1504|5679||HR|...              New placer order number, on hold for revision (HR)
OBR|...
NTE|...
...

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||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||5679|||...  
OBR|...
...

Multiple Order Replacement, Declined Replacement Proposals, 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)
TQ1|||||||<start>|<stop>||||||HR|...  
OBR|...
ORC|RP|1235|5679||HR|||||||||||PY|... Second order to replace (RP, HR, PY)
TQ1|||||||<start>|<stop>||||||HR|...  
OBR|...
ORC|RP|1236|5680||HR|||||||||||PY|... Third order to replace (RP, HR, PY)
TQ1|||||||<start>|<stop>||||||HR|...  
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 (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||||...                    New replacement order (RO)
OBR|...
NTE|... 
...

Declined Replacement and Order Cancellation

Placer places the initial order (not shown)...

Filler recommends replacement of the order (OML^O21, reverse):
...
ORC|RP|1234|5678||HR|||||||||||PY|... Order to replace (RP control code, HR status, PY reason)
TQ1|||||||<start>|<stop>||||||HR|...  
OBR|...
ORC|RC||5690||HR|...                  Replacement order (RO, HR)
OBR|...
NTE|... 
...

Placer declines replacement, original order stays in effect (OML^O21):
...
ORC|MU|1234|5678||HR||||||||||||...   Replacement declined (MU control)
OBR|...
ORC|RD|2236|5690||HR|...              Declined recommendation (RD)
OBR|...
NTE|... 
...

The Placer may also decline the recommendation but cancel the original order (OML^O21):
...
ORC|MU|1234|5678||HR||||||||||||...   Replacement declined (MU control)
OBR|...
ORC|RD|2236|5690||HR|...              Declined recommendation (RD)
OBR|...
NTE|... 
ORC|CA|1234|5678||HR||||||||||||...   Cancel the original order (CA control)
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.

ORC-1, Order control code
RP Order to be replaced Recommendation and replacement messages for orders to replace
CA Order to be canceled Recommendation and replacement messages for orders to cancel
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
CE* Cost Efficacy Lower cost testing strategy proposed
FO* Future Order Future order timed out without specimen
CI* Contraindicated Requested testing contraindicated in this patient, alternative strategy proposed
PY* Poor Yield Requested strategy has poor diagnostic yield for this patient, alternative strategy proposed
IY* Improved Yield Recommended testing improves diagnostic yield
TQ1-14 (new TQ1 field), Role
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

Order Fulfillment (LAB-7)

LAB-7 supports the ability of clinicians using an Order Tracker or 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. Thus the order created by Tracker application is referred to below as a result annotation order and the primary result of interest in this order is referred to as the target result.

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 an order for follow-up of a particular result (the target result) and may include other results for additional context. The target result may nor may not have been created by the Filler of the LAB-7 order. The 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 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, result annotation orders are linked to the target results and their orders in a consistent way such that the targets can be retrieved using structured data contained by the result annotation order.

Message and transaction details

The link between an annotation order and its target order and result is made through an HL7 parent-child order relationship. The annotation order is created as a child order of the target order and contains a reference to the target result as its parent result. This creates a link to the target order/result as structured data within the annotation order. For ease of reference and also to support cases where the Filler did not produce the original result, the annotation order message carries a copy of the target (parent) order/result, and possibly additional orders and results, as prior results.

The annotation order is carried in a standard OML^O21 laboratory order message. In the order section, the message carries the ORC of the parent (target) order followed by the segments of the child (annotation) 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 contains an observation identifier and subidentifier referencing the parent (target) result and OBR-29 contains the Placer and Filler numbers of the parent order, identical to ORC-8. The prior results section of the message must contain the target (parent) order and its target (parent) result, and may optionally contain other orders and results that provide contextual information. There is no ambiguity between the target and other orders/results in the prior results section because the targets are distinguishable as the parent order and result. The acknowledgement of the annotation order is a standard ORL^O22.

The annotation order may result in changes to the target result, which may be briefly noted in its own result, or the annotation order may carry a report or other information as its result.

The service ID for annotation orders may represent concepts such as result verification, result interpretation, service process problem, or incorrect test. Since the presence of the annotation 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 Order Tracker systems. In the future, LOINC will be the usual source for standard service IDs, and it should be reviewed to determine whether useful services IDs for these concepts exist or whether new concepts should be submitted for coding.

Change proposals and open issues

  1. HL7 CP, add TQ1 segment "role" field: 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.
  2. HL7 CP, new codes: RC control code, ST & HR TQ1 role codes, reason for replacement recommendation codes
  3. IHE LTW CP: Allow usage of more than one TQ1 segment if different roles.
  4. Check on the need for CPs related to unconventional code usage, e.g., UM from Placer to Filler to refuse a change recommendation.
  5. Need to define transaction strategy for LAB-7, result verification. Note that the parent-child strategy under consideration may not be compatible with the desires stated in the third paragraph under Technical Approach Overview.
Retrieved from "http://wiki.ihe.net/index.php?title=LCC_Long_Proposal_-_wiki&oldid=66095"