dot-base / icd-10-api Goto Github PK

🧽 Maintenance Description

We want the Create Release PR action to be customizable with a branch to allow hot fix releases from other branches than main.

✔ Acceptance Criteria

• Workflow allows to specify a branch name.
• The branch name is passed to the reusable workflow in .github repo.

🚀 Describe the Improvement

As a technical user, I'd like to know how to use this API ;)

🧰 Possible Solution

• Write Documentation

🚀 Describe the Improvement

When entering a new diagnose, I want to simultaneously get a list with matching suggestions.

✔ Goals

To complete this story, these things have to be done:

• fuzzy search instead of strict string comparison
• search for matches not only in the icd title but also in meta data (such as icd field "inclusion", containing related diseases and synonyms)
• allow searching for icd10 codes instead of text only
• allow searching for multiple terms - regardless of their order

🧰 Possible Solution

• search will be based on fuse.js
• searching for multiple terms must include searching for all possible combinations of terms

🚧 Blocked by

Work that needs to be done before this story can be started:

• #NUM - creation of fields in X

Acceptance Criteria

• return FHIR.ICodeSystem_Concept directly and not wrapped in object like:

interface Icd10ApiResultItem {
    item: FHIR.ICodeSystem_Concept;
}

🚀 Feature Description

In the editor, users should be able to search for terminology codes (such as LOINC), when they create a new chart. The most feasible solution for the moment needs to be evaluated again.

The following ideas were discussed:

1. Currently we offer free text input (since it is only needed for a demo)
2. Query Questionnaire resources and their items for all existing terminology codes
3. refactor ICD-10 Api to be a general terminology API
4. Use LOINCs FHIR Api or Charite Terminology Server

Acceptance Criteria:

• Rename icd-10-api repo to terminology-code-api (optional)
  • update dotbase stack yml
  • update repo name
  • update repo package name
• we want to have to routes with params search and version
  • icd10/
  • loinc/
• get loinc code data dump to offer search through api

Data Format?

code: String
system: "loinc" | "icd10" | "icd11"
version: String

Related Epic from the past

https://github.com/dot-base/medical-dashboard/issues/963 (but @velramiir suggests another procedure)

Subtasks

• #107
• #105
• #106
• dot-base/data-graph#122
• dot-base/medical-dashboard#1581

Searching icd codes with "longer" queries (> 6 terms), leads to endless searches.
This is due to the way icd10 API is designed, since it searches for all possible combinations of terms.

Thus, max. amount of terms will be restricted by setting a env var MAX_SEARCH_TERMS

🧹 Goal

There are different major version updates for our dependencies availabe.

npm outdated report

✔ Goals

• Update dependencies to current major versions

🔥 Bug Description

Requesting the same query twice returns no results in version 2.0.0.

🔍 Steps to Reproduce the Bug

1. GET http://localhost:3000/api/icd10?search=sinusitis - returns results
2. GET http://localhost:3000/api/icd10?search=sinusitis - returns no results

🚀 Feature Description

As an API consumer I would like to know which ICD-10 catalogue version was used for the generated results

✔ Acceptance Criteria

• Results are of type FuseResult<CodeableConcept>
• include system url http://fhir.de/CodeSystem/bfarm/icd-10-gm
• include version 2024

🚀 Feature Description

Unify API response type in accordance to other dot.base APIs.

🧽 Maintenance Description

We want to refactor the dummy extension removal because the double assignment is hard to read and understand at a glance.

r.item.extension = r.item.modifierExtension = undefined

✔ Acceptance Criteria

• The double assignment is removed.

🚀 Describe the Improvement

As a project manager, I'd like to offer the clinical user optimal diagnosis suggestions, in order to facilitate ICD-10 coding in the diagnoses list.

✔ Goals

To complete this story, these things have to be done:

• Get in touch with people at Charite and ID company to clarify legal situation about the use of ID Logik service
• Ask for API documentation at ID company
• send user input to ID server and receive suggestions
• maybe merge suggestions with those of our own ICD10-API

🧰 Possible Solution

• https://www.toolpool-gesundheitsforschung.de/produkte/id-logik-terminologieserver

🚧 Blocked by

Work that needs to be done before this story can be started:

• none

🚀 Describe the Improvement

As a user, I'd like to search for diagnoses in the officially published icd10 catalogue.
For Germany this ICD10 data is published by DIMDI as a .json file in a custom format. To improve code quality (and enable future adaption) of the project the base data should be typed as a FHIR Codesystem.

✔ Goals

To complete this story, these things have to be done:

• transform base data to typed Codesystem
• preprocessing of base data

🧰 Possible Solution

• A helpful tool for converting DIMDI data into a FHIR Codesystem are fhir types
  For further info, read also this article

🔥 Bug Description

We want to test the new hotfix process, so we need to make a small code change.

We will fix the wrong service name in the README. It says authentication-gateway where it should be icd-10-api.

🚀 Feature Description

Update the API to use the current ICD-10-GM release for 2024, which was recently published by BfArM: https://www.bfarm.de/SharedDocs/Downloads/DE/Kodiersysteme/klassifikationen/icd-10-gm/version2024/icd10gm2024syst-claml_zip.html?nn=841246&cms_dlConfirm=true&cms_calledFromDoc=841246

BfArM publishes the ICD-10 catalogue as a ClaML / XML. This can be converted to a FHIR CodeSystem using this tool or the already parsed CodeSystem from Medizininformatik Initiative

✔ Acceptance Criteria

• use 2024 version of ICD-10-GM

🔥 Bug Description

When using the local dotbase stack, both npm install and npm start fail with the error that the npm cache contains root-owned files. The reason is that the home dir in the development container is the root dir / and npm tries to create the cache at ~/.npm by default.

🔍 Steps to Reproduce the Bug

1. Launch stack from icd-10-api repo
2. Run either command in the docker container of the icd-10-api

🧯 References and Tools

• https://www.notion.so/dotbase/Known-Solution-Archive-e1206bf3597347c8aac1c32588650bcb?pvs=4#0f61383472b44f15b0a58af39184d4fc
• The medical-dashboard solves this by setting the home dir to /tmp in the dev overlay.

🧽 Maintenance Description

We want to call the workflow Manage PR remotely from the .github repo, so we can maintain it at a central location for all repos.

✔ Acceptance Criteria

• The action runs with the version located in .github

🔥 Bug Description

In the previous version of the Docker image, there was a specific ARM version linux/arm64 (see screenshots). However, starting from v5, only the linux/amd64 version is available.

🔥 Bug Description

Results contain an extension with no url set. This is not a valid FHIR resource as extension urls are mandatory.

http://127.0.0.1:3000/api/icd10?search=akute%20sinusitis%20maxi

[
  {
    "item": {
      "code": "J01.0",
      "display": "Akute Sinusitis maxillaris",
      "definition": "Akute Sinusitis maxillaris",
      "property": [
        {
          "code": "kind",
          "valueCode": "category"
        },
        {
          "code": "parent",
          "valueCode": "J01"
        },
        {
          "code": "inclusion",
          "valueString": "Akute Kieferhöhlenentzündung"
        }
      ],
      "extension": [
        {
          "id": "displayCopy",
          "valueString": "AkuteSinusitismaxillaris"
        }
      ],
      "modifierExtension": [
        {
          "id": "InclusionCopy",
          "valueString": "AkuteKieferhöhlenentzündung"
        }
      ]
    },
    "refIndex": 4302,
    "matches": [
      {
        "indices": [
          [
            14,
            17
          ],
          [
            5,
            13
          ],
          [
            0,
            4
          ]
        ],
        "value": "AkuteSinusitismaxillaris",
        "key": "extension.valueString",
        "refIndex": 0
      }
    ],
    "score": 0.12589254117941673
  }
]

Possible solution

• remove the extension before sending the response

🚀 Feature Description

As a User, I'd like to get all ICD10 Values, in order to to be more precise in my diagnosis. (For Example the whole F10 area is missing in the data)

🚀 Feature Description

As a API user I do not want to get items that are incomplete.

✔ Acceptance Criteria

• API returns only complete items containing code and display
• service should log error if incomplete items exist / are returned

📦 Describe the Goal

As a user, I would like to be able to search diagnoeses based on the icd-10 terminology. When entering a new diagnose, I want to simultaneously get a list with matching suggestions. In the current solution these suggestions are just based on simple string comparison.
The ICD-10 API should include the following features and improvements:

• fuzzy search instead of strict string comparison
• search for matches not only in the icd title but also in meta data (such as icd field "inclusion", containing related diseases and synonyms)
• allow searching for icd10 codes instead of text only
• allow searching for multiple terms - regardless of their order
• filter best matches based on scoring and ranking

🚚 Steps Towards this Goal

To achieve this goal, the following stories have to be completed:

• setup new microservice
• #3 - converting icd10-gm.json into FHIR Codesystem and preprocessing of data
• #2 - implement search algorithm including the features mentioned above
• #4 - implement scoring and ranking of matches

🚀 Feature Description

Update the API to use the current ICD-10-GM release for 2023, which is published by BfArM: https://www.bfarm.de/DE/Kodiersysteme/Services/Downloads/_node.html

BfArM publishes the ICD-10 catalogue as a ClaML / XML. This can be converted to a FHIR CodeSystem using this tool or the already parsed CodeSystem from Medizininformatik Initiative

✔ Acceptance Criteria

• use current 2023 version of ICD-10-GM

🚀 Feature Description

Update the API to support using the current ICD-11-GM release on top to ICD-10.
ICD-11-GM is published by BfArM: https://www.bfarm.de/DE/Kodiersysteme/Services/Downloads/_node.html

BfArM publishes the ICD catalogues as a ClaML / XML. This can be converted to a FHIR CodeSystem using this tool . For ICD-10 a already parsed CodeSystem from Medizininformatik Initiative is available, but none for ICD-11 so far.

✔ Acceptance Criteria

• Add a CodeSystem with the current release of ICD-11-GM
• Make using ICD-10 or ICD-11 eligible

🚀 Describe the Improvement

As a user, I'd like to have a convenient trade off between getting a narrow list of matches, but also getting a complete list of relevant results.
Therefore the API should not only search for matches, but also perform a kind scoring, which can be used for ranking (and filtering) results.

Example: A user enters the term "idiopathic parkinson syndrom".
Only the combinations of "idiopathic AND parkinson" and "syndrom AND parkinson" should lead to relevant results.
Nevertheless, the combination of "idiopathic AND syndrom" will also lead to a huge number of matches, that blur the overall result.

Therefore, scoring of matches should take into account, if (combinations of) search terms seem to be too generic, to be considered as matches.

✔ Goals

To complete this story, these things have to be done:

• implement scoring (based on fuse.js fuzzy score and custom scoring)
• implement custom score, considering if term is too generic
• rank results based on score
• filter results (e.g. based on threshold) if results seems to be too wide

🔥 Bug Description

Currently, the API returns Condition with incorrect extensions - they are missing a url value. This at least happens on displayCopy.

🔍 Steps to Reproduce the Bug

1. Was recognized due to a frontend bug in production

🧯 Possible Solution

• Quickfix: Set String value for URL.
• Check why this extension is added and if it is really needed. I think we added it to not only search on icd codes but also there "chapter"-descriptions

🚧 Important

If extensions are removed from ICD-10-Api, this Issue would also need a migration on exisitng data