Interoperabilitätsforum / TC-Arbeit 10. und 11. Juni 2013 in Berlin

Aus Hl7wiki
Wechseln zu: Navigation, Suche

Veranstaltungsort

SPECTARIS - Deutscher Industrieverband für optische, medizinische und mechatronische Technologien e.V.
Werderscher Markt 15
D-10117 Berlin
Fon +49 (0)30 41 40 21-0
Fax +49 (0)30 41 40 21-33

Start 1. Tag: 11:00
Ende 2. Tag: 15:00

Das Interoperabilitätsforum diskutiert und bearbeitet Themen zur Standardisierung der Technischen Komitees der HL7-Benutzergruppe, IHE Deutschland und anderer Standardisierungsaktivitäten im Gesundheitswesen. Teilnehmen kann jeder, jedoch wird aus administrativen Gründen um Anmeldung unter office@hl7.de gebeten.

Vorgesehene Agenda

  • Administrativa
    • Finalisierung Agenda
    • Protokoll
    • offene Punkte
  • OR.net: Vorstellung
  • Ballots
    • Ergebnis gerade abgelaufener Abstimmungsverfahren (Beteiligung, Ergebnis, Reconciliation):
      • Cookbook
      • EFA 2.0
    • neue/geplante Verfahren:
      • IHE PAM Abgleich
      • Meldung infektiöser Krankheiten
  • HL7 v2.x
    • IHE-ITI-PAM-Profil: Vorbereitung Ballotierung
    • Patientenwilligung
    • Helpdesk (eingegangene Anfragen)
    • Z-Segmente
  • weitere Projekte: Die Ansprechpartner der Interoperabilitätsprojekte werden gebeten, offene Fragen auf dem Weg zur Fertigstellung des Projekts hier als Angendapunkte zu platzieren.
  • Sonstiges

Weitere Agendapunkte werden gerne mit aufgenommen.

Aufgrund der Arbeitsschwerpunkte wird auf diesem Treffen der Schwerpunkt auf die Fortführung der Template-Arbeiten gelegt, d.h. wir werden versuchen, die Templates im Detail durchzusprechen und Todos dazu zu vergeben.

Teilnehmer

Name Organisation Tag 1 Tag 2
Gerhard Abel Siemens X X
Mathias Aschhoff ZTG X X
Johannes Dehm VDE X X
Heike Dewenter FH Krefeld X X
Daniel Flemming FH Osnabrück - X
Simone Heckmann Health-Comm X X
Daniel Hellmuth Tieto X X
Salima Houta Fraunhofer ISST X X
Tarik Idris ICW X X
Stephan Janz CSC X X
Timo Kahlert Redline GmbH X X
Stefan Lang Lang IT Consulting - X
Heike Moser DIN X X
Stefan Müller-Mielitz DMI X X
Frank Oemig Agfa X X
Stephan Schiek 3M X X
Andreas Schultz GS4eB X X
Lars Treinat ZTG X X
Marek Vaclavic SER X X
Kai Winnig AIS AG X -
Farid Zain Elabdin ixmed X X
Bogdan Zyla, FH Krefeld X X

Protokoll

Administrativa

Es wird festgelegt, dass die Protokollführung ungefähr jede 1 Stunde weitergegeben wird. Auf Grund der Überschwemmungen und damit verbundenen Zugverspätungen hat die eigentliche Sitzung erst um 14:00 Uhr begonnen. Am Vormittag hat Herr Dehm das Projekt OR.NET "Sichere dynamische Vernetzung in Operationssaal und Klinik" vorgestellt. Das Projekt wurde im Herbst 2012 gestartet. Beteiligt sind ca. 50 Projektpartner aus Industrie, Wissenschaft und Forschung sowie aus dem Normungsbereich (VDE, DIN, OFFICE u.a.). Die gezeigten Folien werden auf den Seiten des Interoperabilitätsforums bereitgestellt.

Finalisierung Agenda

