OO CReDOS-006 OM3 and OM4 Usage in M08 message

Return to OO Change Requests page.

Submitted by: Eric Haas	Revision date: Jan 23 2014
Submitted date: Jan 23 2014	Change request ID: OO CReDOS-006
Standard/IG: Implementation Guide	Artifact ID, Name: OM3 and OM4 Usage in M08 message

Issue

OM3 and OM4 Usage in M08 message are treated differently. OM2 is O in base whereas OM3 is not. They are both give additional information about results- one is for numeric and one is for non-numeric results - so why are the usages different.

Recommendation

Make both "RE" (preferred) in base or make both "O" in base and "RE" in info component profile.

Rationale

Treat these segments that are functionally similar the same.

Discussion

2014-03-18 eDOS WG call notes: Why is OM-3 being treated differently from OM2 – both convey the same type of information, one for numeric tests and one for coded results – can they be treated the same. Review the guide section 5.5.7 and 5.5.8 for more information on the use of OM2 and OM3. This really relates to OM2 and OM3 – not OM4 – OM2 is for numeric results, while OM3 is for categorical results – why do we treat the categorical differently from numeric results? Purpose is the same – make either both O or RE. For categorical may need to have the understanding of what the codes mean and how many results you can expect – slightly different from dealing with numerical results.

1. 112: was related to RFR data type that was the start to creating the optional INFO profile
2. 109: was withdrawn

File on wiki may have the answer to the question. Eric will do research on where the change to making OM2 Optional comes from – supporting documents in ballot are on the S&I wiki – Vendor didn’t want to receive the OM2 nor OM3

Megan thinks the segments should both be RE, because you need only one of these (OM2, OM3 and OM4) will be sent after each OM1, depending on the type of test. In base standard OM3 seems to be allowed to be used for narrative results as well – this is more constrained in the actual field descriptions – interesting why we are not using the valid coded answers (OM3-3) – for strep screen valid coded answers are positive and negative

Reference range was informational – the actual reference range to use was what is sent for the results for interpretations

Post call: Eric to research ballot reconciliation re: why OM2 segment attached to Info profile. See uploaded file print screen of ballot reconciliation uploaded post call. See

3/25/2014: The change was requested by EPIC – do we need to reach out to Craig to get his input on this discussion – on why he wanted to have these both segments be treated differently? Aren’t units part of the deciding factor on what test to order in some cases? Will find a time that Craig can be on the call to discuss.

4/1/2014: Freida talked to the HL7 US taskforce for guidance on how to handle this kind of issue, where a new decision may reverse a ballot comment, when DSTU comments are being reviewed – most WGs are treating these as ballot comments – Frieda did invite Craig to a call in April for completion of the issue – Eric out this week, too, so skip this item this week.

4/8/2014: Information in OM3 and OM2 segments is supposed to help the doctor decide which lab test to order. Craig’s issue is that transaction IGs impact EHR-functionality. Labs believe this information is needed in the EHR system – how the systems uses it is not defined – currently there are various ways doctors can access this information. How would this be tested - juror document requirement – the data is part of the test data. Craig suggested making OM3 segment RE for the INFO profile, same as OM2 segment. Can we have the doc order the test, without information in OM3 Segment? Yes they can. However, information in the OM3 segment may be needed to help you set up your system, because it does list the codes to expect for these (CATEGORICAL SERVICE/TEST/OBSERVATION) Will have to have both Eric and Craig on – plan for 4/22 or 4/29 – checking with Eric Craig drops off at 2:22PM ET

4/22/2014: Unfortunately Eric is not on – his main issue was that they should be treated the same way; originally OM2 and OM3 were conditional to have one or the other. Kathy states she ALWAYS supported RE for both – she relented to move OM2 into INFO profile, because she felt may be setting up numeric results was easier than coded results. Craig likes having a separate INFO profile for OM3 also. Information on coded results may be needed to help set up your results properly. If receiving system takes in the data sent in OM2 or OM3 because the lab sends it, they could NOT reject the message as an error, but might not do anything with the data in OM2 or OM3 Functional requirements for EHR-S need to be set up first, before we make these RE in the message, because we don’t have clear guidance on what to do with the data, when it comes in. That discussion should happen first (and if we have the INFO profile it can be declared required for certification). Bob asked: Is information in these segments necessary and if missing keeps docs from ordering the test? Or is it just helpful? Straw vote: Motion to make them both (OM2 and OM3 segments) “varies”, with “RE for INFO profile” and “O in all other profiles” – i.e. leave OM2 as is and make OM3 “varies” Bob Yencha, Craig Newman Abstain: 3, against: 2, in favor: 3 Craig states Epic is flexible enough – we take what the labs send in – do not compare this to what we are expecting; are labs expecting that receiver should validate – a lot of EHR-Systems cannot just take in what we are sending, if they don’t know what to expect. Are you expecting that EHR-systems can take an eDOS update and automatically update the build? Not sure this is a defined requirement. Store and manual intervention – not something easily done, even in LIS and EHR-systems. In the long run this is supposed to help automate the directory updates from manual / semi manual etc. In some implementations there are rule engines involved to list the reflex triggers, what tubes to draw, what can be combined into a single tube etc.

The HL7 project scope statement for the functional lab profile was expanded on last OO call to include eDOS – but a separate functional requirement is not currently planned

Motion to table until both Eric Haas and Craig Newman are on the call by Mark, second by Bob Yencha, no further discussion; Abstain: 0, against: 0, in favor: 8 – hopefully Eric will be available for next call 4/29; Craig will be back on 4/29 call.

4/29/2014: Change Request 006 - OM2 and OM3 being valued the same Last week discussed making both OM2 and OM3 be profile based. Eric stated they serve the same purpose so should be treated the same. As far as whether it’s part of a main profile or called out in an optional profile; it’s nice to have if clinician but from a certification standpoint, doesn’t matter. Felt either way, they should be treated the same. Kathy indicated that it’s not just a nice to have, but some vendors need this information to properly set up their system to receive and file results correctly. She state she was reluctant to have OM2 changed from RE to Varies in the first place, but relented since OM3 would remain as RE. LabCorp uses these fields for all EHR vendors except one. Craig stated he understands some systems may need to have it required it but not all, and RE would require all systems to have it. If we used an optional profile, then if EHR system doesn’t require it, they are not forced into using it. He prefers that we make it an Optional profile with required elements. Concerned about having a receiving system figure out what to do with the information, i.e. does it need to be stored somewhere? Until we know what the requirements are for what the receiving system needs to do with it, he is reluctant to make it mandatory. Eric stated that testing may only be for ability to receive the information; no specific requirements for store, display, etc. Craig said that his system doesn’t require it, but not sure what other systems need. He suggested that maybe we should make it different for sender and receiver? Each system has to receive what is in the OBX regardless, so what value is it to have it in eDOS since the variations are accounted for when results are sent. Kathy again stated that many EHR vendors cannot set it up correctly unless they get the information in the eDOS, but agreed that systems should be able to receive it without throwing an error if they don’t. Craig thinks is should be EHR vendor’s decision as to whether they need it or not. A motion was made by Kathy Walsh to make OM2 RE. Second by Eric Haas. Against: 2 Abstain: 1 In favor: 5

Resolution

2014-04-29 A motion was made by Kathy Walsh to make OM2 RE. Second by Eric Haas. Against: 2 Abstain: 1 In favor: 5