Skip to end of metadata
Go to start of metadata




1a. Project Name

Guidelines for a Standardized Terminology Knowledge Base

1b. Project ID

1623

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), Swapna Abhyankar (Regenstrief), Possible others include CDC and FDA

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

This project begins the work to describe a flexible self-describing standard logical model for format and distribution of terminology knowledge bases.

The work will be executed in two phases:
Phase I - Creation of the logical model and analysis to map the requirements to existing standards, including FHIR
Phase II - If necessary, definition of a syntax for sharing the terminology artifacts (may be new or an extension to existing standards, including FHIR).

Phase I is covered in this PSS and further described below. Phase II, if necessary, will be covered in a separate PSS:
The logical model will include the ability to represent structures/collections like value sets, refsets, etc.
The resulting logical model is aimed to standardize representation of machine-processable semantics, consistent representation of language and dialect, and change over time.
References and previous standards that will be considered include:
- The Data Management Requirement re: reference data (DMBOK 2019)
- Existing ISO Standards including https://www.iso.org/standard/32881.html, https://www.iso.org/standard/61979.html
- Existing HL7 standards including CTS2, MIF and FHIR

Specifically, the scope includes 1) outlining how the standardized terminology knowledge base can support FHIR resource generation, perhaps closing gaps that are currently covered as extensions 2) a gap analysis of CTS2 logical model, including an evaluation of why it may be considered a unsuccessful attempt to provide a single logical model, so that those pitfalls may be avoided with this attempt.
This project is a first step of defining a logical architecture, based on concepts & requirements that come from existing FHIR terminology services, and the terminologies themselves, such as SNOMED, LOINC, RxNorm, and so forth, and then we can make use of existing—or possibly revised—FHIR resources as a physical representation.
Standard terminologies provide some interesting challenges, such as reconciliation of differing models of modularity and change over time. RxNorm for example, has the need for representing concrete domains, in addition to the current "concepts for numbers" approach that SNOMED is currently taking, and also makes use of cardinality restrictions on role restrictions. There are other things to consider such as how stated and inferred views are represented, how does FHIR terminology services support classification, support for class-based queries (aka kind-of queries).
The terminologies also having differing models of language, dialect, and usage (aka something like a "nursing dialect"), and fitting them all into a consistent logical architecture is part of the effort.
Our goal is to define the logical architecture (i.e. implementation neutral) and then take inventory of the FHIR resources (e.g. CodeSystem, ValueSet, ConceptMap, Basic) and FHIR terminology services to support the implementation of standard-based, integrated terminology knowledge bases, master files, domain specific mapping files, etc. Based on that inventory, this project may develop formal requirements for Phase II and result in FHIR implementation guides to support standard-based terminology knowledge bases.

Attachments

3b. Project Need

This project is intended to create a logical model to 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. More specifically, the guidance is needed to describe how a "sanctioned standard terminology knowledge base" can allow integration of standard content (e.g., currently LOINC can’t be modeled in a SCT model or published in SCT format).

3c. Security Risk

No

3d. External Drivers

3e. Objectives/Deliverables and Target Dates

Jan 2021 Ballot
- Normative specification, 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:

https://confluence.hl7.org/display/VOC/Guidelines+for+a+Standardized+Terminology+Knoweldgebase

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

Logical Model

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

Create new standard

5a. White Paper Type

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

Normative (no STU)

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

Quality Reporting Agencies, Regulatory Agency, Standards Development Organizations (SDOs)

6f. Other Stakeholders

6g. Vendors

Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS

6g. Other Vendors

6h. Providers

Clinical and Public Health Laboratories, Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6h. Other Providers

6i. Realm

Universal

7d. US Realm Approval Date

7a. Management Group(s) to Review PSS

7b. Sponsoring WG Approval Date

Apr 09, 2020

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

May 05, 2020

7j. TSC Approval Date

May 18, 2020


 Show Changes

Version

6

Modifier

Caroline Macumber

Modify Date

Jun 04, 2020 20:07

1a. Project Name

Guidelines for a Standardized Terminology Knowledge Base

1b. Project ID

1623

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

No

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

No

2a. Primary/Sponsor WG

39

2d. Project Facilitator

Carol Macumber

2f. Modeling Facilitator

Ioana Singureanu (VA)

2g. Publishing Facilitator

Ioana Singureanu (VA)

2h. Vocabulary Facilitator

Carol Macumber

2i. Domain Expert Representative

Keith Campbell (VA), Swapna Abhyankar (Regenstrief), Possible others include CDC and FDA

2j. Business Requirements Analyst

Loren Stevenson (VA)

2k. Conformance Facilitator

N/A

2m. Implementers

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

3a. Project Scope

This project begins the work to describe a flexible self-describing standard logical model for format and distribution of terminology knowledge bases.

The work will be executed in two phases:
Phase I - Creation of the logical model and analysis to map the requirements to existing standards, including FHIR
Phase II - If necessary, definition of a syntax for sharing the terminology artifacts (may be new or an extension to existing standards, including FHIR).

Phase I is covered in this PSS and further described below. Phase II, if necessary, will be covered in a separate PSS:
The logical model will include the ability to represent structures/collections like value sets, refsets, etc.
The resulting logical model is aimed to standardize representation of machine-processable semantics, consistent representation of language and dialect, and change over time.
References and previous standards that will be considered include:
- The Data Management Requirement re: reference data (DMBOK 2019)
- Existing ISO Standards including https://www.iso.org/standard/32881.html, https://www.iso.org/standard/61979.html
- Existing HL7 standards including CTS2, MIF and FHIR

