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).

AGENDA

• Standing Topics 
  • Special Topics
  • Workflow updates
• LIVD IG
• Other?

Meeting Minutes

• eSignature Update:
  • Background:
    • The following CMS rule has been released: Title: Adoption of Standards for Health Care Attachments Transactions and Electronic Signatures, and Modification to Referral Certification and Authorization Transaction Standard; Scheduled Pub. Date: 12/21/2022; Permalink: https://www.federalregister.gov/d/2022-27437.   
    • it does include commerce law language allowing a symbol as substitute as described to us by John Moehrke
    • ACLA had a call with ONC representative to remind them that we still have to resolve this – it will affect ALL existing interfaces in the orders and the results
    • Hans to give PAC a heads up that OO will provide feedback on this
    • Comments Due March 21, 2023 (when are comments due to PAC?) 
    • [2023-02-03 Discussion] 
      • Scope is vague for lab orders - and need to continue discussion next two calls (time permitting)
      • General definition - currently v2 should work and no changes need to be made. 
    • [2023-02-10 Discussion]
      
      • PAC knows something is coming
      • Goal is to comment on attachment rule to get CMS engaged in convo about electronically orders for lab around signature
        • General definition of what a signature requirement is (starting on page 78449, section C) – but on page 78450 mentions electronic signature is vague
          • Focus on how the process is defined and describe the flow as it currently happens in
          • Lab orders produce attachments exchanges, so then are covered here
            • Attachments is wider than just document – it includes – if that includes request for claim to be paid – that would include orders to substantiate the claim
            • Reference to CLIA is helpful
          • Also include CLIA definition of electronic signature
          • You are implying that lab orders have signatures based on statement from 2011 supposes that existing v2 is working
          • Claims not being paid for missing signature for the last 2 years needs to get reversed
          • For a claim o be submitted can send attachment with submission or later – then have rules on what needs to be in the attachment
          • If an order is required in the attachments – how do we recognize the authorized electronically signed order – attachments include the clinical data
  • Proposed response: OO - CMS Health Care Attachments Response - Draft
    • This is based on Frieda’s reference document (which is broader than just the HL7 perspective that we are focusing on)
    • Includes references to signature requirements for attachments, but we want to ensure CMS understands that that is NOT needed for the current way electronic orders are placed
  • Discussion today:
    • ALL TO REVIEW
      • Feel free to fix typos and grammar
      • Use in-line comments for suggested changes in content
    • Feel free to reach out to Christopher, if you have more feedback / questions about Freida’s document, he is distilling 38 pages of research into Quest comments:
    • ACLA has similar comments, they will continue to provide member feedback
    • Will discuss in more detail next week and decide on what to send to PAC for feedback by <Add due date!>

• New Rule on Race/Ethnicity from OMB - Have 75 days from 1/27/2023, so due date is April 19, 2023  
  • Background:
    • Federal Register :: Initial Proposals For Updating OMB's Race and Ethnicity Statistical Standards  https://www.federalregister.gov/documents/2023/01/27/2023-01635/initial-proposals-for-updating-ombs-race-and-ethnicity-statistical-standards  
    • <from prior call chat> Hans mentioned “trickle down” - the reason we had race and ethnicity terms added in HL7 started with V2 is because CDC requested Patient Administration (Chpt. 3) to add (HL7 V2.4 I think) because CDC had to conform to federal requirements.  The same terms used for Census Bureau data ‘trickled over’ to other federal agencies.  If this new request for comment proceeds to a new proposed then final rule, it would probably “trickle down” eventually impacting CDC, ONC, CDC (thus eventually healthcare standards) etc.  See 1997 link and you will recognize correlation to HL7 V2 of race and ethnicity.  Revisions to the Standards for the Classification of Federal Data on Race and Ethnicity | The White House (archives.gov) https://obamawhitehouse.archives.gov/omb/fedreg_1997standards
  • NOT Discussed this week
• CPT-PLA
  • NOT Discussed this week
