Zeisberg GmbH
Protokolle
medicaide ermöglicht die Spezifikation verschiedener Ausprägungen der gängigen Protokolle (HL7, GDT), um diese an verschiedene Kommunikationspartner wie Klinik-Informationssysteme, Praxisverwaltungssysteme und Medizingeräte anzupassen. Die Auswahl des geeigneten Protokolls erfolgt dabei an unterschiedlichen Stellen, z.B. in Konfigurationsdateien im Fall von Diensten wie dem der HL7-Schnittstelle oder in weiteren Konfigurationsschritten z.B. beim equipment_mapping
(siehe unten).
Felder zur Spezifikation von Protokollen
protocol_id
Die ID der Protkolle wird vom Systemverwendet und dient zur Referenzierung.
protocol_name
protocoll_name und protocoll_version müssen zusammen eindeutig sein. Sie dienen einer leserlichen Identifikation der Protokolle. Es bieten sich hierfür beschreibende Angaben wie z.B.
GDT tomedo v2.1
HL7 SAP-ISH 2.4
an.
protocol_version
s.o.
method_field
Kennzeichnung des Feldes, das im jeweiligen Protokoll die zur Untersuchung angeforderte Methode überträgt.
GDT verwendet hierfür häufig “8402”.
HL7 kennt dafür z.B. das Feld “OBR.4.1”
equipment_field
Kennzeichnung des Feldes, in dem ein spezifisches Gerät für die Durchführung einer Untersuchung gefordert werden kann. Die Angabe dieses Feldes ist optional. Wird kein spezifisches Equipment bei der Untersuchungsanforderung festgelegt, so wird die Durchführung der Untersuchung an allen Arbeitsplätzen angeboten, an denen Equipment installiert ist, das aufgrund der definierten equipment_capabilities
(s.u.) zur Durchführung der Untersuchung geeignet ist.
Im GDT Protokoll kann hierfür z.B. das Feld “8410” verwendet werden. In HL7 ist beispielsweise “OBR.4.3” geeignet.
protocol_facility
Das Feld hat für den Betrieb von medicaide keine Bedeutung. Es dient der Kennzeichnung von änlichen Protokollen, die in verschiedenen Einrichtungen modifiziert verwendet werden.
output_map
Das Feld output_map enthält eine JSON Struktur, mit der die Übertragung der internen Datenfelder in die Felder des Zielprotokolls ermöglicht wird.
Zur Erläuterung dient folgendes Beispiel: hier wird eine GDT Datei für ein Messgerät generiert.
{
"3000": ["PID_intern", "%08d"],
"3101": ["Names.Surname_prefix", "L", "Names.Surname", "L"],
"3102": ["Names.Given_name", "L", "Names.Further_given_names", "L"],
"3103": ["Dob", "02012006"],
"3104": ["Names.Degree", "L"],
"3105": ["Insurance.Policy_number", ""],
"3107": ["Adresses.Street_address", "L"],
"3108": ["Insurance.Insurance_status", ""],
"3110": ["Gender", "GDT2"],
"3112": ["Adresses.Zip_code", "L"],
"3113": ["Adresses.City", "L"],
"3114": ["Adresses.Country", "L"],
"3116": ["Insurance.Company_region", ""],
"3618": ["Telephone", ""],
"3619": ["Email", ""],
"3628": ["Language", ""],
"8315": ["audioApp", "COPY"],
"8316": ["medicaide", "COPY"]
}
Der Aufbau der struct entspricht einer Map von string → []string. Der Schlüssel gibt die Feldkennzeichnung im Zielprotokoll an, der Schlüssel ist ein Array aus Strings, die jeweils paarweise das interne Datenfeld und dessen Formatierung benennen.
Das GDT-Feld 3000 (Patienten ID) wird mit dem internen Feld “PID_intern” gefüllt, formatiert als 8 Zeichen lange Zeichenkette aus Ziffern mit führenden Nullen.
Das GDT-Feld 3101 (Nachname)
input_map
Not yet in use.
protocol_use
Gutenbergstrasse 39 * 72555 Metzingen
Achtung: Ausgedruckte gelenkte Dokumente sind nicht gültig!
Die gültige Fassung ist in Confluence abrufbar.