Specifically, the scope includes 1) outlining how the standardized terminology knowledge base can support FHIR resource generation, perhaps closing gaps that are currently covered as extensions 2) a gap analysis of CTS2 logical model, including an evaluation of why it may be considered a unsuccessful attempt to provide a single logical model, so that those pitfalls may be avoided with this attempt.
This project is a first step of defining a logical architecture, based on concepts & requirements that come from existing FHIR terminology services, and the terminologies themselves, such as SNOMED, LOINC, RxNorm, and so forth, and then we can make use of existing—or possibly revised—FHIR resources as a physical representation.
Standard terminologies provide some interesting challenges, such as reconciliation of differing models of modularity and change over time. RxNorm for example, has the need for representing concrete domains, in addition to the current "concepts for numbers" approach that SNOMED is currently taking, and also makes use of cardinality restrictions on role restrictions. There are other things to consider such as how stated and inferred views are represented, how does FHIR terminology services support classification, support for class-based queries (aka kind-of queries).
The terminologies also having differing models of language, dialect, and usage (aka something like a "nursing dialect"), and fitting them all into a consistent logical architecture is part of the effort.
Our goal is to define the logical architecture (i.e. implementation neutral) and then take inventory of the FHIR resources (e.g. CodeSystem, ValueSet, ConceptMap, Basic) and FHIR terminology services to support the implementation of standard-based, integrated terminology knowledge bases, master files, domain specific mapping files, etc. Based on that inventory, this project may develop formal requirements for Phase II and result in FHIR implementation guides to support standard-based terminology knowledge bases.

3b. Project Need

This project is intended to create a logical model to 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. More specifically, the guidance is needed to describe how a "sanctioned standard terminology knowledge base" can allow integration of standard content (e.g., currently LOINC can’t be modeled in a SCT model or published in SCT format).

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

Jan 2021 Ballot
- Normative specification, 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

3h. Project Dependencies

None

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/display/VOC/Guidelines+for+a+Standardized+Terminology+Knoweldgebase

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

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)

4a. Products

Logical Model

5a. Project Intent

Create new standard

5b. Project Ballot Type

Normative (no STU)

5d. Joint Copyright

No

6a. External Project Collaboration

Regenstrief (Confirmed)
FDA (Possible)
Others

6f. Stakeholders

Quality Reporting Agencies, Regulatory Agency, Standards Development Organizations (SDOs)

6g. Vendors

Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS

6h. Providers

Clinical and Public Health Laboratories, Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

Universal

7b. Sponsoring WG Approval Date

Apr 09, 2020

7i. Steering Division Approval Date

May 05, 2020

7j. TSC Approval Date

May 18, 2020

Version

5

Modifier

Caroline Macumber

Modify Date

Jun 04, 2020 19:07

1a. Project Name

Guidelines for a Standardized Terminology Knowledge Base

1b. Project ID

1623

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

No

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

No

2a. Primary/Sponsor WG

39

2d. Project Facilitator

Carol Macumber

2f. Modeling Facilitator

Ioana Singureanu (VA)

2g. Publishing Facilitator

Ioana Singureanu (VA)

2h. Vocabulary Facilitator

Carol Macumber

2i. Domain Expert Representative

Keith Campbell (VA), Swapna Abhyankar (Regenstrief), Possible others include CDC and FDA

2j. Business Requirements Analyst

Loren Stevenson (VA)

2k. Conformance Facilitator

N/A

2m. Implementers

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

3a. Project Scope

This project begins the work to describe a flexible self-describing standard logical model for format and distribution of terminology knowledge bases.

The work will be executed in two phases:
Phase I - Creation of the logical model and analysis to map the requirements to existing standards, including FHIR
Phase II - If necessary, definition of a syntax for sharing the terminology artifacts (may be new or an extension to existing standards, including FHIR).

Phase I is covered in this PSS and further described below. Phase II, if necessary, will be covered in a separate PSS:
The logical model will include the ability to represent structures/collections like value sets, refsets, etc.
The resulting logical model is aimed to standardize representation of machine-processable semantics, consistent representation of language and dialect, and change over time.
References and previous standards that will be considered include:
- The Data Management Requirement re: reference data (DMBOK 2019)
- Existing ISO Standards including https://www.iso.org/standard/32881.html, https://www.iso.org/standard/61979.html
- Existing HL7 standards including CTS2, MIF and FHIR

Specifically, the scope includes 1) outlining how the standardized terminology knowledge base can support FHIR resource generation, perhaps closing gaps that are currently covered as extensions 2) a gap analysis of CTS2 logical model, including an evaluation of why it may be considered a unsuccessful attempt to provide a single logical model, so that those pitfalls may be avoided with this attempt.
This project is a first step of defining a logical architecture, based on concepts & requirements that come from existing FHIR terminology services, and the terminologies themselves, such as SNOMED, LOINC, RxNorm, and so forth, and then we can make use of existing—or possibly revised—FHIR resources as a physical representation.
Standard terminologies provide some interesting challenges, such as reconciliation of differing models of modularity and change over time. RxNorm for example, has the need for representing concrete domains, in addition to the current "concepts for numbers" approach that SNOMED is currently taking, and also makes use of cardinality restrictions on role restrictions. There are other things to consider such as how stated and inferred views are represented, how does FHIR terminology services support classification, support for class-based queries (aka kind-of queries).
The terminologies also having differing models of language, dialect, and usage (aka something like a "nursing dialect"), and fitting them all into a consistent logical architecture is part of the effort.
Our goal is to define the logical architecture (i.e. implementation neutral) and then take inventory of the FHIR resources (e.g. CodeSystem, ValueSet, ConceptMap, Basic) and FHIR terminology services to support the implementation of standard-based, integrated terminology knowledge bases, master files, domain specific mapping files, etc. Based on that inventory, this project may develop formal requirements for Phase II and result in FHIR implementation guides to support standard-based terminology knowledge bases.

3b. Project Need

This project is intended to create a logical model to 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. More specifically, the guidance is needed to describe how a "sanctioned standard terminology knowledge base" can allow integration of standard content (e.g., currently LOINC can’t be modeled in a SCT model or published in SCT format).

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

Jan 2021 Ballot
- Normative specification, 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

3h. Project Dependencies

None

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/display/VOC/Guidelines+for+a+Standardized+Terminology+Knoweldgebase

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

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)

4a. Products

Logical Model

5a. Project Intent

Create new standard

5b. Project Ballot Type

Normative (no STU)

5d. Joint Copyright

No

6a. External Project Collaboration

Regenstrief (Confirmed)
FDA (Possible)
Others

6f. Stakeholders

Quality Reporting Agencies, Regulatory Agency, Standards Development Organizations (SDOs)

6i. Realm

Universal

7b. Sponsoring WG Approval Date

Apr 09, 2020

7i. Steering Division Approval Date

May 05, 2020

7j. TSC Approval Date

May 18, 2020

Version

4

Modifier

Anne Wizauer

Modify Date

May 19, 2020 19:38

1a. Project Name

Guidelines for a Standardized Terminology Knowledge Base

