Balloting of the central MII terminology server

In recent years, the central terminology server for the MII, which is operated by the SU-TermServ, has been available at the address https://terminology-highmed.medic.medfak.uni-koeln.de/fhir. The server was created within the HiGHmed project. With the start of the current funding phase of the MII in January 2023, an independent 2b project was established to professionalize the operation of this server and to expand the target audience to the entire MII and NUM. We are pleased to finally present our work to you. More information about the ballot can be found in the lower section of this page.

Focus

As a server for the MII, our focus is on providing the terminological resources needed for the Core Dataset (KDS). Currently, we are providing the stable KDS modules. In addition, we have also packaged the resources that are still needed for the implementation of the KDS. Besides SNOMED CT and LOINC, this includes resources provided by the BfArM, resources from the FHIR base specification or from , as well as their dependencies (if applicable). This creates a dependency graph (illustrated below) at the package level, and our server currently provides:

• 1680 CodeSystem resources
• 5155 ValueSet resources
• 100 ConceptMap resources

In addition, the resources created by the HiGHmed use cases, GECCO, as well as BBMRI/ERIC and DKTK are also available – this reflects our previous deployment. If further resources for cross-site applications are needed, we can package and provide them together with you upon request.

New concept

In this context, we have thoroughly overhauled the content and technical foundation of our server through an extensive process. While in the HiGHmed days the focus was on the ad-hoc provision of necessary resources, we have now created a stable and sustainable infrastructure that meets the changing demands of the MII. Instead of uploading resources of any origin in an unstructured manner upon request, our new deployment is based on maximum transparency and sustainability. All resources are managed using FHIR Packages, which are interrelated through dependencies. All packages are transparently managed in our GitLab area and can be accessed via the GitLab NPM Registry.

Package contents

The most important paradigm in our new deployment is the separation of different concerns. Each package contains only resources that are contextually related. For example, there is a package for ICD-10-GM and a package for LOINC. The packages are self-contained and can be installed and updated independently of one another. This allows us to separate the resources both content-wise and technically, ensuring a high level of quality and stability. To manage the dependencies between the packages, we have declared them within the package manifests (package.json). We identified dependencies between the packages through automated tooling, for instance, recognizing bindings within the FHIR profile definitions that refer to other packages.

All packages hosted on our server are managed through our GitLab. If FHIR-NPM packages already existed from the specifiers, we have transferred the contents of these packages into our own packages. This ensures that the resources on our server are always up to date and correct, and allows us to enrich the resources with relevant metadata. The version numbers in our packages track the versions of the source packages.

To illustrate the dependencies between the packages, the following graphic is helpful. It shows all package dependencies of the package @mii-termserv/de.medizininformatikinitiative.kerndatensatz.terminology.bill-of-materials in the currently uploaded version 2024.8.27-rc2 [GitLab Package Registry]:

Dependencies of the package @mii-termserv/de.medizininformatikinitiative.kerndatensatz.terminology.bill-of-materials in version 2024.8.27-rc2

A clearer overview is certainly provided by the fragment that only shows the outgoing dependencies of the package hl7.fhir.r4.terminology in the current version 4.0.1-rc2 [GitLab-Package-Registry]:

Dependencies of the package hl7.fhir.r4.terminology in version 4.0.1-rc2. The cells indicate the number of CodeSystems, ValueSets, and ConceptMaps in the packages.

All package dependencies are based on actual established dependencies at the package level. Of course, most packages do not require the complete terminological content of the FHIR specification, but specifiers can rely on the fact that the resources they use are also provided by the SU-TermServ without restrictions. This makes it easier for DIZ staff to simply install and update the resources they need.

Metadata

Each resource within the packages has been annotated with metadata by us. On one hand, we use meta.tag to illustrate the project and dataset context of each resource. On the other hand, we use the CQF-Scope extension to reference the packages from the resources. Furthermore, we have adjusted the IDs of the resources to avoid collisions between resources and to make them more meaningful. Here is a shortened example from a ValueSet in the FHIR R4 specification:

{
  "resourceType": "ValueSet",
  "id": "fhir.r4-administrative-gender",
  "meta": {
    "profile": [
      "http://hl7.org/fhir/StructureDefinition/shareablevalueset"
    ],
    "tag": [
      {
        "system": "https://mii-termserv.de/fhir/su-termserv/CodeSystem/mii-cs-suts-resource-tags-project",
        "code": "hl7",
        "display": "HL7 International"
      },
      {
        "system": "https://mii-termserv.de/fhir/su-termserv/CodeSystem/mii-cs-suts-resource-tags-dataset",
        "code": "hl7-fhir",
        "display": "HL7 FHIR"
      },
      {
        "system": "https://mii-termserv.de/fhir/su-termserv/CodeSystem/mii-cs-suts-resource-tags-license",
        "code": "https://mii-termserv.de/licenses#fhir",
        "display": "HL7 FHIR License"
      }
    ]
  },
  "extension": [
    {
      "url": "http://hl7.org/fhir/StructureDefinition/cqf-scope",
      "valueString": "@mii-termserv/hl7.fhir.r4.terminology"
    }
  ],
  "url": "http://hl7.org/fhir/ValueSet/administrative-gender"
}

The tags are defined and maintained in code systems managed by us. The license tags are URLs that refer to a page on our web presence where we illustrate the licensing conditions of the resources (for example, here).

Based on our metadata, we also generate narratives that are embedded in the resources to make this metadata transparent for our users. Here is an example:

Canonical Resources Management Infrastrucutre (CRMI)

The use of the CQF-Scope extension has been recommended by the recently published CRMI Implementation Guide. We have implemented the recommendations of this IG in the following areas:

• Packaging of resources as NPM packages [Packaging]
• Distribution within an NPM registry [Publishing]: https://gitlab.com/mii-termserv/fhir-resources
• Identification of dependencies at the resource level [Dependency Tracing]
• Implementation of the syndication profile at the package level with self-implemented open-source API [Syndication]: https://ontoserver-ballot.mii-termserv.de/crmi/syndication.xml

However, a complete implementation of this IG is not possible unless the entire core dataset of the MII is designed according to these guidelines.

Updates

As soon as updates for the upstream packages and resources are released, we will update our packages.

For KDS packages, this means that we will release all stable versions. The packages for the BfArM resources will be updated annually at the turn of the year with the new versions. Updates for SNOMED CT and LOINC will also be carried out at the turn of the year, where the current version will be provided at the beginning of the year.

When releasing the final packages, we will formulate the version ranges in the NPM packages so that the package versions of the dependencies are compatible with the anticipated new versions. The versions specified in the packages should thus be understood as minimal versions. Through our tooling, we will ensure the compatibility of the packages with each other.

Tooling

Our packages are built automatically with GitLab CI and published in the GitLab registry.

Our tooling has been implemented in a Python tool that is tailored to our requirements but can still provide interesting features for others. The tool is therefore available under the CC0 license in our GitLab.

Deployment

The ballot server is now available at https://ontoserver-ballot.mii-termserv.de. The FHIR endpoint can be accessed at https://ontoserver-ballot.mii-termserv.de/fhir. The homepage of the server can be accessed at https://launch.ontoserver-ballot.mii-termserv.de (which redirects from https://ontoserver-ballot.mii-termserv.de).

On the homepage, there are links to other apps and services that access the server.

According to our licensing terms for Ontoserver, we are required to ensure that our customers are located in Germany. Therefore, an SSL certificate is mandatory, which confirms the identity of the requesting party. It is necessary for you to use a certificate from the current Géant or the old DFK PKI. If you do not have a certificate from these PKIs, please contact us to request an exception. We will then issue a certificate from an alternative PKI managed by us. An IP allow list will no longer be used in the future, as maintaining it would involve an disproportionately high effort from our perspective. If needed, please refer to our offer for certificates issued by us.

On the server, you will still only be able to read. With your certificate, you have permission to read all resources on the server and to query via the FHIR API (as long as your client code also presents the certificate). Writing requires further authentication, which is only available to employees in the SU-TermServ. We will also provide a test server in the future, where authorized users can work with write access.

Our CRMI API is available at https://ontoserver-ballot.mii-termserv.de/crmi/syndication.xml, which allows us to make the uploaded packages transparent (see above).

Balloting

Until October 20, 2024, we look forward to your feedback on the ballot environment. Please comment in our Zulip channel or via email. The use of Zulip is preferred, as it allows us to have a transparent discussion that is accessible to other interested parties.

We are particularly interested in your feedback on the following points:

• Are all the resources you need/expect available on the server?
• Are the metadata of the resources helpful to you?
• Do you have suggestions for improving the server infrastructure?
• Is the representation of the more complex CodeSystem resources compatible with your requirements? Do you have any additional improvement suggestions?

What’s Next?

After the ballot phase, we will collect and evaluate your feedback. We will then possibly consult with the community in a video conference to clarify open questions. Subsequently, we will approach the new productive deployment, incorporating the lessons learned from this deployment and your feedback. The ballot server will remain available until further notice.

Additionally, the previous deployment at https://terminology-highmed.medic.medfak.uni-koeln.de/fhir will remain available until further notice. However, this server will no longer be updated. We are currently planning for the decommissioning of the old server and will inform you in good time. Expect a shutdown no later than March 30, 2025, at the end of the first quarter.

Furthermore, we have exciting projects planned for the upcoming period that will make your work with the terminological resources easier:

• Our tooling for creating/converting resources into FHIR-CodeSystem (BabelFSH) will be further developed.
• Through the Data Sharing Framework and other technologies, we will present a distribution concept for our resources, enabling local validation of ValueSet membership even in DIZen without their own terminology server.
• Based on package-based resource management, we will develop interfaces that make the dependencies of the resources transparent.