This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Electronic laboratory reporting (ELR) - Issues"
Jump to navigation
Jump to search
(Initial load) |
(Index item for HL7 validation tools.) |
||
| (15 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
[[http://wiki.hl7.org/index.php?title=Public_Health_and_Emergency_Response_work_group_%28PHER%29 PHER main page]] | [[http://wiki.hl7.org/index.php?title=Public_Health_and_Emergency_Response_work_group_%28PHER%29 PHER main page]] | ||
| − | == | + | ==Variations in sent message formats and receiving requirements== |
| − | *For lab system vendors and labs: States have a variety of reporting formats they require | + | *For senders (lab system vendors and labs): States have a [[Jurisdiction ELR Specifications|variety of reporting formats they require]]. |
| − | * | + | *For receiving jurisdictions: [[ELR Sender Variations|Labs submit messages in a variety of erroneous or questionable or suboptimal formats]], although they may be syntactically correct. |
==Message structure== | ==Message structure== | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
*Microbiology linkage | *Microbiology linkage | ||
**Most labs don’t do it | **Most labs don’t do it | ||
| Line 21: | Line 13: | ||
**The 2.5.1 IG is not clear enough about certain requirements | **The 2.5.1 IG is not clear enough about certain requirements | ||
*The HL7 manual is not crystal clear about when OBX-5 repetitions are appropriate and when they aren’t | *The HL7 manual is not crystal clear about when OBX-5 repetitions are appropriate and when they aren’t | ||
| + | *Preadoption of field datatypes from later HL7 standards will prevent parsers from working | ||
| + | **In standard HL7 2.5.1, CE is used for OBX-3, OBX-5, and OBR-31; IS is used for OBX-8. CE has 6 subfields, IS has one field (no subfields). The 2.5.1 IG for ELR to PH specifies CWE from 2.6 for all of these fields. CWE from 2.6 has 22 subfields, of which 14 are supported in the IG. | ||
| + | **Preadopting from a higher version does the opposite of constraining, which is what a conformance profile is supposed to do. Instead, it expands the standard beyond what it originally allows. | ||
| + | **Parsers for a particular HL7 version are designed to accept what the original raw HL7 standard specifies, and no more. At least one commonly used one, HAPI, is like this. Since it is open source, the source can be modified to use CWE instead of CE, but that is a fairly involved process. | ||
| + | |||
| + | ==Validators== | ||
| + | Given a set of standards/profiles for messages and/or vocabulary, implementers would like to have those standards embodied in tools that will take a given message and evaluate whether and how well that message conforms to the standard/profile. There are [[HL7 message validation tools|several such tools out there]], most in some stage of development. | ||
| + | |||
| + | ==Proposed improvements to the IG== | ||
| + | *Discussion between Jimmy Dee and Lily Tatham on PhConnect, ELR CoP forum, and further discussion on the CSI (Collaborative Software Initiative, authors of Utah’s TriSano) forum. Discussion is about how confusing the IG is and how hard to find what you want to know. Will track down links. | ||
| + | *Clarify the 2.3.1 message/data model diagram | ||
| + | *What does "required" really mean from a receiver's point of view? From a practical point of view, any receiver can ignore any incoming data they want. | ||
| + | *The Abstract Message Syntax in the IG extends across 6 pages. May be possible to add a compressed version that is still correct but more convenient. Can we get it on a single page? | ||
| + | **Omitting segments and groupings that we can basically agree no one will use for ELR, e.g. TIMING_QTY, TQ1, TQ2, CTD, FTI, etc... | ||
| + | **Omit the Description column, or have a very narrow column that simply indicates whether there is any Description in the full Abstract Message Syntax diagram. | ||
| + | **Omit all but the Lab Sender usage column. | ||
| + | |||
| + | ==Conformance Profile== | ||
| + | *What are the advantages of capturing the ELR standard in a formal HL7 Conformance Profile? | ||
| + | **How to produce? Message Workbench (MWB), other? | ||
| + | **How to use? Who in the ELR community - senders and receivers - has software tools that can consume formal HL7 conformance files and then be useful in checking conformance to the standard during implementation. What software tools are those? | ||
| + | ***The HAPI parser has some [http://hl7api.sourceforge.net/conformance.html conformance capabilities], which I have not worked with. It supposedly can accept a conformance profile (in XML format?) and then parse/validate messages according to that profile. | ||
| + | *What are the risks? | ||
| + | **Effort to produce | ||
| + | **Maintainability | ||
==Terminology== | ==Terminology== | ||
| − | * | + | * different data exchanges may request different terminology including aggregated or rolled-up information; this may lead to different terminology requirements depending upon the receiving system's exchange requirements. How can or should this be handled? |
| + | * many, if not most, of the current terminology practices place the onus for terminology mapping and transformation on the Senders; is this a best practice to be continued or should some of the onus be placed on the Receivers and/or other elements within the data exchange architecture such as RHIOs and/or HIEs? | ||
| + | *Conformance profile terminology, e.g. "Required but may be empty" | ||
==Implementation== | ==Implementation== | ||
| − | |||
*Not all labs have CLIA codes, e.g. Veterans Administration hospital labs. | *Not all labs have CLIA codes, e.g. Veterans Administration hospital labs. | ||
*Clem McDonald comments during WG webinar | *Clem McDonald comments during WG webinar | ||
**“Implementers don’t like to use Structured Numeric.” | **“Implementers don’t like to use Structured Numeric.” | ||
**“No microbiology lab wants to flag abnormals.” | **“No microbiology lab wants to flag abnormals.” | ||
| + | |||
| + | ==Architecture== | ||
| + | *Different senders (labs) have different software systems, modules, and/or packages available, some of these have been provided by vendors and some are "home-grown". What candidate architectures are in use and what are the benefits of each architecture? | ||
==Harmonization== | ==Harmonization== | ||
*How much can we/should we harmonize with IHE profiles? | *How much can we/should we harmonize with IHE profiles? | ||
Latest revision as of 15:17, 17 February 2011
Contents
Variations in sent message formats and receiving requirements
- For senders (lab system vendors and labs): States have a variety of reporting formats they require.
- For receiving jurisdictions: Labs submit messages in a variety of erroneous or questionable or suboptimal formats, although they may be syntactically correct.
Message structure
- Microbiology linkage
- Most labs don’t do it
- Some labs even send the drug sensitivity observations in separate messages/files from the organism results: no linkage is possible
- Of those who do it, none does it completely correctly
- The 2.5.1 IG is not clear enough about certain requirements
- Most labs don’t do it
- The HL7 manual is not crystal clear about when OBX-5 repetitions are appropriate and when they aren’t
- Preadoption of field datatypes from later HL7 standards will prevent parsers from working
- In standard HL7 2.5.1, CE is used for OBX-3, OBX-5, and OBR-31; IS is used for OBX-8. CE has 6 subfields, IS has one field (no subfields). The 2.5.1 IG for ELR to PH specifies CWE from 2.6 for all of these fields. CWE from 2.6 has 22 subfields, of which 14 are supported in the IG.
- Preadopting from a higher version does the opposite of constraining, which is what a conformance profile is supposed to do. Instead, it expands the standard beyond what it originally allows.
- Parsers for a particular HL7 version are designed to accept what the original raw HL7 standard specifies, and no more. At least one commonly used one, HAPI, is like this. Since it is open source, the source can be modified to use CWE instead of CE, but that is a fairly involved process.
Validators
Given a set of standards/profiles for messages and/or vocabulary, implementers would like to have those standards embodied in tools that will take a given message and evaluate whether and how well that message conforms to the standard/profile. There are several such tools out there, most in some stage of development.
Proposed improvements to the IG
- Discussion between Jimmy Dee and Lily Tatham on PhConnect, ELR CoP forum, and further discussion on the CSI (Collaborative Software Initiative, authors of Utah’s TriSano) forum. Discussion is about how confusing the IG is and how hard to find what you want to know. Will track down links.
- Clarify the 2.3.1 message/data model diagram
- What does "required" really mean from a receiver's point of view? From a practical point of view, any receiver can ignore any incoming data they want.
- The Abstract Message Syntax in the IG extends across 6 pages. May be possible to add a compressed version that is still correct but more convenient. Can we get it on a single page?
- Omitting segments and groupings that we can basically agree no one will use for ELR, e.g. TIMING_QTY, TQ1, TQ2, CTD, FTI, etc...
- Omit the Description column, or have a very narrow column that simply indicates whether there is any Description in the full Abstract Message Syntax diagram.
- Omit all but the Lab Sender usage column.
Conformance Profile
- What are the advantages of capturing the ELR standard in a formal HL7 Conformance Profile?
- How to produce? Message Workbench (MWB), other?
- How to use? Who in the ELR community - senders and receivers - has software tools that can consume formal HL7 conformance files and then be useful in checking conformance to the standard during implementation. What software tools are those?
- The HAPI parser has some conformance capabilities, which I have not worked with. It supposedly can accept a conformance profile (in XML format?) and then parse/validate messages according to that profile.
- What are the risks?
- Effort to produce
- Maintainability
Terminology
- different data exchanges may request different terminology including aggregated or rolled-up information; this may lead to different terminology requirements depending upon the receiving system's exchange requirements. How can or should this be handled?
- many, if not most, of the current terminology practices place the onus for terminology mapping and transformation on the Senders; is this a best practice to be continued or should some of the onus be placed on the Receivers and/or other elements within the data exchange architecture such as RHIOs and/or HIEs?
- Conformance profile terminology, e.g. "Required but may be empty"
Implementation
- Not all labs have CLIA codes, e.g. Veterans Administration hospital labs.
- Clem McDonald comments during WG webinar
- “Implementers don’t like to use Structured Numeric.”
- “No microbiology lab wants to flag abnormals.”
Architecture
- Different senders (labs) have different software systems, modules, and/or packages available, some of these have been provided by vendors and some are "home-grown". What candidate architectures are in use and what are the benefits of each architecture?
Harmonization
- How much can we/should we harmonize with IHE profiles?