1b. Project ID

1623

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

No

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

No

2a. Primary/Sponsor WG

39

2d. Project Facilitator

Carol Macumber

2f. Modeling Facilitator

Ioana Singureanu (VA)

2g. Publishing Facilitator

Ioana Singureanu (VA)

2h. Vocabulary Facilitator

Carol Macumber

2i. Domain Expert Representative

Keith Campbell (VA), Swapna Abhyankar (Regenstrief), Possible others include CDC and FDA

2j. Business Requirements Analyst

Loren Stevenson (VA)

2k. Conformance Facilitator

N/A

2m. Implementers

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

3a. Project Scope

This project begins the work to describe a flexible self-describing standard logical model for format and distribution of terminology knowledge bases.

The work will be executed in two phases:
Phase I - Creation of the logical model and analysis to map the requirements to existing standards, including FHIR
Phase II - If necessary, definition of a syntax for sharing the terminology artifacts (may be new or an extension to existing standards, including FHIR).

Phase I is covered in this PSS and further described below. Phase II, if necessary, will be covered in a separate PSS:
The logical model will include the ability to represent structures/collections like value sets, refsets, etc.
The resulting logical model is aimed to standardize representation of machine-processable semantics, consistent representation of language and dialect, and change over time.
References and previous standards that will be considered include:
- The Data Management Requirement re: reference data (DMBOK 2019)
- Existing ISO Standards including https://www.iso.org/standard/32881.html, https://www.iso.org/standard/61979.html
- Existing HL7 standards including CTS2, MIF and FHIR

Specifically, the scope includes 1) outlining how the standardized terminology knowledge base can support FHIR resource generation, perhaps closing gaps that are currently covered as extensions 2) a gap analysis of CTS2 logical model, including an evaluation of why it may be considered a unsuccessful attempt to provide a single logical model, so that those pitfalls may be avoided with this attempt.
This project is a first step of defining a logical architecture, based on concepts & requirements that come from existing FHIR terminology services, and the terminologies themselves, such as SNOMED, LOINC, RxNorm, and so forth, and then we can make use of existing—or possibly revised—FHIR resources as a physical representation.
Standard terminologies provide some interesting challenges, such as reconciliation of differing models of modularity and change over time. RxNorm for example, has the need for representing concrete domains, in addition to the current "concepts for numbers" approach that SNOMED is currently taking, and also makes use of cardinality restrictions on role restrictions. There are other things to consider such as how stated and inferred views are represented, how does FHIR terminology services support classification, support for class-based queries (aka kind-of queries).
The terminologies also having differing models of language, dialect, and usage (aka something like a "nursing dialect"), and fitting them all into a consistent logical architecture is part of the effort.
Our goal is to define the logical architecture (i.e. implementation neutral) and then take inventory of the FHIR resources (e.g. CodeSystem, ValueSet, ConceptMap, Basic) and FHIR terminology services to support the implementation of standard-based, integrated terminology knowledge bases, master files, domain specific mapping files, etc. Based on that inventory, this project may develop formal requirements for Phase II and result in FHIR implementation guides to support standard-based terminology knowledge bases.

3b. Project Need

This project is intended to create a logical model to 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. More specifically, the guidance is needed to describe how a "sanctioned standard terminology knowledge base" can allow integration of standard content (e.g., currently LOINC can’t be modeled in a SCT model or published in SCT format).

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

Jan 2021 Ballot
- Normative specification, 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

3h. Project Dependencies

None

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/display/VOC/Guidelines+for+a+Standardized+Terminology+Knoweldgebase

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

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)

4a. Products

Logical Model

5a. Project Intent

Create new standard

5b. Project Ballot Type

Normative (no STU)

5d. Joint Copyright

No

6a. External Project Collaboration

Regenstrief (Confirmed)
FDA (Possible)
Others

6i. Realm

Universal

7b. Sponsoring WG Approval Date

Apr 09, 2020

7i. Steering Division Approval Date

May 05, 2020

7j. TSC Approval Date

May 18, 2020

Version

3

Modifier

Anne Wizauer

Modify Date

May 07, 2020 21:20

1a. Project Name

Guidelines for a Standardized Terminology Knowledge Base

1b. Project ID

1623

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

No

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

No

2a. Primary/Sponsor WG

39

2d. Project Facilitator

Carol Macumber

2f. Modeling Facilitator

Ioana Singureanu (VA)

2g. Publishing Facilitator

Ioana Singureanu (VA)

2h. Vocabulary Facilitator

Carol Macumber

2i. Domain Expert Representative

Keith Campbell (VA), Swapna Abhyankar (Regenstrief), Possible others include CDC and FDA

2j. Business Requirements Analyst

Loren Stevenson (VA)

2k. Conformance Facilitator

N/A

2m. Implementers

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

3a. Project Scope

This project begins the work to describe a flexible self-describing standard logical model for format and distribution of terminology knowledge bases.

The work will be executed in two phases:
Phase I - Creation of the logical model and analysis to map the requirements to existing standards, including FHIR
Phase II - If necessary, definition of a syntax for sharing the terminology artifacts (may be new or an extension to existing standards, including FHIR).

Phase I is covered in this PSS and further described below. Phase II, if necessary, will be covered in a separate PSS:
The logical model will include the ability to represent structures/collections like value sets, refsets, etc.
The resulting logical model is aimed to standardize representation of machine-processable semantics, consistent representation of language and dialect, and change over time.
References and previous standards that will be considered include:
- The Data Management Requirement re: reference data (DMBOK 2019)
- Existing ISO Standards including https://www.iso.org/standard/32881.html, https://www.iso.org/standard/61979.html
- Existing HL7 standards including CTS2, MIF and FHIR