• Update from FHIR Lab Workflow call
• LIVD IG
  • Ed’s spreadsheet <ADD LINK / PROVIDE UPDATED VERSION>
    • Ed cleaned up the other tabs: Composition, DeviceDefinition, ObservationDefinition
    • TestCodeConceptMap v2
      • Rethinking use of codeSystem resource to reference in targetURI to maybe using a valueSet instead?
      • valueSet does not support use all of the attributes we want to include, so that it is self-contained
      • We picked codeSystem, because we can have the full definitions of all the codes
      • We are now using fragment – but the definition is that it is published by the codeSystem owner – maybe we can update that definition to be more flexible – this would need to be brought to Terminology Infrastructure WG (aka Vocab)
      • All codes in this value set use the same code system, so the code system identification MUST be the same and MUST be LOINC
      • The targetURI should be referring to the valueset of LOINCs we are using in this catalog, rather than the LOINC webpage
      • We would need to add a tab for the LOINC valueSet/fragment and an extension on the conceptMap to identify the fragment rather than using the fragment URI in code system
      • In the current build we have targetCanonical that reference ValueSet
      • So we need to add tabs to the spreadsheet for LOINCValueSet and SNOMED CTValueSet (And we may want to split this into specimen and result for future proofing)
      • In the ValueSet profile we would need to include the extension to the codeSystemFragment ValueSet.compose.system.ext.fragment – referencing the CodeSystemFragment.id
      • And then ValueSet.concept will have all the concepts in the respective fragment version
    • The tabs for Code system fragments will be ready
  • Motion to submit a NIB for May 2023 ballot – Riki Merrick, Ed Heierman, further discussion, against: 0, abstain: 0, in favor: 15
    • Hans will submit V2 FHIR and LIVD; Marti will submit UDI
  • Will pick LIVD back up 3/10
  • In general Ed is taking Fridays off in April – maybe we can flip with specimen on Mondays 2 PM?

Call adjourned 1:56 PM ET - BELOW NOT DISCUSSED

JIRA Triage

R5 Ballot JIRA - None on the agenda (unless someone identifies a critical item)

• JIRA on Task 
  1. FHIR-39324 - Add example value set for Task.businessStatus for Lab TRIAGED
     1. Example codes (we'll continue in the next call)
        1. Specimen collected ← Not clear whether we need this - it's in specimen
        2. IG prepped ← TBD
• https://jira.hl7.org/browse/FHIR-32154 - Definition for preliminary
  • Please review the comment
  • Decided that we would not add partial at this time.
  • We will update the definition of Observation.status to mirror that of DiagnosticReport. 
    

FROM CHAT

• Andrea Pitkus, PhD, MLS(ASCP)CM 1:36 PM
  • not to disrupt the conversation but more background....  A number of folks think implementation of codesystems across health care is the same and thus how things are designed.  For physicians, determining diagnoses, having a stream of terms/codes they decide to use on a per patient implementation fits their use case, but that does not work for lab tests/LOINC.
• Riki Merrick 1:36 PM
  • https://build.fhir.org/ig/HL7/livd/branches/master/StructureDefinition-conceptmap-testcode-uv-livd.html
• Andrea Pitkus, PhD, MLS(ASCP)CM 1:36 PM
  • Will be curious where this ends up with current FHIR solutions or if a different approach is needed to solve this.
  • Regarding value sets, folks may recall, MU1-3 listed (all of ) LOINC as the value set instead of specific codes (as they would vary by implementation).
• Andrea Pitkus, PhD, MLS(ASCP)CM 1:45 PM
  • Will this approach work for pre-release LOINCs too (as we discussed with COVID)?
• Riki Merrick 1:46 PM
  • yes - that is part of the LOINC version ID
• Andrea Pitkus, PhD, MLS(ASCP)CM 1:47 PM
  • thanks.  just checking ;)
  • Sounds like any codesystem would require a ID/URL so   if one didn't have that, would it cause issues?
• Rob Hausam 1:53 PM
  • Not sure what you mean exactly by ID/URL, Andrea?  The url is the canonical reference, so you should be able to rely on it (plus potentially version) for the specific identification.
• Andrea Pitkus, PhD, MLS(ASCP)CM 1:54 PM
  • OID/URL for the codesystem you were describing
  • My question is what if one isn't available?
  • Are you proposing to move LIVD/lab completely?
• Rob Hausam 1:56 PM
  • Hmm.  We should discuss further.