Interoperabilitätsforum / TC-Arbeit 2. und 3. Dezember 2013 in Köln

Veranstaltungsort und -zeiten

Eden Hotel Früh am Dom
Sporergasse 1
50667 Köln
Tel.: 0221 / 27 29 20

Siehe auch Abschnitt Hinweise.

Das Interoperabilitätsforum diskutiert und bearbeitet Themen zur Standardisierung der Technischen Komitees der HL7-Benutzergruppe, IHE Deutschland und anderer Standardisierungsaktivitäten im Gesundheitswesen.

Vorgesehene Agenda

• Administrativa
  • Protokollführung
  • Genehmigung Protokoll
  • Status offene Aufgaben
  • Wiki: Startseite
  • Arbeiten mit Arbeitskreisen

• Strategisches
  • Fortsetzung der Diskussion über die Arbeitskreis im Forum
  • Planungsstudie des BMG mit der darin besonders erwähnten Rolle des Interop-Forums
  • IHE MHD, HL7 FHIR en RESTful DICOM (René)

• Auflösung Kommentare zu abgelaufenen Ballotverfahren
  • EFA 2.0 (verschoben vom letzten Meeting)
  • Cookbook (verschoben vom letzten Meeting) (Mo)
• Abgeschlossene Ballots
  • Infektionsschutz (Arztmeldung)
  • deutsche Nachrichtenprofile
• Neue Verfahren
  • Infektionsschutz (Labormeldung, Lars, Montag)

• neue Leitfäden
  • Arztbrief 2013
  • AkdÄ-Medikationsplan
  • Pathologiebefund/Krebsregistermeldung -> APSR: aktueller Stand
  • ePalliativdokumentation (Houta)
  • Pflegeüberleitung CDA (Jonas Schwartze, Dienstag)
  • ..

• CDA-Templates (offene Fragen, Status)
  • Header
  • Section
  • Entry

• HL7 v2.x
  • offene Anfragen
  • Z-Segmente
  • weitere National Extensions
  • deutsche Anforderungen für v2.9

• Planungsstudie
  • aktueller Stand
  • weiteres Vorgehen

• Terminologien
  • Infektionsschutz/Keime/Erreger (Sylvia, Montag)
  • OID-Register (Verfahrensweise, DIMDI+Kai, Montag)

• Security
  • Security Label (Di vorm.)

• Sonstiges

Protokoll

Administrativa

Vorstellungsrunde

Anwesende: Ralf Brandner; Daniel Hellmuth; Daniel Flemming; Christof Geßner; Simone Heckmann; Kai Heitmann; Alexander Ihls; Stefan Müller-Mielitz; Frank Oemig; Timo Kahlert; Peter Scholz; Andreas Schulz; Bernd Schütze; Norbert Sigmond; René Spronk; Sylvia Thun; Lars Treinat; Marek Vaclavík; Fakhri Zain Elabdin; Zaki Elbara; Matthias Aschhoff; Thomas Nitzsche; Markus Mechnich; Dominik Brammen; Bogdan Zyla; Elisabeth Pantazoglou; Heike Dewenter; Sonja Kreuels

Protokollführung

Elisabeth Pantazoglou, Bogdan Zyla, Heike Dewenter (Hochschule Niederrhein)

Genehmigung Protokoll

Es gibt keine Einwände oder Korrekturwünsche zum Protokoll vom September 2013. Das Protokoll ist somit genehmigt.

Status offene Aufgaben

Es wird durch die Liste der offenen Aufgaben gegangen.

• Arztbrief: Abgleich/Erarbeitung heute
• eTrainingsplan: Weitere Erarbeitung durch das Team aus Heidelberg, heute nicht anwesend
• Kurze Berichte von den abgeschlossenen Ballots
• Thema Cookbook wird verschoben: Einzelheiten sind nachzulesen im Wiki
• Vorstellung Thema Infektionsschutz: Labormeldung
• Arztbrief 2013soll heute zu Ende spezifiziert werden
• Vorstellung des Leitfadens zum Medikationsplan
• CDA-Templates; CDA-Arztbrief; Planungsstudie