Specifically, the scope includes 1) outlining how the standardized terminology knowledge base can support FHIR resource generation, perhaps closing gaps that are currently covered as extensions 2) a gap analysis of CTS2 logical model, including an evaluation of why it may be considered a unsuccessful attempt to provide a single logical model, so that those pitfalls may be avoided with this attempt.
This project is a first step of defining a logical architecture, based on concepts & requirements that come from existing FHIR terminology services, and the terminologies themselves, such as SNOMED, LOINC, RxNorm, and so forth, and then we can make use of existing—or possibly revised—FHIR resources as a physical representation.
Standard terminologies provide some interesting challenges, such as reconciliation of differing models of modularity and change over time. RxNorm for example, has the need for representing concrete domains, in addition to the current "concepts for numbers" approach that SNOMED is currently taking, and also makes use of cardinality restrictions on role restrictions. There are other things to consider such as how stated and inferred views are represented, how does FHIR terminology services support classification, support for class-based queries (aka kind-of queries).
The terminologies also having differing models of language, dialect, and usage (aka something like a "nursing dialect"), and fitting them all into a consistent logical architecture is part of the effort.
Our goal is to define the logical architecture (i.e. implementation neutral) and then take inventory of the FHIR resources (e.g. CodeSystem, ValueSet, ConceptMap, Basic) and FHIR terminology services to support the implementation of standard-based, integrated terminology knowledge bases, master files, domain specific mapping files, etc. Based on that inventory, this project may develop formal requirements for Phase II and result in FHIR implementation guides to support standard-based terminology knowledge bases.

3b. Project Need

This project is intended to create a logical model to 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. More specifically, the guidance is needed to describe how a "sanctioned standard terminology knowledge base" can allow integration of standard content (e.g., currently LOINC can’t be modeled in a SCT model or published in SCT format).

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

Jan 2021 Ballot
- Normative specification, 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

3h. Project Dependencies

None

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/display/VOC/Guidelines+for+a+Standardized+Terminology+Knoweldgebase

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

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)

4a. Products

Logical Model

5a. Project Intent

Create new standard

5b. Project Ballot Type

Normative (no STU)

5d. Joint Copyright

No

6a. External Project Collaboration

Regenstrief (Confirmed)
FDA (Possible)
Others

6i. Realm

Universal

7b. Sponsoring WG Approval Date

Apr 09, 2020

7i. Steering Division Approval Date

May 05, 2020

Version

2

Modifier

Dave Hamill

Modify Date

May 07, 2020 18:06

1a. Project Name

Guidelines for a Standardized Terminology Knowledge Base

1b. Project ID

1623

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

No

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

No

2a. Primary/Sponsor WG

39

2d. Project Facilitator

Carol Macumber

2f. Modeling Facilitator

Ioana Singureanu (VA)

2g. Publishing Facilitator

Ioana Singureanu (VA)

2h. Vocabulary Facilitator

Carol Macumber

2i. Domain Expert Representative

Keith Campbell (VA), Swapna Abhyankar (Regenstrief), Possible others include CDC and FDA

2j. Business Requirements Analyst

Loren Stevenson (VA)

2k. Conformance Facilitator

N/A

2m. Implementers

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

3a. Project Scope

This project begins the work to describe a flexible self-describing standard logical model for format and distribution of terminology knowledge bases.

The work will be executed in two phases:
Phase I - Creation of the logical model and analysis to map the requirements to existing standards, including FHIR
Phase II - If necessary, definition of a syntax for sharing the terminology artifacts (may be new or an extension to existing standards, including FHIR).

Phase I is covered in this PSS and further described below. Phase II, if necessary, will be covered in a separate PSS:
The logical model will include the ability to represent structures/collections like value sets, refsets, etc.
The resulting logical model is aimed to standardize representation of machine-processable semantics, consistent representation of language and dialect, and change over time.
References and previous standards that will be considered include:
- The Data Management Requirement re: reference data (DMBOK 2019)
- Existing ISO Standards including https://www.iso.org/standard/32881.html, https://www.iso.org/standard/61979.html
- Existing HL7 standards including CTS2, MIF and FHIR

Specifically, the scope includes 1) outlining how the standardized terminology knowledge base can support FHIR resource generation, perhaps closing gaps that are currently covered as extensions 2) a gap analysis of CTS2 logical model, including an evaluation of why it may be considered a unsuccessful attempt to provide a single logical model, so that those pitfalls may be avoided with this attempt.
This project is a first step of defining a logical architecture, based on concepts & requirements that come from existing FHIR terminology services, and the terminologies themselves, such as SNOMED, LOINC, RxNorm, and so forth, and then we can make use of existing—or possibly revised—FHIR resources as a physical representation.
Standard terminologies provide some interesting challenges, such as reconciliation of differing models of modularity and change over time. RxNorm for example, has the need for representing concrete domains, in addition to the current "concepts for numbers" approach that SNOMED is currently taking, and also makes use of cardinality restrictions on role restrictions. There are other things to consider such as how stated and inferred views are represented, how does FHIR terminology services support classification, support for class-based queries (aka kind-of queries).
The terminologies also having differing models of language, dialect, and usage (aka something like a "nursing dialect"), and fitting them all into a consistent logical architecture is part of the effort.
Our goal is to define the logical architecture (i.e. implementation neutral) and then take inventory of the FHIR resources (e.g. CodeSystem, ValueSet, ConceptMap, Basic) and FHIR terminology services to support the implementation of standard-based, integrated terminology knowledge bases, master files, domain specific mapping files, etc. Based on that inventory, this project may develop formal requirements for Phase II and result in FHIR implementation guides to support standard-based terminology knowledge bases.

3b. Project Need

This project is intended to create a logical model to 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. More specifically, the guidance is needed to describe how a "sanctioned standard terminology knowledge base" can allow integration of standard content (e.g., currently LOINC can’t be modeled in a SCT model or published in SCT format).

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

Jan 2021 Ballot
- Normative specification, 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

3h. Project Dependencies

None

3i. HL7-Managed Project Document Repository URL:

[github repo TBD]

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

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)

4a. Products

Logical Model

5a. Project Intent

Create new standard

5b. Project Ballot Type

Normative (no STU)

5d. Joint Copyright

No

6a. External Project Collaboration

Regenstrief (Confirmed)
FDA (Possible)
Others

6i. Realm

Universal

7b. Sponsoring WG Approval Date

Apr 09, 2020

7i. Steering Division Approval Date

May 05, 2020

Version

1

Modifier

Caroline Macumber

Modify Date

May 05, 2020 22:52

1a. Project Name

Guidelines for a Standardized Terminology Knowledge Base

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

No

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

No

2a. Primary/Sponsor WG

39

2d. Project Facilitator

Carol Macumber

2f. Modeling Facilitator

Ioana Singureanu (VA)

2g. Publishing Facilitator

Ioana Singureanu (VA)

2h. Vocabulary Facilitator

