ANSI Anti-Trust Policy:  Professional Associations, such as HL7, which bring together competing entities are subject to strict scrutiny under applicable antitrust laws. HL7 recognizes that the antitrust laws were enacted to promote fairness in competition and, as such, supports laws against monopoly and restraints of trade and their enforcement. Each individual participating in HL7 meetings and conferences, regardless of venue, is responsible for knowing the contents of and adhering to the HL7 Antitrust Policy as stated in §05.01 of the Governance and Operations Manual (GOM).

Follow up on ISA Comments voted on during the WGM

• The comment was voted on by OO on the WGM quarter, was forwarded to PAC and it will be submitted as part of that package
• Individual suggestions can be made by anyone
• see link in chat for more details

LOI/LRI ACK Choreography Question

It seems like the structure of when to send back an AA response with I and or W's?, and AE with E's (or maybe W's) isn't as clearly defined as it is with immunizations.  So I'm trying to find a general rule of thumb that applies to these,

If an error warning severity, is I or W, do we send back an AA response? or do Ws belong with AE's in a nut shell!

MSH|^~\&|MT^1.3.6.1.4.1.24310^ISO|IA.DOH.IDSS^2.16.840.1.114222.4.3.3.19^ISO|BMC^16D0383666^CLIA||20220902092354.0000-0500||ACK^R01^ACK|1c1b750a-c8ca-4602-8c2d-e56199872fef|P|2.5.1|||||USA

MSA|AA|1c1b750a-c8ca-4602-8c2d-e56199872fef

ERR|||101^required field missing|W|||Field lastName is required.

As far as I recall, the original ELR standard didn’t have much to say on when the MSA-1 values should be used. The MSA-1 value set for the harmonized LOI/ELR updated IG which does provide some guidance on when to use each code.

But I think there is a larger (and much messier) question here about original versus enhanced mode acknowledgments. Looking at both the original and harmonized IGs, I think support for at least MSH-15 is required. This means that the exchange is locked into enhanced mode acknowledgments. Technically (anyone correct me if I get this wrong), this essentially means that MSH-15 is AL (perhaps not technically a requirement in the original ELR) and MSH-16 is NE (I don’t know of any system that responds to an ORU message with an application level ACK). Assuming that the ORU you are getting has MSH-15 and/or -16 populated, what you are probably responding with is the accept ACK and not the application ACK which means the relevant codes are CA, CR and CE (not AA, AR and AE). Note that this is little bit different than the immunization space where (despite using MSH-15 and -16) the expectation is that the IIS will return the equivalent of an application level ACK.

Now if you look at Chapter 2 of the v2.5.1 base standard it says:

This tells you what validation should be performed upon accepting a message and how to populate MSA-1. It’s fairly limited in it’s scope although I think that condition (c) might be interpreted pretty broadly to allow syntactic correctness checks (such as a missing required field).

All of this to say, that CE is probably the right code to use when there is an error that isn’t related to the contents of specific MSH fields.

Now, having said all that, in the real world, I don’t know what your trading partners are going to expect. Or if the ACK you construct will ever actually get back to the sending application unless it’s a direct connections with no intermediaries (including interface engines) in between. The diagram below is from the harmonized LRI IG which clearly shows the distinction between accept and application level ACKs. If I had to guess, there will only be accept ACKs used and the ACK you construction will only ever go back one “hop” to indicate acceptance of the message.

• Discussion today:
  • AE seems applicable – should be from the receiving system = application level
  • If AA is sent there should be NO ERR segments, because if AA is sent, receiver may not ever look for ERR segments
  • Sidebar about the example: An error for a required field should really be a reject
  • A receving system would:
    • parse message and create ERR for each found item
    • each has its own level of severity
    • The highest level of severity sets the MSA-1 code
  • What to do with the ‘I’ level severities?
  • Labcorp does not send ERR for AA or CA
  • Take a look at Immunizations IG
  • Could also take to INM to ensure we have this more consistent across the board Ulrike Merrick 
  • Daniel Rutz  and Hans Buitendijk  will check what their systems are doing when severity level is I
• Will follow up with InM and report back in 2 weeks.

DiagnosticReport.status

• See MM from Sept. WGM: 2023-09-11-15 WGM#2023091115WGM-StatuscodesinobservationanddiagnosticReport
• Not yet Normative content
• Recommended to update value set - elevating "corrected" to level 1; need to revise the definitions for "amended" and "corrected" to make the use of these clear.
• add appended to this code system / value set
• Spawned from FHIR-33042 - Getting issue details... STATUS

Observation.status

• Substantive changes to Normative – requires community consensus
• For observationStatus we will need to change definitions so that amended and corrected are mutually exclusive
  • In V2 we are sending NTEs after the amended OBX, so in FHIR we would do that in observation.note, so the observation resource is changed, without the observation.value being changed
  • Corrected relates to changes in observation.value and observation.interpretation
  • Amended (in the lab space) relates to any other changes in observation
  • If folks want to have these explicitly identified we can either
    • Update the definition of amended
    • add a sibling code to corrected
  • Lab status may not work with current value set hierarchy
  • Maybe we need to create a labObservation?
• We would have to reach out to ALL the folks using observations – in all domains
  • Action item – :
    • For CAP accreditation define what we need to have
      • at report level
      • at observation level

Action item: 

• Need to write up for Lab specific use = For CAP accreditation define what we need to have
  • at report level
  • at observation level
  • Andrea Pitkus  / Kathy Walsh  / Robert Hausam to draft and brign something back -  Ulrike Merrick to reach out to CLIA folks at CDC and CAP

Adjourned 2:02 PM ET

Chat History:

Hans Buitendijk  to  Everyone 1:11 PM

On CPT-PLA, the text submitted is in italic on this page: OO Lab and CPT PLA where we provided an either/or first indicating to update the current page, or alternatively add another.

Marti Velezis to Everyone (Sep 29, 2023, 1:38 PM)
https://confluence.hl7.org/pages/viewpage.action?pageId=171450118#id-2023091115WGM-StatuscodesinobservationanddiagnosticReport
 
Riki Merrick to Everyone (Sep 29, 2023, 1:39 PM)
FHIR-33042
 
Marti Velezis to Everyone (Sep 29, 2023, 1:39 PM)
https://jira.hl7.org/browse/FHIR-33042
 
Andrea Pitkus to Everyone (Sep 29, 2023, 1:55 PM)
Amended/amendment - Any change in a previously issued anatomic pathology or cytopathology report
intended to correct an inaccuracy, including changes in the diagnosis, narrative text, clinical history, pre- and
post-operative diagnoses, patient identification, or other content.
from CAP general checklist
and Corrected/correction - A change in a previously issued clinical pathology test report intended to correct an
inaccuracy, including changes in test results, patient identification, reference intervals, interpretation, or other
content.
CAP is the largest accreditor of labs.
Note CAP indicates amendment is used in AP/cytopathy, but not clinical lab/clinical pathology

These definitions should be in notes from a few weeks ago when discussed too

V2 Lab JIRAs (link)

The following JIRA Tickets need to be reviewed by the Lab members as carry over from May 2023 WGM:

• V2-25376 - As soon as Dan has proposal.

FHIR Lab JIRA (link)

The following JIRA Tickets need to be reviewed by the Lab members as carry over from May 2023 WGM:

• FHIR-32406
• FHIR-32405
• FHIR-33041
• FHIR-34205
• FHIR- 32154 - Pending outcome of DiagnosticReport/Observation/Panel discussions

--------Backlog of Topics---------

• DiagnosticReport.status
  
  • Zulip chat: https://chat.fhir.org/#narrow/stream/179256-Orders-and-Observation-WG/topic/DiagnosticReport.20statuses.20and.20CLIA.20requirements.3F

  • Status in FHIR: http://hl7.org/implement/standards/fhir/codesystem-diagnostic-report-status.html

  • v2-FHIR Mapping Spreadsheet: HL7 Concept Map: ResultStatus[Non-Queries] - Google Sheets
  • 8/4 - Summarized the discussion from OO Main call and ran out of time. 
    • See links in Chat below
    • Still need a bit of clarification
    • Reviewed CAP Checklist from 2023
      • Corrected/correction - A change in a previously issued clinical pathology test report intended to correct an
        inaccuracy, including changes in test results, patient identification, reference intervals, interpretation, or other
        content.
•  Micro
  • Craig's v2 micro question: https://confluence.hl7.org/pages/viewpage.action?pageId=161080303#id-20230518Main-Subject:"v2discretemicroquestion"-Listservemessage(fromCraig)
  • The OBX-30 Observation Sub-Type Enhancements - Orders & Observations - Confluence (hl7.org) was created, and as it was created identified that various values were actually deleted, and examples were available for most but not all sub-types.
  • We reviewed the current wording and examples and updated the page with suggested adjustments (in red for text not in the published version and strikethrough where text is suggested to be removed)
  • Craig updated the example (Micro Example) using only the active/new values.
  • Open questions for next week:
    • Any other updates to the definitions/descriptions to clarify?
    • Any examples that would primarily be using MOD?
    • Any examples that could use either use MID or MOD?  We discussed PCR, but that raised questions whether is actually confusing and would require further explanation as for some it would never be used with MID.
    • Andrea had suggested that a more complex example she described would be helpful, but a volunteer to create that has not yet been identified.
    • No update
• Panel/Micro and discoverable Observations in FIHR
  • Hans/Fran to create an initial proposal, focusing on the micro scenario, on how to approach this in FHIR / FHIR US Core.
    • No update

• Other JIRAs from Triage Inventory - Not discussed