Wiki-Startseite

Die möglichen Alternativen wurden beim letzten Treffen vorgestellt. Es gab zwischenzeitlich keine Rückmeldungen bzw. Beschwerden oder Verbesserungsvorschläge bzgl. der Umstellung. Die Hauptseite wird demnach in den nächsten Tagen umgestellt, die alternative Seite wird unter „Diskussion“ weiter bestehen bleiben.

Agenda

Es gibt keine zusätzlichen Punkte zur vorab veröffentlichten Agenda für heute und morgen.

HL7 v2.x

Offene Anfragen

IBAN und BIC

Es gibt zwei mögliche Varianten, die IBAN und BIC einzubinden. Dabei ist zu beachten, dass die BIC vorhanden sein muss, obwohl die IBAN ausreicht. Zum Übertragen solcher Daten soll das CX Datensegment verwendet werden, da dieses oft als Behälter für Bankdaten verwendet wird.

Die IBAN soll in CX-4 „Assigning Authority“ angedeutet werden, welches aus weiteren vier Subfeldern besteht. Die IBAN nach ISO 13616 soll nur noch über Assigning Authority abgewickelt werden. Bei ISO 9362 sind SWIFT und BIC identisch.

Eine Mandats-Nummer ist ein Problem, da dies im CX Segment nicht vorhanden ist. CX-11 ist nun die Mandats-Nummer, CX-12 ist die ID für die Mandats-Nummer, diese muss allerdings noch bestimmt werden.

In 1.3 ist ein Daten Feld von CX in 1.31, vom Typ Lastschrift. Art und Umfang von Kostenübernahme, nicht komplett Rechnung sondern nur Telefon? und 2.29. um gewissermaßen eine Einschränkung zu machen.

Wie unterscheidet man Kassen von Selbstzahlern oder sonstige voneinander? Mit der Patient Insurance, von der Tabelle 1.2 Tab 72/ P 2.5. Da steht p für Patient und o für andere.

Für ein HL7 Nachrichtenprofil soll für eine Abstimmung geklärt werden, ob es in anderen Staaten genauso gehandhabt wird. Die Information zur Nutzung von IBAN und BIC werden dazu an alle Affiliate Chairs gesendet. Diesbezüglich soll auch nachgefragt werden, ob schon was anderes existiert.

In die Table 3.01. ISO 9362 , 13616 mit reinbringen.

In das Sub Name der Bank Sub ID IBAN Registry.

Im Verfahren wie die Nummer vergeben wird IBAN eintragen. TMN, TermInfo-Problem, vorne BLOB, mit kompletten String, und hinten nur das es sich um die IBAN handelt.

ISO 13616 2007-1 alias fürs SEPA, OID 13616. Das englische Proposal muss an die anderen Übermittel werden und das deutsche wird der Gruppe per Mail, von Frau Heckmann, zugesandt.

Z-Segmente, weitere National Extensions, deutsche Anforderungen für v2.9

Nicht weiter besprochen.

Strategisches

Fortsetzung der Diskussion über die Arbeitskreise im Forum

Arbeitsgruppen zu verschiedenen Themen wie Arztbrief, Labormeldung Infektionsschutz etc. sind so gut wie abgeschlossen und können nun in Ballot-Pools „umgewandelt“ werden. Die Templates sollen besonders betrachtet werden.

Nächstes Jahr wird es zwei Treffen in Berlin und zwei in Köln geben. Das Mieten von weiteren Räumen steht aus Kostengründen zur Diskussion. Wenn die Veranstaltung beim DIN stattfindet, erfolgt dies zusammen mit der ISO-Tagung, dies würde an einem Tag zu einem Engpass führen. Die Diskussion darüber soll später erfolgen.

XING

Es gint eine XING-Gruppe für Teilnehmer des Interop-Forum. Gruppe dient primär informationellen Zwecken (who is who), weniger dem fachlichen Austausch. Kontaktanfragen bitte an Simone Heckmann

IHE MHD, HL7 FHIR en RESTful DICOM, Anwendergruppen (René)

René stellt die drei Standards