OR.NET wird als TOP aufgenommen. Unter CDA-Leitfäden – Grundlagen wird die Agenda unterteilt in:

  1. Templates
    1. [Header Level Templates-http://wiki.hl7.de/index.php/Kategorie:CDA_Header_Level_Template]
      1. [Record-Target (detailliert)-http://wiki.hl7.de/index.php/cdaab2:Patient_(recordTarget)_(Template)]
      2. weitere (Ausprägungen?)
    2. [Section Level Templates-http://wiki.hl7.de/index.php/Kategorie:CDA_Section_Level_Template]
    3. [Entry Level Templates-http://wiki.hl7.de/index.php/Kategorie:CDA_Entry_Level_Template]

Ungünstig ist, dass einige Akteure an dieser Sitzung gar nicht und andere nur am Dienstag teilnehmen können, deshalb wird z. B. der Onkologieleitfaden erst am 2. Tag besprochen und die Diskussion der Ballot-Ergebnisse zur EFA 2.0 muss voraussichtlich entfallen.

Schwerpunkt dieser Sitzung wird die Diskussion der Templates der CDA-Leitfäden sein, insbesondere der Header Level Templates, die direkt im Wiki bearbeitet werden sollen. Anschließend werden die Leitfäden selber, insbesondere "Meldung infektiöser Krankheiten" behandelt.

OR.Net Initiative

Link: [1]

Datenaustausch zwischen verschiedenen Medizingeräten. Teilprojekt 4 - Standardisierung


Ballots

Das von HL7 formalisierte Verfahren wurde diesmal nicht eingehalten, d. h. man hat keine Anmeldung für die Teilnahme an der Abstimmung benötigt. Dies soll sich in Zukunft ändern, damit man den eigenen Ansprüchen ein größeres Spektrum an Meinungen zu vertreten auch gerecht wird.

Es wurde noch einmal kurz das Abstimmungsverfahren (http://wiki.hl7.de/index.php/Abstimmungsverfahren) vorgestellt. Grundsätzlich wird zwischen Reviewer und Voter unterschieden: Voter sind diejenigen, die auf Ansage nur eine Stimme abzugeben haben. Reviewer sehen sich das Material hingegeben detailiert an und liefern die Grundlage für eine Stimmabgabe. Negative Stimmen sind zu begründen, dabei kann auch auf einen anderen Voter verwiesen werden, der die dazugehörigen Kommentare abgeben muss. Kommentare können immer abgegeben werden. Negative Kommentare müssen immer aufgelöst werden.

Cookbook – Ballotauswertung (Tarik Idris, ICW AG)

Bisher ist ein Kommentar (von Frank Oemig) eingegangen und ein weiterer wurde angekündigt. Es sind noch einige Punkte offen, die bearbeitet werden müssen. Das Projekt ist bisher nicht angenommen (zu wenig Resonanz, Kommentare noch aufzulösen). Der Datenschutz ist bereits sehr gut beschrieben, aber andere Bereiche (Strukturierung) müssen noch verbessert werden. Es wird direkt Im Wiki gearbeitet, was positiv bewertet wird. Einige Felder sind noch zu definieren und einzelne Mappings zu erstellen. Eine Auflösung der Kommentare ist derzeit nicht sinnvoll, da diese noch nicht vollständig sind. Aus den bisherigen Kommentaren ist erkennbar, dass die Patientenidentifikation, MPI, klarer darzustellen ist. Auch Spezifikationen von EFA müssten eigentlich im Cookbook enthalten sein (auch Kommentar zur EFA entsprechend einzureichen). Überschneidungen, insbesondere im Bereich Sicherheit, sind zu klären und zu vereinheitlichen. Akteure für Security müssen Entscheidungen treffen, was wiederverwendbar ist an bestehenden Definitionen. Die XML Terminologie zu verwendet wird kritisch gesehen, die IHE Akteure übernehmbar zu prüfen, ob etwas Passenderes zu finden ist.

Bisher sind für unterschiedliche Projekte verschiedene Ansätze gewählt worden, z. T. wird jetzt bereits gemappt auf das Cookbook, aber noch ist nicht alles erfasst. Die neue EFA 2.0 Beschreibung ist nutzbar für einiges, was eher ins Cookbook als in die EFA gehört (EFA zu dick, Cookbook zu dünn). Langsam kristallisiert sich aber ein gemeinsames Ziel heraus.

EFA – Ballotauswertung

Die Auflösung der Kommentare muss auf die nächste Sitzung verschoben werden.

HL7 v2.x-Themen

Z-Segmente

Es wurden von Simone Artikel hierzu geschrieben und veröffentlicht. Sie hat unterdessen schon eine umfangreiche Sammlung an Z-Segmenten ([2]) angelegt. Für alle liegen ihr auch die entsprechenden Firmenspezifikationen vor. Es wird diskutiert in wie weit die Spezifikationen allgemein verfügbar gemacht werden können. Die rechtliche Situation ist unklar. Für unseren Wunsch der Spezifikationsveröffentlichung ist es sicher sinnvoller bei den Firmen nachzufragen, ob die Detailspezfikation eingestellt werden kann und dann mit oder ohne Namensnennung der jeweiligen Firma.

Hausaufgaben: Simone ersetzt in der Liste die Firmennamen, von denen keine Einwilligung vorliegt, durch einen Pseudonamen, damit zumindest erkennbar ist, wie die einzelnen Z-Segmente zusammengehören.

Bisher identifizierte Schwachstellen in V2.0: Neugeborenendaten, OP-Daten (Schnitte usw.) fehlen. Ziel der Sammlung ist auch Defizite festzustellen und statt eigener neu definierter Z-Segmente lieber zu überlegen, ob und wie die Spezifikation geändert werden kann. Dazu ist es wichtig auch die Inhalte zu listen (ob mit oder ohne Firma), damit eine Lösung als Spezifikation gefunden werden kann. Und wenn schon nicht die Spezifikation geändert werden kann, dann sollten alle Firmen wenigstens dasselbe Z-Segment für den gleichen Inhalt verwenden.

Falls eine derartige Liste besteht ist unklar, wer Eigentümer vom Z-Segment ist und dieses ggf. weiterentwickelt oder ändert. Wer macht was (Eigentümer, Pfleger…) - alle sollten im Wiki gemeinsam arbeiten, aber nicht einfach wild ändern. Die Firmen, die sich hier zu erkennen geben, werden dann auch "Eigentümer" dieser Segmente und sind für Erweiterungen zuständig.

Hausaufgabe: Geprüft werden soll auch noch einmal ob die Österreicher ihre Spezifikation nicht doch freigeben würden (bisher Namensnennung gestattet aber nicht die Veröffentlichung der Spezifikation). (Frank)

Hausaufgaben: Jede klärt in seiner Firma, ob die Spezifikation veröffentlicht und der Name genannt werden kann (-> Info an Simone).

Eine Gefahr wird auch gesehen, dass bei der Umsetzung der EFA vieles über Z-Segmente realisiert wird. Beim EFA Stecker wird abweichend von dem offiziellen MDM-Profil eine eigene Spezifikation genutzt, statt abgestimmte Spezifikation zu verwenden, z. B. eigene Patienteneinwilligung festgelegt.

Berechtigte Ärzte

Es besteht derzeit bei einigen Firmen die Tendenz, die Information über behandelnde Ärzte, Einweise, etc. in PV1-7+8+9 zur Berechtigungssteuerung zu misbrauchen. Ohne eine weitere Definition (über ein separates Feld oder eine Profilkennung) führt dieses Vorgehen zu Problemen, da sich damit der Inhalt des Feldes ändert. Auch ist problematisch, dass Systeme, die diese Kennung nicht auswerten, eine Änderung des Inhaltes nicht feststellen können. Daher wird von dieser Lösung abgeraten. Eine weitere Ausarbeitung ist notwendig, der aktuelle Stand ist im Wiki zu finden.

Patienteneinwilligung

Wie dokumentiert man Einwilligung des Patienten und deren Umfang?

Es geht darum, wer darf nach der Übertragung auf das Dokument zugreifen. Nur der Empfänger, Consent-Segment oder behandelnder Arzt hat immer Zugriff.

Muss die Einwilligung explicit oder implicit sein. Ist der behandelnde Arzt automatisch berechtigt? Die Erklärung sollte explicit sein, das beinhaltet auch die Möglichkeit jemanden Explicit nicht zu berechtigen.

Bei den Aktensystemen werden Dokumente verwendet. Woher weiß das System, wann es ein ADT Nachricht an das Aktensystem weiterleiten darf.

Es wird für den Patienten ein Dokument hinterlegt, dass über den Inhalt und die Reichweite der Einwilligung informiert. Dies kann dann von allen Anwendungen abgerufen werden.

Es sollte eine Empfehlung für ein Mapping von einem ADT mit einem Con-Segment auf eine XDS-Lösung (XACML orientierte Patientenzustimmung) erarbeitet werden.

Berechtigungsentscheidungen können nicht nur für ein Haus getroffen werden. Wie können Berechtigungen geprüft werden. Ist dies bereits „ein Verlassen der Dokumente“ wenn die Gegenseite die Einwilligung des Patienten prüft und gegebenenfalls ablehnt.

Es muss in jedem Fall eine Consent-ID untergebracht werden, also Dokumenten-ID der Einwilligungserklärung.

Hausaufgabe: Soll im Rahmen des Cookbooks geprüft werden.


sonstige Anfragen

Liegen nicht vor.


PAM Abgleich

Marek berichtet zum PAM Abglech. Das Projekt läuft nun seit fast zwei Nachrichten, um die bestehenden ADT Nachrichtenprofile von HL7 Deutschland mit IHE PAM zu harmonisieren.

Daraus ergeben sich zwei Schritte:

  1. Anpassung HL7 Spezifikation Deutschland. Stand: Inhaltich abgeschlossen. Administrative Schritte stehen noch an, um das einer formalen Ballotierung zu unterziehen.

Hausaufgaben:

  • Frank macht die PDFs für die Spezifikationen fertig. Planung diese über den Sommer für ein Ballot freizugeben (2-3 Monate).
  • Ankündigung der Ballotierung
  1. Einreichung Änderungsvorschläge an das IHE Committee. Stand: 4 Change Proposals wurden erstellt. 1 CP wurde bereits in dem letzten Ballot eingeschlossen. Eins ist in dem aktuellen Ballot eingeschlossen. Die zwei letzten Change Proposals werden zukünftig eingereicht. Teilnahme an Telefonkonferenzen von dem IHE Committee. Weitere Teilnahme geplant, um die weiteren zwei Proposals einzubringen. Aktuell sehr unbefriedigende Kommunikation mit dem IHE Committee .

Hausaufgaben:

  • Change Proposals werden im Herbst im Ballot eingestellt
  • Harmonisierung Struktur und Semantik
  • Überführung in ein maschinenlesbares Format (Tooling würde vieles einfacher machen); Anmerkung Frank: Es befindet sich aktuell ein Tool bei NIST in Entwicklung: "Implementation Guide Authoring Tool". (Der Entwickler der MWB ist letztes Jahr verstorben.) Probleme von MWB: Code nicht vollständig; Lizenzfragen für verwendete Komponenten sind nicht vollständig geklärt. Trotzdem gibt es in den USA Bestrebungen sich weiter um das Tool zu kümmern.

HL7 CDA

Frank erklärt die Ebenen vom CDA. Frank stellt die Header Level Templates im WIKI vor. Problematik: Leitfäden wurden parallel entwickelt. Teilweise Header kopiert, teilweise unterschiedliche Strukturen der Implementierungsleitfäden im Header. Daraus resultiert eine Menge von Header Level Templates, die doppelt (z. b. zwei Mal Autor) sind. Diese müssen auf Gleichheit untersucht werden.

Mögliches Ergebnis bei recordTarget: 3 Templates für den Patienten: 1)Patient mit kompletter Identifizierung 2) pseudonymisierter Patient und 3) anonymisierter Patient. Management der Template erfolgt auf Basis der Template ID. Vorhandene Templates können in neue Implementierungsleitfäden inkludiert werden. Es wird diskutiert, welche verständlichen Darstellungsformen im WIKI möglich sind.

Frank erstellt im WIKI die Seite CDA-IG-Grundlagen (CDA Grundlagen für Implementierungsleitfäden). Diese Seite soll ein Verständnis über die Zusammenhänge zwischen Implementierungsleitfäden und Templates geben. Weitere Details siehe WIKI. Frank präsentiert die Methodik am Beispiel CDA MIK.

RecordTarget ist damit abgeschlossen.


Diskussion zu Vorgehen mit Tabelle: Tasks / Action-Items

Daniel regt an, Projekttabelle mit TO-Dos und aktuellem Stand anzulegen, um Übersicht zu bewahren und Projekte schneller voranzutreiben.

Ziel ist es, die Templates im Wiki durch ART-DECOR automatisiert zu erstellen. Dazu muss aber erstmal klar sein, wie die Templates strukturiert sind und was diese enthalten sollen.

Primärer Fokus: welche Informationen brauchen wir, Überführung in ART-DECOR und Verwendung eines Tool ist dazu nachrangig.

1. Schritt: validieren gegen ELGA und ART-DECOR => Zunächst ist zu prüfen, ob Wiki fachlich mit den Dingen in Art-decor und ELGA übereinstimmen (an offizieller Spec orientieren, Elga-Homepage als primäre Quelle/Orginal)

ELGA hat generischen Header für alle Leitfaden, machen versionierte Leitfäden. Der Aufbau für unsere Templates ist auf der Hilfeseite beschrieben.

Daniel hat die Vorstellung, dass die Arbeitsgruppen zumindest einmal zwischen IntOp-Forum eine Telko machen, um sich abzustimmen und offene Fragen zu klären.

Frank: Vergleich von PDF-Leitfäden ist heute nicht mehr zeitgemäß und zielführend. Arbeit muss toolbasiert erfolgen können.

Daniel: Redundanzen aus dem Wiki herausarbeiten/entfernen.

Daniel: Zielgruppe für Wiki sollen Entwicklungsleiter sein (darf auch schon technisch sein, aber Zusammenhänge müssen klar werden)

Festlegungen, welche Bestandteile in die Templates hineingehören wurden am Tag 1 (10.06.2013) getroffen.

Vorgehen:

  1. Im R-MIM nachsehen, ab Kardinalität 1
    • Information Recipient (Adressat, der auch auf dem Papier aufgeführt würde)
    • Autor
    • Custodian (verwaltende Organisation)
    • Recordtarget
  1. Basis sind Templates für eArztbrief, alle anderen werden nur mit Modell und Constraints dargestellt
  2. Templates mit ELGA und art-decor abgleichen
  3. Mit mandatory-Fields anfangen

Der annonymisierte und der pseudonymisierte Record-Target müssen nach der Vorgabe (Protokoll 10.06.) überarbeitet werden. Authenticator soll zunächst nicht nicht betrachtet werden (im Unterschied zu legal authenticator)

Template "participant"

Daniel Flemming stellt das „participant" Template vor: http://wiki.hl7.de/index.php/Cdaepb:weitere_Beteiligte_(participant)

Daniel Hellmut listet die Templates aus ELGA: Es wurden mehrere Templates erstellt. Unterscheidung über den typeCode und functionCode (z.B. Hausarzt PCP)

Frank Oemig generischer participant entwickeln und in den Namespace cdaab2 überführen. Weitere Spezialisierungen von "Beteiligte" sind "Einweiser" und "Zuweiser"

Diskussion – Es gibt drei Möglichkeiten für betreuende Einrichtungen (custodian, recordTarget->Organisation und über participant) - Festlegung, dass Betreeunde Einrichtungen über den recordTarget abgebildet wird.

Kurze Diskussion zum Notfallkontakt – es gibt einen speziellen functionCode dafür Daniel Hellmut: Elga unterscheidet über functionCode und typeCode – Vorschlag nur den functionCode zu verwenden. Hier nochmal Absprache mit Kai Heitmann notwendig

WYSIWYG-Editor für das Wiki

Mathias präsentiert einen WYSIWYG-Editor, der als Plugin alternativ zum Standard-Wiki-Editor verwendet werden kann. Hausaufgabe: Den WYSIWYG-Editor ins Wiki einzubinden (Mathias, Kai)

Hausaufgabe: Offene Aufgaben ([3]) werden zusammengefasst und Arbeitsgruppen zugewiesen. Hausaufgabe: Festlegung bis zum nächsten Interoperabilitätsforum sollen die Aufgaben abgearbeitet werden.


Bereinigung und Aktualisierung der Liste der Action Items

Zuordnung von Verantwortlichen und Deadlines: siehe Wiki http://www.wiki.hl7.de/index.php/IF_Action_Items


Fragen von Mathias zum Leitfaden meldepflichtiger Krankheiten

"Transclude": Kann bei unachtsamer Nutzung zu Verschachtelungsfehlern im Wiki führen. Ein Transclude soll deshalb nur im Leitfaden selbst erfolgen und nicht rekursiv. (Frank stellt die korrekte Verschachtelung von Verweisen anhand des CDA-Arztbrief-Leitfadens dar.)

Franks Dokument zur Template-Architketur, das die Struktur der Wiki-Seiten grafisch darstellt, wird wikifiziert (siehe Action-Items)

Informationen zur Template-Architektur sind im Wiki redundant unter den Kapiteln "CDA-Arztbrief", "Leitfaden" und "Hilfe zu Implementierungsleitfäden" aufgeführt und sollten zusammengefasst werden.

Frage zur Darstellung von uncodierten Diagnosen: "Freitextdiagnosen" sollen als separate Section eingepflegt werden. Näheres dazu regelt der Diagnoseleitfaden.

Daniel zeigt Vorschlag aus DAGIV-Dokument. Parallel dazu sollte nach neuen geeigneten LOINC-Codes Ausschau gehalten werden.

Angabe von Symptomen und deren Verlinkung zu Diagnosen: Separate Sections für Symptome ungünstig, da die Beziehung zu Diagnosen hergestellt werden muss. Dann wäre nur noch eine Diagnose pro Section möglich. Besser wäre eine Liste von Observations (Diagnosen und Sympotomen), die dann untereinander verlinkt werden.

Leitfaden für Arztmeldebogen und Labormeldebogen sollte in zwei separate Leitfäden getrennt werden, da es sich an unterschiedliche Interessenten richtet.


Allgemeines zu CDA-Leitfäden

Konvention beim Transclude von Templates: Zusatz "generisch" in der Überschrift bei Transclude ohne Änderung. Bei Transclude mit Einschränkung muss der Zusatz "spezialisiert" angefügt werden

Der Umgang mit Mehrfachvererbung und der Deklarierung der generischen Templates als offen/geschlossen ist zum aktuellen Zeitpunkt noch unklar.

Das Thema der Deklarierung soll in der nächsten TelKo aufgegriffen und im nächsten Meeting erneut diskutiert werden, die Mehrfachverwebung wird wieder aufgegriffen, wenn der Fall tatsächlich eintritt.


Medienpartner

Unsere Medienpartner sind:

kma eHealthcom KH-IT
Abgerufen von „https://wiki.hl7.de/index.php?title=IF_2013-06-10&oldid=15311“