Page Comparison

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 19 named members, so 2/3 = 12 (excluding chair and government members).

Open Meeting

Started 12:08 PM, ?? quorum reached

Report on progress to FDA Collaborative Community

Will have to fill out report for 2023 and goals for 2024

Follow up Items

• Special Topic calls:

  • Next dates:

    • March 12 - UK Experience

    • April 9th - will use for USCDI Comments

    • May 14th - Netherlands

    • June 11th - Specimen CrossMapping Table

  • Proposed:

    • Use of standards and reporting across the different systems used in Cancer and Pathology - ask CAP folks if interested / someone available (Scott offered)

Review Working Groups progress

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

• Laboratory Interoperability Data Registry (LIDR) Working Group

  • Working on white paper draft - submit for SC review by end of April

• IVD Data Hub

  •  topic for white paper being discussed in light of dependencies on other work like NEST and knowledge management

  • planning on more detailed presentation on April 23rd ALL SHIELD call

• Standards Updates and Vocabulary Working Group

  • next meeting is April 8th - nothing new

• Communications and Branding Working Group

  •  CAP Today article - there are 2 articles in the works - one about the BAA and one on the community, so this needs coordination and approvals

  • monitor presentation opportunities

  • working on elevator pitches for SHIELD for specific audience types - created a page to collect these

Feedback on ONC USCDI V5

• United States Core Data for Interoperability (USCDI) (including USCDI v5) due to ONC by April 15, 2024

• ONC January 2024 Health IT Standards Bulletin due to ONC by July 2024

  Information about the SVAP 2024 can be found at: = Standards Version Advancement Process

Collating comments here: SHIELD Feedback on USCDI V5 Draft

Discussion:

Working on Unique Device Identifier

If FDA UDI is the only Applicable Standards listed, it is required for exchange

If more than one are listed and no preference given, then both are allowed

If the code does not exist, then it ok to not send it

For testkit Identifier - what happens, when one system supports full UDI, but DI is the only one listed in USCDI as expected, then sending the full UDI would not meet requirements?

Ultimately we want the full UDI

should encourage translation capabilities to cover these situations

For implantable devices full UDI has been required since 2015 edition, so the functionality is in the system, but not in the module used for lab

Can we pull the instrument identifier from level 1 - using the same associated vocabulary as for the testkit identifier

COpied from page to record status at end of call:

• Test Kit Unique Device Identifier

  • Current definitions

    • in USCDI: Numeric or alphanumeric code representing a collection of materials necessary to perform diagnostic tests with Applicable Vocabulary Standard(s) = FDA Unique Device Identification System (UDI System)

    • in USCDI+: Uniquely identifies the type of test (at minimum by using test name and manufacturer (similar to the make and model of a car)) that was used to obtain the Test Result Value. It is a device identifier and should be referenced using Device Identifiers (DI), when available. The DI is contained within the unique device identifier (UDI), created by manufacturer (Manufacturer requests UDI issuance, then provides DI, or can be pulled from GUDID database (https://accessgudid.nlm.nih.gov/).

    • COMMENT:

      • #1 - Definitions between USCDI and USCDI+ MUST be the same for this data element for the same use case

      • #2 - Update definition: Uniquely identifies the test reagent configuration (at minimum by using test name and manufacturer (similar to the make and model of a car)) that was used to obtain the Test Result Value. For FDA cleared/approved tests, refers to the unique device identifier (UDI), created by the manufacturer and available as a barcode and human readable text on the package.

  • Applicable Vocabulary for test kits that have no UDI - for those that are not FDA approved for example

  • Data Rationale portant to PHA and where currently available): For the clinical use case it is important to support result trending when obtained from different laboratories. For PH this is important to understand test performance, especially for EUA or new methods. For regulatory use case this can suport post-market surveillance and enhance migration of EUA to 510K applications as well as provide support for real world data use for research in general.
    This data element will require some implementation planning in order to get to the expected full FDA defined UDI and its elements. While each laboratory tracks the tests they perform, documenting the UDI is not currently done in the LIS and creating a way to make that easiest for laboratories must be part of the plan.

  • LDTs are out of scope for SHIELD, so we didn’t explicilty consider it, but overall that area needs to be examined for impacts

  • Update definition: Uniquely identifies the test reagent configuration (at minimum by using test name and manufacturer (similar to the make and model of a car)) that was used to obtain the Test Result Value. For FDA cleared/approved tests, refers to the unique device identifier (UDI), created by the manufacturer and available as a barcode and human readable text on the package.

  • Element specific Mapping, rather than just naming the resource:
    V2: OBX-17 or OBX-18 or PRT-10 or PRT-22
    FHIR: observation.device
    CDA:

• Instrument Unique Identifier

  • Suggest to elevate this element into V5 as it supports the use of Test Kit Identifier

  • Using the same applicable vocabulary as for Test Kit Identifier

• OVERALL:

  • Need to create a better model of relationships between the USCDI data element to help implementers understand the dependencies and cntext each of them provide for the use case they are implementing:

    • examples are

      • Need LOINC to represent the Performed Test by patient generated wearables like a continuous glucose monitor, that produces quantitative result values (with units of measure) and each one needs to be identified using the instrument identifier

      • units of measure and result values for quantitaitve results

      • specimen type and source site

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

1. The roadmap mission section describes a broad vision of lab interoperability. However, the roadmap proposed solution is limited to the FDA use cases around In-vitro diagnostics (IVD) data, specifically populating the IVD data hub.  ONC suggests clearly describing the roadmap scope so the proposed solutions can be discussed within that context.

From last SC call: Nick will connect with Sara to get more context and then bring this to the IVD datahub group - then Nick will bring back here

2. The roadmap identifies training and education needs around using LOINC as a barrier to interoperability. ONC suggests clarifying how the roadmap addresses this barrier. ONC recognizes that terminologies require training and education, and replacing LOINC with another standard will not address the barrier.

Update from Standards and Vocab WG about re-write of this section?

3. 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 exampel implementation - create the structures and bound terminologies to showcase how each element would be properly represented be working.

Looking for volunteer to tackle this re-write: 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.

Antimicrobial result reporting

Placeholder to get back to

Related work at HL7 Europe:

Next calls

All SHIELD:

General Updates: April 23, 2024

Special Topic: OPEN for April - will use for UCSDI V5 Comment approval, if desired

SC: April 16, 2024 would be next

Also May 7th neither Chair nor Vicehair is available - should we just cancel or move to April 30th?

Adjourned

12:55 PM ET