• IHE MHD
• HL7 FHIR
• RESTful DICOM

und deren unterschiedliche Basisfunktionen in Bezug auf mobile Anwendungen vor.

Die Gemeinsamkeit der Standards liegt in der Verwendung von http als Transportprotokoll und einer einheitlichen URL, z.B. für Patienten-Identifier. Sie sind alle geeignet für Hypermedia-Anwendungen.

Basisfunktionen in HL7 FHIR (Fast healthcare interoperability resource)

HL7 FHIR besteht aus einem unabhängigen Datenblock in dem eine Patientenressource als kleinste zu identifizierende Einheit vorkommt. Es wurde eine Liste mit ca. 150 Ressourcen aufgestellt, die es ermöglichen sollen, alles im Gesundheitswesen weitestgehend abzudecken. Es finden nur die Datenelemente Beachtung, die zu mindestens zu 80% im Gesundheitswesen benutzt werden. Datenelemente, deren Vorkommen unter 80% liegt, bilden Ausnahmen und sind (individuell) als Extensions zu deklarieren. Davon gibt es ziemlich viele, für deren Einbindung aber ist ein Vorgehensmodell vorgesehen. So ist z.B. das Datenelement „Rasse“ aus dem amerikanischen Raum, dessen Anwendung im europäischen Raum die 80%-Hürde nicht erreicht bzw. sogar nicht erlaubt ist, selbst für die Amerikaner nur noch als Extension vorgesehen.

Die Daten liegen in strukturierter Form vor. Darüber hinaus gibt es aber auch eine textuelle Zusammenfassung, die menschenlesbar ist. Hier besteht eine große Ähnlichkeit zur CDA. Die Anwenderfreundlichkeit wird darüber hinaus durch Hyperlinks gefördert.

Die Metadaten im Header-Dokument liegen als versionierte Ressourcen mit textuellem Teil vor.

Status von FHIR

Die erste Draft-Version dieses Standards soll 2014 erscheinen. Schätzungsweise erfolgt dann wiederum nach einem Jahr die erste normative Variante. Während die administrative Technologie bereits ausgereift ist, ist der medizinische Bereich noch erweiterungsfähig.

IHE MHD (Mobile Excess to Health Documents)

Der Fokus dieses Standards liegt in der Smartphone Unterstützung. Die Nutzung als Webservice ermöglicht dem Anwender, RESTful Protokolls zu nutzen bzw. hochzuladen und mit FHIR zu updaten.

Status von IHE MHD

Der erste Draft ist erschienen.

RESTful DICOM

Der Transport erfolgt bei diesem Standard sequentiell. Das heißt, Metadaten und Pixeldaten werden bei RESTful DICOM losgelöst voneinander transportiert. So besteht dadurch z.B. die Möglichkeit, erst die Metadaten zu laden um im Anschluss das gesuchte Bild zu laden und so neue Befunde zu alten Dokumenten einfach hinzuzufügen. Dadurch wird die benötigte Bandbreite niedrig gehalten und das Austauschverfahren optimiert. Bei den Information Entities ist das DICOM-Verfahren äquivalent zu FHIR.

Fazit

Alle Standards unterstützen RESTful Protokolle. Bei den XDS-Registry-Dokumenteninhalten handelt es sich um versionierte Ressourcen mit der Möglichkeit der textuellen Darstellung.

Alle bewegen sich in die Richtung der disruptiven Technologie, diese kommt zum Einsatz bei OpenAPIs und legt alle Daten offen, um Zusatzapplikationen zu ermöglichen. Durch Federated Metadata Repositories erfolgt eine Verknüpfung auf lokaler Ebene, die Teilnehmer im Gesundheitswesen können mit ihren Devices darauf zugreifen, z.B. Handy-Frage-Antwort-Verfahren.

Die Standards passen folglich in diese neuen Arbeitsmethoden und sind alle miteinander verlinkt.

Anmerkungen

• Gefahr der Begriffsvermischung→Eindeutige Bezeichnung notwendig.
• Anstatt openAPI gibt es auch andere Lösungen.
• RESTful ist „Hacker-geeignet“, jedoch bei schnellen Ergebnissen gut zu verwenden.
• FHIR für „Implementierer“ zurzeit besser geeignet als für „Semantiker“ (Kai).

