A number of HL7 affiliates or associates would like to make terminology content that they own and manage available to the FHIR validation and IG publication system. Such requests might come from:
- HL7 affiliates
- national services such as VSAC or Australia's NCTS
- other SDOs such as DICOM, IHE
- design services such as simplifier
- business such as IMO
In principle, terminology content (CodeSystems, ValueSets, and ConceptMaps) can be made available to the FHIR ecosystem in the following ways:
- publish the terminology through HL7 - this means, make a change request through the UTG system to get the content published on http://terminology.hl7.org. Content published through terminology.hl7.org is available across the entire ecosystem automatically - users don't need to do anything for that
- publish a package containing the value set and code system definitions into the FHIR NPM package system. Users reference the package, and all the content is automatically available when they do. To publish a package to the FHIR ecosystem, either:
- register the package in an RSS feed listed in https://github.com/FHIR/ig-registry/blob/master/package-feeds.json
- author a project on simplifier and publish it
- Provide a terminology server, and declare it's availability to the FHIR tools. Content hosted on these terminology servers will automatically be available to all users in the FHIR eco-system. Note that these servers can require user tokens to protect their content (see below)
- Ask one of the maintainers of tx.fhir.org to make your content available directly by some other means (currently: email@example.com)
The rest of this page documents the third option: providing a terminology server for the wider use of the FHIR community.
Providing a terminology server for the FHIR ecosystem
Services made available to the FHIR community in this way are only intended to be used for design time tooling, not operational health services. Whatever SLA they are made available under can and should exclude use for supportin operational health services.
Requirements for the service
The service must host a FHIR terminology service. At least R4 or R5 must be supported. It's server discretion whether to support R3, or R5. The validator and IG publisher will happily interoperate with either an R4 or R5 server irrespective of the version it's working with. Choose R5 if the new features on ConceptMap are compelling.
The service must support:
- read on CodeSystem, ValueSet, and ConceptMap
- search on CodeSystem, ValueSet, and ConceptMap by canonical URL
- $expand, $validate-code, $lookup (if code systems are hosted), and $translate (if ConceptMaps are hosted). $subsumes is highly recommended but not required
- support for $validate-code in a batch (potentially very large number)
Services may provide operation support for implicit value sets and code systems that are not available through read/search
- All CodeSystems, ValueSets, and ConceptMaps must be have an associated URL at which a user with a browser can read the definition of the artifact. This should be a human readable web page that describes the artifact of the type that FHIR implementation guides provide (note that the specific presentation used by the IG guides is not required). The page must include a link/method for the user to download the raw definition of the resource. This URL must known for each resource. If it is not algorithmically determined (see below), then it must be specifically identified in the Resource when the resource is accessed (see below).
- The service is assumed to be the source of truth and trusted expansions for terminology artifacts as defined by the registry (todo: provide link), but it can use the trusted-expansion-source to indicate another service that is the trusted-expansion-source but this will be ignored by FHIR tools unless it's also a registered server
|$expand||see https://github.com/FHIR/fhir-test-cases/blob/master/tx/requirements.md for details|
|$translate||to be determined at this point|
The service may require users to authenticate. If the service requires authentication, it must be in the form of basic authentication (username/password) or an authentication header - usually a bearer token - that the user can determine in advance, and then provide to their FHIR tooling in their FHIR Tool Settings File. It is assumed that the service will have some mechanism to provide these tokens to appropriate authorised users (which might be anyone who accepts the required license, or any users with appropriate citizenship or business relationship with the entity that provides the service).
Note that there must be an arrangement for FHIR tool smiths to get a token that grants access to the service without cost in order to test their support of the these services.
Registering the service
Such services are registered following discussion with the FHIR Product Director (firstname.lastname@example.org) which will also include discussion on the tooling channel on chat.fhir.org.
This is to be described... (a registry of registries)