LRI+Draft+Implementation+Guide

include component="page" wikiName="siframework" page="LRI Header" **Draft LRI Implementation Guide Workspace for comments/suggestions**

Draft LRI Implementation Guide
The purpose of this review is to provide a review and proposed revisions to text as noted throughout this version by the core editorial teams comments within the document below (V0.5).

This version includes all content updates available as of Friday 9/9 in the spreadsheets the IG Analysis Group has been updating in on-going meetings.

Please note the following regarding the status of this document and expectations of a review at this time:
 * 1) The creation of conformance statements is incomplete and will continue in the background. Reviewers are encouraged to comment on the highlighted text in the Comments column of the datatype and field segment tables to indicate if there are additional conformance points that can be inferred from the notes.
 * 2) **COMMENT DEADLINE:** Comments and suggested revisions will be accepted until 8AM Wed Sept 14 as deadline for submission to HL7 for ballot cycle is Noon PT Thursday, 9/15. Comments or suggestions received after 8AM Wed will be incorporated, time permitting, or will be held over for consideration along with other Ballot review Comments.
 * 3) How to provide feedback:
 * 4) For substantial changes to text, please edit a copy of the document with track changes on and send to Bob Yencha and Kathryn Calderone, please put LAB IG REVIEW COMMENTS in the subject line.
 * 5) For minimal comments, please add to the Comments section of this page (see the Comments Section below).
 * 6) Note that the style for heading and table references is being reworked to correct numbering, index generation and repeat across page breaks, therefore the current document subsection numbering is out of sync with the major headings. A number of open editorial tasks are also noted in the document.


 * [[file:V251_IG_LB_AMBLABRPTLRI_R1_V0.5_DRAFT.docx]] ||

Completed Artifacts for Inclusion in the Implementation Guide

 * Title || Date of Completion ||

