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
Version: 1.0
Domain: Clinical Laboratory

Summary

The communication and resolution of needs for order modification, 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 capture 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 modification of orders is required 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, data elements, and messages to support automated communications between the LIS and EHR about orders and results. It is intended to carry enough information about an order and likely alternatives that systems can implement very convenient, targeted displays to support modification of particular orders or issuing orders related to particular results.

Use Cases

Order modification prior to testing

1. 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. 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 of inadequate volume. 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. 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. Note: 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.
4. 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.
5. 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 the position of the missing/erroneous data highlighted. The physician quickly enters the new data and submits the order. Note: This and the previous scenario show limited rules-based processing of received orders that can be used to detect errors, omissions, and potential utilization problems. This mechanism might also be used for some types of decision support in test ordering. 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.

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

1. 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. Note: 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. 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. 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. Note: 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.
4. There is 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. A problem flag with a coded and/or free text explanation is easily attached to the result for quality assurance followup and reporting. Note: this capability allows development of databases 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.
5. 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). Note: this 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 is 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, and there is a reasonable possibility that this will suffice, perhaps with some additional terminology definition. If extension of field definitions, new fields, or new messages 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 be completed 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. LAB-6 carries a proposal for modification of orders from the Order Filler to the Order Placer in the form of a recommended "unsolicited" order modification message. The message may be edited by the Order Placer before it is returned to the Order Filler and it carries a code indicating that it is a response to a recommendation.

LAB-7 carries an order for verification or interpretation, a request for annotation, or an assertion of error, for one or more results, from the Order Result Tracker to the Order Filler. The order includes the results to be interpreted or annotated (as OBX segments) 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 provided the previous results. The response by the Order Filler is in the form of an addendum to the result.

New transactions (LAB-6 and LAB-7) proposed in the LCC profile with responses using existing transactions

New actors

For simplicity, initial plans call for the LCC to use existing actors from the LTW (see below). New actors will be considered only if absolutely necessary.

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. Its content will be in the form of a partially completed unsolicited order modification message (though traveling from Filler to Placer, in the opposite of the usual direction) so that the Order Placer can queue up those orders for easy submission or editing. 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 to the result.

The LCC will be based as much as possible on HL7 messaging (v. 2.5.1) similar to the LTW. Standard terminologies for new data elements such as reasons for order modification and post-result action requests will be identified during the project, if possible, or basic term lists may be created. If changes in the field content of HL7 message segments are needed, they will be pursued in collaboration with the HL7 Orders and Observations workgroup.

Impact on existing integration profiles

LCC profile development will attempt to avoid modification of the LTW and other profiles, except for the definition of a limited number of new codes and terms. If minor modifications of existing transactions are required, appropriate change proposals will be submitted as part of the LCC project.

New integration profiles needed

The LCC will be a new integration profile.

Breakdown of tasks that need to be accomplished

1. Analysis of available HL7 data elements; use case completion [use cases complete; initial HL7 review complete for LAB-6; work on LAB-7 will begin on completion of LAB-6]
2. Extraction of data elements, actors, and transaction patterns from use cases and mapping to existing HL7 data elements [complete for LAB-6]
3. Establish subsequent development timeline based on mapping results and the need for new HL7 work [in progress for LAB-6]
4. [If necessary] HL7 development in collaboration with HL7 O&O Workgroup [6 months - 1 year]
5. LCC message construction [5 months; in progress for LAB-6]
6. Final documentation [1 month]
7. Initial balloting [Fall 2013]
8. 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 Lab TF-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 not represent optimal care. The purpose of the transaction is to recommend one or more replacement orders for one or more orders that have been placed (see Use Cases, Order Modification), and it may occur any time from immediately after the order is placed until the initiation of the technical testing workflow. This differs from existing Filler order replacement in that the replacement order is not created immediately without clinical input, but depends on the update that ultimately comes from the Placer. Processing of orders that may be replaced is suspended temporarily pending the update and the status of those orders is set to Hold for a limited timespan during which a replacement order may be received. The replacement transaction should be independent of the flow of processing such that inclusion of the transaction does not require changes to existing workflow and transactions. This means that the effect of the transaction on subsequent workflow should be essentially identical to a Placer-initiated order update, which is a defined event in the LAB-1 transaction of the Laboratory Testing Workflow (LTW) profile. Thus subsequent processing can follow the path already defined for order updates and no significant changes to existing LTW transactions should be required to support order modification requests. LAB-6 is intended to be consistent with and an optional addition to the LTW. An overview of the LTW is provided in Lab TF-1, and LAB-1 is defined in detail in Lab TF-2 (p. 68 and Fig. 4.4.1-1 on p. 70).