Carol Macumber

2i. Domain Expert Representative

Keith Campbell (VA), Swapna Abhyankar (Regenstrief), Possible others include CDC and FDA

2j. Business Requirements Analyst

Loren Stevenson (VA)

2k. Conformance Facilitator

N/A

2m. Implementers

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

3a. Project Scope

This project begins the work to describe a flexible self-describing standard logical model for format and distribution of terminology knowledge bases.

The work will be executed in two phases:
Phase I - Creation of the logical model and analysis to map the requirements to existing standards, including FHIR
Phase II - If necessary, definition of a syntax for sharing the terminology artifacts (may be new or an extension to existing standards, including FHIR).

Phase I is covered in this PSS and further described below. Phase II, if necessary, will be covered in a separate PSS:
The logical model will include the ability to represent structures/collections like value sets, refsets, etc.
The resulting logical model is aimed to standardize representation of machine-processable semantics, consistent representation of language and dialect, and change over time.
References and previous standards that will be considered include:
- The Data Management Requirement re: reference data (DMBOK 2019)
- Existing ISO Standards including https://www.iso.org/standard/32881.html, https://www.iso.org/standard/61979.html
- Existing HL7 standards including CTS2, MIF and FHIR

Specifically, the scope includes 1) outlining how the standardized terminology knowledge base can support FHIR resource generation, perhaps closing gaps that are currently covered as extensions 2) a gap analysis of CTS2 logical model, including an evaluation of why it may be considered a unsuccessful attempt to provide a single logical model, so that those pitfalls may be avoided with this attempt.
This project is a first step of defining a logical architecture, based on concepts & requirements that come from existing FHIR terminology services, and the terminologies themselves, such as SNOMED, LOINC, RxNorm, and so forth, and then we can make use of existing—or possibly revised—FHIR resources as a physical representation.
Standard terminologies provide some interesting challenges, such as reconciliation of differing models of modularity and change over time. RxNorm for example, has the need for representing concrete domains, in addition to the current "concepts for numbers" approach that SNOMED is currently taking, and also makes use of cardinality restrictions on role restrictions. There are other things to consider such as how stated and inferred views are represented, how does FHIR terminology services support classification, support for class-based queries (aka kind-of queries).
The terminologies also having differing models of language, dialect, and usage (aka something like a "nursing dialect"), and fitting them all into a consistent logical architecture is part of the effort.
Our goal is to define the logical architecture (i.e. implementation neutral) and then take inventory of the FHIR resources (e.g. CodeSystem, ValueSet, ConceptMap, Basic) and FHIR terminology services to support the implementation of standard-based, integrated terminology knowledge bases, master files, domain specific mapping files, etc. Based on that inventory, this project may develop formal requirements for Phase II and result in FHIR implementation guides to support standard-based terminology knowledge bases.

3b. Project Need

This project is intended to create a logical model to 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. More specifically, the guidance is needed to describe how a "sanctioned standard terminology knowledge base" can allow integration of standard content (e.g., currently LOINC can’t be modeled in a SCT model or published in SCT format).

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

Jan 2021 Ballot
- Normative specification, 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

3h. Project Dependencies

None

3i. HL7-Managed Project Document Repository URL:

[github repo TBD]

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

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)

4a. Products

Logical Model

5a. Project Intent

Create new standard

5b. Project Ballot Type

Normative (no STU)

5d. Joint Copyright

No

6a. External Project Collaboration

Regenstrief (Confirmed)
FDA (Possible)
Others

6i. Realm

Universal

7b. Sponsoring WG Approval Date

Apr 09, 2020

7i. Steering Division Approval Date

May 05, 2020

