201709 Terminology Services Track
Terminology Services
Submitting WG/Project/Implementer Group
FHIR Management Group (FMG)
Justification
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 set resource, and the underlying code systems. 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.
David Hay's blog post on Terminology Services
Track Administration
Coordinator: Rob Hausam
Management & Communications: Zulip Chat Stream
Test Support: Richard Ettema
Expected participants
- Health Intersections - FHIR Server
- AEGIS - Touchstone tool and test scripts
- Apelon - Terminology Server (uid/pwd dtsadminuser/dtsadmin): http://fhir.ext.apelon.com/dtsserverws/fhir
- Lantana - FHIR services on Trifolia
- CSIRO Australia - Ontoserver
- NLM - FHIR services on VSAC
- IMO - FHIR services on IMO ProblemIT/ProcedureIT
- Patients First NZ Terminology Server
- Health Language FHIR terminology services (new)
- Hausam Consulting test server
- Additional servers and clients
Roles
FHIR Terminology Server
For service providers, implement the following operations from http://hl7.org/fhir/terminology-service.html:
- $expand - Value Set Expansion
- $validate-code - Value Set Validation
- $lookup - Concept Lookup
- $subsumes - Subsumption Testing
- $translate - Concept Translation
- $closure - Maintaining a Closure Table
Support additional capabilities:
- Expansion Profile (Maturity Level: 2) - Defining constraints on the Expansion of a FHIR ValueSet
- SNOMED CT and LOINC implicit value sets - using SNOMED CT with FHIR and using LOINC with FHIR
- $compose - Code Composition based on supplied properties (experimental)
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
- 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
- Experiment with the capabilities of the expansion profile (see description above of the expected capabilities and scenarios)
- 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/r3). Other servers, including the Apelon server (http://fhir.ext.apelon.com/dtsserverws/fhir) and the others listed above will support several of these operations and capabilities. For a list of functions supported by the Apelon Server, see the demo web app (http://fhir.ext.apelon.com/DtsOnFhirDemo, uid/pwd dtsadminuser/dtsadmin).
Scenarios
Scenarios - See server and client roles as listed above
Pre-Requisites
For all levels of testing the required pre-requisite is the fundamental requirement that all FHIR servers SHALL support the capabilities interaction.
TestScripts
Starting with the Connectathon 16 event in San Diego this track now includes additional levels of testing that introduce more formalized execution and reporting of test results.
Level 1 - Introduction to Terminology
This has been and will remain the primary purpose of this track and provides a 'friendly introduction' for those new to Terminology Track in FHIR. Attendees participate in this track using a simple scenario that can be met with limited domain knowledge. It is quite feasible to complete the client side terminology interaction of the track within a day with only knowledge of a development environment and some previous FHIR knowledge (such as Patient). If creating a server, advanced preparation will be required.
Pre-connectathon testing is encouraged, but not required, where the participants can utilize the existing Publicly_Available_FHIR_Servers_for_testing.
Testing and test reporting at the Connectathon event will be self-attested using the Results tab of the Tracking Spreadsheet (link TBD) and primarily involve peer-to-peer execution between known FHIR clients and/or servers.
Level 2 - Formal Testing of Terminology - Participants with FHIR experience
(Level 1 +) This level 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 is significantly leveraged for both automated testing (testing tool to FHIR 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 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.
The supporting TestScripts and corresponding fixtures have been committed to the FHIR SVN repository at:
http://gforge.hl7.org/gf/project/fhir/scmsvn/?action=browse&path=%2Ftrunk%2Fconnectathons%2FMadridMay2017%2FConnectathon15%2FTerminology%2F
[Will be updated for San Diego]