MedicalDevice Product ICD terminology LIR and search improvements

[ArdonToonstra]

From HL7 NL validation team feedback (https://jira.hl7.org/browse/HN-149) we got the feedback that there are potentially more SNOMED codes available in the Dutch refset - in the landelijke implementation register - LIR https://nictiz.nl/wat-we-doen/activiteiten/terminologie/referentielijsten-2/inclusielijst-lir/

These codes may have been the ones implemented in the Dutch IT landscape and we should check and confirm if these codes are applicable and if we should incorporate them.

Another feedback point what that naming of the zib/nl-core extensions for the references to HealthcareProfessional and Location are not really straightforward in what they semantically mean. This is however a zib ticket.

[MariekeMassa]

Additionally comment to look at, coming from Lonneke:

ProductType van ICD 2022-10-26T11:32:44 (statisch / Verplicht/CNE)
is-a Code 72506001 implanteerbare cardioverter-defibrillator (fysiek object)
Let op, de Snomed CT codes onder deze code moeten dus gekozen kunnen worden. Dit geldt ook voor de Questionnaire!

Should we change something in the questionnaire?

[MariekeMassa]

Lonneke:
Hieronder het lijstje wat ART-DECOR als expansieset van de ICD (is-a Code 72506001 implanteerbare cardioverter-defibrillator (fysiek object)) uit Snomed CT haalt.
8-S 72506001 Implantable defibrillator, device (physical object) SNOMED Clinical Terms
9-L 465460004 Single-chamber implantable defibrillator (physical object) SNOMED Clinical Terms
9-L 468542000 Dual-chamber implantable defibrillator (physical object) SNOMED Clinical Terms
9-S 704707009 Cardiac resynchronization therapy implantable defibrillator (physical object) SNOMED Clinical Terms
10-L 1263462004 Cardiac resynchronization therapy defibrillator pulse generator (physical object) SNOMED Clinical Terms
9-L 1236894001 Subcutaneous implantable cardioverter defibrillator (physical object) SNOMED Clinical Terms

Alle codes zitten ook in de refset voor de implantatenregistratie. Er zitten niet meer codes in de refset dan hierboven genoemd.

[ArdonToonstra]

We have a couple of things going on regarding MedicalDevice Prodcut ICD terminology. Luckily the is-a code list of 72506001 is not very extensive can we can for now consider taking over the codes explicitly to decrease implementation burden. Here some thoughts:

ValueSet ACP-MedicalDeviceProductType-ICD

Currently, the ValueSet uses a compose include with a filter. This keeps the specs dynamic, but places the burden on the implementers who need to check a terminology server that needs to support SNOMED ECL. Options to simplify:

1. Upon publishing, we need to make sure that we or the IG publisher adds a ValueSet expansion. Like it currently does for https://build.fhir.org/ig/IKNL/PZP-FHIR-R4/branches/develop/ValueSet-ACP-MedicalDeviceProductType-ICD.html . It did not do this for the 1.0.0-rc1 version because at that moment tx.fhir.org was down. We need to double check if this expansion is helpful for tooling not supporting ECL themselves.
2. We could 'hard code' the individual codes into the ValueSet.compose.include part. This increases the governance on the IG authors.

Search URL in data exchange

Depending on the ValueSet adjustments, we could simplify the search url in data-exhange.html:

6 GET [base]/DeviceUseStatement?patient=Patient/[id]&device.type:in=https://api.iknl.nl/docs/pzp/r4/ValueSet/ACP-MedicalDeviceProductType-ICD&_include=DeviceUseStatement:device

1. We could write down the all snomed codes as hardcoded values like we do for Observation search, to get rit of the :in modifier:

...device.type=http://snomed.info/sct|72506001,465460004,...

2. We could leave the :in parameter which might work better / easier if the ValueSet contains an expansion or all the codes in the ValueSet.compose.include as then the ECL request is not needed.

Questionnaire

Currently, the Questionnaire item with "linkId": "1008" contains as anwserOption only the demo/test code "ICD". This is plain wrong. Either here we need to point to the ValueSet or put the codes inline in answerOption[]. Since we use answerOption everywhere, I think we should remain consistent and include the expansion snomed codes here hard coded as wel...

[niekvangalen]

@ArdonToonstra have you considered adding the IKNL PZP terminology to the NTS?

[ArdonToonstra]

@ArdonToonstra have you considered adding the IKNL PZP terminology to the NTS?

Do you mean adding the ValueSets to the NTS as we don't have custom CodeSystems? What would be the benefit of that? Definitely something we can discuss for sure. Would be great to have the NTS first work together with tx.fhir.org though 🗡️

[niekvangalen]

@ArdonToonstra have you considered adding the IKNL PZP terminology to the NTS?

Do you mean adding the ValueSets to the NTS as we don't have custom CodeSystems? What would be the benefit of that? Definitely something we can discuss for sure. Would be great to have the NTS first work together with tx.fhir.org though 🗡️

Have the NTS work with tx.fhir.org is the best option here. And yes, I meant adding the (expanded) ValueSets to NTS, as we (and maybe others) use the NTS for terminology validation.

[ArdonToonstra]

Discussed today, decided to go for writing down all the codes in .compose.include and write down all the codes inside the search url query to descrease implementation burden.

[ArdonToonstra]

Is merged into develop of both STU3 and R4 repo.