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
May 2021 Ballot
- Informative 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
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
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
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
8
Modifier
Jessica Bota
Modify Date
Nov 12, 2020 16:31
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
May 2021 Ballot
- Informative 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
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
Informative
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
7
Modifier
Jessica Bota
Modify Date
Nov 06, 2020 15:52
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
May 2021 Ballot
- Informative 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
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
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
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
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
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
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
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
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)
(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.
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.
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...
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
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".
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.
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.
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.
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.
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 arbitrarydescriptors in FHIR but we don't want to use arbitrary but standard-based descriptors.
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).
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?
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.,
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?
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.
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.
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.
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.
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."
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?
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).
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.
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.
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.
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.
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.
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.
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.
Our logical model is intended to be reused in the same way as Gender Harmonize: Files are a form of persistence too 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.
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.
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.
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.
How do you handle concrete domain representation, role chaining, property chaining with implication, and multiple sufficient sets with a FHIR terminology resource?
I expect for most of those, via extensions - which is how most sophisticated, non-commonly used capabilities are implemented. Grahame GrieveRobert Hausam?
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.
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.
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.
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.
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.
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.
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.
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).
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).
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
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.
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."
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.
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.
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.
64 Comments
Caroline Macumber
ISO Standards to consider - https://www.iso.org/standard/32881.html, https://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
Caroline Macumber
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.
Michael Lawley
The UMLS model would also seem to be relevant for review.
Ioana Singureanu
It is indeed.
Michael Lawley
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.
Ioana Singureanu
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...
Lloyd McKenzie
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
Ioana Singureanu
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".
Lloyd McKenzie
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.
Ioana Singureanu
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.
Lloyd McKenzie
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.
Ioana Singureanu
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.
Lloyd McKenzie
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.
Ioana Singureanu
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.
Lloyd McKenzie
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).
Lloyd McKenzie
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?
Ioana Singureanu
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.,
Lloyd McKenzie
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?
Ioana Singureanu
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.
Lloyd McKenzie
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.
Keith E. Campbell
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.
Lloyd McKenzie
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.
Keith E. Campbell
We will work on language revisions that communicate this basic sentiment.
Ioana Singureanu
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."
Rob McClure
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?
Keith E. Campbell
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).
Lloyd McKenzie
If we can incorporate that language into the PSS, I'd be much happier voting to approve.
Keith E. Campbell
We will work to incorporate this language into the PSS.
Ioana Singureanu
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.
Lloyd McKenzie
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.
Ioana Singureanu
We talking format/schema for exchanging/storing terminology knowledge bases containing integrated concepts.. Does this work?
Lloyd McKenzie
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.
Ioana Singureanu
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.
Lloyd McKenzie
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.
Ioana Singureanu
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.
Lloyd McKenzie
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.
Ioana Singureanu
Our logical model is intended to be reused in the same way as Gender Harmonize: Files are a form of persistence too
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.
Lloyd McKenzie
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.
Ioana Singureanu
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.
Lloyd McKenzie
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.
Keith E. Campbell
How do you handle concrete domain representation, role chaining, property chaining with implication, and multiple sufficient sets with a FHIR terminology resource?
Lloyd McKenzie
I expect for most of those, via extensions - which is how most sophisticated, non-commonly used capabilities are implemented. Grahame Grieve Robert Hausam?
Grahame Grieve
I don't know what all those things actually are. I'd have to see detailed analysis to have any opinion
Keith E. Campbell
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.
Lloyd McKenzie
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.
Robert Hausam
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.
Ioana Singureanu
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.
Lloyd McKenzie
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.
Reuben Daniels
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.
Ioana Singureanu
Thanks for the clarification... Reuben Daniels. I was wondering about that ...
Caroline Macumber
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.
Robert Hausam
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).
Robert Hausam
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).
Ioana Singureanu
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!
Reuben Daniels
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.
Ioana Singureanu
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!
Lloyd McKenzie
That works
Caroline Macumber
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.
Ioana Singureanu
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.
Rob McClure
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
Ioana Singureanu
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.
Rob McClure
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.
Lloyd McKenzie
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).
Anne Wizauer
TSC approved 2020-05-18 via e-vote
Project Approval Request for Guidelines for a Standardized Terminology Knowledge Base