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 02/08/2013
Version: 1.0 (draft)
Domain: Clinical Laboratory
Status: Work in progress Winter 2013. Order modification 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.

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

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.

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 update mechanism based on the OML^O21 message structure by adding a new messaging pattern, new control 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 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 establishes a linkage between replaced and replacing orders that supports 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.

This is a test

LAB-6 defines a laboratory order update recommendation transaction in which the Filler sends the Placer a proposed order update message, illustrated below. 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 they are followed by their proposed replacements, as in the existing order update message. Recommended 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 recommended orders may provide additional detail on the reason for replacement, or decision support.

If specimens are available and appropriate for analysis, recommended orders should include SPM segments referring to those specimens. If more than one order can be fulfilled by a specimen, its 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 recommended order does not contain an SPM segment the order will require a new specimen. Because order modification 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.

Structure of a 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 OH 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.	Recommended replacement orders will contain control code RC in ORC-1.
4.	Recommended 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 recommended order, an appropriate SPM segment will be attached to the recommended order. More than one recommended order can contain the same SPM segment. In this illustration, some recommended orders have available specimen and some do not.

 

On receipt of the order recommendation message, the Placer immediately returns an acknowledgement message (ORL^O22) containing the order(s) recommended for change with an RR control code (request received), and reflecting the ORC content and hold time TQ1 segment.

Structure of a recommendation acknowledgement message, derived from ORL^O22.

The acknowledgement message is returned by the Placer immediately after receiving the recommendation message. It includes an acknowledgment segment (MSA) and reflects the order recommended for replacement. As above, segments are shown for illustration. Some optional segments are shown and some segments not shown may appear in certain messages.
1.	The order to be replaced contains RR (request received) in ORC-1
2.	The acknowledgement includes the TQ1 segment carrying revision acceptance time window.

 

Later, after consideration, the Placer may accept the recommended changes by inserting placer order numbers into the replacement orders, removing the TQ1 segment carrying the hold time, and returning the message otherwise intact within the recommendation time window as a Placer order update. Additionally the Placer may delete recommended orders from or add new orders to the replacement lists. Orders added by the Placer have control code RO similar to standard order update messages, which distinguishes them from the recommended orders that retain the RC control code. If the Placer does not wish to modify an order, it may return the order in the update message with UM (unable to modify) as a control code in ORC-1 (recommended orders may be stripped from the message). 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.

Structure of an order update message including recommended orders, derived from OML^O21.

The update message is returned after the Placer considers the recommendations. Its structure is similar to the recommendation message except that the TQ1 segment carrying the revision acceptance timestamps is not included. Orders to be replaced are followed by the orders that will replace them. Orders for which a specimen is available carry an SPM segment, otherwise orders need new specimens. In this illustration the Placer has accepted two of the three original replacement recommendations for the first replacement group (control code RC) and has added one replacement order of its own (control code RO). The second replacement group was accepted without changing the recommendations. If recommendations were not accepted, an order could be returned with a UM control code, as shown at the bottom of the figure. As above, segments are shown for illustration and segments with LCC specific data are shown in red. RP and RO are existing order update codes and are thus shown in black. UM is shown in red because this is an LCC-specific use of that code.
1.	Orders to be replaced have control code RP in ORC-1
2.	Replacement orders have control code RC in ORC-1
3.	The Placer may elect to add additional replacement orders that were not recommended. These orders carry control code RO in ORC-1
4.	The Placer may elect to maintain the original order. In that case, the original order is returned with a UM control code (unable to modify) in ORC-1.

 

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 update messages for orders to replace
CA	Order to be canceled	Recommendation and update messages for orders to cancel
RC*	Recommended change	Recommendation and update messages for recommended replacement orders
RO	Replacement order	Update messages for replacement orders added by Placer
UM	Unable to modify	Update messages for orders that should not be modified
RR	Request received	Ack messages for orders to replace indicating receipt of recommendation
ORC-5, Order status
OH	On hold	Recommendation, ack, and update messages for orders to be replaced, 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)

This section is currently in development.

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 a particular 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, indicate particular order/result to target, describe problem). A LAB-7 transaction will generally create an order for follow-up of particular results. This order will yield an addendum, amendment, correction, or annotation of an existing result, and its own result will be a reference to this result modification.

Message and transaction details (tentative)

1. An existing result is targeted for follow up in the Order Result Tracker
2. Spawn order for annotation as child order of the target result's order, with link to the parent order and possibly the specific result OBX
3. Indicate type of follow up and annotation needed (single patient result verification, systematic inaccuracy over multiple patients, result interpretation, service process or workflow problem, other result annotation)
4. Possibility of capturing comments and direct annotations from clinicians via NTE and OBX at order time
5. Order for follow up is sent to the Filler
6. Targeted result is annotated/amended/corrected/addended
7. Result of child order indicates that the annotation was added to the target result

Note: There is a pertinent HL7 change request from early 2012 submitted to O&O by Austin Kreisler attempting to clarify the use of ORC-8 and OBR-29 in referring to parent-child relationships in orders and results. The proposal was to define ORC-8 as referencing order relationships and OBR-29 as referencing result relationships. This could be very useful in allowing LAB-7 to target both orders and results (#2 above), and we need to follow up to determine what happened to that request. See http://wiki.hl7.org/index.php?title=OO_CR073-723_Parent_Orders

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.