Vorstellung von Anwendergruppen (AID) als Überblick für Deutschland

Die Anwendergruppen AID (Application Implementation and Design, früher RIMBAA) tauschen Erfahrungen z.B. über die Art von Software-Architekturen aus. Die Gruppe ist Anwender-orientiert (Heilberufler, Implemementierer, etc.).

AID Anwendergruppen gibt es seit 2006, die Teilnahme ist kostenfrei. Es finden face-to-face Meetings in ganz Europa statt mit dem Ziel best practices zu publizieren und Implementierungen zu überprüfen.

HL7 International möchte ähnliche Anwendergruppen gerne als Membership-Benefit positionieren. Der Fokus wird dabei jeweils geografisch gesetzt, z.B. Anwendung in allen deutschsprachigen Ländern.

Abgrenzung

Bei HL7 Affiliates handelt es sich nicht um eine Anwendergruppe. Hier werden losgelöst von den Anwendern Lokalisierungen vorangetrieben und Leitfäden geschrieben.

Bei der Interntaional HL7 Interoperability Conference (IHIC) handelt es sich um internationale Treffen, die praktische Implementierungsaspekte berücksichtigt aber auch akademische Belange behandelt.

Bei Connect-a-thons handelt es sich um User-orientierte Treffen auf internationaler Ebene.

Auflösung Kommentare zu abgelaufenen Ballotverfahren

EFA 2.0 (verschoben vom letzten Meeting)

Das Dokument wurde auf dem HL7 Wiki veröffentlicht.

Ende November wurde das zweite Abstimmungsverfahren abgeschlossen.

Es gab ca. 240 Kommentare, einige davon wurden hinten angestellt wegen noch offenen Peer-Verfahren. Diese werden Anfang nächsten Jahres abgearbeitet, zusammen mit der Anforderung die „Patientenzustimmung“ im CDA abzubilden. Als Grundlage soll das amerikanische Profil adaptiert werden. Die Spezifikationen dienen für das Single-Peer-Verfahren und wurden auf Anregung des EFA-Vereins veröffentlicht. Das zukünftige Profil soll umfassender und ergänzend zum derzeitigen sein. Eine Finale Draft soll als PDF erscheinen und als Angebot zum Download in einer eingefrorenen Version zur Verfügung gestellt werden. Darüber hinaus soll es Pressemitteilungen mit Link z.B. an bvitg, DIN, HL7 und IHE geben.

Anmerkungen:

• Abstimmungsmöglichkeiten mit anderen Projekten, z.B. Pflegebericht.
• Spätestens wenn das Peer-Verfahren abgeschlossen ist, sollten alle Kommentatoren über den Umgang mit den Kommentaren informiert werden.

Cookbook (verschoben vom letzten Meeting) (Mo)

Die Abstimmung über das Cookbook ist erfolgt und weitestgehend abgeschlossen. Die Kommentierung ist abgeschlossen, nun erfolgt die Erarbeitung. Es besteht eine Diskussion über die Aufteilung der Aufgaben wie z.B. Management-Aufgaben und technische Aufgaben. Diese soll in der ganzen Gruppe erfolgen.

Fehlende Punkte

Themen Netzwerkkommunikation und Patientenzustimmung

Am Beispiel der Schweiz zur Interoperabilität im Bereich Telemonitoring und Telekardiologie soll eine Erarbeitung und Spiegelung mit dem Cookbook durchgeführt werden. Erweiterungen und Ergänzungen sollen dadurch erfolgen.

Es gab ca. 120 Kommentare, die „major-negatives“ wurden nachfolgend in Telefonkonferenzen durchgesprochen und Antworten formuliert. Andere Vorschläge wurden vorformuliert und zur Diskussion eingestellt, es gab dazu keine Kommentare bisher.

Anmerkungen:

