2025-06-04 SHIELD Steering Committee Meeting Notes

2025-06-04 SHIELD Steering Committee Meeting Notes

Date

Jun 4, 2025

Attendees

(bolded names indicate attendance)

Stakeholder group

SHIELD organization

Name of SHIELD member

organization designation

Industry Entity

Labgnostic, Inc.

Steve Box

primary

 

 

alternate

Epic

Dan Rutz

primary

 

 

alternate

Biomerieux

Xavier Gansel - regrets

primary

 

 

alternate

Roche

Nick Decker

primary

Roche

Yue Jin - regrets

alternate

Healthcare Provider

Indiana University/Indiana University Health/Association for Molecular Pathology

Mehdi Nassiri, MD

primary

University of Wisconsin-Madison

Andrea Pitkus, PhD, MLS(ASCP)CM, FAMIA

primary

UT Southwestern Medical Center

Hung Luu - late/regrets

primary

UNMC

Scott Campbell

primary

Longtime Lab Professional

Carmen Pugh - late/regrets

primary

Sonic Healthcare

Eric Crugnale - regrets

primary

Former Quest Diagnostics

Collom, Craig D

primary

Patient Advocate

 OPEN

OPEN

individual

Standards Organization

SNOMED International

 

Jim Case

primary

Monica Harry

alternate

Regenstrief Institute

 

Marjorie Rallins

primary

Eza Hafeza - regrets

alternate

HL7

 

Julia Skapik

primary

 

alternate

Professional Organization

Association of Public Health Laboratories

 

Riki Merrick

primary

Christina Gallegos - regrets

alternate

Graphite Health

 

Stan Huff

primary

 

alternate

CAP

 

Raj Dash

primary

 

alternate

AMP

 

Robyn Temple

primary

 

alternate

Governmental - non Voting

CMS

Michael Smalara

primary

Open

alternate

ASTP/ONC

Sara Armson

primary

 

alternate

CDC

Hubert Vesper (/DDNID/NCEH/DLS)

primary

Jasmine Chaitram

alternate

NLM

 John Snyder

primary

 

alternate

FDA

 Keith Campbell

primary

Victoria Derbyshire

alternate

Agenda and Notes

Item

Notes

Item

Notes

Quorum evaluation (two-thirds (2/3) of the Voting Representatives shall be necessary to constitute a quorum for the transaction of business)

Currently we have 17 named members (2 open slots), so 2/3 = 11 is quorum (excluding chair and government members).

# of voting member per charter: 13 - 21

# of non-voting members per charter: 7

 

Open Meeting

12:06 PM ET no quorum

Conferences/Time critical things / FYI

AMIA November 15 - 19 in Atlanta, GA https://amia.org/education-events/amia-2025-annual-symposium/call-participation submitted proposal - no update

ADLM reached out to request a webinar about SHIELD later this year to be scheduled in August or later

New ASTP/ONC director appointed: https://www.healthit.gov/leadership/thomas-keane-md-mba

CLIAC FACA was eliminated in March 2025, several lab professinal orgs (ADLM, APHL, ASCLS) working on letter trying to get this reinstated -

Postcall updates:

Link to SignOn Letter: https://www.aphl.org/policy/Advocacy_Documents/2025 CLIAC sign-on letter.pdf

Request for Information; Health Technology Ecosystem