Comments Section
introducing in this section there are two profile options, one requiring OIDS, one allowing but not mandating OIDS and add reference to the Profile section (1.6). || Resolved in v0.3 DRAFT ||  || hyperlink to HL7 Members Only Section for download [] Or HL7 Store [] || Resolved in v0.3 DRAFT ||  ||
 * **Reviewer's Name** || **Organization** || **Draft IG Section** || **IG Page Number** || **Suggested Change** || **Comments** || **Questions** ||
 * Freida Hall || Quest Diagnostics || 1.5.1 || 21 || “Use of ISO OID for Strong Identifier” – Suggest mentioning/
 * Freida Hall || Quest Diagnostics || 1.8 || 17 || Re: Assumption reader has HL7 V2.5.1, suggest adding
 * Freida Hall || Quest Diagnostics || C.3.6 ||  || It would be helpful for implementers to have a summary recap list of everything pre-adopted in this section ||   ||   ||
 * Rob Snelick || NIST || MSG DEF Sections ||  || Identify and list all conformance requirements in a standardized fashion. Give an ID to each conformance statement. Each conformance statement should be understandable without context. That is, write conformance statements like "OBX.3.1 shall be XXX" as opposed to "this field shall be XXX". || Suggestion adopted, see example doc above for || Design questions in the example need review ||
 * Rob Snelick || NIST ||  ||   || Create a list of all conformance requirements based on previous suggestion. List should include ID tag, requirement description, reference to section of document, type of requirement, more?? ||   ||   ||
 * Rob Snelick || NIST ||  ||   || Is it enough to reference the value sets or should the document (or supplement) list the value sets (at least for the static sets). It seems to me that if each implementor has to track down the value sets they may not come up with the same results. What about dynamic value sets? I'm looking for a single source of truth. ||   ||   ||
 * Freida Hall || Quest Diagnostics || 1.6 Conformance to this Guide ||  || Comment withdrawn ||   ||   ||
 * Freida Hall || Quest Diagnostics || 1.7.1 Referenced Profiles ||  || Suggest remove Appendix C here and throughout the document; don't think LRI IG has discussed including it in the IG || See questions in v0.3 DRAFT re:duplicate content in C, suggest that the Titles be cataloged as Items of interest to new HL7 developers with links to HL7, other sources ||   ||
 * Freida Hall || Quest Diagnostics || 1.7.1 Referenced Profiles ||  || Toward the end of this section, suggest changing to map the spreadsheet description of sender/receiver, for example:
 * Ambulatory LIS to EP EHRLab Result Sender – This profile is provided for informational purposes onlyand is a message profile for an Ambulatory Lab Information System (LIS) sending a message to an Eligible Provider(EP) Electronic Health Record (EHR) System. A sender of Laboratory result messages conforming to the profile will satisfy the requirements of the ELR profile, and in the future may meet the requirements of the Lab to EHR profile.
 * EP EHR from Ambuatory LISLab Result Receiver – a message profile for Eligible Provider EHR receiving message from Ambulatory Lab Information System (LIS)Electronic Laboratory Reporting to Public Health. This is the primary focus of this document. ||  ||   ||
 * Freida Hall || Quest Diagnostics || 1.8.1 ||  || I think the LRI IG WG declared that truncation is not allowed by receiver. Suggest removing explanation of symbols for truncation from this section (especially # Truncation allowed) as this seems to conflict. || Resolved in v0.3 DRAFT ||   ||
 * Freida Hall || Quest Diagnostics || various ||  || There are several references to pre-adopt from V2.6; I think LRI IG decided to revise reference to pre-adopt from V2.7 (vs. determining the exact version item was added). || Resolved in v0.3 DRAFT ||   ||
 * Ken McCaslin || American Clinical Laboratory Association || All chapters ||  ||  The sub-paragraph number is all messed up. We have paragraphs 1.1 in all Chapters (example Chapter 1, 2, 3 the first sub-paragraphs are all 1.1) very confusing. It makes any reference for problems to be complicated and requires both the chapter and section number. One cannot assume that section number is in chapter references as the first part of the section id.  || v0.5 ||   ||
 * Ken McCaslin || American Clinical Laboratory Association || This is 1.4.3 in Chapter 1.  ||   || Proposed wording: The laboratory recieves an order (electronically or by paper) to perform tests as directed by the Ordering Provider. In addition, followup requests maybe made to the order to confirm or provide additional information about a test. In addition, a lab may reflexively add tests based on relfex criteria when an order tests exceed a pre-determined value as determined by the Ordering Provider and the laboratory. || v0.5 ||   ||
 * Ken McCaslin || American Clinical Laboratory Association || Section 1.15.4.2 of Chapter 4 ||  ||  Snap shot processing, should we just say that this should default to the underlying spec?  || v0.5 ||   ||
 * Ken McCaslin || American Clinical Laboratory Association || Many places in the document ||   || There are references to ELR. These were removed in the updated document I sent before going on vacation || v0.5 ||   ||
 * Ken McCaslin || American Clinical Laboratory Association || Section 1.34.1 Chapter 6 ||  ||  Regarding the OBX-3 clarification. I think in Chapter 6 section 1.34 there is clarification regarding the uniqueness that must be established using OBX-3 and OBX-4. The complexity may not be completely apparent. We may want a subsection 1.34.1 to provide the cross field relationships to help define that in combination these provide a unique identification under the OBR using information from the Austin, Buitendijk and McCaslin emails.  || v0.5 ||   ||
 * Ken McCaslin || American Clinical Laboratory Association || Section 1.34.1 Chapter 6 and section 1.13 chapter 1 ||  ||  In Chapter 1 section 1.13 there is an indication that UCUM would be piloted. In Chapter 6 section 1.34.1 states that UCUM is required. This is not insync with my understanding.

1.1 UCUM
UCUM (Unified Code for Units of Measure) appears to be a viable option for reporting units of measure but must be pilot tested in order to understand the impact of key issues identified by various stakeholders. This guide does not preclude the use of UCUM coding where senders and receivers have localized this guide by mutual agreement. UCUM is approved to be piloted and is not a requirement as stated in Chapter 6 Section 1.34.1 that it is required. || v0.5 ||  || If OBR-11 Valued G then Parent/child fields need to be used. Can this also be used for Micro – and if so how do we develop a paragraph to support this concept: To determine if Parent/Child structure is necessary, OBR-26, OBR-29 and OBR-50 (Parent Result, Parent, and Parent Universal Service Identifier), to communicate the appropriate relationships, it is determined when the value of OBR-11 (Specimen Action Code) of the child is "G" (Generated order; Reflex Order). Therefore the conformance requirements are: Condition Predicate: If OBR-11 is valued "G" Conformance Statement: If NG – OBR-26, OBR-29 and OBR-50 must be valued. If GU – OBR-26 and OBR-29 must be valued. Third Part: for micro culture and susceptibility Insure that this is tested – Conformance Statement: The sender can use the parent/child structures The receiver can receive and process the parent/child structure Note: The decision Table can be found below as a separate table. || v0.5 ||  || Section 1.14.3 ||  || The conformance statement does not match what was decided by the LRI IG WG as outlined below for CWE-9: Conformance Statement: If the triplets identified by elements CWE.1, CWE.2 and CWE.3 and CWE.4, CWE.5, and CWE.6 are not valued then CWE.9 shall be valued. || v0.5 ||  || In Word: File/Properties select Summary tab ||  ||   || Diagnostics || Chapter 1 Introduction || 14-207 || Typo second paragraph Chpt. 1 (elment) If the condition predicate associated with the element is false then the usage for the elment is RE-Required but may be empty. ||  ||   || From Condition predicate: Required if component 1 (ID Number) is populated. To Condition predicate: Required if component 1 (identifier) is populated. ||  ||   || If CE.1 is valued, this must be valued ||   ||   || 1.14.6 || 29-207And 30-207 || CX-GU, component CX.10 Assigning Agency or Department – remove LEN column of 3..3 3..3 is not specified in the spreadsheet, and not sufficient for CWE sub-component of CX data type ||  ||   || (following table) || 29-207 And 31-207 || Do we need to retain the reference to HITSP since this is not a HITSP initiative? Although this guide does not deal directly with Version 3 constructs, it is intended to work within the context of the HITSP Interoperability constructs, which work with both Version 2.x messaging and Version 3 constructs. ||  ||   || HL7 0396 is maintained online by HL7 at http://www.hl7.org/Special/committees/vocab/table_0396/index.cfm ||   ||   || I believe this was discussed by the LRI IG in July with decision to retain the Table HL70191 from V2.5.1 rather than Table HL70834 in V2.7. ||  ||   || HL7  (from HL7 2.7) ||   ||   || Suggested rewording of the first sentence….”LOINC is used as an additional coding system for this field, in conjunction with local codes.” || v0.5 ||  || Suggested rewording…..UCUM® is an HL7-approved code system and shall __may__ be used for units __of measure__ as described in the appropriate HITSP Interoperability Specification. The UCUM unit of measure for values without a unit of measure is “1”. We __absolutely do not want__ a “1” transmitted if there are not units of measure for the result. This is one of the issues identified by the Vocab WG that needs to be tested during the pilots. The transmitted data must maintain accuracy and using a default value would go against this requirement. || v0.5 ||  ||
 * Ken McCaslin || American Clinical Laboratory Association || Appendix A Micro ||  || We agreed that this appendix was not valid and should be removed. We have meeting minutes information and email strings that captured the final decision made on the conference call. This would be the conference call that was scheduled the week of August. This is the document that was on display on the webex and forward
 * Ken McCaslin || American Clinical Laboratory Association || Chapter 2 section 1.14.3 ||  || CWE data type for CWE.2 and CWE.3 has language from ELR and not from the LRI Grid. This should reflect decisions made by the LRI IG WG. || v0.5 ||   ||
 * Ken McCaslin || American Clinical Laboratory Association || Chapter 2
 * Ken McCaslin || American Clinical Laboratory Association || Table 3-1 Data Type usage in Chapter 3 Section 1.14 ||  || This table should be removed. It does not add value and was not a decision process that was driven by the LRI IG WG. || v0.5 ||   ||
 * Ken McCaslin || American Clinical Laboratory Association || Chapter 5 Section 1.22 ||  || There was no discussion in the LRI IG WG regarding batching. It was assumed that the process would be real time and there for there was no discussion that included the batch segments. This should be removed to be consistent with the work done by the LRI IG WG || v0.5 ||   ||
 * Freida Hall || Quest Diagnostics || 1.7.1 || 10-207 || Correct typo in footnote (h:7 to hl7) ||  ||   ||
 * Freida Hall || Quest Diagnostics || n/a || n/a || Update properties to current title/author
 * Freida Hall || Quest Diagnostics || Table 1.3 || 12-207 || Usage table – cross reference error message ||  ||   ||
 * Freida Hall || Quest Diagnostics || 1.8.2 ||  || Typo in paragraph beginning “ ** MAY ** or the adjective "**OPTIONAL”,** second sentence –change **“**suppie” to “suppier” ||   ||   ||
 * Freida Hall || Quest
 * Freida Hall || Quest Diagnostics || 1.14.2 || 21-207 || CNN.7 – Add C.LEN ||  ||   ||
 * Freida Hall || Quest Diagnostics || 1.14.3 || 22-207 || Change comment (reference in parenthesis)
 * Freida Hall || Quest Diagnostics || 1.14.3 || 22-207 || Resolve duplicate statement of Condition predicate statement in same row.
 * Freida Hall || Quest Diagnostics || 1.14.5and
 * Freida Hall || Quest Diagnostics || 1.14.5 and 1.14.6
 * Freida Hall || Quest Diagnostics || 1.14.7 || 31-207 || First component should be RE not R per the LRI IG spreadsheet ||  ||   ||
 * Freida Hall || Quest Diagnostics || 7 || 132-207 || Add footnote to //HL7 0396//;some of the values in this IG did not have a coding system in V2.5.1, but do in the version maintained online:
 * Freida Hall || Quest Diagnostics || 1.14.10 ED || 32-207 || .2 component- Type of Data
 * Freida Hall || Quest Diagnostics || 1.14.10 ED || 32-207 || .3 component Data Subtype note is unclear; HL70291 existed in V2.5.1. If you are stating this IG calls for values in V2.7, has the Vocabulary WG concurred?
 * Freida Hall || Quest Diagnostics || 1.14.11 EI-GU || 33-207 || .4 Universal ID Type LEN should be 3..3 because the literal “ISO” is used in the GU profile ||  ||   ||
 * Freida Hall || Quest Diagnostics || 1.14.12 EI-NG || 34-207 || Component .4 – Universal ID Type – remove note stating contrained to ISO in the NG profile ||  ||   ||
 * Cindy Johns || LabCorp || Acknowledgements and Copyrights || Page iv || Correct name for LOINC is "Logical Observation Identifiers Names and Codes" || v0.5 ||  ||
 * Cindy Johns || LabCorp || 1.3 Scope || 3-207 || Revise first sentence....."sending of lab results from an ambulatory lab __a laboratory__ to an ambulatory __care__ provider." I don’t think most labs are designated as “ambulatory” vs. something else. || v0.5 ||  ||
 * Cindy Johns || LabCorp || Footnote || N/A || Change date to September 2011 (instead of August 2011) || v0.5 ||  ||
 * Cindy Johns || LabCorp || Table of Contents || Page vi-ix || Sub-number sequencing is incorrect for Sections 2-8 (this goes along with the comment Ken made above as the sub-number sequence throughout the document is also incorrect) || v0.5 ||  ||
 * Cindy Johns || LabCorp || Use Case and Context Diagrams || 4-207 || Correct typo in first sentence…..” Laboratory is any facility that __provides__…….” || v0.5 ||  ||
 * Cindy Johns || LabCorp || 1.4.3 Pre-Conditions || 6-207 || Change wording in second bullet to....”(which is based on __established__ criteria set by the medical review board …..)”. The criteria may be set up by clinical experts in the lab or by ordering providers or agreement by both. I don’t believe we need to specify who establishes the criteria. || v0.5 ||  ||
 * Cindy Johns || LabCorp || 1.5.3 Field Length and Truncation || 9-207 || Correct spelling of “requirements”, last word in the paragraph. || v0.5 ||  ||
 * Cindy Johns || LabCorp || 1.6 Conformance to this Guide || 9-207 || Correct wording of sentence in first paragraph …..”  shall not conflict with __any__ either of the three profiles already listed….” || v0.5 ||  ||
 * Cindy Johns || LabCorp || 1.9 Vocabulary Distribution || 16-207 || The Vocab WG did not determine that the IG should recommend or explain the purpose of the PHIN VADS vocabulary so we should remove the second paragraph. However, we did discuss having it as a reference so could include the link  [|http://phinvads.cdc.gov] at the end of the first paragraph. || v0.5 ||  ||
 * Cindy Johns || LabCorp || 1.11 LOINC || 16-207 || Correct LOINC name to “Logical Observation Identifier__s__ Name__s__ and Code__s__”. Also, LOINC should have the trademark symbol after it. || v0.5 ||  ||
 * Cindy Johns || LabCorp || 1.12 SNOMED CT || 16/17-207 || I would remove everything in this section starting with “The following text is cited from the [|National Library of Medicine] web page on SNOMED”, unless it is the intent of the IG to educate people on the background of the vocabularies. My thought is that the links are provided in the beginning, which should be enough to guide users to the right places for more details. If it is determined that the SNOMED information should be kept in the guide, then we should expand the LOINC and UCUM sections to provide the same type of background info (but it’s probably not necessary to do that). || v0.5 ||  ||
 * Cindy Johns || LabCorp || 1.20.2 Diagram of ORU^R01^ORU_R01 ||  || Correct grammar in third sentence. “The data found in these segments __is__ are key……” || v0.5 ||   ||
 * Cindy Johns || LabCorp || 1.32 OBR, Table 6-10, Seq 4, 50 || 108/114-207 || We should remove any reference to using LOINC codes as universal order codes. Many concerns have been expressed by the laboratory community to NLM regarding this issue, which have not been resolved. This was also __not__ addressed by the Vocab WG so should not be included as a recommendation in the IG. || v0.5 ||  ||
 * Cindy Johns || LabCorp || Multiple || Multiple || I agree with Riki’s comments in that value sets should not be recommended for Optional elements. These should be subject to negotiation between trading partners. We should only reference vocabularies that have been reviewed and recommended by the Vocab or IG workgroups. || v0.5 ||  ||
 * Cindy Johns || LabCorp || 1.33 TQI, Seq 2, 5, 6, 13 || 113/114-207 || The Vocab WG did not review UCUM vocabulary for use in these fields and we should verify if it’s the appropriate vocabulary for these data elements. Also, these are optional fields and as indicated above, we should not recommend value sets that have not been reviewed. || v0.5 ||  ||
 * Cindy Johns || LabCorp || 1.34 OBX, Seq 3 || 117-207 || Need to modify this sentence…” LOINC is used as the coding system for this field except where the test being reported has no equivalent LOINC code. In this case, use of local codes is allowed. This should only occur for new tests that have yet been coded by LOINC.” Someone can correct me if I’m wrong, but I don’t believe the Vocab WG intended for LOINC to replace the local codes, only to be sent __in addition to__ the local codes. Due to inconsistencies in the LOINC database, it would be difficult in many instances to cleanly associate a LOINC code with the specific order code if the local codes are not provided in the transmission.
 * Cindy Johns || LabCorp || 1.34 OBX, Seq 4 || 117-207 || Correct typos in “multiple” and “identification” || v0.5 ||  ||
 * Cindy Johns || LabCorp || 1.34 OBX, Seq 6 || 118-207 || We need to modify the statement regarding UCUM to remove using “shall” as it is not a given yet. A recommendation has not been made pending the outcome of pilot testing.
 * Cindy Johns || LabCorp || Table 6-13 Observation Identifiers, Column OBX.6 Units || 122/123-207 || We should remove the statement “UCUM Units required” as that has not yet been determined. || v0.5 ||  ||
 * Cindy Johns || LabCorp || 1.41 Vocabulary Constraints || Multiple || There are several references to HITSP C-80 and PHIN VADS vocabularies. The Vocab WG included references from PHIN VADS for a few of the Vocab Owned HL7 tables, but we did not review any others. Did anyone from LRI review the other vocabulary value sets prior to including them in our IG? If not, it would be better for these references to be replaced with the HL7 v2.x which is the base standard we are using. || v0.5 ||  ||
 * Cindy Johns || LabCorp || 1.41 Vocabulary Constraints, Laboratory Order Value Set || 144-207 || <span style="font-family: 'Calibri','sans-serif'; font-size: 15px;">The Vocab WG did not recommend using LOINC as the value set for Laboratory Order Codes. We should remove any reference to the HITSP C-80 guide and the Description verbiage. || v0.5 ||  ||
 * Cindy Johns || LabCorp || Table 8-1 Mandatory Table Requirements, OBX-3 || 182-207 || <span style="font-family: 'Calibri','sans-serif'; font-size: 15px;">We should not be referring to HITSP Interoperability Specification as the standard to follow for LOINC. We should only be using HL7 v2.x as our base standard. || v0.5 ||  ||
 * Cindy Johns || LabCorp || Table 8-1 Mandatory Table Requirements, SPM 21, SPM-22 || 183-207 || <span style="font-family: 'Calibri','sans-serif'; font-size: 15px;">Agree with Riki’s comments. Vocab WG did not review SNOMED for use in these fields so no recommendation was made. Unless the IG workgroup reviewed it, suggest removing this recommendation. || v0.5 ||  ||
 * Donna Carter || LabCorp || Chapter 1: Intoduction || 4-207 || Shouldn't we also reference that connectivity protocol is out of scope? Or if in scope, clearly indicate what is needed. ||  ||   ||
 * Donna Carter || LabCorp || Chapter 1: Intoduction (Out of Scope) || 4-207 || This comment is too ambiguous. Would prefer that out of scope may state something like "Results not adhering to this HL7 Version 2.5.1 Implementation Guide: Laboratory Results Interface to US Realm, Release 1". ||  ||   ||
 * Donna Carter || LabCorp || Chapter 1: Intoduction (Figure 1-2. Context Diagram) || 5-207 || The diagram for the Context Diagram does not visually represent the order input and does not match the User Story. There is no Lab Results Interface for an order, nor should there be an assumption that this is processed via an interface as orders can be both manual or electronic for this use case. ||  ||   ||
 * Donna Carter || LabCorp || 1.8.1 Message Element Atrributes || 12-207 || Under Usage, See Section ….has Error notation and needs to be resolved. ||  ||   ||
 * Donna Carter || LabCorp || 3.0 Message Profile || 19-207 || The Usage code of 'U' is utilized on this table, but the definition of 'U' is not identified in the Sending Application Conformance and Receiving Application Conformance tables. ||  ||   ||
 * Donna Carter || LabCorp || General ||  || There was not enough time allotted to do a comprehensive review of this guide and provide updates and comments. This will likely lead to more negative ballots and public comments. ||   ||   ||
 * Donna Carter || LabCorp || General ||  || Although important to refer to the other Implementation Guides as predecessors to this IG, the actual components should support this as a new IG based on the HL7 base standard. ||   ||   ||
 * Ken McCaslin || Quest Diagnostics || Appendix a-c ||  || These should be removed. These were never discussed by the work group. ||   ||   ||
 * Freida Hall || Quest Diagnostics || Various segment tables ||  || The IG used as basis for the LRI IG had preadopted CWE datatypes throught the segment tables. LRI IG made a case by case decision re: preadoption of datatypes. For optional elements not in the LRI IG spreadsheet, wasn't the decision to revert to base V2.5.1? For example, PID-15, 16, 17, 22, 26, 27, 28, 35, 36, 38 represented as CWE in the LRI IG should be reverted back to CE? ||   ||   ||


 * Reviewer's Name:** Ken McCaslin **Organization:** American Clinical Laboratory Association **Suggested Change:** See table below.
 * Appendix A replacement ||  ||   || Needed? || Needed? ||
 * Linkage || Child || Parent || NG || GU ||
 * Observation Identifier || OBR-26.1 || OBX-3.1 || Y || Y ||
 * Observation sub Identifier || OBR-26.2 || OBX-4 || Y || Y ||
 * Placer Order Number || OBR-29.1.1 || OBR-2.1 || Y || Y ||
 * Filler Order Number || OBR-29.2.1 || OBR-3.1 || Y || Y ||
 * Universal Service Identifier || OBR-50.1 || OBR-4.1 || Y || N ||

include component="page" wikiName="siframework" page="space.template.inc_contentleft_end"