• Für Außenstehende schwer zu verfolgen, Wunsch nach einer Beispielimplementierung um die Zugänglichkeit für einen weiten Kreis zu ermöglichen.
• Die Seite ist öffentlich zugänglich, ohne Zugangsbeschränkungen.
• Übergang zu Neuspezifikationen: dedizierte Auflistung; sodass bei einer Umstrukturierung Verweise auf die Neuerungen erfolgen können.

To do: In alle Leitfäden soll ein Standard-Disclaimer; z.B. LOINC, SNOMED

Abgeschlossene Ballots

Infektionsschutz (Arztmeldung)

Beim Abstimmungsverfahren zur Infektionsschutzmeldung durch die Arztmeldung wurden alle Fragen bearbeitet. Die neue Version wird als PDF in den nächsten Tagen veröffentlicht. Als weiteres Vorgehen ist die Beantragung einer National Extension vorgesehen.

Deutsche Nachrichtenprofile

Beim Abstimmungsverfahren zum Ballot der Nachrichtenprofile sind noch kleinere Überarbeitungen notwendig. Das Technical Framework ist in Überarbeitung. Das Technical Committee Proposal lautet, dass sich zum Thema „Tod des Patienten“ ein eigenes Ballot ergibt.

Die anderen drei Ballots sind verabschiedet und final.

Anmerkungen:

• Überlegungen ob Word Dokument oder Wiki-Veröffentlichung. Am geschicktesten erscheint erst einmal ein Word-Dokument mit anschließender Verknüpfung zum Wiki.
• Idee von einem Tool (IGAM) das alle Dokumentationsarten zusammenfasst, evtl. Vorstellung beim nächsten Treffen

Neue Abstimmungsverfahren

Infektionsschutz (Labormeldung, Lars, Montag)

In Österreich und der Schweiz sind ebenso Infektionsschutzmeldungen definiert, dort wird der Austausch bald möglich sein. Für die deutsche Spezifikation können einige Objekte übernommen werden. Im Projekt wird der Probebetriebe gestartet, um herauszufinden ob noch nachjustiert werden muss.

Header

Anmerkungen:

• Patient, Author, Verwalter können im Wesentlichen aus der Arztmeldung übernommen werden.
• Unterzeichner wird nicht verwendet.
• Empfänger (Gesundheitsamt) kann übernommen werden.
• Participant “Einsender” muss neu erstellt werden
• Service Event (Dienstleistung) mit Labor-Identifikation muss eingebaut sein.

Laboratory Body

Anmerkungen:

• Specimen Assessment ACT bündelt Abnahme, Abgabe und Labor Informationen.
• Wird auch von der Schweiz benutzt, landesspezifische Erweiterung sind nötig (zum Beispiel Value Sets).
• Im Notification Organizer sind die Erreger und die Meldepflichtige Krankheit codiert.
• Laboratory Observation kann mit Anpassungen übernommen werden, muss DEMIS kompatibel sein. Wie findet man die richtigen Codes?
• Ergänzendes Value Set laut vom RKI surfnet; manche Erreger sind nicht ganz mit LOINC abbildbar, da Methoden oder Material nicht definiert sind, evtl. eigene Value Sets für Methoden oder Materialen erstellen. Prä-koordinierte LOINC Codes sollen eher nicht benutzt werden sondern Post-koordiniert, also drei Achsen: Erreger / Material / Methode

Neue Leitfäden

Arztbrief 2013

Am Freitag den 29.11.2013 fand ein Meeting bezüglich des Implementierungsleitfadens statt.

Seit langer Zeit besteht das Bestreben den Arztbrief 2013 herauszubringen, dieser ist fast fertig gestellt. Es müssen noch redaktionelle und fachliche Arbeiten geleistet werden.

Die Struktur und der Aufbau wurden redaktionell überarbeitet, der Lesefluss insgesamt verbessert. Der Header wurde fertig gestellt, Header und Section-Templates wurden in in ART-DECOR definiert.

Im Forum erfolgt der Vergleich der Sections beim Arztbrief 2013 (2.0), Vergleich zu ELGA (Ärztlicher Entlassbrief) und Consolidated CDA 1.1 Es soll in Gruppen diskutiert werden auf welche Sections man sich im Arztbrief 2013 einigt. Wo liegen die Unterschiede?