Due by Jun 16, 2025 - so we would need approval by email (send out on Jun 6, 2025 with responses back by Jun 13, 2025, if we get to consensus on how we want to approach it today

CMS RFI Feedback

Discuss:

Riki looked through the RFI to find questions that explicitly mention USCDI - those were copied over to the confluence page and then coppied the prior USCDI feedback into the 2 slots - outstanding not yet copied is the comment on “Updated Vocabulary”

Consider writing comment on USCDI limitations:

  • current data definition is too vague to be useful, for example creating binding at the level of SNOMED CT leaves too much choice for picking the wrong hierarchy; tighter vocab bindings would be better, which would avoid potential for different interpretations by vendors / standards developers that work in different HL7 products (V2, CDA, FHIR)

  • USCDI data elements should be the “bar” systems attest to, not what they can currently do, so they should have links to actual data models, including choice of datatypes and associated vocabulary, if coded, will help implementers in the long run, because if the “bar” folks attest to in certification is too vague, then it is not supporting interoperability (example during MU1 and MU2 where folks were using ST datatype for lab results and then attesting that they support lab result reporting) as different vendors will implement the same element in a different way

  • For MU public health reporting use case ELR required use of LOINC and SNOMED CT for coded results, so figured USCDI elements “Tests” and “Results/Values” would be already implemented, but found out that labs often have a separate module for PH reporting / only LOINC/SNOMED CT encoded tests that were reportable, so LOINC/SNOMED CT was not available to include in the reports back to the providers

  • Examples:

    • Specimen Type:

      • definition in LIS/LIMS data dictionary traditionally what is submitted in the container to the lab

      • should be drawn from specimen hierarchy, which often pre-coordinates several specimen attributes (could also be drawn from substance/physical object hierarchies, if this is considered only the

    • vs Specimen Source Site

      • definition is where the sample is collected from

      • drawn from body structure hierarchy (but often co-mingled in LIS data dictionaries into specimen type)

    • Problems

      • Clinical findings hierarchy is expected by some, others suggest <Andrea please elaborate here!!!>

    • Result/Values

      • current definition does not take the different possible scales of results into account - systems must support

        • quantitative result values, which require use of units of measure (a different USCDI element) and reference range

        • qualitative result values, that depending on scale could have coded answers, where binding to SNOMED CT is appropriate (for example for organisms and maybe clinical findings for nominal scale, qualifiers for ordinal scale), but even for some nominal scale LOINCs there wouldn’t be SNOMED CT concepts created (example genomic variants / viral lineages) and narrative scale LOINCs only have text (unstructured)

      • Previously proposed text for a better definition is here: https://www.healthit.gov/isp/comment/13833

So should USCDI be binding at terminology level or at valueset level? If too restrictive in the terminology binding, then might not be able to adjust to improvements in the underlying terminology in the future - could define intensionally by exclusion, that way new heirarchies would automatically be included - but regardless it will require more maintenance, but be much more helpful, as the terminology binding should not changed when a different HL7 product is used to exchange it (which is currently the case for several USCDI elements)

Problem with drawing from multiple hierarchies, is that currently many LIS/LIMS don't support more than one hierarchy (and definetly not more than one code system for each data element - example LOINC answercodes vs SNOMED CT)

During HL7 Cross Project WG Calls (where US Core is discussed) noticed how the ambiguity in element definition resulted in different choices by some vendors on what FHIR resource to use to represent Lab order for example (using Procedure instead of ServiceRequest/DiagnosticReport/Observation)

NEXT STEPS:

Riki to draft the additional response to the current limitations of USCDI on the feedback page and also find a place for the vocab update comments, then send email to all SC members with link to these minutes and the feedback page, request to read and add contents / comments to that page and REPLY ALL with those comments by Jun 11, 2025 and provide a vote as REPLY ALL for each comment section by Jun 15, 2025, so that we can submit comment on Jun 16, 2025

Exploration of Health Level Seven Fast Healthcare Interoperability Resources for Use in Study Data Created From Real-World Data Sources for Submission to the Food and Drug Administration; Establishment of a Public Docket; Request for Comments

Due by Jun 23, 2025

Discuss:

  • so we would need approval by email (send out on Jun 13, 2025 with responses back by Jun 20, 2025, if we get to consensus on how we want to approach it via email

  • Looking for someone to read and summarize if this is related to SHIELD and wheter we might have some feedback on - it does mention lab results and talks about RWD, so it might be applicable - goal is to focus on that once we have feedback for CMS/ASTP/ONC RFI completed.

NOT-LM-25-002: Request for Information (RFI): Inviting Comments on the Future of the National Library of Medicine Biomedical and Data Science Extramural Research Programs - NEXT TIME

Due by Jul 14, 2025

Will have to read for relevance to SHIELD before we decide if we want to respond - If anyone has bandwidth, please make a note here:

SHIELD Charter Updates - NEXT TIME

Proposed Charter Updates To Article Three - March 2025 - Review the updated Article Three of the Charter as a whole

Discuss:

 

Note: Changes to the Charter require unanimous approval by the Steering Committee!!

LIDR White Paper- NEXT TIME

Review and Vote?

Discuss:

Standards WG Vocab Follow up - NEXT TIME

LRI Review Summary Document

Please review and provide comments - will take this up in early August 2025

Roadmap section updates in response to ONC comments on the SHIELD roadmap - NEXT TIME

Reviewing Updated Roadmap: https://aphlinformatics.atlassian.net/wiki/download/attachments/3214147628/DRAFT_UpdatedSHIELD_Community Roadmap_20250402.docx?api=v2

Changes are highlighted with markup addressing these ONC comments:

  1. Aligning the roadmap scope to the mission scope

  2. Addressing the concern that all standards need training and education

  • Still need to review this one:

  1. There are several solutions proposed, including repositories and tools, which need to be further evaluated before ONC could fully support the roadmap.  ONC suggests the roadmap be updated to include details around feasibility, scalability and how the proposed changes can be integrated into the current laboratory ecosystem (e.g., regulation and industry).

Identify components that could improve the ecosystem infrastructure, and then highlight the places where these components can be advanced / sustained or made easier to implement. Would SHIELD be willing to consider to provide an example implementation - create the structures and bound terminologies to showcase how each element would be properly represented be working.

For each of the Consideration sections we could certainly add a section on feasibility / requirements (e.g. continued funding for LIDR, better describing the intended use of ANY data element added, overall goal of LIDR, clearly delineate what is commonly used and is minimum, provide best practice and alternatives (non-preferred) - example would be metadata around the value sets in VSAC (curation / usage etc) to be able to ascertain quality) and highlight that other mechanisms are needed to achieve for adoption.

Discuss:

Review Working Groups progress - NEXT TIME

THANK YOU to all the WG Chairs for their effort in moving SHIELD work forward!!!

Setting milestones for deliverables should be NEXT for WGs: they will be captured here: SHIELD WG Deliverables and Milestone Grid

Placeholder to get back to later - NEXT TIME

Next calls

 

All SHIELD Calls

  • June 25th

General Updates: 2024 - WG Chairs please make sure we have material for updates (at least notes we can link to)

Special Topic:

  • June 11th - KOMET demo - the Knowledge Management Envrionment authoring tool

  • Let us know if you have topics or speakers of interest

Steering Committee:

  • Jun 18, 2025

  • Jul 2, 2025?

  • Jul 16, 2025

Adjourned

 1: 57 PM ET

From Chat:

image-20250604-172636.png
image-20250604-172645.png

 

Action items

Quick decisions not requiring context or tracking

For quick, smaller decisions that do not require extra context or formal tracking, use the “Add a decision…” function here.

Decisions requiring context or tracking

For decisions that require more context (e.g., documentation of discussion, options considered) and/or tracking, use the decision template to capture more information.