General Strategy

Order modification recommendations will use the existing message types defined for orders in the LTW profile (OML^O21, OML^O33, OML^O35) and will be built on the existing order replacement mechanism. Essentially, the Filler will send the Placer a proposed order replacement message in which the orders to be replaced have the control code RP in ORC-1, status HD in ORC-5, a reason for replacement and a change recommendation code in ORC-16, optionally additional decision support information in an NTE segment following the ORC/OBR, and a hold lifetime in ORC-27. Orders may be recommended for cancel only, in which case a control code of "CA" is used without replacement orders. The recommended replacement orders will have a control code of RO in ORC-1. The orders to be replaced will have both Placer and Filler order numbers. The recommended orders will not have order numbers for either Placer or Filler because they are proposed and do not yet exist in either system. Orders to be replaced are followed immediately in the message by their replacements and this sequence indicates the relationship between replaced and replacement orders. For example, one or more orders to be replaced (control code 'RP') are immediately followed by one or more replacement orders (control code 'RO'). Additional orders to be replaced then appear and are followed by their own replacement orders. Thus replaced and replacement orders patterns may have one-to-one, many-to-one, and many-to-many relationships. The message will have the general form of an unsolicted Placer order replacement message except that it is sent from the Filler to the Placer, which is reverse the usual direction, the replacement orders do not have Placer order numbers, and ORC-16 contains codes indicating reason for replacement and the role of the current message (see below).

If the Placer accepts the recommendations, it can insert placer order numbers into the replacement orders and return the message essentially intact as a Placer order update. Thus the Filler "queues up" the recommended orders so they can be chosen with minimal processing. However, the Placer is not required to choose the recommendations and may elect to modify the replacement orders or keep the original orders. The message returned by the Placer is a standard order replacement message except that the orders to be replaced return the codes in ORC-16 indicating the reason for replacement and acknowledging the change recommendation. If an original order should be kept, it may be returned with "UM" in ORC-1. Processing then continues as it would after an unsolicted order replacement message. If the message does not yield a response by the end of the Hold lifetime in the recommendation message, processing continues from that point as it normally would. Messages that contain orders acknowledging prior change recommendations (in ORC-16) should not processed for further automatic change recommendations to avoid extended looping.

Message Details

The order replacement mechanism is not described in detail in Lab TF-1 or TF-2, but is referenced in Lab TF-2 on p. 68 and in Fig. 4.4.1-1 on p. 70. The mechanism is discussed in the HL7 spec for v. 2.5.1 in Ch. 4 beginning on p. 4-30, as part of the discussion of the use of control codes in the Order Control field of ORC segments (ORC-1). Existing order replacement transactions allow unsolicited order replacment requests from the Placer to the Filler and unsolicited replacement notifications from the Filler to the Placer. In both cases, the order(s) to be replaced are listed in the message with ORC-1 control codes indicating orders to be replaced (RU or RP codes depending on who initiates the request) and the replacement order(s) follow with ORC-1 control codes of RO (both cases). The reason for order replacement is contained in ORC-16. The contents of this field are defined in HL7 v. 2.5.1 Chapter 4 to allow both codes and text and are not constrained in Lab TF-2. In the case of Placer-initiated updates, the order(s) to be replaced include both the Placer and Filler order numbers (in ORC-2 and -3, respectively) and the replacement order(s) include the Placer order number. For Filler-initiated replacements, the orginal order(s) have both numbers and the replacement order(s) have the Filler order number and imply a request for a Placer order number.

The proposed order modification request message will be sent from the Filler to the Placer and uses the structure of a standard order replacement message as described in HL7 v. 2.5.1 Ch. 4 beginning on p. 4-30 and also in figure 4-2 (using RP instead of RU). ORC segments for orders to be replaced contain the RP control code in ORC-1, the reason for order replacement in ORC-16 (primary identifier, 16.1-.3), and an acknowledgement of the recommendation in ORC-16 (secondary identifier, 16.4-.6) as codes and/or text. These orders are moved to status "Hold" when the message is sent and are indicated as HD status in ORC-5. A lifetime for the recommendation, equivalent to a duration or timeout for the hold status, is carried in ORC-27, Filler's Expected Availability Date/Time.

In the message, the orders to be replaced are listed first with control code RP in ORC-1, followed by the recommended replacement orders with control code RO in ORC-1. OBR and OBX segments included in the original order must follow their ORC segments (the order should appear in its entirety). After the ORC/OBR/OBX segment(s), additional information about order replacement or decision support can be contained in an optional NTE segment (not shown below). If several sets of orders are to be replaced by alternative orders, each set to be replaced should be grouped ahead of its replacements.