Beispiel: Anrede wird in ELGA: Brieftext genannt

Verschiedene Aspekte werden diskutiert/festgestellt:

Fragestellung: Reason for Referral/Aufnahmegrund

Medikation: Vier Sectionsnötig: Medikation bei Einweisung, während des Aufenthaltes und bei Entlassung sowie empfohlene Medikation (Bemerkung: Hospital Medication im Arztbrief).

Epikrise: Prognose (fraglich), Zusammenfassung des Aufenthaltes, Plan of Care (Empfehlungen), ggf. Hospital Discharge Instructions

Anamnese: ELGA und C-CDA relativ ähnlich, grobe Einteilung in aktuelle und frühere Krankheiten. Wichtig als eigene Sections: Jetzige Anamnese, frühere (stattgefundene) Erkrankungen, Familienanamnese, Schwangerschaften (nicht letztlich geklärt), Immunisierung.

Diagnosen: Aufnahme und Entlassungsdiagnose werden dokumentiert (gleiche LOINC-Codes C-CDA und Arztbrief 2013)

Fragestellung am 03.12. primär zu klären: Zu welchen Sections benötigen wir Entries (CDA Level 3)?

Antworten:

• Nach wie vor für Diagnosen
• Für Operationen und Prozeduren (Entry: Procedures: OPS)
• Medikation Medication Activity: ATC/PZN
• Immunisierung (neues Codesytem „Schutzimpfungs-Richtlinie“ des Gemeinsamen Bundesausschuss), OID wird benötigt
• Laborwerte
• Pathologie mit Diagnosen: ICD 10GM, ICD-O und TNM
• Scores
• Allergien/Unverträglichkeiten (ICD 10 GM, Alpha-ID)

Generell soll eine neue Bezeichnung für das Dokument gewählt werden (ggf. Arztbrief 3.0 statt Arztbrief 2013)

AkdÄ-Medikationsplan

Es finden momentan viele Aktionen statt. Die wichtigste ist das der Plan standardisiert repräsentiert wird. Als „Mutterformat“ soll CDA dienen. In der Version 1.8 des Medikationsplans ist immer noch das |-Format vorgeschrieben.

Anfang nächsten Jahres soll der AkdÄ-Medikationplan weiter ausgearbeitet werden. Für eine Ausrichtung nach CDA als Mutterformat müssen Adaptionen vorhandener Templates durchgeführt werden, so zum Beispiel für die Dosierungszeitpunkte Morgens, Mittags, Abends, Nachts. Pathologiebefund/Krebsregistermeldung -> APSR: aktueller Stand Der Leitfaden ist nach wie vor in Arbeit. Es wird ein Template ausgearbeitet welches generisch auf den gemeinsamen Grundlagen basiert. Mit den Ausführungen in IHE Anatomic Pathology soll der Leitfaden ergänzt werden.

ePalliativdokumentation (Houta)

Nicht besprochen.

Pflegeüberleitung CDA (Jonas Schwartze, Dienstag)

Die „ehealth.Bank - Gesundheitsdatenbank Niedersachsen“ adaptiert die Idee der „Health Record Bank“. Es geht um Kommunikation z.B. Klinik- ambulante Pflege, Pflegeüberleitung.

Das Ergebnisdokument soll Daten enthalten wie z.B. Wundbeschreibung, MRSA-Sanierungsstand, Medikation etc.

Joans zeigt eine Demonstration des Pflegeüberleitungsbogens (als Formular/Papierdokument) Fragen von seiner Seite:

• Darf das Record Target angepasst werden?
• Wie verfahren mit neuen Codesystemen?
• Wie verfahren mit „fremden“ Templates, die schon in anderen Projekten definiert wurden
• Wie verfahren bei Section Level Templates?

Als nächstes wird eine Pflegeüberleitungs-Projektseite im WIKI angelegt und die Fragen dort dokumentiert! Nächster Schritt ist, die Anforderungen an die Templates zu formulieren und daraus die Templates im Entwurf zu generieren.

CDA-Templates (offene Fragen, Status)

