LIVD File Repository Requirements

Requirements:

  1. Create repository for LIVD files produced by manufacturers
    a. Identify hosting site (MVP)
    b. Support for IVD vendors to upload their LIVD files
    i. Electronic as FHIR catalog resource bundle (The current LIVD catalog is universal realm IG – see: https://build.fhir.org/ig/HL7/livd/
    ii. Manual as spreadsheet (Caveat: we have to validated for non-printable extended ASCII Characters that need to be either removed or replaced because these characters can and do play havoc with ETL processing between database warehouses and other electronic messaging formats)
    iii. Manual as csv file
    c. Support for validation during upload (MVP)
    i. Format (MVP) and codes (could be later)

    1. Versioning

      1. Support for versioning of each LIVD file and changes warranting version updates (i.e. additions, deletions, changes to existing content in file)

      2. Support for each LIVD file containing different versions of code systems, including different versions of same code system in a single LIVD file

  2. if correct then accept into holding area

  3. if not correct reject and send/display error message (MVP)
    ii. LOINC codes used (query LOINC “Daily Build” environment to get the most up-to-date status)

  4. If using deprecated codes create error in staging area and list suggested replacement codes (if none exist, then escalate to Regenstrief) (could be later, need to discuss)

    1. Deprecated/discouraged codes may be in IVD LIVD map if they have not maintained/updated their maps as they may not be deprecated/discouraged on that supported version, but are now.

  5. If using discouraged codes create warning in staging area (could be later, need to discuss)

    1. There’s a need to support discouraged codes for some lab tests as it may be the best map. Although not common (i.e. Blood Lead if only a single assay offered for both capillary and venous specimens, and separate assays are not built in LIS for each. This is fairly common.)

  6. UDI needs
    iii. UDI entries in test kit UID or equipment UID columns (query against Global Unique Device Identification Database (GUDID)) (could be later, need to discuss, especially scope)

    1. Support for 10 + UDIs for each “result” where multiple reagents, device(s), etc used to produce single test result and value

    2. Representation where UDIs are not available (i.e. when SARS-COV2-tests emerged)

    3. How UDIs are collected, stored, transmitted. Need LIS functionality for UDIs, barcodes so laboratory professionals are not burdened with trying to find, hand enter, avoid typos/errors, etc. into databases (LIS, LIDR, etc.)


d. Support for staging area after upload to
i. Review mapping (MVP)
ii. Resolve any discrepancies with vendor (could be later)
iii. If that is not possible support flagging of content that is published without review by (MVP)

  1. LIVD committee and governance group (whoever staffs the official review group) (MVP)

  2. Manufacturer after changes have been made
    iv. Support for preview of content in staging area that is not error or warning
    e. Support for validation of repository content after LOINC, SNOMED CT, etc releases, UDI updates?

    1. What validations are done? valid code (no typos, errors)? Active code (vs deprecated, discouraged, trial, etc) If results only, are checks done to make sure no order only LOINCs?

    2. Which code system versions are validated (all/last 5? for LOINC), SCT US and/or Intl?

      1. Are only certain SCT hierarchies validated? Result values must come from qualifier or organism hierarchies? others in/out of scope?

    3. Scope of content validation.

      1. Will validation occur for all timed/challenge tests (i.e. glucose tolerance, fasting gluc)

      2. Will validation occur for calculated results, ratios, etc. only found in LIS?

      3. Will validation occur for relevant LOINCs used in conjunction with IVD assays (Total Volume LOINC for timed urines; Hours of Collection LOINC for timed urines; Source for micro/specimen less LOINCs; Specimen Type for cell counts/fluids, etc.)


  3. f. Support for audit trail
    g. Support for role based user access restrictions (MVP)
    h. Support for workflow supported review process
    i. Suggest 3 levels of review:
    ii. single reviewer can be assigned a map record to review and either approve, modify, or request the mapper redo the work. Sounds like (primary and secondary reviewer of maps needed if utilized per best practice)
    iii. team review, so a single map can be reviewed during a team meeting and group comments / decision be documented.
    iv. automated QA validation scripts that run against the content to very technical data
    i. Support for access
    i. By manufacturer entire catalog only (first step)
    ii. By instrument for a given manufacturer (part of one catalog)
    iii. By test kit for a given manufacturer (part of one catalog)
    iv. By instrument across more than one catalog (for instrument platforms that are open across multiple manufacturers
    v. If we have disease specific LIVD files, then access to those
    j. Support for access using
    i. API calls
    ii. manual search and download
    iii. potentially tooling to help with selection of LOINCs and downloading just the mapping(s) that is/are needed (guided decision based on selection of result scale / allowable specimen / other factors described in comments)
    k. Support for user feedback (MVP)
    i. Support email (MVP)
    ii. FAQs (MVP)
    iii. Helpdesk (this could be part of the implementation of SHIELD standards and should probably not be limited to just the LIVD file)

  4. Update LIVD format to support individual lines and associated mappings for
    a. Results – is already in the 2021JanBallot version of the LIVD FHIR IG balllot version of the LIVD FHIR IG (https://build.fhir.org/ig/HL7/livd/ )
    b. Specimen (currently text only (currently text only)

    1. Source (if applicable. some micro, genetics, pathology, etc.)
      c. Method (in the excel this is not a separate column, but in the LIVD FHIR observationDefintion it is a coded element that could support automation of mapping validation and grouping of test kits)
      d. Order codes (was added for COVID-LIVD file; would need to be added to both the spreadsheet and the LIVD FHIR IG) (Orders are out of scope currently, future support?)

    2. Calibration needed flag (can be just boolean and/or also identify the standard needed for calibration - may be by “test family”) (How is calibration defined? Looks like different meaning here. Most all tests require calibration.)

  5. Searchability/Usability Aspects needed?

    1. Capability to free text type in search bar by LIVD fields (instrument, assay,) and content therein

    2. Ability to filter both with inclusion and exclusion criteria for each LIVD field

      1. include IVD vendor Model XYZ, but exclude ABC, DEF, etc.

      2. include plasma (which includes both ser/plas and plasma), while excluding urine, blood, etc. assays

    3. Capability to produce a change/differential report. Compare LIVD maps from a vendor previously available in one year, version, compared to current/most recent year/version, etc.

    4. Any capability (future) for a lab user to search for maps by all their vendors and perform an export for their LIS or just view and manually map in LIS?

    5. Capability for users to store settings of instruments, vendors, assays via user id so they don’t have to set up IVD search criteria each time?

    6. Capability for users to upload their maps/ instrument info in tool to compare against vendor updates to know if any changes or no changes and maps are current?

    7. Need to think through all user/customer needs as LIVD has been designed for/by IVD vendors. What would improve ease of use for laboratory professionals?

  6. Will repository scope include LOINC maps (even if not in LIVD format) for major reference labs (Quest, LabCorp, Mayo, ARUP, Sonic)? May be more LIDR.

    1. What different fields/functionality is needed to support? Another major source of maps per roadmap.

  7. Existing tooling:
    SOLOR created a prototype that consumed LIVD Excel content and provided UI access to the content. Capabilities included versioning, identifying differences between versions, combining catalogs across MDMs, generating LIVD content in different formats, support for automating lab mapping and selection of content.

  8. BUDGET PROPOSAL: see: https://aphlinformatics.atlassian.net/wiki/download/attachments/915407143/LIDR - Budget.xlsx?api=v2