Open jpwiedekopf opened 3 years ago
Betreffend des authorSpecialty-VS ist die kanonische URL noch abweichend von der entsprechenden Schlüsseltabelle.
Zum Hintergrund für das TC: Im Rahmen der gmds wurden diese Arbeiten vorgestellt. Ich habe darum gebeten, dass die Ergebnisse und auch die Lessons Learned HL7 zur Verfügung gestellt werden. Danke @jpwiedekopf!
Hallo zusammen!
In hl7germany/basisprofil-de-r4#105 wurde bereits über die Nichtverfügbarkeit von FHIR CodeSystems für die in ArtDecor erstellten ValueSets gesprochen. Ich habe daher die in den ValueSets referenzierten Codes nun - sofern sie nicht aus anderen Terminologien wie LOINC, DICOM DCM, SNOMED CT, FHIR/HL7 V3-Terminologie stammen - extrahiert.
Das von mir verwendete in Python geschriebene Script ist unter https://github.com/itcr-uni-luebeck/artdecor-vs-to-cs verfügbar. Im Ordner "data/output-cs" findet Ihr die so erzeugten CodeSystems, die ich auch unter den Releases im ZIP-Format hochgeladen habe. (Edit: Link angepasst)
Um konkret in einem FHIR-Terminologie-Server (Ontoserver am UKSH Campus Lübeck/Campus Kiel) zu arbeiten, ist die Verfügbarkeit von FHIR CodeSystems extrem sinnvoll, sonst funktioniert z.B. die Operation
$expand
nicht richtig. Deshalb halte ich es persönlich für sinnvoll, die so erstellten CS mit in die Distribution aufzunehmen. Hierfür sind allerdings ggf. noch Anpassungen an dem Script, den verwendeten Optionen (Status, Version, ...), und teilweise auch für die zugrundeliegenden ValueSets notwendig. Ich kann das gerne vornehmen und dann ein entsprechendes PR in diesem Repository erstellen.Ich habe bislang nur Version 2 der ValueSets konvertiert. Als Grundlage für das Script dient dabei die Repräsentation der VS im ArtDecor-spezifischen Format als JSON.
Wichtig: mir sind ein paar größere Probleme aufgefallen, die der Verwendung der VS in einem FHIR-Terminologie-Server noch im Wege stehen.
eventCodeList
DICOM-ValueSets
Hier sind zwei Verweise auf DICOM-Terminologie per OID gesetzt. Diese Artefakte stehen auf Seiten von DICOM als FHIR-ValueSets (nicht CodeSystems! Die ValueSets speisen sich aus der DICOM DCM) zur Verfügung:
Die in ArtDecor gesetzte kanonische URL (urn:oid:...) weicht von der im jeweiligen DICOM-Artefakt gesetzten URL ab: http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_29.html.
Also sollten die ArtDecor-Artefakte dahingehend angepasst werden, dass sie auf
valueSet
statt aufsystem
verweisen, und die kanonischen URLs auf die angegebenen URLs angepasst werden.Codes Sozialgesetzbuch
Die FHIR-Version des ValueSets verweist auf ein ValueSet, das im ArtDecor nicht als verwendetes VS angezeigt wird (siehe Abbildung):
Öffne ich den die kanonische URL dieses VS, erhalte ich ein VS "Codes Sozialgesetzbuch"?!
formatCode (Intl)
Dieses VS referenziert die DICOM UID Registry, die im DICOM-Standard unter http://dicom.nema.org/medical/dicom/current/output/chtml/part06/chapter_A.html enthalten ist. Diese Tabelle habe ich mit LibreOffice Calc und CSIRO Snapper in ein FHIR-CS transfomiert.
Vermutlich sollte das auch in die Distribution aufgenommen werden, da diese Liste sonst nicht als FHIR-CS verfügbar ist. Sie ist im o.g. Repo unter https://github.com/LtSurgekopf/artdecor-vs-to-cs/blob/main/data/referenced-resources/CodeSystem/dicom-uids.json, die Ressourcen zur Transformation sind dort auch enthalten.
authorSpecialty
Hier wird die KBV-Schlüsseltabelle S_BAR2_WBO referenziert, die auch im FHIR-Format verfügbar ist. Die verwendete kanonische URL im IHE-VS weicht aber von der FHIR-Version der KBV ab (OID statt KBV-URL).
Ich habe leider auch jetzt erst realisiert, dass es sich dabei um ein KBV-CS handelt, das nicht aus dem VS hätte extrahiert werden müssen. Ich werde also die OID dieses CS in meinem Script (morgen) blacklisten, damit dies nicht konvertiert wird. Edit: erledigt. Neues Release unter https://github.com/LtSurgekopf/artdecor-vs-to-cs/releases/tag/v1.0.1
kanonische URLs im ArtDecor-Bereich
Es gibt einige VS, die eine kanonische URL haben, die auf ArtDecor verweist, während einige VS und CS eine solche haben, die "ihe-d" enthält. Funktioniert so natürlich beides gleich gut, aber eine "hübsche" kanonische URL (die auch nicht unbedingt das Datum der jeweiligen Version) enthält wäre vermutlich schöner. Gibt es hier einen triftigen (historischen) Grund? Wäre aber vermutlich auch eine größere Änderung, wenn die Ressourcen in der FHIR-Profilierung verwendet werden.
Viele Grüße aus Lübeck Joshua
-- Edits: 2021-03-16