Diese Punkte wurden bei den Leitfäden selbst besprochen.

Planungsstudie (Di früh)

aktueller Stand

Die Planungsstudie ist fast abgeschlossen Historie:

• Herbst 2011 – Workshop im BMG zur Semantischen Interoperabilität
• 30 Januar 2012 – AG Interoperabilitätsoffensive“ Meeting im BMG
  • Ankündigung eine Planungsstudie ausschreiben zu wollen

15. Mai 2012 Vorentwurf der Studie vom BMG vorgelegt

Weiteres Vorgehen

Vorgeschlagene Organisation zu Umsetzung: eHealth-Rat Entscheidungsgremium→ Geschäftsstelle→ Koordinator/Sekretariat → Standards/Anwendungen

Aufbau des nationalen eHealth-Rat:

• 9 bestellte Mitglieder
  • Gesundheitsausschuss des Bundestages nach Vorschlag des BMG
  • 5 für 5 Jahre
  • 4 für 4 Jahre
• 3 Vertreter der gematik
• 1 Vertreter der GMK der Länder
• 1 Vertreter des BMG

Terminologien

AKTIN-Projekt(Di)

Es handelt sich um ein Forschungsprojekt mit dem Ziel das deutsche Register für das Notaufnahmeprotokoll zu optimieren. Bei der Datensammlung wird auf das DIVI-Notfallprotokoll zurückgegriffen, wie z.B. die Datenpunkte Anamnese oder Medikation. Die Version 1.0 bildet die Grundlage für das AKTIN-Projekt. Im ersten Arbeitspaket werden durch die Hochschule Niederrhein die Items aus dem DIVI in semantische Notationen umgewandelt.

Es soll eine Abfrage auf das dezentrale Datawarehouse der teilnehmenden Krankenhäuser durchführbar sein, dafür müssen die Daten in anonymisierter Form vorliegen. Es dürfen keine Rückschlüsse auf den Patienten möglich sein. Die Wertedomain soll eine Auswahlliste mit möglichst guten Definitionen für den Dienstleister bieten ohne neuer Einfügungen zwischen den Werten auf Grund der Terminologien. Dazu muss eine Einigung über die Wortdefinitionen erfolgen. Als Problem erweist sich, dass es keine durchgängige IT-Unterstützung in den Notaufnahmen gibt. Und falls doch, muss die Möglichkeit des Exports gegeben sein. Als erste Idee soll ein Standard geschaffen werden und nur den Krankenhäusern, die diesen nutzen, sollen dann an dem Projekt teilnehmen dürfen. Ein weiteres Problem besteht in der Definition der Subsets, um nicht alle Informationen aus dem Datawarehouse abzufragen. Bisher gibt es 15 teilnehmende Standorte, die aus dem Projekt Zusatznutzen erzielen, wie z.B. die Durchführung epidemiologischer Untersuchungen.

Anmerkungen:

• Referenzierung der Systeme für bessere Interoperabilität (IHE konform)
• Metadatendefinionen sollen unabhängig von der Schnittstelle erfolgen
• Veröffentlichung auf der Wiki-Seite mit der Möglichkeit von Kommentaren u. Anmerkungen

Infektionsschutz/Keime/Erreger (Sylvia, Montag)

Wurde bei den Leitfäden „Infektionsschutz“ besprochen.

OID-Register (Verfahrensweise, DIMDI+Kai, Montag)

Herr Sigmond berichtet. Es gibt 7 neue OIDS, 3 neue Registrierungsverfahren (Äste), zum Beispiel für Templates und Value Sets.

Das OID Verfahren wurde 2004 von der KBV übernommen. OIDs müssen bei der zentralen Verwaltungsstelle im DIMDI gemeldet werden.

Krankenhäuser und deren Abteilungen kann man noch nicht alle identifizieren, da noch nicht alle über OIDs verfügen.

Herr Sigmodn erläutert das Vorgehen zu der Handhabung bei den Sybolic Names:zum Beispiel wurde „Medistar“ zu „Medistar-alt“ und die neue Firma bekam eine neue OID weil sich eine Firmenkonstellation geändert hatte. Die alte OID wurde deaktiviert und in die Beschreibung „out of use“ aufgenommen.

