This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "201801 Terminology Services Track"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "{{subst::Template for FHIR Connectathon Track Proposals}}")
 
(Copy and update of content from Connectathon 16 track proposals)
Line 1: Line 1:
−
 
+
[http://wiki.hl7.org/index.php?title=Category:201801_FHIR_Connectathon_Track_Proposals Return to Jan 2018 Proposals]
 
[[Category:201801_FHIR_Connectathon_Track_Proposals|Jan 2018 Proposals]]
 
[[Category:201801_FHIR_Connectathon_Track_Proposals|Jan 2018 Proposals]]
 
__NOTOC__
 
__NOTOC__
−
=Track Name=
+
=Terminology Services=
  
 
==Submitting WG/Project/Implementer Group==
 
==Submitting WG/Project/Implementer Group==
 
<!-- Who is asking for this track? -->
 
<!-- Who is asking for this track? -->
 +
FHIR Management Group (FMG)
  
 
==Justification==
 
==Justification==
 
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. -->
 
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. -->
 +
The FHIR specification includes support for the provision of a [http://hl7.org/fhir/terminology-service.html 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.
  
−
==Proposed Track Lead==
+
[https://fhirblog.com/2016/09/16/terminology-services/ David Hay's blog post on Terminology Services]
 +
 
 +
==Track Administration==
 
<!-- Name, email and Skype id of individual who will coordinate the track at the connectathon -->
 
<!-- Name, email and Skype id of individual who will coordinate the track at the connectathon -->
−
See [[Connectathon_Track_Lead_Responsibilities]]
+
Coordinator: [mailto:rrhausam@gmail.com Rob Hausam] 
 +
 
 +
Management & Communications: [https://chat.fhir.org/#narrow/stream/connectathon.20mgmt/topic/Connectathon.20Terminology.20Services.20Track Zulip Chat Stream]
 +
 
 +
Test Support: [mailto:richard.ettema@aegis.net Richard Ettema]
 +
 
 +
=='''Terminology Services Track Report'''==
 +
FHIR Connectathon 17 will be held on January 27-28, 2018 in New Orleans.
 +
<br>A link to download the report will be available after the conclusion of the Connectathon.
  
 
==Expected participants==
 
==Expected participants==
 
<!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track -->
 
<!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track -->
 +
*[http://test.fhir.org/r3 Health Intersections - FHIR Server]
 +
*[https://touchstone.aegis.net/touchstone 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
 +
*[https://ontoserver.csiro.au/stu3-latest CSIRO Australia - Ontoserver]
 +
*[[NLM - FHIR services on VSAC]]
 +
*[http://implementation.e-imo.com/fhir/Lexical IMO - FHIR services on IMO ProblemIT/ProcedureIT]
 +
*[http://its.patientsfirst.org.nz/RestService.svc/Terminz Patients First NZ Terminology Server]
 +
*[[Health Language FHIR terminology  services]]
 +
*[http://fhir.hausamconsulting.com/ Hausam Consulting test server]
 +
 +
*Additional servers and clients
  
 
==Roles==
 
==Roles==
−
Please include information here regarding how much advance preparation will be required if creating a client and/or server.
 
 
<!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on -->
 
<!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on -->
−
===Role 1 Name===
+
===FHIR Terminology Server===
 +
<!-- Provide a description of the capabilities this role will have within the connectathon -->
 +
For service providers, implement the following operations from http://hl7.org/fhir/terminology-service.html:
 +
* $expand - [http://hl7.org/fhir/valueset-operations.html#expand Value Set Expansion]
 +
* $validate-code - [http://hl7.org/fhir/valueset-operations.html#validate-code Value Set Validation]
 +
* $lookup - [http://hl7.org/fhir/codesystem-operations.html#lookup Concept Lookup]
 +
* $subsumes - [http://hl7.org/fhir/codesystem-operations.html#subsumes Subsumption Testing]
 +
* $translate - [http://hl7.org/fhir/conceptmap-operations.html#translate Concept Translation]
 +
* $closure - [http://hl7.org/fhir/conceptmap-operations.html#closure Maintaining a Closure Table]
 +
Support additional capabilities:
 +
* Expansion Profile (Maturity Level: 2) - [http://hl7.org/fhir/expansionprofile.html Defining constraints on the Expansion of a FHIR ValueSet]
 +
* SNOMED CT and LOINC implicit value sets - [http://hl7.org/fhir/snomedct.html using SNOMED CT with FHIR] and [http://hl7.org/fhir/loinc.html using LOINC with FHIR]
 +
* $compose - [http://hl7.org/fhir/codesystem-operations.html#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===
 
<!-- Provide a description of the capabilities this role will have within the connectathon -->
 
<!-- Provide a description of the capabilities this role will have within the connectathon -->
 +
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
  
−
==Scenarios==
+
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).
 +
 
 +
==Pre-Requisites==
 +
 
 +
'''For all levels of testing the required pre-requisite is the fundamental requirement that all FHIR servers ''SHALL'' support the [http://hl7.org/fhir/http.html#capabilities capabilities] interaction.'''
 +
 
 +
==Test Scripts==
 +
 
 +
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. Furthermore, none of the Client and Server Assigned Id Test Scripts, used for the $expand and $validate-code operations in previous events, have been carried forward to this Connectathon. The expectation now is that the FHIR Terminology Servers under test will have already downloaded and installed the required resources (Code Systems, Value Sets & Concept Maps).
 +
 +
These resources, and the corresponding TestScripts, will be committed to the FHIR documents Github repository at:
 +
[https://github.com/FHIR/documents/tree/master/connectathons FHIR documents Github repository]
 +
Please contact [mailto:grahame@healthintersections.com.au Graham Grieve] if you require commit privileges to this repository; otherwise, you may forward your TestScripts and related artifacts to [mailto:richard.ettema@aegis.net Richard Ettema] who will get them committed.
 +
 
 +
'''Additional Resources:'''
 +
* [https://github.com/FHIR/documents/blob/master/connectathons/SanDiegoSep2017/Connectathon16/Terminology-Formal/FHIR%20Connectathon%2016%20Terminology%20Formal%20Tests.xlsx Terminology Test Definition Spreadsheet] - Example proposals for Terminology tests (positive and negative) from the Connectathon 16 event held in San Diego
 +
 
 +
==Scenarios & Tasks==
 
<!-- What will be the actions performed by participants? -->
 
<!-- What will be the actions performed by participants? -->
 +
<!-- Provide a description of each task -->
  
−
===Scenario Step 1 Name===
+
===Level 1 - Introduction to Terminology===
−
:Action: <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
−
:Precondition: <!-- What setup is required prior to executing this step? -->
 
−
:Success Criteria: <!-- How will the participants know if the test was successful? -->
 
−
:Bonus point: <!-- Any additional complexity to make the scenario more challenging -->
 
  
−
<!-- Provide a description of each task -->
+
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 publically-available FHIR Terminology Servers listed above.
 +
 
 +
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 [http://hl7.org/fhir/testreport.html 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.
 +
 
 +
====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-16-ts-expand''' - Terminology tests for $expand where the FHIR server is expected to have the existing ValueSet resources for extensional and intensional test cases.
 +
* '''connectathon-16-ts-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.
 +
 
 +
====Test Scripts - CodeSystem Lookup - $lookup====
 +
 
 +
* '''connectathon-16-ts-lookup-loinc''' - $lookup tests where the FHIR Terminology server is expected to have the LOINC  code systems available.
 +
* '''connectathon-16-ts-lookup-snomed''' - $lookup tests where the FHIR Terminology server is expected to have the SNOMED-CT code systems available.
 +
 
 +
====Test Scripts - CodeSystem Subsumes - $subsumes====
 +
 
 +
* '''connectathon-16-ts-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-16-ts-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-16-ts-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-16-ts-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-16-ts-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-16-ts-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-16-ts-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-16-ts-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-16-ts-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-16-ts-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-16-ts-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-16-ts-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.
  
−
==TestScript(s)==
+
====Test Scripts - ValueSet Validate Code - $validate-code====
−
<!-- Optional (for initial proposal): Provide links to the TestScript instance(s) that define the behavior to be tested. 
 
−
These should be committed to SVN under trunk/connectathons/[connectathon]
 
−
-->
 
  
−
==Security and Privacy Considerations==
+
* '''connectathon-16-ts-validate-code''' - $validate-code tests where the FHIR Terminology server is expected to have the LOINC and SNOMED-CT code systems available.
−
<!-- Optional (for initial proposal): Address the topic of Privacy and Security.
+
* '''connectathon-16-ts-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.
−
* What Authentication/Authorization will be used (e.g. SMART on FHIR (OAuth), HEART (UMA/OAuth), IHE IUA (OAuth), generic OAuth, generic SAML, mutual-Auth-TLS), or explicitly indicate that it is out of scope and left to implementations.
 
−
* What Privacy Consent management will be used? When the Consent Resource is used, define how.
 
−
* What Audit Logging will be used? When the AuditEvent Resource is used, define expectations of what events will be logged and what each AuditEvent will contain.
 
−
* How will Provenance be used? Provenance use should be mandated when data is imported from other systems, so as to track that source of that data. Provenance should be used when data is authored by unusual sources, such as the Patient themselves or devices.  
 
−
* How will security-labels be used? Security-labels are meta tags used to classify the data into various confidentiality, sensitivity, and integrity classifications. These security-labels are then available for use and available for access control decisions.
 
−
I am happy to help: JohnMoehrke@gmail.com -- security co-chair
 
−
-->
 

Revision as of 13:56, 17 October 2017

Return to Jan 2018 Proposals

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

Terminology Services Track Report

FHIR Connectathon 17 will be held on January 27-28, 2018 in New Orleans.
A link to download the report will be available after the conclusion of the Connectathon.

Expected participants

  • Additional servers and clients

Roles

FHIR Terminology Server

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
  • 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).

Pre-Requisites

For all levels of testing the required pre-requisite is the fundamental requirement that all FHIR servers SHALL support the capabilities interaction.

Test Scripts

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. Furthermore, none of the Client and Server Assigned Id Test Scripts, used for the $expand and $validate-code operations in previous events, have been carried forward to this Connectathon. The expectation now is that the FHIR Terminology Servers under test will have already downloaded and installed the required resources (Code Systems, Value Sets & Concept Maps).

These resources, and the corresponding TestScripts, will be committed to the FHIR documents Github repository at: FHIR documents Github repository Please contact Graham Grieve if you require commit privileges to this repository; otherwise, you may forward your TestScripts and related artifacts to Richard Ettema who will get them committed.

Additional Resources:

Scenarios & Tasks

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 publically-available FHIR Terminology Servers listed above.

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.

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-16-ts-expand - Terminology tests for $expand where the FHIR server is expected to have the existing ValueSet resources for extensional and intensional test cases.
  • connectathon-16-ts-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.

Test Scripts - CodeSystem Lookup - $lookup

  • connectathon-16-ts-lookup-loinc - $lookup tests where the FHIR Terminology server is expected to have the LOINC code systems available.
  • connectathon-16-ts-lookup-snomed - $lookup tests where the FHIR Terminology server is expected to have the SNOMED-CT code systems available.

Test Scripts - CodeSystem Subsumes - $subsumes

  • connectathon-16-ts-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-16-ts-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-16-ts-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-16-ts-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-16-ts-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-16-ts-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-16-ts-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-16-ts-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-16-ts-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-16-ts-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-16-ts-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-16-ts-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 - ValueSet Validate Code - $validate-code

  • connectathon-16-ts-validate-code - $validate-code tests where the FHIR Terminology server is expected to have the LOINC and SNOMED-CT code systems available.
  • connectathon-16-ts-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.
Retrieved from "https://wiki.hl7.org/w/index.php?title=201801_Terminology_Services_Track&oldid=147638"