Short Description

Terminology, and the proper use of it, is fundamental for everything that we do in FHIR.  The purpose of this track is to test and enhance the capabilities of FHIR Terminology Services and promote their use throughout the FHIR implementation community.

In Connectathon 31, Terminology Services testing will include scenarios supporting Gender Harmony code systems and value sets. Participants in this track will test improved FIHR extensions to communicate detailed clinical sex, gender identity , and other elements as defined in the Gender Harmony specification.

Long Description

The FHIR specification includes support for the provision of a terminology service - that is, a service that lets healthcare applications make use of codes and value sets without having to become experts in the fine details of the value sets and underlying code systems and their related resources. The management and proper use of terminology is fundamental to effective, interoperable data exchange, so this is an important capability to provide and test in the Connectathons.  We expect and hope to achieve: (1) improved capabilities of terminology servers measured by testing performance, (2) improved and more extensive terminology service testing, (3) implementation and implementer experience with aspects of the terminology services specifications, including experience with newer and previously lesser used terminology service operations and operation capabilities, (4) identify potential improvements as well as deficiencies and possibly errors in the FHIR terminology service specifications based on implementation and testing experience, and (5) increased awareness and utilization of terminology services by other Connectathon tracks.

David Hay's blog post on Terminology Services

The Gender Harmony component of this track pertains to a cross-paradigm implementation guide describing how FHIR, V2 and CDA can be used to represent Gender Identity, Sex For Clinical Use, Recorded Sex or Gender, Name to Use, and Pronouns using transformable and consistent data elements as described in the HL7 informative Gender Harmony specification. Examples and minimum value sets will be included. FHIR R5 extensions have been defined to represent each of the above concepts. These data elements are now included in USCDI, and other realm specific data requirements.

Please note:  the Gender Harmony portion of this track can be found under a separate page here

Type

Test the design of a Resource/set of Resources associated with FHIR Terminology Services

Track Prerequisites

Bring a draft IG that uses terminology content or a FHIR Terminology Server to test.  All others: familiarity with ConMan and the Touchstone suite of test (listed below) is required. 

Track Lead(s)

Davera Gabriel 

Track Lead Email(s)

dgabrie4@jhmi.edu

Specification Information

FHIR Terminology Services

http://hl7.org/fhir/terminology-service.html (R4 Terminology Services)

http://build.fhir.org/conceptmap.html (proposed R5 changes to ConceptMap)

https://www.hl7.org/fhir/terminologycapabilities.html (Terminology Capabilities)

Call for participants

FHIR Terminology Services: IG developers or systems implementers that require utilization terminological content (Code systems, codes, maps or value sets) with FHIR

Zulip stream

https://chat.fhir.org/#narrow/stream/312007-Terminology-Services-Connectathon

Track Kick off Call

Recording can be found here

Slides can be found here



Related Tracks?Clinical Reasoning

Testing Scenario:

For service providers, implement the following operations from http://hl7.org/fhir/terminology-service.html:

Support additional capabilities:

Service providers are not required to implement all of this functionality - it's a lot to do. For new implementers, start at the top and work down (generally).

FHIR Terminology Client Consumer

Implement any one or more of:

  • Do a value set expansion of one of the value sets in the spec
  • Validate a code using the spec against a FHIR value set, a v2 value set, LOINC or SNOMED CT
  • Validate a code using the spec against a code system such as LOINC or SNOMED CT
  • Look up a display for a code (most appropriate for v2/FHIR conversion)
  • Translate a code from one value set to another, based on the existing value set and ConceptMap resources, and/or other additional knowledge available to the server
  • Maintain a client-side closure table based on server-side terminological logic
  • References to SNOMED CT and LOINC implicit value sets
  • Create (POST, PUT) ValueSet resources referencing in-line and/or external code systems

At least one server supports all of these operations and capabilities (http://test.fhir.org/r5). Other servers (see the list below) will support several of these operations and capabilities.

CSIRO's Ontoservers - R4: https://r4.ontoserver.csiro.au/fhir / R5 (in alpha): https://ontoserver-r5.australiaeast.cloudapp.azure.com/fhir

    • Supports Terminology Services
    • CodeSystem, ValueSet, ConceptMap, StructureDefinition, and Bundle with read, create, update, delete, search
    • $expand, $lookup, $subsumes, $validate-code, $validate, $closure, $translate, and $batch
    • Specialized support for SNOMED CT, and LOINC
    • Supports NamingSystem and the $find-matches and $preferred-id operations.

HL7 New Zealand Terminz - R4: https://terminz.azurewebsites.net/fhir

  • Supports Terminology Services (passes all Touchstone Terminology Service Tests for C31)
  • CodeSystem, ValueSet, ConceptMap, NamingSystem, TerminologyCapabilities with read & search
  • $expand, $lookup, $validate-code, $subsumes, $closure, $translate, $preferred-id & $translate-id (custom operation for R4)
  • Contains latest versions of SNOMED CT (NZ Edition & IPS) and LOINC (2.73)

Hausam Consulting Server (R4): https://fhir.hausamconsulting.com/r4 

  • Terminology Servers as well as a general-purpose HAPI FHIR server

Scenarios

1 - Testing Proposed ConceptMap R5 Changes 

For FHIR R5 significant changes have been made to the ConceptMap resource, including:

  1. Replace the previous 'equivalence' element with a new 'relationship' element.
  2. Revise the concept-map-relationship (previously concept-map-equivalence) code system and value set so that the codes are easier and simpler to understand and choose and so that the mapping relationship direction is clearly specified.
  3. Related changes to the $translate and $closure operations based on the above code changes. 
  4. Updates to group.element.target.dependsOn and group.element.target.product

Connectathon testing and implementation experience is needed to progress the revised ConceptMap resource through the maturity levels toward normative status.  

2 - Formal Testing of Terminology - Participants with FHIR experience

This scenario introduces a more formalized testing approach for those participants that have been working the FHIR Terminology specification and wish to move beyond basic testing and may have systems that are in active development, deployed or soon to be deployed into a production environment. Automated testing tooling is significantly leveraged for both automated terminology server testing (testing tool to FHIR terminology server) and surveillance of peer-to-peer testing (external FHIR client to external FHIR server).

Pre-connectathon testing is highly encouraged in order to be better prepared for the actual Connectathon event and to become familiar with the public testing platforms that will be used for the formal testing.

Testing and test reporting will be done using the public testing platforms which will provide test results via the new FHIR TestReport resource type as well as any specific reporting capabilities of those testing platforms. These reports will provide qualitative and quantitative analysis of the system under test and its conformance to the FHIR specification.

3 - NamingSystem $translate-id proposed operation testing (R5)

Executing the use of the NamingSystem resource in and with FHIR terminology services and its applications in profiles and IGs, testing the $translate-id operation functionality

4 - Minimum Capabilities for a Terminology Server

A FHIR Terminology Server should be able to support a minimum set of capabilities (behaviors).  This activity will provide the opportunity to test whether a terminology server's capability statement is conformant to the minimum set of requirements as established by a vocabulary WG task force described here.  As a first step to developing a complete profile and test scenario for minimum Terminology Server capabilities, the $implements on the CapabilityStatement resource is leveraged.   Resource testing can be achieved via a POST to https://terminz.azurewebsites.net/fhir/CapabilityStatement/$implements with a CapabilityStatement resource.  An OperationOutcome resource with a series of issue elements of varying types will be returned.  This server is configured to accommodate the capabilities identified by the task force for a minimum Terminology Server as referenced above. 

TestScript(s):

This track includes formal testing and reporting of test results utilizing a defined set of test scripts.

AEGIS Touchstone TestScripts will be available for Connectation 31.  Please email Touchstone_Support@aegis.net for any questions about using Touchstone.

Available  Connectathon 31 Test Script Sets

The test scripts listed below have been updated for Connectathon 30 and scripts for additional tests may be added. 

Test Scripts - Supported Formats

  • JSON - TestScripts and fixtures are available under the JSON Format folder
  • XML - TestScripts and fixtures are available under the XML Format folder

Test Scripts - ValueSet Expand - $expand

  • connectathon-31-terminology-expand - Terminology tests for $expand where the FHIR server is expected to have the existing ValueSet resources for extensional and intensional test cases.
  • connectathon-31-terminology-expand-filter - Terminology tests for $expand with filter options where the FHIR server is expected to have the existing ValueSet resources for extensional and intensional test cases.
  • terminology-31-expand-version-extensional1-01-ok  - $expand operation with a valid version parameter test for ValueSet extensional-case-1 where the expected outcome is a successful response.
  • terminology-31-expand-version-extensional1-02-notok - $expand operation with an invalid version parameter test for ValueSet extensional-case-1 where the expected outcome is a failure response with a returned OperationOutcome.

Test Scripts - CodeSystem Lookup - $lookup

  • connectathon-31-terminology-lookup-loinc-01-ok-get-simple - CodeSystem $lookup simple tests against known LOINC codes where the expected outcome is a successful response with valid name and display value. All $lookup operations are performed using the FHIR Operation Framework HTTP GET method.
  • connectathon-31-terminology-lookup-loinc-02-ok-post-code-simple - CodeSystem $lookup simple tests against known LOINC codes where the expected outcome is a successful response with valid name and display value. All $lookup operations are performed using the FHIR Operation Framework HTTP POST method with Parameters of system and code.
  • connectathon-31-terminology-lookup-loinc-03-ok-post-coding-simple - CodeSystem $lookup simple tests against known LOINC codes where the expected outcome is a successful response with valid name and display value. All $lookup operations are performed using the FHIR Operation Framework HTTP POST method with Parameters of coding.
  • connectathon-31-terminology-lookup-sct-01-ok-get-simple - CodeSystem $lookup simple tests against known SNOMED codes where the expected outcome is a successful response with valid name and display value. All $lookup operations are performed using the FHIR Operation Framework HTTP GET method.
  • connectathon-31-terminology-lookup-sct-02-ok-post-code-simple - CodeSystem $lookup simple tests against known SNOMED codes where the expected outcome is a successful response with valid name and display value. All $lookup operations are performed using the FHIR Operation Framework HTTP POST method with Parameters of system and code.
  • connectathon-31-terminology-lookup-sct-03-ok-post-coding-simple - CodeSystem $lookup simple tests against known SNOMED codes where the expected outcome is a successful response with valid name and display value. All $lookup operations are performed using the FHIR Operation Framework HTTP POST method with Parameters of coding.

Test Scripts - CodeSystem Subsumes - $subsumes

  • connectathon-31-terminology-subsumes-snomed-01-ok-get - $subsumes tests against known SNOMED codes where the expected outcome is a successful response with a valid outcome code value. All $subsumes operations are performed using the FHIR Operation Framework HTTP GET method.
  • connectathon-31-terminology-subsumes-snomed-02-ok-post-code - $subsumes tests against known SNOMED codes where the expected outcome is a successful response with a valid outcome code value. All $subsumes operations are performed using the FHIR Operation Framework HTTP POST method with Parameters of system, codeA and codeB.
  • connectathon-31-terminology-subsumes-snomed-03-ok-post-coding - $subsumes tests against known SNOMED codes where the expected outcome is a successful response with a valid outcome code value. All $subsumes operations are performed using the FHIR Operation Framework HTTP POST method with Parameters of system, codingA and codingB.
  • connectathon-31-terminology-subsumes-snomed-04-notok-get - $subsumes tests against known and unknown SNOMED codes where the expected outcome is a failure response with a returned OperationOutcome. All $subsumes operations are performed using the FHIR Operation Framework HTTP GET method.
  • connectathon-31-terminology-subsumes-snomed-05-notok-post-code - $subsumes tests against known and unknown SNOMED codes where the expected outcome is a failure response with a returned OperationOutcome. All $subsumes operations are performed using the FHIR Operation Framework HTTP POST method with Parameters of system, codeA and codeB.
  • connectathon-31-terminology-subsumes-snomed-06-notok-post-coding - $subsumes tests against known and unknown SNOMED codes where the expected outcome is a failure response with a returned OperationOutcome. All $subsumes operations are performed using the FHIR Operation Framework HTTP POST method with Parameters of system, codingA and codingB.

Test Scripts - CodeSystem Translate - $translate

  • connectathon-31-terminology-translate-01-ok-get - $translate tests against known FHIR code systems where the expected outcome is a successful response with a matched code value from the target system. All $translate operations are performed using the FHIR Operation Framework HTTP GET method.
  • connectathon-31-terminology-translate-02-ok-post-code - $translate tests against known FHIR code systems where the expected outcome is a successful response with a matched code value from the target system. All $translate operations are performed using the FHIR Operation Framework HTTP POST method with Parameters of system, codeA and codeB.
  • connectathon-31-terminology-translate-03-ok-post-coding - $translate tests against known FHIR code systems where the expected outcome is a successful response with a matched code value from the target system. All $translate operations are performed using the FHIR Operation Framework HTTP POST method with Parameters of system, codingA and codingB.
  • connectathon-31-terminology-translate-04-notok-get - $translate tests against known and unknown FHIR code systems where the expected outcome is a failure response with a returned OperationOutcome. All $translate operations are performed using the FHIR Operation Framework HTTP GET method.
  • connectathon-31-terminology-translate-05-notok-post-code - $translate tests against known and unknown FHIR code systems where the expected outcome is a failure response with a returned OperationOutcome. All $translate operations are performed using the FHIR Operation Framework HTTP POST method with Parameters of system, codeA and codeB.
  • connectathon-31-terminology-translate-06-notok-post-coding - $translate tests against known and unknown FHIR code systems where the expected outcome is a failure response with a returned OperationOutcome. All $translate operations are performed using the FHIR Operation Framework HTTP POST method with Parameters of system, codingA and codingB.

Test Scripts - CodeSystem Validate Code - $validate-code

  • connectathon-31-terminology-validate-cs-loinc-01-ok-get - $validate-code tests against known LOINC codes where the expected outcome is a successful response using the FHIR Operation Framework HTTP GET method.
  • connectathon-31-terminology-validate-cs-loinc-02-ok-post-code - $validate-code tests against known LOINC codes where the expected outcome is a successful response using the FHIR Operation Framework HTTP POST method with Parameters of url, code and display.
  • connectathon-31-terminology-validate-cs-loinc-03-ok-post-coding - $validate-code tests against known LOINC codes where the expected outcome is a successful response using the FHIR Operation Framework HTTP POST method with Parameters of url and coding.
  • connectathon-31-terminology-validate-cs-loinc-04-notok-get - $validate-code tests against known LOINC codes where the expected outcome is a failure response using the FHIR Operation Framework HTTP GET method.
  • connectathon-31-terminology-validate-cs-loinc-05-notok-post-code - $validate-code tests against known LOINC codes where the expected outcome is a failure response using the FHIR Operation Framework HTTP POST method with Parameters of url, code and display.
  • connectathon-31-terminology-validate-cs-loinc-06-notok-post-coding - $validate-code tests against known LOINC codes where the expected outcome is a failure response using the FHIR Operation Framework HTTP POST method with Parameters of url and coding.
  • connectathon-31-terminology-validate-cs-sct-01-ok-get - $validate-code tests against known SNOMED-CT codes where the expected outcome is a successful response using the FHIR Operation Framework HTTP GET method.
  • connectathon-31-terminology-validate-cs-sct-02-ok-post-code - $validate-code tests against known SNOMED-CT codes where the expected outcome is a successful response using the FHIR Operation Framework HTTP POST method with Parameters of url, code and display.
  • connectathon-31-terminology-validate-cs-sct-03-ok-post-coding - $validate-code tests against known SNOMED-CT codes where the expected outcome is a successful response using the FHIR Operation Framework HTTP POST method with Parameters of url and coding.
  • connectathon-31-terminology-validate-cs-sct-04-notok-get - $validate-code tests against known SNOMED-CT codes where the expected outcome is a failure response using the FHIR Operation Framework HTTP GET method.
  • connectathon-31-terminology-validate-cs-sct-05-notok-post-code - $validate-code tests against known SNOMED-CT codes where the expected outcome is a failure response using the FHIR Operation Framework HTTP POST method with Parameters of url, code and display.
  • connectathon-31-terminology-validate-cs-sct-06-notok-post-coding - $validate-code tests against known SNOMED-CT codes where the expected outcome is a failure response using the FHIR Operation Framework HTTP POST method with Parameters of url and coding.

Test Scripts - ValueSet Validate Code - $validate-code

  • connectathon-31-terminology-validate-code - $validate-code tests where the FHIR Terminology server is expected to have the LOINC and SNOMED-CT code systems available.
  • connectathon-31-terminology-validate-code-optional - $validate-code tests with optional invocations where the FHIR Terminology server is expected to have the LOINC and SNOMED-CT code systems available.

Test Scripts - NamingSystem Preferred ID - $preferred-id

  • connectathon-31-terminology-preferred-id  - $preferred-id tests against the example NamingSystem resource in the R4 specification namingsystem-example.xml. All $preferred-id operations are performed using the FHIR Operation Framework HTTP GET method.
  • connectathon-31-terminology-preferred-id-optional - $preferred-id tests against the example NamingSystem resource in the R4 specification namingsystem-example.xml. All $preferred-id operations are performed using the FHIR Operation Framework HTTP POST method with Parameters of id and type

The AEGIS Touchstone testing tool has test scripts available for tracks to test their implementations. See www.touchstone.com to sign in our register if you are a new user.  Below, you will find a link to the tests specific to this HL7 track. Please send questions or issues to touchstone_support@aegis.net and a team member will be glad to assist you.  Terminology Tests for Connectathon 30 are found here:   Terminology Tests in Touchstone

Terminology Server Security and Privacy Considerations:

Most FHIR terminology terminology service endpoints are open (at present).  This may change in the future as adoption and implementation experience increases in order to more directly manage external (non-HL7) terminology licensing considerations.  Some servers do allow or require authentication (e.g. Apelon - see above).