ONC_LRI_UCR Workgroup Meeting

Meeting Summary S&I Framework

Use Case and Requirements Workgroup

Laboratory Results Interface

Date: 03/03/11

Name: Laboratory Results Interface Initiative (LRI) Use Case and Requirements (UCR) Workgroup

Session 4

Agenda/Objectives:



Administration o Announcements of Sub-Workgroup (SWG) Meetings o Confirmation of New UCR Workgroup Meeting Time - Thursdays 2:30 PM EST – 4:00 PM

EST o Content Approach Moving Forward



Active Discussion o Overview and Scope o Challenge Statement o Value Statements



Homework o Comment on all Use Case sections by 3/10/2011

Attendees:

Panelist Attendees:



Merideth Vida



Ed Larsen



Arien Malec



Jitin Asnaani



Heather Stevens

Webinar Attendees:

Wendy Blumenthal, Andriy Selivonenko, John Ritter, Thanos Tsiolis, Ken Willett, Jon Bartels, Robert

Dieterle, Jonathan Tadese, James Harrison, Michael Nenashev, Andrew Splitz, Austin Kreisler, Kathy

Walsh, Brian Pech, Ken Gerlach, Ken McCaslin, Rosa Aleman, Robert Hausam, Riki Merrick, Michael

Brunelle, Mark Butler, Lorre Pacheco, Gabby Jewell, John Hall, Bob Lutolf, Sandy Jones, Bob Yencha,

Steve Hufnagel, Cynthia Coulter,Corey Spears, Brian Ahier, Glen Moy, Brandy Hays, Arturo Sanchez,

Jillian Wanner, Elliot Sloane, Julie Cantor-Weinberg, Wes Kennemore, Amy Goring, Jonah Frohlich, Ed

Larsen, Gary Dickinson, Randolph Sanks, William Ormerod, Srinath Remala, Robert Coli, MD, Frieda

Hall

Action Items:

Lead

N/A

Action Item

Sign up for Sub-Workgroups

Using the Wiki

Next Steps / Status

In Progress

Comment on Remaining LRI

Use Case Content

In Progress N/A

Contributors Due Date

WG

Participants,

Committed

Members

WG

Participants,

3/10/11

3/10/11

Laboratory Results Interface Initiative – UCR Workgroup Session 4, 03/03/11 1

Meeting Summary

Identify requirement to cover what order information should be included as part of the result message.

Author additional content for the

Overview and Scope to provide the context for orders.

In Progress

In Progress

Determine how to incorporate clinical decision support so that it isn’t precluded

Author content for the background section to ensure past Implementation Guides are properly referenced.

Author content, to be included as part of the challenge statement, to cover challenges associated with meeting CLIA reporting requirements.

Revise value statement and or gaps and risks to incorporate comments and discussion points concerning coordinated families of lab interface standards.

In Progress

In Progress

In Progress

In Progress

S&I Framework



Support

Leads

N/A

Robert

Hausam

N/A

Austin

Kreisler

Committed

Members

Ken Willet,

Andy Splitz,

Jim Harrison,

Thanos

Tsiolis, David

Cheng

Ken Willet,

Andy Splitz,

Jim Harrison,

Thanos

Tsiolis, David

Cheng

In Scope Lab

Tests

3/10/11

3/10/11

3/10/11 Riki Merrick

& Austin

Kreisler

3/10/11

Austin

Kreisler, Glen

Moy, Ken

McCaslin

3/10/11





Use Case Content Discussion

Overview and Scope:

Comment #4: (Jim Harrison)

I have some concern that standards for results transmission that are defined outside of a more complete order-result communication context may be incomplete or may require assumptions that are ultimately limiting. For example, is it reasonable to constrain HL7 results reporting messages adequately to allow "plug and play" with consequent significant reduction in implementation time and cost, without considering order messages? Results messages carry OBR segments with order information, and constraining these segments would appear to require constraint of the order messages from which they are derived.

Key Discussion Points:



Result messages have an OBR segment which comes from the detail of the order



Defining results without the context of the order may lead to problems/issues



ELINCS created a logical ordering process/virtual order that set pre-conditions that were necessary for the results to work



Similarly to how ELINCs handled orders, the order message structure does not need to be defined; however, required OBR elements should be identified