Herr Sigmond kann sich auch vorstellen, OID-Bereiche zu reservieren wobei über die reservierten Bereiche möglichst viele Informationen angegeben werden sollen. Evtl. können auch die SmybolicNames als reserved markiert werden damit keiner diese OIDs belegt.

Template OIDs für alle Templates des Interoperabilitätsforums werden beantragt.

Die Deutsche Krebs Gesellschaft (DKG) hatte OIDs für den Remmele Score beantragt. Momentan sind nur OIDs für die DKG vergeben, es sollten noch OIDs für die Wertetabelle und Scores vergeben werden. Des Weiteren sollen für nicht vorhandene Scores neue LOINC Codes beantragt werden. Es werden Codesystem und Value Set OIDs benötigt.

Es wird ausführlich besprochen, dass OIDs für Codesysteme und Value Sets notwendig sind, die Konzepte selbst (wie der Remmele Score) werden hingegen besser mit LOINC bezeichnet/identifiziert, da Einträge schon vorhanden sind.

Security

Security Label (Di vorm.) Kein Zuständiger erreichbar, daher verschoben auf das nächste Treffen. Sonstiges Frank und Christof berichten von einer Podiumsdiskussion mit Hr. Mainz und Hr. Mohr auf der Medica bzgl. Use Case “End-zu-End Kommunikation”.

• Es wurde die Behauptung aufgestellt, Freitext sei besser als Kodierungen.
• Terminologien: kein Unterschied zwischen stationär und ambulant
• Standardisierungsorganisationen leisten gute Arbeit.
• Kein Widerspruch zwischen Freitext und Standards (Codes).

Sylvia hat eine Anfrage der Asklepios bzgl. der Dokumentation von Sterilgut. Als Antwort wird angeboten, „MDM mit PDF“ zu nutzen, ggf. muss der Use-Case aber noch genauer beschrieben werden.

In Bezug auf SNOMED Lizenzen ergibt sich die Frage: Was bedeutet die Bezeichnung „public good licence“? Darf ein Service-Anbieter in diesem Sinne publizieren? Z.B. Infektionsschutz? Bisher gibt es noch keine Aussage von der IHTSDO und auch kein Rechtsgutachten. Die Schweiz hat zwischenzeitlich eine kleine Lizenz, Österreich ist in Überlegungen / Verhandlungen.

Es muss darüber nachgedacht werden um zum Beispiel eine Veröffentlichung (eHealth.com u.a.) zum Thema „Terminologien und Snomed“ zu etablieren, um Notwendigkeit zu verdeutlichen. Aus diversen europäischen Projekten berichtet Kai, dass von 100 Begriffen etwa 98 in Snomed als präkoordinierte Codes gefunden werden kann, der Rest muss entweder aus anderen Codesystemen kommen oder wird Snomed wird postkoordiniert.

Das AP 3 des BMG hat das Statement, dass Snomed CT genutzt werden soll. Es wird eine Kooperation mit WHO, GMDS etc angestrebt.

Hinweise

Teilnahme: An den Sitzungen können alle Interessierten teilnehmen, egal ob Mitglied bei HL7, IHE oder einer der kooperierenden Organisationen oder nicht! Um eine vorherige Anmeldung an office@hl7.de wird allerdings gebeten.

Zeiten: Das Treffen beginnt am ersten Tag um 10:30 mit Kaffee/Tee, um 11 Uhr beginnt die Besprechung. Am zweiten Tag beginnt das Treffen um 9 Uhr und dauert bis zu Nachmittag (meist ca. 15-16 Uhr)

Unterkunft: Für ein Zimmer im Eden Hotel Früh am Dom oder in einem der umliegenden Hotels sorgen die Teilnehmer selbst.

Gemeinsames Abendessen: Am 2. Dezember ab 19 Uhr im Haxenhaus, Kölner Altstadt, Anlauf siehe: http://www.haxenhaus.de/de/das-haus/ihr-weg-zu-uns

Medienpartner

Unsere Medienpartner sind: