Skip to end of metadata
Go to start of metadata




1a. Project Name

Guidelines for a Standardized Terminology Knowledge Base

1b. Project ID

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact being Reaffirmed or proceeding to Normative directly after being either Informative or STU?

No

1e. Today's Date

1f. Name of standard being reaffirmed

1g. Project Artifact Information

1h. ISO/IEC Standard to Adopt

1i. Does the standard include excerpted text from one or more ISO, IEC or ISO/IEC standards, but is not an identical or modified adoption?

1j. Unit of Measure

2a. Primary/Sponsor WG

Vocabulary

2d. Project Facilitator

Carol Macumber

2e. Other Interested Parties (and roles)

2f. Modeling Facilitator

Ioana Singureanu (VA)

2g. Publishing Facilitator

Ioana Singureanu (VA)

2h. Vocabulary Facilitator

Carol Macumber

2i. Domain Expert Representative

Keith Campbell (VA), ? (CDC), ? (FDA), Swapna Abhyankar (Regenstrief)

2j. Business Requirements Analyst

Loren Stevenson (VA)

2k. Conformance Facilitator

N/A

2l. Other Facilitators

2m. Implementers

-- UTG (collaboration, exchange format)
-- Department of Veterans Affairs

3a. Project Scope

To describe a flexible self-describing standard logical model for format and distribution of terminology knowledge bases.
-- including collections to represent structures/collections like value sets, refsets, etc.
To standardize representation of machine-processable semantics, consistent representation of language and dialect, and change over time.
- data management requirement re: reference data (DMBOK 2019)

Attachments

3b. Project Need

This project is intended to create a logical model and distribution format to represent represent HL7 Codesets, SNOMED, LOINC, RxNorm, and other clinical terminologies. This model is needed to represent machine-processable semantics for standard terminology and local content/concepts.

3c. Security Risk

No

3d. External Drivers

3e. Objectives/Deliverables and Target Dates

Jan 2021 Ballot
- White Paper including a Logical Model (use case, information model, operations)
- Example implementation (platform-specific) - e.g., XML Schema

3f. Common Names / Keywords / Aliases:

Master Terminology Knowledge Base, Master Term Dictionary

3g. Lineage

3h. Project Dependencies

None

3i. HL7-Managed Project Document Repository URL:

[github repo TBD]

3j. Backwards Compatibility

No

3k. Additional Backwards Compatibility Information (if applicable)

3l. Using Current V3 Data Types?

N/A

3l. Reason for not using current V3 data types?

3m. External Vocabularies

Yes

3n. List of Vocabularies

Ideally, the resulting guidelines can be used to represent both internal (HL7) and external (SNOMED, LOINC etc) vocabularies, including extensions (e.g., SOLOR extension to SNOMED)

3o. Earliest prior release and/or version to which the compatibility applies

4a. Products

Guidance (e.g. Companion Guide, Cookbook, etc), Logical Model, White Paper

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

4c. FHIR Profiles Version

4d. Please define your New Product Definition

4d. Please define your New Product Family

5a. Project Intent

White Paper

5a. White Paper Type

Balloted Informative

5a. Is the project adopting/endorsing an externally developed IG?

5a. Externally developed IG is to be (select one)

5a. Specify external organization

5a. Revising Current Standard Info

5b. Project Ballot Type

Informative

5c. Additional Ballot Info

5d. Joint Copyright

No

5e. I understand I must submit a Joint Copyright Letter of Agreement to the TSC in order for the PSS to receive TSC approval.

no

6a. External Project Collaboration

Regenstrief (Confirmed)
FDA (Possible)
Others

6b. Content Already Developed

6c. Content externally developed?

6d. List Developers of Externally Developed Content

6e. Is this a hosted (externally funded) project?

6f. Stakeholders

6f. Other Stakeholders

6g. Vendors

6g. Other Vendors

6h. Providers

6h. Other Providers

6i. Realm

Universal

7d. US Realm Approval Date

7a. Management Group(s) to Review PSS

7b. Sponsoring WG Approval Date

7c. Co-Sponsor Approval Date

7c. Co-Sponsor 2 Approval Date

7c. Co-Sponsor 3 Approval Date

7c. Co-Sponsor 4 Approval Date

7c. Co-Sponsor 5 Approval Date

7c. Co-Sponsor 6 Approval Date

7c. Co-Sponsor 7 Approval Date

7c. Co-Sponsor 8 Approval Date

7c. Co-Sponsor 9 Approval Date

7c. Co-Sponsor 10 Approval Date

7e. CDA MG Approval Date

7f. FMG Approval Date

7g. V2 MG Approval Date

7h. Architecture Review Board Approval Date

7i. Steering Division Approval Date

7j. TSC Approval Date



























4 Comments

  1. ISO Standards to consider - https://www.iso.org/standard/32881.htmlhttps://www.iso.org/standard/61979.html

    Gap analysis against CORE MIF schema and XML

    Support of FHIR resource generation, closing gaps that are currently covered as extensions

  2. Sydney WGM Comments:

    (ML) Gap analysis against the CTS2 logical model - including looking at it as a failed attempt to provide a single logical model. 

    (RM) Within the context of HL7, we have to start as a first princple the current interchange format (FHIR) and previous (again CTS2, which is under consideration for wihdrawal or reaffirmation)

    (RM) We should pose the question "why do we need this now? what does it help us accomplish that we can't do now?" The prevailing opinion at HL7 is that we don't need logical models. In this project, we need to make the case, while recognizing that the VA, the/one of the largest healthcare systems in the US, wants to do this and is providing resources to do so.

    (IS) We want to be able to support various import and export formats. FHIR is not the only format. The logical model allows us to make many technological decisions with the same underlying model underneath. This would not replace, but an aumentation of what the existing APIs are trying to accomplish. We hope that we can avoiid the pitfalls of hardcoded representations. 

    (ML) Previous attempt to implement CTS2 for SNOMED: SNOMED -> CTS2 -> SNOMED format (roundtrip was required) required consideration of things that were not native to the SNOMED model, and caused issues.

    (IS) We invite everyone to provide use cases for consideration as part of this effort.

    (RM) Would be very useful to be very clear on goals (and conversely, what is NOT a goal). For example, expand on importance of being able to take represenation of terminology content in various formats and be able to link that content together.

    (IS) In terms of uses cases, we are going to be very clear, in that publishing of the content may turn out to be FHIR Codesystems and Valuesets, we are not supercedeing, and we are not addressing runtime. 

    1. The UMLS model would also seem to be relevant for review.

  3. A key challenge faced when attempting to represent SNOMED in CTS2 was confusion as to whether it was a representation of SNOMED as a code system (a logical view of SNOMED), or SNOMED as represented in RF2 (essentially a syntactic re-representation), or something in between.

    This was mainly (IMO) because there was no clear use-case for the CTS2 representation. It was further compounded by other code system's CTS2 representations that did not facilitate logical alignment with SNOMED. Furthermore, a goal of round-tripping RF2 meant that the logical model that was in scope extended beyond the "code system" and included point-in-time implementation details of how SNOMED's distribution format operated.