64 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.

    1. We are trying to avoid a predefined, one-size-fits-all structure in favor of a self-describing structure that can be extended seamlessly. The CTS2 data structures were very closely tied to V3 terminology structures so it couldn't be reused for other  purposes without significant changes. This is what we found out so far... 

  4. Defining a logical model for requirements analysis seems reasonable.  Defining a new exchange syntax doesn't sound like a good/wise idea.  Certainly that shouldn't be a preferred outcome if profiling/extending FHIR proves to be viable.  For the logical model, you could consider the FHIR-based logical modeling tools

  5. Organizations have to integrate concepts from SNOMED CT, LOINC, SNOMED CT, RxNorm, HL7 V2, HL7 FHIR, C-CDA, etc. Each terminology system specifies a different set of concept descriptors required by copyright rules,  If an organization is integrating LOINC test identifiers into a local master file, it needs to preserve the parts fully specified naming structure.  These are specific to LOINC: https://loinc.org/faq/structure-of-loinc-codes-and-names/. The Fully-Specified Name (FSN) includes all the parts.
    HL7 concepts have a different set of descriptors than LOINC:  level, mnemonic, display name, definition, and comments.

    This representation needs to support code systems and value set descriptors across V2, V3, FHIR  but also support SNOMED CT refsets and LOINC "panels".

    1. Sure - but FHIR does that (or can be extended to do that).  That's absolutely part of its scope.  It doesn't make sense to invent yet another syntax.

      1. We may end up creating additional FHIR profiles, designing databases, etc. from this logical model. It's not about a syntax as much it's about a self-describing model that can integrate terminologies.  Not a terminology server replacement but a terminology server enabler. 

        1. The PSS specifically says "and distribution format".  If you're defining a distribution format, then you're defining a syntax.  I'm opposed to us coming up with another  syntax for exchanging code systems unless we're quite certain that FHIR can't be used to satisfy the use-case.  If you want to yank the "and distribution format" and only create a logical model, that's ok, though a 'model' won't integrate terminologies.  That will be a terminology service - which pretty much means using FHIR.

          1. We are trying to create a terminology-independent, standards-based representation for LOINC, SNOMED, HL7, etc, concepts. HL7 FHIR concepts each have the following descriptors:  a code, display, and definition. LOINC has its own descriptors (aka fully-specified name). SNOMED and RxNorm similarly. If I need to use all 4 terminologies in VA, I need to import and use the descriptors associated with each terminology. If I create an application, device, or enterprise-specific extension I need to supply the descriptors that are specific to each terminology... and do it consistently. 

            Currently, we don' t have any  LOINC-specific concept descriptors but we could add them later as extensions. However, we don't have a set of extensions for LOINC, another for SNOMED, etc. We would create set of extensions that could work any terminology system irrespective of its chosen descriptors. It has to work for HL7 V2, V3, FHIR concepts as well LOINC, SNOMED ,RxNorm, CVX, etc.


            1. FHIR supports an arbitrary number of typed designations for each concept as well as arbitrary properties.  It's completely possible to represent LOINC, SNOMED and any other code system we've encountered within FHIR.  FHIR is  a terminology-independent standards-based representation.  We don't pass LOINC or SNOMED around with their full content because they're too darn huge (plus, in the case of SNOMED, there's no one source where everything is published).  But it's totally possible to access the content of SNOMED, LOINC and countless other non-HL7 code systems using FHIR.  And we wouldn't even need extensions.  I don't understand why this project is pursuing something other than FHIR.

              1. If you look at the HAPI FHIR database schema it supports FHIR resources but the data model is not recognizable as being related to any version of FHIR because it's version-neutral. That's very powerful. A HAPI FHIR database can support any version of FHIR. We're trying to do the same: define a logical data model that could be externalixed using FHIR  Terminology resources with extensions corresponding to standard-based, terminology-neutral descriptors. We're basically trying to create the data model for integrated terminology knowledge base that one would need to support MU2015, for instance.

                Indeed you can represent arbitrary descriptors in FHIR but we don't want to use arbitrary but standard-based descriptors.

                1. But the FHIR data model already supports all of the MU2015 code systems.  If you're trying to define a common ontology for concept descriptors (across LOINC, SNOMED, RxNorm, etc.), that's not a data model, that's a terminology.  A data model that supports arbitrary descriptors doesn't change when you try to standardize descriptors (at least to cover a particular set of code systems - you'll never standardize descriptors across all  code systems).

        2. Also, it would be helpful to understand what the next step is after the logical model.  A logical model is an analysis artifact.  It doesn't actually do  anything.  What is the interoperability problem we're trying to solve in the end and how is having a logical model a step on the path to fixing that problem?

          1. We will use the logical model to create a DB schema that allows us to integrate local and standard concepts and manage local and standard value sets, mappings. etc 

            Similar to the way HAPI has its own flexible DB Schema for storing FHIR resources irrespective  of FHIR version. This DB schema would allow us to import local and standard terminology (coding systems, value sets, modules) from a variety of sources using the same DB (relational, graph/nosql) and create additional descriptor (e.g. mapping/equivalence relationships) to discover and address gaps as extensions. Right now a lot project give up this important step in semantic mapping: addressing the gaps.  As provider organizations we need to use LOINC, SNOMED CT, CPT-4, etc in accordance wiht the licensing requirements and that means addressing the specific requirements each terminology while using all of them in concert to fill complementary needs.,


            1. Why?  CodeSystem and ValueSet are now normative.  If you want a standards-based database format that will store arbitrary code systems, use HAPI's (if you need relational) or the HL7 terminology registry's (if you don't).  Both of them already store all the code systems you care about - including addressing the specific characteristics of each terminology.  It seems this project is trying to reproduce something that already exists.

              Given that FHIR can represent LOINC, SNOMED-CT, CPT-4, RxNorm, CVX, etc. and already has an open terminology service that exposes the content of all of them (with the exception of CPT where there doesn't appear to be any way of doing so in an 'open' fashion that meets their licensing terms), what is it that doesn't exist that this proposed project will cause to exist?

              1. First of all, we want to have standard-based, platform-independent  terminology knowledge base that can work with or without FHIR. Many EHR  still use files to import enterprise-specific master files - not FHIR resources. In the future, the concepts may be defined using a Basic resource, perhaps,.  We are envisioning a model that supports integrating and extending terminology. A precursor to value set creation:  standard-based knowledge base of  integrated concepts  from  standard CodeSystem(s) and from locally-defined CodeSystem(s). These concepts may be organized into an infinite number of ValueSet resources. 

                We plan to model how to declare standard-based descriptors for any concepts (including locally-defined ones who get left behind mapping file. Any concept in may appear in CodeSystem and ValueSet resources and address their descriptors first.  The HAPI persistence model for FHIR  resources can store Patient and ValueSet resources in the exact same way. Our work would inform the content of a value set expansion and it would follow a similar approach to managing concepts that FHIR DB uses to manage resources.

                Our logical model would look similar to the HAPI  resource  data model (except we want it to be db-neutral so we can use relational,  NoSQL, files) .The difference between HAPI and what we're envisioning is that the central object for us would be a concept. From a FHIR ValueSet stand-point, a concept could me a member in any number of ValueSet(s). Agaom. we foundational data model that allows us to integrate local and standard concepts so we can create.

                1. I don't understand "standards-based, platform independent".  If you're defining an exchange or persistence syntax, you're defining a standard.  FHIR already is a standard.  Why define another one?  FHIR already supports integrating and extending terminology - via the code systems themselves or via code system supplements.

                  The base question is: what is that you are trying to do with this project that can't/shouldn't be done with FHIR?  If you want to build a different data repository than HAPI, you can - but it's not clear why that needs to be (or should be) blessed by HL7.

                  1. Why prejudge the outcome? It won't be blessed by HL7 unless it makes it successfully thorough a ballot process. It may be that the outcome confirms that FHIR terminology resources are sufficient for the task, or that they may need some revisions as can be managed through future FHIR ballot versions.

                    1. If the project were phrased as "determine if FHIR can meet the requirement and if so, create an IG giving necessary guidance", I could live with that.  However, as phrased, the outcome seems to be presumed to be to create something separate.  I could be ok with that too if  it was clear why that was necessary - but so far, I haven't heard it.

                      1. We will work on language revisions that communicate this basic sentiment.

                        1. I added "Our goal is to define the logical architecture (i.e. implementation neutral) and then take inventory of the FHIR resources (e.g. CodeSystem, ValueSet, ConceptMap, Basic) and FHIR terminology services to support the implementation of standard-based, integrated terminology knowledge bases, master files, domain specific mapping files, etc. Based on that inventory, this project may develop formal requirements or implementation guides to support standard-based terminology knowledge bases."

  6. Would it be correct to define this project as intending to define extensions to FHIR to support the generalizations you feel are needed? In that way it is not a new standard but additions to FHIR terminology resources (or even something new within FHIR?

    1. We are trying to start with a first step of defining a logical architecture, based on concepts & requirements that come from existing FHIR terminology services, and the terminologies themselves, such as SNOMED, LOINC, RxNorm, and so forth, and then we can make use of existing—or possibly revised—FHIR resources as a physical representation.

      The terminologies provide some interesting challenges, such as reconciliation of differing models of modularity and change over time. RxNorm for example (based in preview releases that I have reviewed) has need for representing concrete domains, in addition to the current "concepts for numbers" approach that SNOMED is currently taking, and also makes use of cardinality restrictions on role restrictions. There are other things to consider such as how stated and inferred views are represented, how does FHIR terminology services support classification, support for class-based queries (aka kind-of queries).

      The terminologies also having differing models of language, dialect, and usage (aka something like a "nursing dialect"), and fitting them all into a consistent logical architecture is part of the effort. 

      Our goal is to define the logical architecture, and then take inventory of the FHIR resources and terminology services, and then see if we should provide guidance on use, or on evolution, of appropriate FHIR resources.

      So perhaps this is a long way of saying that we are not trying to create a new standard that would diminish FHIR terminology resources in any way, but that may point for how these may need to evolve (and if they don't need to evolve, be a robust way of confirming that as well).


      1. If we can incorporate that language into the PSS, I'd be much happier voting to approve.

        1. We will work to incorporate this language into the PSS.

          1. Thanks, Lloyd McKenzie and Keith E. Campbell. I added the language recommended to the Scope section above.  Please feel free to suggest additional edits to clarify the scope., We want to clarify how this work complementary to other HL7 and Vocab WG projects.

            1. Can you reword/clarify "This project is intended to create a logical model and distribution format"?  If you're talking about distribution of a logical model, HL7 has two standard ways of defining and publishing logical models - EA files or FHIR logical models - presume you're not planning to define a new mechanism for sharing logical models?  If you're talking about a distribution format for artifacts, we should clarify that it will be FHIR.

              1. We talking format/schema for exchanging/storing terminology knowledge bases containing integrated concepts..  Does this work?

                1. It doesn't clarify that the distribution format will be FHIR, so no not really.  What I'm trying to avoid is the creation of a new  distribution format when we've already got one.

                  1. FHIR is format but it can't be the only one because we need to create repositories and master files too. Without this proviso we can't really use in VA right now.

                    1. VA is free to store however it likes.  Generally HL7 doesn't try to standardize how data is persisted, and not sure why we'd try to do that here.  In terms of exchange, that should be FHIR unless we have a very good reason to do something else (and said reason should either be captured in the PSS or there should be a decision point in the execution of the project where the rationale - once developed - would be vetted and approved by the vocab WG and/or the FMG prior to proceeding to create an alternate syntax).

                      I'm just wanting to ensure that the HL7-balloted/endorsed artifacts don't include anything that conflicts with FHIR unless we've agreed in advance that that's necessary and desirable.

                      1. A logical model that can be implemented in FHIR does not contradict FHIR obviously. Vocab has other projects like this (e.g. Gender Harmonization).  If we say this is a logical model that applies to FHIR resources, we are needlessly leaving real implementations behind. 

                        A logical model is implementation  and platform neutral and it should, therefore,  allow multiple implementation for a  terminology knowledge base. I'm  struggling to understand how this project differs from Gender Harmonization in that regard.

                        1. Gender Harmonization isn't defining a mechanism to share or persist.  I have no concerns about this project creating a logical model.  The sticking point is the definition of a syntax to share/persist.  That's no longer 'logical' territory.

                          1. Our logical model is intended to be reused  in the same way as Gender Harmonize:  Files are a form of persistence too (smile) so we need to standard to manage.  I will add that the explicitly intended ot have  like FHIR resources and profiles, file formats, and database schemas consistent with this logical model.

                            1. As I understand the discussion, there shouldn't be any file formats other than FHIR.  I.e. this project isn't going to be defining any new standards for file exchange.  Persistence requirements are driven by app-specific requirements.  If you're planning to use the database as an exchange interface, we should be leveraging the SQL on FHIR stuff rather than inventing something new that's terminology-specific.

                              1. According to the PSS , we are planning to a use case driven  logical model that  be used to create V2 master files, a standard-based file format, a standardized  db schema, change a FHIR resource (e.g. ConceptMap) or profile other resources (.e.g. ValueSet, CodeSystem). It's platform-independent logical model  therefore not specific to FHIR but specific to integrated terminology knowledge bases. I think it's worth reiterating this point.

                                1. Right.  I understand you want to handle non-FHIR terminologies.  FHIR is designed to handle all  terminologies.  We should not be defining a new "A standard-based file format".  We can create a FHIR implementation guide that provides specific guidance on sharing the particular subset of terminologies of interest to the VA if existing guidance is insufficient.  If there's a belief that FHIR is inappropriate for use as the cross-terminology file format, then we need to talk about why.  I'm not oppose to creating an alternative to FHIR if FHIR can't meet the need.  But I am opposed to creating "yet another syntax" without a pressing reason.

                                  In terms of a database schema. HL7 has not defined those in the past.  If the intent is to use it as a point of interoperability, then we should be using SQL on FHIR.  If the intention is to demonstrate how it can be done but not expect the persistence layer to be a point of interoperability, create it as a reference implementation and don't include it as a balloted artifact.

                                  1. How do you handle concrete domain representation, role chaining, property chaining with implication, and multiple sufficient sets with a FHIR terminology resource?

                                    1. I expect for most of those, via extensions - which is how most sophisticated, non-commonly used capabilities are implemented.  Grahame Grieve Robert Hausam?

                                      1. I don't know what all those things actually are. I'd have to see detailed analysis to have any opinion

                                        1. Exactly, we need to do the detailed analysis, and that is what we are committed to do as part of this project. I'm reasonably confident that these type of capabilities where not thoroughly analyzed as part of the design of the existing FHIR terminology resources, and depending on ad-hoc extensions has well documented downsides with respect to interoperability, analysis, and consistency of implementation.

                                          One of the challenges with CTS 2, is that it was/is too depend on ad-hoc extensions to represent systems such as SNOMED, and there where inconsistent implementations. Two companies with competing term servers could not even make the systems consistent at the API level (I know because many years ago, we paid for two different groups to load SNOMED into CTS servers and analyzed the results). I think we need to do better.

                                          Demanding a particular outcome before even completing the work seems unnecessarily dogmatic, contrary to the principles of meritocracy, and not really collegial.

                                          The ballot process will allow for a proper set of checks and balances on the outcome of this work.

                                          1. They wouldn't need to be ad-hoc extensions.  We can define standard extensions for the necessary purpose and publish them as a standard implementation guide - which could eventually reach normative status.  I don't want to authorize a project that's contemplating creating an alternative to FHIR for the representation of terminology resources unless we're confident that FHIR is inappropriate for the use-case and something else will work better.  I'm fine with a project to create the logical model and perform the analysis of any gaps to go forward, but if there's an intention to define a new syntax, I'd like that to be a distinct project that we can evaluate the wisdom of proceeding with after  we have a good sense of the gaps and the suitability of FHIR to meeting them.  The ballot process is too late for such a check-point.

                                            Side-point - the main reason that CTS2 failed is that it was too complicated and hard to implement.  FHIR has fixed that problem - we have numerous terminology services using FHIR and interoperating successfully.  We need to be cautious about throwing confusion into that marketplace.

                                      2. Yes, I agree that (at least for now) we would handle concrete domain representation, role chaining, property chaining with implication, and multiple sufficient sets as extensions in FHIR.  Actually, I suspect that the CodeSystem property model (CodeSystem.property and CodeSystem.concept.property) may already be robust enough to handle concrete domains without needing to use extensions.  I don't know if anyone has tested that?  Michael Lawley?  That is also something that if there's sufficient interest we could look at during the Connectathon.

                      2. In order to implement a knowledge base we would also need a Normative resource like ConceptMap (chttp://build.fhir.org/conceptmap.htm) to represent relationships between concepts from different coding systems. We hope our analysis on this model may inform the Normative version of ConceptMap.  We will be able to come up wiht a formal set of requirements for ConceptMap

                        1. ConceptMap can already represent relationships between code systems from different code systems.  You're free to submit change proposals, though there are limitations on the types of changes possible now that the resource is normative.

                          1. ConceptMap is not yet normative. The CI build currently (and incorrectly) indicates that it is at maturity level 3. In fact, due to significant recent changes (specifically moving the equivalence element to relationship), Vocabulary WG voted to change the maturity level to 1 (minutes here), but this change has not yet been made in the FHIR build by Robert Hausam.

                            1. Thanks for the clarification... Reuben Daniels. I was wondering about that ...


                            2. Agreed, the use of ConceptMap to represent the various types of relationships between concepts is still being crafted by Vocab. Progress has been made as Reuben briefly described, and the work completed as part of this project to define the logical architecture will certainly provide some additional insight to help move ConceptMap maturity forward. In addition to providing a platform independent logical model for those who aren't utilizing FHIR.

                            3. Actually, the changes to ConceptMap have now been made (as of early this morning US time) and can be seen here.  It was a pain to do, as expected, but with Grahame's assistance we got it done for the milestone.  So a bit of good news on that front, Reuben Daniels!  And since we're talking about it, I'll mention that I did use some editorial license to change the revised relationship codes as 'broader' → 'source-is-narrower-than-target' and 'narrower' → 'source-is-broader-than-target' (rather than 'source_is_narrower_than_target' and 'source_is_broader_than_target', as approved by Vocab WG and documented in FHIR-25923).

                              1. The resource maturity level is still shown as 3, though.  In the crush of getting the substantive technical changes done and into the milestone build, updating the maturity level missed getting any attention.  Given the substantive but limited changes that were made, I'm not sure what the "proper" maturity level actually is at this point.  That might warrant some additional discussion.  And these changes are now available for testing during the upcoming Connectathon (one of the major goals of getting them into the milestone). 

                          2. ConceptMap is not normative yet - level 3 (but it should 1) and it has undergone significant changes. Vocab WG is working on it... we hope to provide some formal requirements based on the needs of organizations to manage terminology.  BTW, we will also need a series of profiles to represent locally-defined.  modules/extensions

                            Thanks for your feedback!

                            1. All,

                              In today's Vocabulary / FHIR-I "FHIR Trackers" call (FHIR Tracker Issues 2020-05-07 Call Agenda and Minutes) it was agreed that the vote to change of maturity level for ConceptMap from 3 to 1 will be upheld and the associated FHIR JIRA Tracker ( FHIR-25921 - Getting issue details... STATUS ) updated accordingly.


                              The change will be applied to the CI build of FHIR in due course.

                      3. Lloyd McKenzie let me know if this addresses your concerns: "Our goal is to define the logical architecture (i.e. implementation neutral) and then take inventory of the FHIR resources (e.g. CodeSystem, ValueSet, ConceptMap, Basic) and FHIR terminology services to support the implementation of standard-based, integrated terminology knowledge bases, master files, domain specific mapping files, etc. Based on that inventory, this project may develop formal requirements or implementation guides to support standard-based terminology knowledge bases."

                        Thanks, Lloyd!

                        1. The Value Set Definition FHIR Profile (VSDP) project, that aims to provide a resource for implementers to be compliant with both FHIR and the Characteristics of a Value Set Definition normative specification, can also be used in the analysis here to ensure alignment with not only FHIR but with the other terminology related normative specifications. The VSDP project has almost completed a comparitive analysis against the FHIR, and will be creating a FHIR profile. We would welcome collaboration between the projects as some of that work may inform the goals of this one.

              2. We'are actually modeling in EA using UML and will generate the format/db schema from the UML-based logical model. We will not share/exchange - though it will be available in the Github in XMI and available for people who want to use this logical to create Java or other languages supported  by their code generator of choice. Vendors may use this model for their tooling dev if they find it useful. 

  7. Ioana Singureanu , Caroline Macumber , Lloyd McKenzie  Can you all document your final thoughts on the status of this PSS at the ISD voting page please

    1. Rob McClure - I believe the ISD voting page highlights the main edit but other clarifications were added to address how we plan to support platform-specific implementation models for terminology knowledge bases that are based on this Normative logical model.

      1. I think the ISD page is now fine. Just make sure the PSS has all the noted changes. I don't think we should rely upon also reading the comments. 

  8. I'm not sure how a logical model can be 'normative'.  Logical models don't drive implementer behavior...

    The key thing is that the development of implementation models is deferred to a subsequent project (if they're deemed necessary and appropriate).