Identifier for patient, identifying for ordering system, identifier for orderable item which is sent to the lab, should all be included as part of the result

Resolution(s):



Identify requirement to cover what order information should be included as part of the result message



Ken Willet, Andy Splitz, Jim Harrison, Thanos Tsiolis and David Cheng will author additional content for the Overview and Scope to provide the context for orders. The OBR elements that will be required as part of the results message will also be included as part of the new content.

Comment #5: (Ken McCaslin)

Do "clinical laboratory test results" in this context include decision support content, including links to external content, that may be incorporated by the system the originates the results?




Decision support should be included as part of the results message through extensions



Linking results to decision support through the EMR/EHR will be difficult and will require extensions



Context should be included to support future use of clinical decision support so that it is not precluded

Resolution(s):



Establish general guideline; LRI Use Case should be within the scope of the HL7 standard.

This will prevent implementers from having to implement extensions.



Robert Hausam will bring up this topic as part of the In Scope Lab tests SWG


Please clarify the meaning of this statement: •Stage 2: Automating the laboratory results interface

Resolution(s):



Clarification provided -- A standardized laboratory results interface will automate the laboratory results interface for MU stage 2.





Comment #19: (Austin Kreisler)

The HITSP/IS01 specification, or more properly the HL7 2.5.1 Lab to EHR IG that HITSP points to, is now the lead IG in a family of implementation guides. This family now includes the HL7 2.5.1 Electronic Laboratory Reporting to Public Health IG (ELR to PH IG) as well as a HL7 2.5.1 IG for Genetic Testing. The 2.5.1 ELR to PH IG has been adopted as one of the public health MU standards. The

ELR to PH IG actually lays out a strategy for constructing a family or related message profiles that don't conflict with one another and enable a sender to support multiple receiver profiles. This should be added as additional background related to the HITSP ISO1 IG.




The HL7 implementation guides have been designed to be consistent with one another.



Having a family of consistent implementation guides and profiles ensures consistency reducing the impact of the implementers, particularly the senders of data.



These standards and implementation guides need to be included as part of the background for the LRI Use Case to show that they are important even if they aren’t being implemented.

Resolution(s):



Riki Merrick & Austin Kreisler will author content for the scope or obstacles and risks to ensure past Implementation Guides in which coordinated lab results interfaces and messaging are properly referenced.

Comment #20: (Thanos Tsiolis)

"Ordering Laboratory Results" is listed as an out-of-scope topic. While I understand that we do not plan to address or standardize as part of this effort the content of a lab order message, in our experience, the time and cost reduction in the implementation of laboratory interfaces depends a lot on the existence of an outgoing orders interface to the lab. When addressing and defining the field by field needs of the lab result reporting message we should also consider and address the case where an order has been sent to the lab previous to the result coming back to the order placer.




This comment was addressed in the discussion on comment #4

Resolution(s):



Identify requirement to cover what order information should be included as part of the result message



Ken Willet, Andy Splitz, Jim Harrison, Thanos Tsiolis and David Cheng will author additional content for the Overview and Scope to provide the context for orders. The OBR elements that will be required as part of the results message will also be included as part of the new content.

Comment #21: (Hans Buitendijk)

The definition of "structured data" needs to evolve to agree on appropriate level of data for the tests at hand.

Resolution(s):



This comment will be addressed as part of the Structured Data SWG


The use of "Receive results in structured format and display in human readable format" is confusing as some may believe that the transaction is easy to read, or that it be displayed as "reported" at the source. As long a computer can interpret and put it in a reasonable format that is o.k. We also should not have a reason to restrict this such that a CDA document format is the only format to make this work or whether it is sufficient to have the data where the recipient can determine how best to display that in human readable format (graph, report, other) for the intended use. I submit that getting the data is sufficient.

Resolution(s):



This comment will be addressed as part of the Structured Data SWG






The definition of provider is limited to the potential role within this use case (although even then it would not work), rather than a general definitions as supplied for others. Generally, can we point to generally accepted definitions and name the source?

Resolution(s):



Support leads will ask Hans to review definition in the glossary to see if it is adequate.

Challenge Statement:


There are many specifications for ambulatory lab reporting. Every vendor in this space has its own format for reporting results. Each lab has its own vocabulary for identify tests and reporting test results and units of measure. Customization of interfaces is extremely common in the acute care hospital setting where the individual hospitals demand result formats customized to meet local requirements. Labs on the other hand want to use result reporting formats that conform with CLIA standards and once a lab finds a result format and content acceptable to their local CLIA examiner, the lab is loath to change that format. It's a sad fact that in many cases, lawyers associated with laboratories have a greater say in the format of lab results than the clinicians or the IT folks. Moving labs off these proprietary specifications will be the real challenge. Meaningful Use doesn't directly address the reasons why labs use the formats they do today, and does not provide incentives to the labs to change current practices. That's the real challenge here.




Laboratories are locking in formats on the outbound side to meet CLIA reporting requirements and lawyers seem to have more input on the format than clinicians.



HL7 v2.5.1 includes a section to address risks and obstacles in dealing with CLIA issues.



This challenge statement needs to be revised to cover the challenges associated with CLIA.

Resolution(s):



Austin will draft language to be included as part of the challenge statement to cover the concerns related to CLIA regulations.


Proposed change to the last line of the Challenge Statement from: The field by field details of HL7 v2 implementation guides used by clinical labs and EHRs vary, creating a need for mapping or configuration per interface, and the prevalence of core subsets of LOINC codes for common tests and analytes also varies, causing downstream issues in decision support and quality reporting. Proposed:

There are many HL7 v2 implementation guides for labs and EHRs that accommodate a wide variety of use cases and unique system level limitations of various systems. In some cases the scope is not restrictive in the implementation guides attempting to solve multiple unique receivers of lab systems with the one guide therefore creating ambiguity for all users not only with the data elements, but also with the data sets to be used causing downstream issues in decision support and quality of reporting




In order to have Implementation Guides co-existence, it will require identifying a standard set of data types and vocabularies.



Having a family of consistent implementation guides and profiles ensures consistency reducing the impact of the implementers, particularly the senders of data.

Resolution(s):



Change to the last line of the Challenge Statement to: “There are many HL7 v2 Implementation

Guides for labs and EHRs that accommodate a wide variety of use cases and unique system level limitations of various systems. In some cases, the scope is not restrictive in the

Implementation Guides attempting to solve multiple unique receivers of lab systems with the one guide; therefore, creating ambiguity for all users not only with the data elements, but also




Laboratory Results Interface with the data sets to be used causing downstream issues in decision support and quality of reporting .”

Comment #3: (Thanos Tsiolis)

"There are at least two standard specifications for ambulatory laboratory reporting..." I would say that "There are at least two implementation guides for the same standard specification for results reporting..." Both of these implementation guides use the same standard - HL7 V2 messaging, however the constraints and specificity they introduce in the field-by-field implementation and content needs to be examined, possibly further restricted, and definitely harmonized.




Workgroup members agreed with comment and suggested the change.

Resolution(s):



Update challenge statement. o Current: There are at least two standard specifications for ambulatory laboratory reporting, neither of which are adopted universally across industry. o Updated: There are at least two Implementation Guides for the same standard specification for laboratory results reporting, neither of which are adopted universally across industry.


The larger challenge is the cost to change from a current working format to a new format, whatever it is. The downstream challenge for clinical decision support and quality reporting is not a strongly tied to the format/implementation guide used, typically capable of handling a wide range of unstructured to structured data, but rather the level of structure that allows for appropriate mapping. So a re-phrasing may be "There are many implementation guides used in ambulatory laboratory reporting, neither of which are adopted universally across the industry. The cost and time to migrate to a common implementation guide with a consistent level of structure using a consistent vocabulary that accommodates clinical decision support and quality reporting is substantial."

Resolution(s):



This comment will be addressed as part of the Success Metrics SWG

Comment #5: (Cindy Vinion)

Please supply a clear statement of the challenge and intent of this initiative; what is listed is a restatement/copy of the problem as stated in section 2.0. What should this initiative do with or about the "two standard specifications"; should we develop only one? Are there existing implementations of either or both of these 2 specifications that need to be accounted for and allowed by any new specification? What role do the "downstream issues" play in this initiative, or are secondary and analytical uses of the data not a consideration at this time? If they are a consideration, what other than "decision support and quality reporting" needs should be considered, and whose decisions and reporting needs are to be considered?



Commenter not present for discussion.

Value Statement:


I would add more than "reduction in cost" to the value statement as well as explain whose costs will be reduced. For example, having lab results "sent in a more timely manner" means that the patient can be appropriately treated in a more timely manner, disease outbreaks can be identified or confirmed in a more timely manner, overall healthcare costs to the patient may be reduced since treatment can start earlier, overall healthcare costs to society can be reduced since infectious conditions can be identified and remediated early, administrative costs & time to labs may be reduced by eliminating the overhead of preparing and sending paper reports, etc. In short, this section could use some additional value statements.









I encourage this initiative to select a perspective, either Sender or Receiver, to take when developing or selecting an imple mentation guide. It is much easier to author standard's guidance and implementation guides if you have this kind of focus. I also suggest developing the guide from the Receiver perspective. This perspective would focus the guide on what an EHR should be capable of receiving which is the aim of the Meaningful Use criteria for Stage 1 as listed in section 2.3.




Comment #3: (Glen Moy)

Agree with Cindy's comment that the value of standardized exchange goes beyond reduction in cost; would argue that the more significant value is in better decision making at the point-of-care and improved care delivery.




Improvement of care is the goal of the S&I Framework and MU; the intention of including cost of as part of this statement is so that we have a quantifiable measure.

Resolution(s):



This comment will be addressed as part of the Success Metrics SWG

Comment #4: (Glen Moy)

Assuming that standardization of transport method is out of scope, think the second sentence should be rephrased so that it's clearer that the end result will be a specification that standardizes content.




Transport is independent of the message; therefore, it should be kept out of scope



Transport should be a Pre-Condition of the Use Case

Resolution(s):



Glen Moy, Ken McCaslin & Austin Kreisler will provide content to cover this topic as part of the value statement.


Proposed change to clarify the Value Statement: An interface is an automated delivery of data between two disparate systems in a consistent formatted process that both the receiver and the sender can understand and effectively use. For a laboratory interface an example of disparate systems are laboratory and EHR. The best coupling of systems is to provide the full circle of connectivity where an order requests services and results of that request are provided through an interface. Due to the limits of the scope of this project, laboratory results to an EHR are the priority. A laboratory results interface has the potential to provide an efficient process by using standards to define the message, the data elements, how those data elements will be used, and the vocabulary to be used. If the lab reports are maintained in an electronic record there is a potential for improved clinical outcomes. This process will result in a specification that standardizes laboratory results for the ambulatory setting. This will drive consistent behavior across multiple organizations to support a consistent implementation that has the potential to reduce costs.

Resolution(s):





Part of the value in a specification is how reusable it is across other use cases. Having a specification so narrowly defined that it is unusable across multiple use cases will drive up the total cost of lab interfaces because the sheer number of different lab interfaces necessary to implement the variety of specialized incompatible lab interfaces will be costly. We must guard against being pen ny wise

(i.e., so narrowly constraining the ambulatory lab interface) and pound foolish (dramatically increasing the number of incompatible lab interfaces needed). Today, labs serve both the acute care and ambulatory settings simultaneously. In addition, those same labs will




Laboratory Results Interface be send results to public health and other destinations as well as the ordering providers. We need to emphasize lowering the total cost across all interfaces, not just lowering the cost for a single interface.




Public Health reporting needs to be taken into consideration

Resolution(s):





The value statement should include the further downstream value to clinical decision support, quality reporting, continuity of care support through consistent language, etc. Clearly there are cost savings over manual transcription, but the end goal is where the real value is.

Resolution(s):




Other:

Content Approach Moving Forward



In order to develop functional requirements early on in the Use Case development process all remaining LRI content will be posted to the wiki.



The workgroup has been asked to provide comments by 3/10/2011, when possible make sure comments are actionable.



When reviewing this content, please start to think about what section you would like to own and/or shape.



Sub-Workgroups will be created to tackle each of the remaining sections.



Sub-Workgroups will meet offline, take into account the comments that were provided by the larger workgroup and will work to refine the section content.



Content will be presented during WG sessions and all comments/issues with the content will be ironed out on the call. The Sub-Workgroup will be responsible for making the updates based on the WG session discussion and then the section will be put up for consensus.



Each LRI UCR workgroup member is encouraged to participate in at least one of Sub-

Workgroups to address the remaining sections.


ONC_LRI_UCR Workgroup Meeting

Related documents

Products

Support

ONC_LRI_UCR Workgroup Meeting

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib