HL7-D ADT & IHE PAM: Unterschied zwischen den Versionen
(→Differenzen PAM/HL7-D: ADT^A01) |
(→Differenzen PAM/HL7-D: ADT^A01) |
||
Zeile 1.283: | Zeile 1.283: | ||
|- | |- | ||
|PID-21 | |PID-21 | ||
− | |PAM: O | + | |PAM: O; |
+ | HL7-D Gemeinsame Elemente: C (5.5.13: "In diesem Feld werden die Identifikatoren der Mutter übertragen, wenn es sich bei dem Patienten um ein Kind handelt.") | ||
|FZE | |FZE | ||
|MV | |MV |
Version vom 8. März 2012, 13:56 Uhr
Diese Wiki-Seite fasst die Ziele, das methodische Vorgehen und die Verweise auf externe Ressourcen zusammen.
Inhaltsverzeichnis
Übersicht: IHE PAM - Administration Management
Das Integrationsprofil PAM sieht 4 verschiedene Akteure vor, die in 2 Transaktionen Daten austauschen:
Actor | Opt. | Transaction | Interaction | Direction | Opt. | Actor | Options | Kommentar |
---|---|---|---|---|---|---|---|---|
Pat. Demographics Supplier | R | Pat. Identity Management | ITI-030 | -> | R | Pat. Demographics Consumer |
|
|
Pat. Encounter Supplier | R | Pat. Encounter Management | ITI-031 | -> | R | Pat. Encounter Consumer |
|
Gegenüberstellung der Message-Types und Trigger-Events
Die nachfolgende Tabelle listet die ADT-Events mit den dazugehörigen Nachrichten auf, die entweder in den deutschen Profilen oder PAM genutzt werden. Bei PAM ist zu berücksichtigen, dass es hier mehrere Transaktionen mit unterschiedlichen Optionen gibt. Diese sind in jeweils eigenen Spalten aufgelistet. Abgerundet wird das Ganze mit Angaben zu identifizierten Problemstellen sowie den möglichen Auflösungen dazu.
Msg
Type + Trigg. Event |
Beschreibung | dt.
Profil |
PAM
ITI-30 Mrg |
PAM
ITI-30 Lnk |
PAM
ITI-31 Inp./ Outp. Mgmt |
PAM
ITI-31 Pending Evt. Mgmt, |
PAM
ITI-31 Adv. Enc. Mgmt |
PAM
ITI-31 Temp. Pat. T. T. |
PAM
ITI-31 Hist. Mov. |
Kommentare
(=ToDo) |
Status |
---|---|---|---|---|---|---|---|---|---|---|---|
ADT^A01 | Aufnahme | x | x all | x all | x all | x all | x all | Mit diesem Profil wurde begonnen. Es sind Korrekturen sowohl bei PAM als auch bei uns notwendig. | 2011-11-18: in Arbeit (Vaclavik, Oemig, Brandner, Lieske) MSH-4/6: ?? | ||
ADT^A02 | Verlegung | x | x in-/outpatient | x pending | Analyse fehlt | ||||||
ADT^A03 | Entlassung | x | x all | x all | x all | x all | x all | Analyse fehlt | |||
ADT^A04 | Besuchsmeldung (nicht-stationär) | x | x all | x all | x all | x all | x all | Analyse fehlt | |||
ADT^A05 | Voraufnahme eines Patienten (z.B. vorstationär) | x | x in-/outpatient | x pending | Analyse fehlt | ||||||
ADT^A06 | Änderung von ambulant in stationär | x | x in-/outpatient | x pending | Analyse fehlt | ||||||
ADT^A07 | Änderung von stationär in ambulant | x | x in-/outpatient | x pending | Analyse fehlt | ||||||
ADT^A08 | Änderung von Patienteninformationen | x | x all | x all | x all | x all | x all | Analyse fehlt | |||
ADT^A09 | Patient verläßt Einrichtung | x | x temporary | Analyse fehlt | |||||||
ADT^A10 | Patient erreicht Einrichtung | x | x temporary | Analyse fehlt | |||||||
ADT^A11 | Stornierung für A01 und A04 | x | x all | x all | x all | x all | x all | Analyse fehlt | |||
ADT^A12 | Stornierung für A02 | x | x in-/outpatient | pending | Analyse fehlt | ||||||
ADT^A13 | Stornierung für A03 | x | x all | x all | x all | x all | x all | Analyse fehlt | |||
ADT^A14 | Geplante Aufnahme | x pending | |||||||||
ADT^A15 | Geplante Verlegung | x pending | |||||||||
ADT^A16 | Geplante Entlassung | x pending | |||||||||
ADT^A21 | Beginn einer Patientenabwesenheit | ? | x advanced | ||||||||
ADT^A22 | Ende einer Patientenabwesenheit | ? | x advanced | ||||||||
ADT^A24 | Verknüpfen von Patientendaten | x link | Analyse fehlt | ||||||||
ADT^A28 | Personendaten hinzufügen | x merge | x link | Analyse fehlt | |||||||
ADT^A31 | Ändern personenbezogener Daten | x merge | x link | Analyse fehlt | |||||||
ADT^A32 | Stornierung zu A10 | x temporary | |||||||||
ADT^A33 | Stornierung zu A09 | x temporary | |||||||||
ADT^A37 | Auflösung einer Verknüpfung von Patientendaten | x link | Analyse fehlt | ||||||||
ADT^A38 | Stornierung zu A05 | x in-/outpatient | x pending | ||||||||
ADT^A40 | Zusammenführung v. Pat-Information über patient ID-Liste | x merge | x all | x all | x all | x all | x all | Profil erstellen | fehlt | ||
ADT^A44 | move account information | x advanced | |||||||||
ADT^A47 | Änderung der Pat.ID-Liste (PID-3) | x merge | x link | Analyse fehlt | |||||||
ADT^A52 | Cancel leave of absence for a patient | ? | x advanced | ||||||||
ADT^A53 | Cancel patient returns from a leave of absence | ? | x advanced | ||||||||
ADT^A54 | change attending doctor | x advanced | |||||||||
ADT^A55 | cancel change attending doctor | x advanced |
Als erstes Fazit kann festgehalten werden, dass nicht alle PAM-Nachrichten in Form deutscher Profile lokalisiert worden sind. Dies ist nachzuholen, nachdem die Analyse und Korrektur durchgeführt wurde.
ToDo
Aufgaben werden unter den Arbeitsgruppenmitglieder verteilt (alphabetische Namensliste nachstehend):
- 'RB' = Dr. Ralf Brandner, InterComponentWare AG
- 'BL' = Dr. Bettina Lieske, SAP
- 'FO' = Dr. Frank Oemig, AGFA Healthcare
- 'MV' = Dr. Marek Václavík, SER HealthCare Solutions GmbH
- 'FZE' = Fakhri Zain Elabdin, CORTEX Software GmbH
Allgemeine ToDos (nächste Schritte)
- Für ADT^A01 die in der Analyse erkennbaren Korrekturen herausarbeiten und in die Profile übernehmen bzw. als CP für IHE ITI ausarbeiten.
- Die fehlenden deutschen Profile identifizieren und ausarbeiten.
Spezielle ToDos
Hier werden die konkreten ToDos aus der Analyse aufgelistet, sofern sie nicht in die entsprechende Spalte der Excel-Tabelle passen. Jedes von MWB gemeldete Issue braucht eine Verifizierung unter Einbeziehung der menschen- und maschinenlesbaren Form beider Spezifikationen.
Redaktionelle Änderungen in "gemeinsame Elemente"
Vor der Anpassung der ADT-Profile wegen PAM-Harmonisierung Abarbeitung sind die bekannten Issues der bestehenden Version zu beheben.
Folgende Unregelmäßigkeiten wurden im Text von "gemeinsame Elemente" und "ADT Aufnahme" im Laufe der XML-Erstellung identifiziert.
Location | Issue | Resolution (FO) | Hand- lungs- bedarf | Behoben in
Profil-Word ... |
Behoben in
Profil-XML ... |
---|---|---|---|---|---|
5.2, 5.3 | Ursprüngliche Usage nicht aufgeführt, blau-Markierungen fehlen (gibt es keine?) | => markiert | <none> | <2011-12> | <todo> |
5.6: Tabellenzeilen 6, 7, 8, 13, 14, 16, 17, 18, 20, 21, 24, 25 | keine Usage Änderung - wieso blau markiert? | => Markierung entfernt | <none> | <2011-12> | <todo> |
5.6: Tabellenzeile 47 (PV2-47) | Usage braucht blau-Markierung ("C"->"CE") | => markiert => hier stellt sich aber die Frage, ob man diese Änderung durchführen darf? => im Standard ist "C" relativ flexibel, während es bei Profilen eine genaue Bedeutung hat. Von daher sollten wir es bei "C" belassen, aber die verfeinerte Darstellung aus v2.8 übernehmen. => "C" -> "C(R/O)". Das lässt sich dann beliebig weiter einschränken. | HL7-D | <2012-02> | <todo> |
5.8: Tabellenzeile 3 | Tippfehler "o" statt "O" | ok | <none> | <2011-12> | <todo> |
5.8: Tabellenzeile 7 (EVN-7) | "[0..0] O" soll wahrscheinlich "[0..0] X" heißen | =>wir sollten das eher auf [0..1] mit "RE" setzen, das passt dann zu der Beschreibung; ausserdem ist es in PAM auf "RE" | HL7-D | <2012-02> | <todo> |
5.9.4 | Tabelle hat keine Nummer | 4901: Verarbeitungskennzeichen | <none> | <2011-12> | <todo> |
5.5.12.1 | "Weitere Werte ... sind zulässig, wenn sie vorher vereinbart wurden:" - Aussage unklar | => soll heißen, die Tabelle ist nicht abschließend (coding strength CWE) => hier müssen wir jetzt noch einmal in die ValueSet Diskussion einsteigen!!
Für die Spezifikation wurde die Formulierung daher erweitert. |
HL7-D | <2012-02> | <todo> |
5.10 | Tabelle für NK1 hat zwei extra Spalten: req. und rep. - sollte vereinheitlicht werden | relikt, sollte eigentlich gelöscht sein => erledigt | HL7-D | <2011-12> | <todo> |
5.10: Tabellenzeilen 13, 17, 18, 29, 30, 31, 32, 33 | "rep." ist "Y", aber "Kard." ist 0..1, => müsste "0..*" sein | korrigiert bzw. markiert | HL7-D | <2011-12> | <todo> |
5.11 (ROL) | Beschreibung zu ROL unvollständig | Beschreibung zu ROL ergänzt | HL7-D | <2011-12> | <todo> |
5.11 (ROL-1) | Tabellenzeile 1: blau entfernen | => Entfernung der Konditionierung ist ok; da es sich dann um eine Veränderung handelt bleibt die Farbmarkierung erhalten | <none> | <2012-02> | <todo> |
5.12 (DG1) | DG1-2, DG1-19 sind nicht blau - und noch ein paar weitere… | ok | <none> | <2012-01> | <todo> |
5.12 (DG1) | Tabellenzeile 15, Länge: ">=3 (2)" - Beschreibung unklar | => ist ein Fall für C.LEN, da wir keine konkrete Länge definieren können!
(erstmal wie vorgeschlagen auf 3 geändert) |
HL7-D | <2012-02> | <todo> |
5.13.5.1 | Weitere Codes ??? | Eintragszeilen korrigiert | HL7-D | <2011-12> | <todo> |
5.13: Tabellenzeilen 2, 4, 8, 11, 12 | Usage soll blau sein | => ok | <none> | <2011-12> | <todo> |
5.14 | OBR ist nicht als Profil-Segment beschrieben - Abschnitt sollte umgeschrieben werden oder ganz weg | => ich habe die Tabelle zumindest umformatiert und angepasst; da wir das irgendwann brauchen sollten wir sie erstmal belassen | HL7-D | <2011-12> | <todo> |
5.15: Tabellenzeile 4 | Usage soll blau sein | ok | <none> | <2011-12> | <todo> |
5.15: Tabellenzeile 8 | Länge soll blau sein | => ok | <none> | <2011-12> | <todo> |
5.16: Tabellenzeile 2 | Verwendung "R" soll nicht blau sein. | ok | <none> | <2011-12> | <todo> |
5.16 | Tabellenzeile 3 - Verwendung "C" und Kard. "1..*" widersprechen sich. HL7 2.5 sagt: "C", repeatable. | => wieder auf „R“ gesetzt, da die Bedingung nicht angegeben ist. | HL7-D | <2011-12> | <todo> |
5.16: Tabellenzeile 4, 29, 30, 31, 33, 34, 35, 38, 40, 41 | Ursprüngliche Werte in der Blaumarkierung fehlen. | => ergänzt | <none> | <2011-12> | <todo> |
5.17 | Beschreibung zu IN2 fehlt | Beschreibung zu IN2 ergänzt | <none> | <2011-12> | <todo> |
5.17 | Tabellenzeile 1: Kard. soll [0..*] sein, da wiederholbar. | => ok | <none> | <2011-12> | <todo> |
5.19.7.1 | Codes unklar "xxx = Prozentwert je stationärer Leistungsart" | =>sollte klar sein: 000 (=0%) bis 100 (100%); dies ist aber keine saubere Umsetzung => Fußnote | HL7-D | <2011-12> | <todo> |
5.19.13.1 | Tabellenzeile 1 - "," am Ende der Zeile zu entfernen | => ok | <none> | <2011-12> | <todo> |
5.20 | Beschreibung zu FT1 fehlt | => Beschreibung zu FT1 ergänzt | HL7-D | <2011-12> | <todo> |
7.4: Felder 9 und 10 (Assigning Jurisdiction...) | sind nicht blau | => ok | <none> | <2011-12> | <todo> |
7.6 | Länge fehlt in der ganzen Tabelle | => soweit möglich angegeben | HL7-D | <2011-12> | <todo> |
7.7: Tabelle, Zeilen 1,2 | es fehlt "(O)" | => ok | <none> | <2011-12> | <todo> |
7.13 | Tabellennummer "529" nur 3-stellig | => ok | <none> | <2011-12> | <todo> |
7.13 | Feld 2 es fehlt „(B)“ | => ok | <none> | <2011-12> | <todo> |
7.14 - Feld 12 | es fehlt "(B)" und blaue Markierung | => ok | <none> | <2011-12> | <todo> |
7.14.1 | In der Tabellenspalte "Tabelle" steht überflüssigerweise "0" und blaue Markierung fehlt | => ok | <none> | <2011-12> | <todo> |
7.16 - Zeile 1, 2, 3 | es fehlt "(O)" | ok | <none> | <2011-12> | <todo> |
7.18 - Zeile 12 | es fehlt "(O)" | => ok | <none> | <2011-12> | <todo> |
Glossar | Segmente ROL IN2 FT1 TXA fehlen | => ok | <none> | <2011-12> | <todo> |
Segment ZBE | wird auch von der MDM-Definition referenziert, wird aber unter "gemeinsame Elemente" nicht aufgeführt => Vorschlag: Verlagerung der Definition von ADT (Aufnahme, 4.6) nach "gemeinsame Elemente" | => ist in 5.9 vorhanden | HL7-D | <2011-12> | <todo> |
Redaktionelle Änderungen in ADT "Aufnahme"
Location | Issue | Resolution (FO) | Handlungsbedarf | Behoben in
Profil-Word ... |
Behoben in
Profil-XML ... |
---|---|---|---|---|---|
Deckblatt, erste Seiten | den Vorgaben anpassen | => angepasst | HL7-D | <2011-12> | <todo> |
3.1 | Kardinality von DB1, UB1 und UB2 nicht blau markiert | => ok | HL7-D | <2011-12> | <todo> |
3.1 | Wieso ist Usage von OBX und DG1 blau markiert? | => müsste auf „C“ stehen, ebenso die Insurance Gruppe. | HL7-D | <2011-12> | <todo> |
3.1 | Kardinality von GT1 soll aufgrund Änderung blau merkiert markiert sein | => ok | HL7-D | <2011-12> | <todo> |
Änderung "Subprofile"
Das Profil Aufnahme definiert drei "Subprofile" Standard, Abrechnung, DRG. Diese Subprofile unterscheiden sich in der Usage von einigen Felder in den Segmenten PID, PV1 - siehe unten. Ein sauberer Abgleich mit dem PAM-Profil erfordert, ein konkretes Subprofil auszuwählen und die entsprechende Subprofil-Usage heranzuziehen - diese weicht jedoch von dem Tabellenwert in den Abschnitten 4.3, 4.4 der Aufnahme v2.0.pdf ab.
Subprofile werden in Aufnahme v2.0.pdf im Kontext der Beschreibung von MSH-21 erläutert (Abschnitt 4.1.4, ). In der nächsten Profilversion soll diese Darstellung übersichtlicher werden und die Usage für jedes Subprofil ausdrücklich genannt werden.
Feld | Laut Segmentdefinition
(Aufnahme v2.0.pdf: 4.3, 4.4) |
Profil Standard | Profil DRG | Profil Abrechnung |
---|---|---|---|---|
PV1-13 | CE | O | RE | O |
PV1-20 | CE | O | O | RE |
PV1-24 | CE | O | O | RE |
PV1-25 | CE | O | O | RE |
PV1-26 | CE | O | O | RE |
PV1-27 | CE | O | O | RE |
PV2-3 | CE | O | RE | O |
PV2-10 | CE | O | RE | O |
PV2-36 | CE | O | RE | O |
PV2-37 | CE | O | RE | RE |
Location | Issue | Resolution | Handlungsbedarf | Behoben in
Profil-Word ... |
Behoben in
Profil-XML ... |
---|---|---|---|---|---|
Aufnahme 4.1.4 | Usage-Spezifikation für "Subprofile" braucht eine einfachere Darstellung | FO: In "Aufnahme Rel 2.2 v01 20120229.pdf" Verweis auf MSH-21 vorne als neues Unterkapitel eingeführt und in MSH-21 die Tabelle aufgeführt;
MVA: Das finde ich immer noch zu versteckt :-(. Wie wäre es damit, 4.4 in 4.4.1, 4.4.2 und 4.4.3 aufzuteilen und die Tabelle 3x aufzuführen? |
HL7-D | <todo> | <todo> |
Differenzen PAM/HL7-D: Datentypen
Diese Details finden sich primär im Dokument zu den gemeinsamen Datenelementen:
Issue laut MWB-Report | Verifiziert? | Wer? | Status | Handlungs- bedarf | Behoben in
Profil-Word ... |
Behoben in
Profil-XML ... |
---|---|---|---|---|---|---|
HD-1,
CX-4-1, CX-6-1, XON-6-1, XON-8-1, XCN-9-1, PL-4-1 |
MV: Usage von HD-1 (Namespace ID) ist bei HL7-2.5 (2.A.33) "O", bei HL7-D (gem. Elemente 7.8) "C" und bei IHE (ITI TF-2x, N.3) "R". | MV + FO | ist zu hinterfragen, wie IHE ITI sich das gedacht hat, da es hier keine Beispiele gibt; | HL7-D | <todo> | <todo> |
HD-1 | MV:Inkonsistenz in IHE ITI selbst: Verwendung in PAM (App. N.3) ist "R", Verwendung für PIX/PDQ innerhalb von CX läßt "C" zu (ITI TF 2.x, App. E, Tab. E-3) - gleich mit HL7-D, Verwendung bei XDS-Metadaten innerhalb des Datentyps CX schließt sogar Namespace ID aus (ITI TF-3, Rev. 8, 4.1.7). | MV+FO | FO: dieser Vergleich innerhalb von ist IHE problematisch, da keine Profilhierarchien abgebildet sind. So ist ITI-31 keine Spezialisierung von ITI-8.
MV: Inkonsistenz zumindest zwischen Appendices, welche Framework-weit gültig sein sollen: Die Festlegung für CX in ITI TF 2.x, App. E, Tab. E-3 und Profilierung von HD in ITI TF 2.x, App. N.3. |
<todo> | <todo> | <todo> |
TS-1 | MV: TS-1 (Degree of Precision) hat bei HL7-2.5 (2.A.77), HL7-D (gem. Elemente 7.13) und IHE (ITI TF-2x, N.5) Länge 24. Die CommonElements/Datatype_TS.xml sagt dagegen "20". | MV | =>Korrektur in HL7-D .xml: Length 24 ist richtig | <none> | <none> | <2012-01> |
TS-2 | MV: TS-2 (Degree of Precision) ist bei HL7-2.5 (2.A.77), HL7-D (gem. Elemente 7.13) und IHE (ITI TF-2x, N.5) Datentyp "ID". In der 1.3.6.1.4.12559.11.1.1.60.xml von INRIA steht durchgehend "ST", z. B. bei MSH-7. | MV | =>Änderungsvorschlag an INRIA: Datentyp "ID" ist richtig. | INRIA: Technical Correction | <none> | <none> |
XCN-8, XCN-12 | Für XCN-8 (Source table): HL7-2.5 (2.A.86) und 1.3.6.1.4.12559.11.1.1.60.xml sagen Usage="C" mit dem Prädikat If component 1 is valued, either component 8, or 9, or both 10 and 11, must be valued. (2.A.9.8). HL7-D (gem. Elemente 7.15) sagt dagegen "O". Ditto für XCN-12 (Check Digit Scheme), mit dem Prädikat "zu befüllen zusammen mit XCN-11". | FO | => Korrektur in HL7-D .pdf und .xml: Usage "C" ist richtig. => XCN.8/12 auf “C” gesetzt | <none> | <2012-02> | <todo> |
XCN-9 | MV: HL7-D (gem. Elemente 7.13) sagt "RE", in der 1.3.6.1.4.12559.11.1.1.60.xml steht bei EVN-5-9 (XCN): Name="assigning authority" Usage="X". Dies erscheint unbegründet, da ITI TF-2.x zu XCN keine Aussage trifft, daher müsste der Wert "O" aus HL7-2.5 (2.A.86) gelten. | MV | => Änderungsvorschlag an INRIA: Usage "O" ist richtig | INRIA: technical correction (?) | <none> | <todo> |
XON-7 |
HL7-2.5 (2.A.87), HL7-D (gem. Elemente 7.16) und 1.3.6.1.4.12559.11.1.1.60.xml sagen einvernehmlich "ID". | MV | => Korrektur in HL7-D .xml: Datentyp "IS" ist richtig
FO: unklar: XON-8 ist HD, und nicht ID oder IS. Wahrscheinlich stimmt hier die Referenz nicht!!!!!! MVA: Korrektur - nicht XON-8, sondern XON-7! |
<todo> | <todo> | <2012-01> |
Differenzen PAM/HL7-D: ADT^A01
Issue laut MWB-Report | Problembeschreibung | Verifiziert durch... | Wer? | Status/=>Ergebnis | Handlungs- bedarf | Behoben in
Profil-Word ... |
Behoben in
Profil-XML ... |
---|---|---|---|---|---|---|---|
MSH-4/6 | sending/receiving facility ist "required" | FO | FO | => Profil ändern und Usage auf "R" setzen | s.o. | <2011-12> | <todo> |
MSH-13 | Standard: O, IHE:O, HL7-D: X | FZE | FO | =>MV: Legaler Übergang. Trotzdem: Warum verboten? | <todo> | <todo> | <todo> |
MSH-15/16 | Ack Codes sind verboten | FO | ? | CP für ITI erstellen, um den Usagecode "X" auf "R" zu setzen | IHE: CP | <todo> | <todo> |
MSH-17 | country code: ist bei PAM RE | FO | FO | => in gemeinsamen Datenelementen auf "RE" setzen | HL7-D | <2012-02> | <todo> |
MSH-18 | PAM: C ("This field shall only be valued if the message uses a character set other
than the 7-bit ASCII character set. Though the field is repeatable in HL7, IHE authorizes only one occurrence (i.e., one character set). The character set specified in this field is used for the encoding of all of the characters within the message."), HL7-D: R |
FZE | MVA | => FO: ok
=>MV: Legaler Übergang. |
<none> | <none> | <none> |
MSH-21 | PAM: RE, HL7-D: R
FZE: können wir auch auf RE setzen? |
FZE: | FO | => MVA: Legaler Übergang. | <none> | <none> | <none> |
SFT-4 | Es geht um "Software Binary ID", laut HL7 2.5 (2.15.12.4) Usage "R". In HL7-D gem. Elemente, 5.4 wird es ausdrücklich auf "O" gesetzt, mit dem Kommentar: Ursprünglich war dieses Feld "required". Nach den Regeln ist ein zurücksetzen auf "optional" nicht erlaubt!. | ja: ist zwar richtig, bei IHE wird dieses Segment aber nicht genutzt. Und hier dient es der Vereinfachung, so dass es so bleiben sollte, obwohl es den Regeln nicht ganz entspricht. | MV + FO | => ??? | HL7-D | <none> | <none> |
EVN-5 | Länge übereinstimmend 250. HL-D schränkt die Kardinalität bei EVN-5 (Operator ID) von [0..*] (s. ITI TF-2b, 3.30.5.2) auf [0..1] ein (s. Aufnahme, 4.2). Dies ist zulässig. | ja | MV | => kein Handlungsbedarf | <none> | <none> | <none> |
EVN-6 | PAM: C ("Condition predicate:
that was sent in the message that originally communicated the event being cancelled.); , HL7-D gemeinsame Elemente: O |
FZE | FO | =>MV: Bei HL7-D "C" übernehmen? | <todo> | <todo> | <todo> |
EVN-7 | PAM: RE, HL7-D: O | FZE | FO | =>MV: Aufzulösen! | <todo> | <todo> | <todo> |
PID-6 | PAM: O, HL7-D: X | FZE | MV | => MV: Legaler Übergang | <none> | <none> | <none> |
PID-7, PID-8 | PAM: CE, HL7-D: RE | FZE | MV | => MV: Legaler Übergang | <none> | <none> | <none> |
PID-11 | PAM: CE (for A28 in ITI-30, A01 in ITI-31, A04 in ITI-31, A31 in ITI-30: RE, otherwise O);
HL7-D Gemeinsame Elemente: O, HL7-D Aufnahme: RE |
FZE | MV | => MV: Legaler Übergang. | <none> | <none> | <none> |
PID-13 | PAM: O, HL7-D Gemeinsame Elemente: O, HL7-D Aufnahme: RE | FZE | MV | => MV: Legaler Übergang. | <none> | <none> | <none> |
PID-18 | PAM: O, HL7-D Gemeinsame Elemente: X | FZE | MV | => MV: Legaler Übergang. | <none> | <none> | <none> |
PID-21 | PAM: O;
HL7-D Gemeinsame Elemente: C (5.5.13: "In diesem Feld werden die Identifikatoren der Mutter übertragen, wenn es sich bei dem Patienten um ein Kind handelt.") |
FZE | MV | => MV: Legaler Übergang. Condition? | <none> | <none> | <none> |
PID-22 | PAM: O, HL7-D Gemeinsame Elemente: O, HL7-D Aufnahme: X | FZE | MV | => MV: Legaler Übergang. | <none> | <none> | <none> |
PID-25 | PAM: O, HL7-D Gemeinsame Elemente: CE, HL7-D Aufnahme: CE | FZE | MV | => MV: Legaler Übergang. | <none> | <none> | <none> |
PID-26 | PAM: O, HL7-D Gemeinsame Elemente: O, HL7-D Aufnahme: RE | FZE | MV | => MV: Legaler Übergang. | <none> | <none> | <none> |
PID-29 | PAM: C, HL7-D Gemeinsame Elemente: CE, HL7-D Aufnahme: CE | FZE | FO | => MV: Legaler Übergang. Trotzdem: Bedingungnen vergleichen! | <toto> | <todo> | <todo> |
PID-30 | patient death indicator
PAM: C, HL7-D Gemeinsame Elemente: O, HL7-D Aufnahme: RE |
FO | => auf "C" setzen | HL7-D | <2012-02> | <todo> | |
PID-31 | identity unknown indicator:
PAM: C, HL7-D Gemeinsame Elemente: O, HL7-D Aufnahme: RE |
FZE | FO | => auf "CE" setzen | HL7-D | <2012-02> | <todo> |
PID-32 | reliable code:
PAM: CE, HL7-D Gemeinsame Elemente: O, HL7-D Aufnahme: RE |
FZE | FO | => auf "CE" setzen | HL7-D | <2012-02> | <todo> |
PID-33 | last update time:
PAM: CE, HL7-D Gemeinsame Elemente: O, HL7-D Aufnahme: RE |
FZE | FO | => auf "CE setzen | HL7-D | <2012-02> | <todo> |
PID-35 | PAM: CE, HL7-D Gemeinsame Elemente: X, HL7-D Aufnahme: X | FZE | FO | => Legaler Übergang. Auf X lassen. | HL7-D | <none> | <todo> |
PID-36 | PAM: C; Required if known to the sender, when the patient is a non-human living subject, in the following messages: ... A28 in ITI-30), A01 in ITI-31, A04 in ITI-31, A31 in ITI-30, A08 in ITI-31;
HL7-D Gemeinsame Elemente: X, HL7-D Aufnahme: X |
FZE | MV | => Legaler Übergang, aber wozu die Einschränkung? | <todo> | <todo> | <todo> |
PID-37+38+39 | PAM: O, HL7-D Gemeinsame Elemente: X, HL7-D Aufnahme: X | FO | => Legaler Übergang. Auf X lassen. | HL7-D | <none> | <todo> | |
PV1-3 | PAM: C (ITI TF-2b, 3.30.5.4: "R" for A02+A12, "RE" otherwise);
HL7-D Gemeinsame Elemente: O; HL7-D Aufnahme: C (gem. El. 5.6.3: Dieses Feld ist immer dann zu füllen, wenn es sich um einen stationären Patienten handelt.) |
FZE | FO | => Legaler Übergang, aber die Bedingung passt nicht!
Außerdem: Prädikat für "Aufnahme" wird in "gem. Elemente" ausgesprochen. |
<todo> | <todo> | <todo> |
PV1-5 | PAM: O; HL7-D Gemeinsame Elemente: O; HL7-D Aufnahme: C;
In Aufnahme ist kein explizit formuliertes Prädikat zu finden! Gem. Elemente 5.6.5 sagt: In diesem Feld wird die Fallnummer eingetragen, die bei einer Voraufnahme (Registrierung) zugewiesen wird. |
FZE | FO | => Prädikat formulieren | <todo> | <todo> | <todo> |
PV1-6 | prior patient location
PAM: C (in A02: "R", otherwise "O"); HL7-D Gemeinsame Elemente: O; HL7-D Aufnahme: O; |
FZE | FO | => Auf "C" ändern? | <todo> | <todo> | <todo> |
PV1-7+8 | attending+visiting doctor
PAM: O; HL7-D Gemeinsame Elemente: O; HL7-D Aufnahme: RE; |
FZE | MV | => Legaler Übergang | <none> | <none> | <none> |
PV1-11 | temporary location/Vorübergehender Aufenthaltsort des Patienten im Krankenhaus
PAM: C, IHE TF-2b, 3.30.5.4: "This field is used by the option “Temporary Patient Transfers Tracking” of transaction ITI-31 (messages A09, A10, A32, A33)." => "R" für A09, A10, A32, A33; HL7-D Gemeinsame Elemente: O; HL7-D Aufnahme: O; |
FZE | MV | => Generell: Auch bei PAM müssten wir uns _ein_ zu vergleichendes Subprofil auswählen.
Konkret: Was mit PV1-11? |
<todo> | <todo> | <todo> |
PV1-13 | re-admission indicator/Kennzeichen, ob eine Wiederaufnahme vorliegt
PAM: O; HL7-D Gemeinsame Elemente: O; HL7-D Aufnahme: CE; |
FZE | MV | => Für das Aufnahme-Subprofil "Standard" wandelt sich "CE" zu "O", siehe Subprofil-Problematik oben. Somit keine Differenz. | <none> | <none> | <none> |
PV1-15 | Ambulatory Status/Mobilitätsstaus
PAM: 0..*; HL7-D Gemeinsame Elemente: 0..1; HL7-D Aufnahme: 0..1; HL7 2.5 sagt Repeatable: Y. |
FZE | FO | => Legaler Übergang, aber wozu die Einschränkung? | <todo> | <todo> | <todo> |
PV1-17+18 | Admitting Doctor+Patient Type
PAM: O; HL7-D Gemeinsame Elemente: O; HL7-D Aufnahme: RE; |
FZE | MV | => Legaler Übergang. | <none> | <none> | <none>
|
PV1-19 | PAM: O; HL7-D Gemeinsame Elemente: CE; HL7-D Aufnahme: R; | FZE | MV | => Legaler Übergang. | <none> | <none> | <none> |
PV1-20 | PAM: O; HL7-D Gemeinsame Elemente: O; HL7-D Aufnahme: CE; | FZE | MV | => Legaler Übergang. | <none> | <none> | <none> |
PV1-21 | PAM: O; HL7-D Gemeinsame Elemente: O; HL7-D Aufnahme: RE; | FZE | MV | => Legaler Übergang. | <none> | <none> | <none>
|
PV1-22+23 | PAM: O; HL7-D Gemeinsame Elemente: X; HL7-D Aufnahme: X; | FZE | MV | => Legaler Übergang. | <none> | <none> | <none>
|
PV1-24+25+26+27 | PAM: O; HL7-D Gemeinsame Elemente: O; HL7-D Aufnahme: CE; | FZE | MV | => Für das Aufnahme-Subprofil "Standard" wandelt sich "CE" zu "O", siehe Subprofil-Problematik oben. Somit keine Differenz. | <none> | <none> | <none> |
PV1-39 | PAM: Length 2; HL7-D Gemeinsame Elemente: Length 2; HL7-D Aufnahme: Length 2; | FZE | FO | => FZE: Schlüssel 6: Fachabteilungen mehr als 2 stellen. Anfrage an Interoperabilitätsforum offen seit 24.11.2011. | <todo> | <todo> | <todo> |
PV1-40 | PAM: 0..1; HL7-D Gemeinsame Elemente: 0..0; HL7-D Aufnahme: 0..0; | FZE | FO | => FZE: 'X' von Basis 'B' und nicht 'O'! Wie in gemeinsame Elemente! Schreibfehler bei IHE, ob Card.To. 1?
MV: ??? |
<todo> | <todo> | <todo> |
PV1-42 | PAM: C, in A15, A26: "R", otherwise: "O";
HL7-D Gemeinsame Elemente: O; HL7-D Aufnahme: O; |
FZE | FO | => MV: HL7-D auf C? | <todo> | <todo> | <todo> |
PV1-44 | PAM: RE; HL7-D Gemeinsame Elemente: CE; HL7-D Aufnahme: R; | FZE | MV | => | <todo> | <todo> | <todo> |
PV1-45 | PAM: RE; HL7-D Gemeinsame Elemente: CE; HL7-D Aufnahme: RE; | FZE | MV | => | <todo> | <todo> | <todo>
|
PV1-51 | PAM: O; HL7-D Gemeinsame Elemente: CE; HL7-D Aufnahme: RE; | FZE | MV | => Legaler Übergang. | <none> | <none> | <none> |
PV1-52 | PAM: ..*; HL7-D Gemeinsame Elemente: 0..*; HL7-D Aufnahme: 0..0; | FZE | FO | => MV: Konsistenz herstellen, Änderung bei HL7-D? | <todo> | <todo> | <todo> |
ROL-1 | HL7-2.5 (15.4.7, 15.4.7.1) schreibt Usage "C" vor: This field is required when used in Patient Care and Personnel Management messages. The field is optional when used in ADT and Finance messages. HL7-D (gem. Elemente, 5.11) setzt dies auf "O" zurück. | MV | FO | => HL7-D: Ursprünglich war dieses Feld konditional. Die dazugehörige Regel besagt, dass dieses
Element in ADT und BAR/DFT (Finanznachrichten) optional ist. Daher wird in diesem Fall die Konditionierung entfernt, da wir keine Patient Care oder Personnel Management Nachrichten einsetzen. |
<none> | <2012-02> | <none> |
IN1-3 | PAM: R;
HL7-D XML: C |
MVA | FO | => MV: XML korrigieren. | HL7-D | <none> | <todo> |
IN2-43 | HL7 2.5 6.5.7.43: Repeatable Y;
HL7-D gemeinsame Elemente 5.17: 0..1; |
MVA | FO | => MV: Legaler Übergang, aber wozu die Einschränkung? | <todo> | <todo> | <todo> |
NK1-11 | HL7-D-.xml gibt für das Feld Tabelle "0327" an. Dies hat keinerlei Begründung in HL7-2.5 (3.4.5.11) oder HL7-D (gem. Element, 5.11). | ? | => HL7-D .xml korrigieren | <none> | <none> | <2012-01> |
Differenzen PAM/HL7-D: ADT^A02
- MWB-Datei erstellen
- ...
Differenzen PAM/HL7-D: ADT^A03
- ...
Alle weiteren Detailanalysen müssen noch durchgeführt und hier aufgelistet werden. Allerdings wurde beschlossen, auf Basis der ersten Nachricht (ADT^A01) erstmal die Grundprobleme zu lösen, da hier eine hohe Anzahl an Redundanzen vermutet wird und doppelte Arbeit vermieden werden soll.
Quellen
Basisstandard HL7 2.5
HL7 Version 2.5 Final auf www.hl7.org bzw. der DVD von HL7 Deutschland. Zwischen den Darstellungen als .doc, .pdf und .html (aus der HL7-Datenbank) bestehen kleinere Unterschiede, die im gegebenen Kontext jedoch unerheblich sind. Alle drei Formen werden als gleichwertig betrachtet. Gegenwärtig (November 2011) steht die HTML-Form im geschützten Intranet-Bereich von hl7.de zum Herunterladen bereit: .zip.
HL7-D ADT
Als aktueller Stand der Profilspezifikation wurde die Version 2 genommen, die u. auf den Seiten von HL7 Deutschland als zip verfügbar ist. Die Beschreibung der Nachrichtenstruktur wurde den folgenden Spezifikationsdokumenten entnommen:
Profil | Spezifikationsdokumente |
---|---|
ADT^A01 Aufnahme | gemeinsame Elemente v2.1.pdf,
Aufnahme v2.0.pdf" |
... | ... |
Die maschinenlesbare Form wurde im Zuge der Arbeiten neu erstellt. Der aktuelle Stand der XML-Dateien steht im Unterverzeichnis Output der Toolkit-Distribution, die über Resource Sharing erhätlich ist: Paket "Toolkit zum Generieren der Profil-XMLs und HTML-Doku", geschützter Direktlink zum Stand vom 2011-11-22.
IHE PAM
Die menschenlesbare Beschreibung des IHE-Profils is in dem Technical Framework der Domäne IT Infrastrucuture (Revision 8 vom August 2011) enthalten. Die Spezifikation ist verteilt auf mehrere Volumes:
- Volume 1 (PDF ), Abschnitte 2.2.14, 14
- Volume 2b (PDF ), Abschnitte 3.30, 3.31
- Volume 2x (PDF ), Abschnitte C, E, N, P
- Volume 3 (PDF )
Maschinenlesbare Darstellungen werden als XML aus dem öffentlichen Profile-Repository von INRIA genommen:
IHE-Profil,
Transaktion |
Profil-ID |
---|---|
ITI-31, A01 | 1.3.6.1.4.12559.11.1.1.60 (Ansicht: http://gazelle.ihe.net/InriaHL7MessageProfileRepository/viewProfile.seam?oid=1.3.6.1.4.12559.11.1.1.60) |
ITI-31, A02 | 1.3.6.1.4.12559.11.1.1.62 |
ITI-31, A03 | 1.3.6.1.4.12559.11.1.1.64 |
ITI-31... | ... |
Methoden und Werkzeuge
Folgende Methode wurde für den Vergleich Deutschland Aufnahme ADT^A01 gegen IHE PAM ITI-31 ADT^A01 angewendet:
- Bezug einer Conformance-Profile-XML für IHE ITI-31 (siehe Quellen).
- Erstellung einer Conformance-Profile-XML für Deutschland Aufnahme A01 mit dem dafür erstellten Toolkit.
- Erstellung der .mwb-Datei aus der Conformance-Profile-XML (1) zur Verwendung in Messaging Workbench
- Erstellung der .mwb-Datei aus der Conformance-Profile-XML (2) zur Verwendung in Messaging Workbench
- Generierung eines Vergleich-Reports in Messaging Workbench.
- Filterung der Report-XML mit einem .xls Stylesheet (Namensunterschiede vernachlässigen).
- Manuelle Nacharbeitung des Reports zu einer Excel-Tabelle (geschützter Direktlink zur .xlsx-Datei)
Das Standard-Tool für HL7-2.x-Profiling Messaging Workbench (MWB) in der Version 06.18 wurde nur für die Teilaufgabe Profilvergleich eingesetzt. Der Grund sind bestehende bekannte Unzulänglichkeiten der Anwendung, die teilweise auch das Ergebnis des Vergleichs belasten. (Nachstehende Issues können auf Anfrage mit einem konkreten Beispiel reproduziert werden.)
'MWB Issue 1:' Beim Import der Profil-XML: Das Schema-konforme Element <DataValues …> innerhalb von <Component> hat zufolge das Nicht-Erkennen des darauf folgenden SubComponent-Elements.
'MWB Issue 2:' Nachdem eine Profil-XML importiert wurde, zeigt ein Feld die Länge X. Nach Speichern als .mwb und Öffnen der .mwb-Datei, hat das Feld eine abweichende Länge Y. (Mögliche Erklärung: MWB berechnet die Länge selbständig und neu.)
'MWB Issue 3:' Die Funktion Profil-Vergleich zeigt Differenzen bei „Min“, obwohl ein Unterschied bei „Max“ vorliegt.
'MWB Issue 4:' MWB kann mit Gruppen der Kardinalität [0..*] nicht umgehen. Als Workaround müssen diese in zwei ineinander verschachtelte Gruppen mit der Kardinalität [0..1] und [1..*] aufgeteilt werden.
'MWB Issue 5:' MWB ist nicht in der Lage, mehrere Strukturen aus einer Profil-Datei auszulesen.
Download, Resource-Sharing
Derzeit sind die Dateien noch nicht über einen Download-Link verfügbar. Dies wird baldmöglichst nachgeholt. HL7 Int. hat angeboten, hier das offizielle gForge zu nehmen. Dazu müssen die Freiwilligen aber einen GForge-Account bekommen, um Zugriff auf alle Resourcen zu haben.
Bis dahin stellt SAP einen Activity-Bereich in der Sharing-Plattform StreamWork zur Verfügung. Der Zugriff darauf kann über Fr. Lieske (SAP) erfragt werden. Bereits registrierte StreamWork-Nutzer können sich hier anmelden.