Vision

Create and implement a knowledge management architecture and tools for the purposes of enabling highly reliable semantic interoperability to improve (1) laboratory terminologies, (2) the codification of data exchange structures using those terminologies, (3) the knowledge artifacts that are intended to process the resulting laboratory data, and (4) the clinical interventions and outcomes based on current medical interpretation of available laboratory reporting data. Ultimately, all knowledge managed by SHIELD will have the integrity and agility necessary to provide meaningful and equitable contributions to laboratory information and management systems, local EHRs, and public health reporting initiatives.

• Useful links:

  • https://www.cdc.gov/cliac/docs/addenda/cliac0903/I_Traceability.pdf

  • http://www.skmtglossary.org/

  • Wong A, Otles E, Donnelly JP, et al. External Validation of a Widely Implemented Proprietary Sepsis Prediction Model in Hospitalized Patients. JAMA Intern Med. Published online June 21, 2021. doi:10.1001/jamainternmed.2021.2626

  • Habib AR, Lin AL, Grant RW. The Epic Sepsis Model Falls Short—The Importance of External Validation. JAMA Intern Med. Published online June 21, 2021.

Use Cases and Requirements by Knowledge Architecture Layer

Procedural Knowledge Layer

• Implementation at local laboratory LIS/LIMS

  • Future thinking but may require large colaberation

    • CDC MedMorph

    • SMART on FHIR (CDS Hooks)

Assertional Knowledge Layer

• Assist vendors and consumers

  • Conformance testing

Statement Model Layer

• Data repository/hub

  • e.g., post-market data surveillance (instance data)

  • Data dictionary

  • De-identified patient data

• SDC can support a data dictionary template framework

• How data is populated and curated

Terminology Knowledge Layer

• Deploy a harmonized ontology for supporting LIVD

• UDIs become a part of the concept within the knowledge base

Foundational Architecture Layer

• Open-source and avoid “black box” data

• API and portal/dashboard

  • CRUD for LIVD knowledge

• Traceability management

  • Same value from several institutions and are useful (equally precise and accurate)

  • Harmonization vs normalization

  • Historical data recall of all LIVD knowledge

• Fingerprint for each instance of lab data (vs metadata)

  • e.g., instance equivalence vs object equivalence

  • Logical vs physical model/representation

  • Ability to determine and or choose level equivalence

  • Non-brittle and safe evolution over time

  • Unambiguous and unique - identify the entity but not understand what it is

    • extend metaphor to be more of the DNA - blueprint

    • UDI’s don’t provide semantic context

  • Enhanced local terminologies

• Collaborative (vendors, labs, healthcare systems, regulators), iterative, incremental, continually learning and improving.

Strategies

Tactics

• User Experience and Functionality - strategy for how stakeholders and end-users engage with the SHIELD tooling and available knowledge.

• Infrastructure and Integration - strategy for how the tooling and knowledge management environment will operate and integrate with external systems and standards.

• Knowledge Management and Analytics - strategy for how LIVD knowledge will be captured, versioned, and curated over time in a highly reliable and patient-safe way.

• Quality Assurance and IV&V - strategy for ensuring the quality, fit-for-purpose, and usefulness of available knowledge.

• Solor Knowledge Architecture

• Solor Analysis Normal Form (ANF)

• Solor Tinkar

• Understandable, Reproducible, Useful (URU) Principle

• Use-case-driven, Architecture-centric, iterative and incremental

• HRO Knowledge Management

3 Year Timeline

• Need to identify some ramp up of complexity/capabilities that align to implementation goals (from the Implementation committee)

  • Similar to crawl, walk, run approach for how the SHIELD knowledge will be used

  • Manual mapping is critical to address

  • CDISC wording on how to manage similar type of data