Back to testkits
Developer hub
Testkit | FHIR® Terminology
Built-in management for multi-terminology: FHIR-packaged (e.g. from the German terminology server), self-hosted (e.g. imported SNOMED CT subsets and your own in-house value tables), or remote via services such as Snowstorm or Ontoserver.
134 / 134 = 100.0 %Community compliance
✓ 21 Passed✕ 0 Failed
- ✓ Should support creating and reading terminology resources
- ✓ Should support SEARCH interaction for terminology resources
- ✓ Should support all required search parameters for terminology resources
- ✓ Should support capabilities interaction with absent mode parameter
- ✓ Should support capabilities interaction with mode=full parameter
- ✓ Should support capabilities interaction with mode=terminology parameter
- ✓ Should support required RESTful API capabilities for terminology services
- ✓ Should support required terminology operations
- ✓ Should support XML and JSON formats for terminology resources
- ✓ Should support CodeSystem $lookup operation with required parameters
- ✓ Should support CodeSystem $validate-code operation with required parameters
- ✓ Should support CodeSystem $subsumes operation with required parameters
- ✓ Should support searching CodeSystems by standard search parameters
- ✓ Should support ValueSet $expand operation with required parameters
- ✓ Should support ValueSet $validate-code operation with required parameters
- ✓ Should support searching ValueSets by standard search parameters
- ✓ Should support instance-level ConceptMap $translate operation with GET
- ✓ Should support type-level ConceptMap $translate operation using url parameter
- ✓ Should support ConceptMap $translate with POST using Coding
- ✓ Should handle invalid codes in ConceptMap $translate operation
- ✓ Should support searching ConceptMaps by standard search parameters
✓ 18 Passed✕ 0 Failed
- ✓ Should support CodeSystem-lookup operation with required parameters
- ✓ CodeSystem validate-code should return true for valid code and display using POST
- ✓ CodeSystem validate-code should return false when display text doesn't match code
- ✓ CodeSystem validate-code should return false for non-existent code using GET
- ✓ CodeSystem validate-code should validate valid code and display using GET parameters
- ✓ Should support CodeSystem-subsumes operation with required parameters
- ✓ ValueSet-expand should return full expansion via POST when given a ValueSet URL
- ✓ ValueSet-expand should filter results when filter parameter is provided
- ✓ ValueSet-expand should return full expansion via GET when given a ValueSet URL
- ✓ Should support ValueSet-expand operation at instance level
- ✓ ValueSet-validate-code should return true for valid code and display via GET
- ✓ ValueSet-validate-code should return false for non-existent code
- ✓ ValueSet-validate-code should return 400 when required parameters are missing
- ✓ ValueSet-validate-code should validate code via POST
- ✓ ConceptMap-translate should translate valid source code to target code via POST
- ✓ ConceptMap-translate should return false for non-existent source code via GET
- ✓ ConceptMap-translate should translate valid source code via GET parameters
- ✓ Should support the FHIR Terminology Service required operations set
✓ 3 Passed✕ 0 Failed
- ✓ Should use HTTPS for secure transport when SSL is available
- ✓ Should enforce authorization for terminology creation if required
- ✓ Should support editing terminology resources with proper authorization
✓ 2 Passed✕ 0 Failed
- ✓ Should support the basic terminology resources (CodeSystem, ValueSet, ConceptMap)
- ✓ Should support basic searching for terminology resources
✓ 3 Passed✕ 0 Failed
- ✓ Should expose supported external code systems in CapabilityStatement
- ✓ Should support ValueSets that reference standard external code systems
- ✓ Should allow creating custom CodeSystems alongside external ones
✓ 5 Passed✕ 0 Failed
- ✓ Should expose metadata about supported external code systems
- ✓ Should provide information about valid codes in external terminologies
- ✓ Should handle implicit value sets for external terminologies
- ✓ Should expose properties for code selection in external terminologies
- ✓ Should allow creating and using custom CodeSystems alongside external ones
✓ 6 Passed✕ 0 Failed
- ✓ Should validate incoming CodeSystem resources for integrity
- ✓ Should reflect changes to terminology resources in operational outcomes
- ✓ Should maintain referential integrity when deleting terminology resources
- ✓ Should validate terminology resources against canonical schemas
- ✓ Should check for duplicate concept codes during CodeSystem updates
- ✓ Should reflect versioning changes in CodeSystem lookups
✓ 7 Passed✕ 0 Failed
- ✓ Should expand a value set using its logical id
- ✓ Should expand a value set using its canonical URL
- ✓ Should expand a value set directly provided as a parameter
- ✓ Should filter value set expansion based on text input
- ✓ Should support paging in value set expansion
- ✓ Should support date-based expansion for value sets
- ✓ Should handle value set expansion with additional parameters
✓ 10 Passed✕ 0 Failed
- ✓ Should create a code system with hierarchical concepts for lookup tests
- ✓ Should support CodeSystem-lookup with GET method for a code
- ✓ Should support CodeSystem-lookup with POST method using a coding
- ✓ Should support system-level CodeSystem-lookup with GET method
- ✓ Should support system-level CodeSystem-lookup with POST method
- ✓ Should support requesting specific properties with CodeSystem-lookup
- ✓ Should support retrieving designations with CodeSystem-lookup
- ✓ Should support looking up non-existent codes
- ✓ Should support version-specific CodeSystem-lookup
- ✓ Should return hierarchical relationships with CodeSystem-lookup
✓ 9 Passed✕ 0 Failed
- ✓ Should create a code system with multilingual concepts for standard lookup properties tests
- ✓ Should return the standard 'name' property in lookup response
- ✓ Should return the standard 'version' property in lookup response
- ✓ Should return the standard 'display' property in lookup response
- ✓ Should return the standard 'designation' property in lookup response
- ✓ Should return language-specific designations
- ✓ Should return CodeSystem-defined properties in lookup response
- ✓ Should handle lookup with all standard property types together
- ✓ Should return appropriate properties for inactive concepts
✓ 12 Passed✕ 0 Failed
- ✓ Should create a code system and value set for validation tests
- ✓ Should validate a valid code against a value set using GET
- ✓ Should validate an invalid code against a value set using GET
- ✓ Should validate a valid code with incorrect display using GET
- ✓ Should validate a code against a value set using POST with a Coding
- ✓ Should validate a code against a value set using POST with a CodeableConcept
- ✓ Should validate a CodeableConcept with multiple codes using POST
- ✓ Should validate a code against a value set using type-level operation
- ✓ Should validate a code against the implicit value set of a code system
- ✓ Should validate a code against a client-supplied value set using POST
- ✓ Should validate a non-existent code against a value set
- ✓ Should validate a code in a value set with correct response details
✓ 12 Passed✕ 0 Failed
- ✓ Should create a code system with hierarchical relationships for subsumption testing
- ✓ Should test 'subsumes' relationship using GET method
- ✓ Should test 'subsumed-by' relationship using GET method
- ✓ Should test 'equivalent' relationship using GET method
- ✓ Should test 'not-subsumed' relationship using GET method
- ✓ Should test subsumption using POST with codes
- ✓ Should test subsumption using POST with codings
- ✓ Should test subsumption at type level with system parameter
- ✓ Should test subsumption with version parameter
- ✓ Should test subsumption with multi-hierarchical relationship
- ✓ Should handle invalid codes in subsumption testing
- ✓ Should handle codings with different systems
✓ 5 Passed✕ 0 Failed
- ✓ Should create code systems and value sets for batch validation tests
- ✓ Should validate multiple concepts in a batch with GET requests
- ✓ Should validate multiple concepts in a batch with POST requests
- ✓ Should validate a mix of valid and invalid codes in a batch
- ✓ Should validate codes against client-supplied value sets in a batch
✓ 10 Passed✕ 0 Failed
- ✓ Should create code systems, value sets, and concept map for translation tests
- ✓ Should translate a code using GET with a concept map URL
- ✓ Should translate a code using GET with source and target value sets
- ✓ Should translate a code using POST with a Coding
- ✓ Should translate a code using POST with a CodeableConcept
- ✓ Should translate a code using instance-level ConceptMap operation
- ✓ Should handle translation of non-existent codes
- ✓ Should handle translation from target back to source code
- ✓ Should handle translation with explicit target system specification
- ✓ Should handle translation with POST using client-supplied ConceptMap
✓ 4 Passed✕ 0 Failed
- ✓ Should create test resources for batch translation tests
- ✓ Should support batch translation of multiple concepts
- ✓ Should handle batch translation with invalid concept codes
- ✓ Should handle batch translation with invalid ConceptMap references
✓ 7 Passed✕ 0 Failed
- ✓ Should create test CodeSystem with hierarchical relationships for closure table tests
- ✓ Should initialize a closure table
- ✓ Should add a single concept to the closure table
- ✓ Should add multiple concepts to the closure table
- ✓ Should re-sync the closure table using version
- ✓ Should return an error for invalid closure table name
- ✓ Should support complete re-sync of the closure table using version 0