The general pattern of segments to replace one order with an alternative based on a requirement for initial screening, cancel one order because it is contraindicated in this patient, and replace one order with two orders for improved diagnostic yield:

MSH|...|OML^O21|...
...                           5                            16                          27
ORC|RP|<placer #>|<filler #>||HD|||...|Screening Required^SR^Recommendation^RE|...||<timeout>|...
OBR|...
ORC|RO|||.............................|Screening Required^SR^Recommendation^RE|...
OBR|...
NTE|...|<explanation and decision support>
ORC|CA|<placer #>|<filler #>||HD|||...|Contraindicated^CI^Recommendation^RE|...||<timeout>|...
OBR|...
NTE|...|<explanation and decision support>
ORC|RP|<placer #>|<filler #>||HD|||...|Improved Yield^IY^Recommendation^RE|...||<timeout>|...
OBR|...
ORC|RO|||.............................|Improved Yield^IY^Recommendation^RE|...
OBR|...
ORC|RO|||.............................|Improved Yield^IY^Recommendation^RE|...
OBR|...
NTE|...|<explanation and decision support>
... 
<Specimen references will be handled in the same way as unsolicited order updates.> 

The usual response to an unsolicited order update is an ORL message that repeats the replaced and replacement orders, with RQ in ORC-1 of the replaced orders to indicate "Replaced as requested" (HL7 v. 2.5.1 Ch. 4, p. 4-31). In the proposed transaction, the recommendation message carries information for presentation to clinicians and human decision-making, thus the immediate acknowledgement of the recommendation cannot carry the final clinical decision. Thus the transaction will return an ORL that reflects the message as sent but contains RA (recommendation acknowledgement) in ORC-16.2. The overall transaction remains incomplete until an order update message is received or the hold period times out. The update message will usually be associated with a significant and unpredictable delay. Thus from an interface perspective, it's probably appropriate to regard that message as prompted but unsolicited. The returned message is proposed to be a standard unsolicited order replacement message with a new recommendation acknowledgement code (RR, recommendation response) in the secondary identifier components of ORC-16 indicating that the replacement is the result of a Filler recommendation.

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, ack, and modification messages for orders to replace
CA	Order to be canceled	Recommendation, ack, and modification messages for orders to cancel
RO	Replacement order	Recommendation, ack, and modification messages for replacement orders
UM	Unable to modify	Modification messages for orders that should not be modified
ORC-5, Order status
HD	Hold	Recommendation, ack, and modification messages for orders to be replaced, indicating hold status
ORC-16.1, Reason for recommendation (new, REC codes)
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
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
ORC-16.2, Recommendation message status (new, REC codes)
RE*	Recommendation	Initial recommendation message from Filler to Placer (OML)
RA*	Recommendation Acknowledgement	Immediate (ORL) response from the Order Placer system indicating receipt of the recommendation
RR*	Recommendation Response	Clinical response to the recommendation (OML order modification)

Risks for the Project

1. Failure to attract and maintain adequate interest and personnel
2. Inadequate support for necessary data types and data models in existing standards, requiring standards development work (additional resources & delay) or inadequate progress in the HL7 v. 3 Behavioral Model prototype, with which the LCC will maintain conceptual consistency
3. May lose attention if not part of Meaningful Use (time frame may be OK for phase III, though)
4. Balloting issues that introduce delay
5. Implementation failure -- not a problem for development of the spec, per se, but the effort is wasted if there is no broad implementation. A Connectathon demonstration is key, as is commitment to marketing through CAP and others.

Mitigating factors:

1. Strong backing and logistics support from the College of American Pathologists
2. Group members are participants in the S&I Framework effort
3. Group members are also members of the HL7 O&O Workgroup, will draw on that expertise, and will share plans and progress between the groups
4. The LCC has a limited scope related to order modification and results verification/interpretation. If progress on the HL7 Behavioral Model lags, the LCC should be able to complete its development in this limited area while remaining consistent with the overall Behavioral Model strategy.

Open Issues

1. Final participant roster
2. Are all necessary data elements adequately covered in existing standards (i.e., HL7 v. 2.51) and, if not, how much additional standards work might be required?

Effort Estimates

Optimal personnel include 2 - 4 pathologists (MD) and 4 - 8 industry participants. The ideal final group is 8 - 10 committed participants. Development of the specification will take about one year, with subsequent balloting and a Connectathon demonstration. Depending on the need for additional development in HL7, there could be two phases of LCC development separated by a pause of several months to one year during which some LCC Workgroup members contributed to HL7 development in the HL7 O&O Workgroup.