Kommentare und Auflösungen zum Abstimmungsverfahren Elektronischer Impfpass
Stand: [Calendar: AD]4. Oktober 2019
Auszählung (Tally) | |
---|---|
Anzahl Kommentare | 220 |
Angenommen | 0 |
Angenommen mit Modifikationen | 0 |
Nicht angenommen | 0 |
Nicht relevant | 0 |
Zur zukünftigen Verwendung | 0 |
Weitergeleitet | 0 |
Warten auf Information vom Antragsteller | 0 |
Warten auf Information von anderer Arbeitsgruppe | 0 |
Unbearbeitet | 220 |
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
---|---|---|---|---|---|
2 |
p14-15 | Negativ, schwerwiegend | Horst Kakuschke | HÄVG Hausärztliche Vertragsgemeinschaft AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Impfstatus | ? grundsätzliche Konzeption ? | Konzeptionelles Problem: in diesem Dokument werden zwei unterschiedliche Konzepte abgebildet, die unterschiedliche Intentionen verfolgen und auch unterschiedlichen Aktualisierungszeiträumen unterliegen.
Auf der einen Seite wird der „klassische“ Inhalt eines Impfpasses in der Form der Historie der durchgeführten Impfungen abgebildet – dieser Teil wird bei jeder durchgeführten Impfung erweitert. Auf der anderen Seite deckt der Impfstatus auch eine Impfplanung ab – dieser Teil unterliegt einer Aktualisierung bei Bedarf. Problem dabei ist, dass diese beiden Aspekte miteinander verwoben sind, aber unterschiedlich aktualisiert werden ohne zumindestens die Aktualität und die Herkunft der Impfplanung zu erkennen. Beispiel: mein Hausarzt plant mit mir meine regelmäßigen Standard-Impfungen – für einen Auslandsaufenthalt benötige ich aber eine Gelbfieber-Impfung, die nur durch eine Gelbfieber-Impfstelle durchgeführt werden kann. Diese Impfstelle würde nun den Teil der durchgeführten Impfungen aktualisieren, aber natürlich nicht die gesamte Impfplanung und den Impfstatus über „Gelbfieber“ hinaus anpassen. Trotzdem findet sich aber nach der Aktualisierung diese Gelbfieber-Impfstelle als Autor des gesamten Dokuments und somit auch als verantwortlich für den gesamten Impfstatus wieder. Zwei Möglichkeiten zur Auflösung sehe ich hier: (a) das Führen von unterschiedlichen Autoren und Erstellungszeitpunkten für Impfstatus und Impfhistorie (bei Impfstatus möglichweise sogar für einzelne Teile des Impfstatus) (b) generelle Trennung der Dokumente für Impfstatus und Impfhistorie |
|||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
3 |
p182-18 | Negativ, schwerwiegend | Horst Kakuschke | HÄVG Hausärztliche Vertragsgemeinschaft AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Keine Versionen mit Status draft, active, review oder pending. | hier sollte etwas stehen… | Problem beim Export aus Art Decor? | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
4 |
p170-10 | Negativ, kleineres Problem | Horst Kakuschke | HÄVG Hausärztliche Vertragsgemeinschaft AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Dokumentationstyp= | Dokumentationstyp | Tippfehler: „=“ | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
5 |
p158-12 ff | Negativ, schwerwiegend | Horst Kakuschke | HÄVG Hausärztliche Vertragsgemeinschaft AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Zeitraum für Tätigkeit in Berufsgruppe aufnehmen | Die Angabe der Berufgruppe würde durch eine Angabe eines Zeitraums (in der die Person in dieser Berufsgruppe tätig ist) an Aussagefähigkeit gewinnen | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
6 |
p198-26 | Negativ, schwerwiegend | Horst Kakuschke | HÄVG Hausärztliche Vertragsgemeinschaft AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Keine Versionen mit Status draft, active, review oder pending. | hier sollte etwas stehen… | Problem beim Export aus Art Decor? | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
7 |
p198-26 | Negativ, schwerwiegend | Horst Kakuschke | HÄVG Hausärztliche Vertragsgemeinschaft AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
In Art Decor findet sich zu dem Value Set „Berufsgruppen“ (https://art-decor.org/art-decor/decor-valuesets--eImpfpass-?id=2.16.840.1.113883.3.1937.777.35.11.33&effectiveDate=2019-07-05T16:53:54&language=de-DE) folgender Hinweis: Das folgende Value Set enthält Konzepte aus der Praxis und stellt einen Einblick in tatsächlich genutzte Angaben aus praktischen Implementierungen dar. Die Konzepte und insbesondere die Codes müssen noch an standardisierte Terminologien angepasst werden. | Anpassung an „standardisierte Terminologien“ | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
8 |
p197-05 | Negativ, schwerwiegend | Horst Kakuschke | HÄVG Hausärztliche Vertragsgemeinschaft AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Hinweis: Das folgende Value Set enthält Konzepte aus der Praxis und stellt einen Einblick in tatsächlich genutz- te Angaben aus praktischen Implementierungen dar. Die Konzepte und insbesondere die Codes müssen noch an standardisierte Terminologien angepasst werden. | Anpassung an „standardisierte Terminologien“ | Es sind auch mehrere unterschiedliche Codes für „Kontakt zu Erkrankten“ aufgeführt. | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
9 |
p198-31 | Negativ, schwerwiegend | Horst Kakuschke | HÄVG Hausärztliche Vertragsgemeinschaft AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Hinweis: Das folgende Value Set enthält Konzepte aus der Praxis und stellt einen Einblick in tatsächlich genutz- te Angaben aus praktischen Implementierungen dar. Die Konzepte und insbesondere die Codes müssen noch an standardisierte Terminologien angepasst werden. | Anpassung an „standardisierte Terminologien“ | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
10 |
p197-09 ff p199-03 ff | ? ? | Horst Kakuschke | HÄVG Hausärztliche Vertragsgemeinschaft AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Abgrenzung zwischen Expositionsgruppen und Gefährdungsgrößen ist nicht klar – z.B. taucht bei den Gefährdungsgrößen ein „Expositionsrisiko (Hepatitis A)“ auf, das ich eher bei den Expositionsrisiken gesucht hätte. | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
11 |
? ? | Mareike Przysucha | Hochschule Osnabrück | ||
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
12 |
allgemein | Negativ, schwerwiegend | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Codes der Sections | Warum wurden hier keine LOINC-Codes verwendet? Einige Punkte sind sicherlich als LOINC-Code vorhanden | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
13 |
p009 - p013 | Negativ, schwerwiegend | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Allgemein | Klärung Informationsmodell | hier werden v.a. beim Gesamimpfstatus Sachen vermischt, die nicht vermischt werden sollten
|
|||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
14 |
allgemein | Negativ, kleineres Problem | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
<hl7:...>…</hl7:…>
bzw. <hl7:… …/> |
In den Beispielen ist das "hl7:" in den Tags nicht zwingend notwendig, wenn man den Namespace am Anfang definiert. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
15 |
allgemein | Negativ, kleineres Problem | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Art der Einbindung anderer Templates (z.B. bei Impfstatus) | Art der Einbindung überprüfen | Die Einbindung jetzt übernimmt die Einträge in die Templates, was diese sehr lang macht. Vielleicht wäre eine andere Art der Einbindung besser. | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
16 |
p024-04 | Negativ, kleineres Problem | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
2.16.840.1.113883.3.1937.777.35.10.45 | 2.16.840.1.113883.3.1937.777.35.10.27 | falsches Template eingebunden: aktuell Entry statt Section | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
17 |
p148-15 | Negativ, kleineres Problem | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Kardinalität von targetSiteCode auf 1..1 | constrainen auf 0..1 | es gibt Diagnosen, die nicht lokal gebunden sind, z.B. ICD-10 Code E11.90 Diabetes mellitus, Typ 2: Ohne Komplikationen, nicht als entgleist bezeichnet | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
18 |
p154-19 ff | Negativ, kleineres Problem | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Abschnitte:
|
Frage: Inwieweit unterscheiden sich die Angaben von denen aus dem Arztbrief bzw. inwieweit gibt es das schon von HL7? | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
19 |
p165-09 ff | Negativ, kleineres Problem | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Template "Flag 'Titer ausreichend'" | als InterpretationCode an Observation? | bei der Angabe des Titer wird dieser gleich "interpretiert" in dem Sinne, dass angegeben wird, ob er ausreichend ist oder nicht. | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
20 |
p166-13 | Negativ, kleineres Problem | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Template "Flag 'Übernahme aus Impfpass'" | als Referenz auf ExternalDocument | Hier wäre vielleicht der Verweis auf den Papier-Impfpass in Form einer external Reference sinnvoll, oder ist das nicht passend? | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
21 |
p167-20 | Negativ, kleineres Problem | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Template "Flag 'Übernahme in Account" | Ist dies nicht jeweils Kontextabhängig? Es ist jedenfalls den Gefährdungsgrößen zugeordnet ==> siehe auch allgemein - Datenmodell | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
22 |
p172-05 | Negativ, kleineres Problem | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Template Impfserie | Übertragung in substanceAdministration.repeatNumber | dieses Feld ist dazu gedacht | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
23 |
p174-21 | Negativ, kleineres Problem | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Keine Versionen mit Status draft, active, review oder pending. | fehlendes Template oder zusätzliche Überschrift | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
24 |
p175-01 | Negativ, kleineres Problem | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
observation | substanceAdministration mit entsprechendem moodCode (prp) | Eine Empfehlung hat den moodCode "PRP". Da es sich hierbei um die Empfehlung einer SubstanceAdministration handelt, sollte das auch entsprechend angegeben werden. | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
25 |
p176-07 | Negativ, kleineres Problem | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Observation | substanceAdministration.effectiveTime mit entsprechendem moodCode (evn) | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
26 |
p182-17 | Negativ, kleineres Problem | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Keine Versionen mit Status draft, active, review oder pending. | fehlendes Template oder zusätzliche Überschrift | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
27 |
p185-10 | Negativ, kleineres Problem | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Keine Versionen mit Status draft, active, review oder pending. | fehlendes Template oder zusätzliche Überschrift | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
28 |
p185-13ff | Negativ, kleineres Problem | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
externalObservation | sind nicht External... dazu gedacht, Inhalte aus anderen Dokumente, also tatsächlich "externe" Inhalte zu referenzieren? Wenn ja, müsste hier anders gearbeitet werden. Ich wüsste aber auch nicht, wie. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
29 |
p186-11 ff | Negativ, kleineres Problem | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
siehe p185-13ff | siehe p185-13ff | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
30 |
p187-17 ff | Negativ, kleineres Problem | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
siehe p185-13ff | siehe p185-13ff | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
31 |
p188-16 ff | Negativ, kleineres Problem | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
siehe p185-13ff | siehe p185-13ff | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
32 |
p045-02 | Tippfehler | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Header Level Templates | CDA Header Templates | Einheitlichkeit mit Abschnitt 3 und 5 | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
33 |
p070-10 | Tippfehler | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Abgelehnte Impfungen werden in der Impfungen-Sektion in einem eigenem Entry-Template dargestellt, welches das Attribut @negotianInt mit dem festen Wert true besitzt. | @negationInd | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
34 |
p083-02 | Tippfehler | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Entry Level Templates | CDA Entry Level Templates | Einheitlichkeit mit Abschnitt 3 und 5 | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
35 |
p132-02 | Tippfehler | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
statusCode code="true" | true ist kein zulässiger StatusCode | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
36 |
p170-10 | Tippfehler | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Dokumentationstyp= | Dokumentationstyp | Ein "=" zu viel | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
37 |
p171-17 | Tippfehler | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
welche der Personen in Ihren verschiedenen Rollen | welche der Personen in ihren verschiedenen Rollen | keine direkte Anrede | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
38 |
p197 - p209 | Tippfehler | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Umlaute | Beachtung der Codierung (UTF8, ASCII, ...) - die Umlaute passen nicht | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
39 |
p070-11 | Vorschlag | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Abschnitt ICD 10 Diagnosen | Kann man hier nicht einfach auf die Diagnosen verweisen? Muss man die Diagnosen von jemandem anderes in den Implementierungsleitfaden aufnehmen? Sie werden ja schließlich nicht abgestimmt. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
40 |
p149-05 | Vorschlag | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Diagnosedatum als Überschrift | muss das als Überschrift hier sein? | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
41 |
p149-11 | Vorschlag | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Dokumentationsdatum als Überschrift | muss das als Überschrift hier sein? | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
42 |
Abschnitt 6 | Kommentar allgemeiner Art | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Vielleicht andere Strukturierungselemente | Abschnittstitel mitunter nicht so verständlich | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
43 |
p007-01 | Kommentar allgemeiner Art | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden … | Löschung des Abschnittes | dies wird nicht mehr benötigt | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
44 |
p011-08 | Kommentar allgemeiner Art | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Flag 'Übernahme in Account' | Account evtl. umbenennen? | In HL7 FHIR bezeichnet Account einen Abrechnungsfall. 'Übernahme in Account' suggeriert somit die Übernahme in den aktuellen Abrechnungsfall, was hier nicht gemeint ist. | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
45 |
p115-18 | Kommentar allgemeiner Art | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Wird das Attribut mit „true" angegeben, so wird ausgesagt, dass die über die Observation-Klasse beschriebene Beobachtung negiert wird. In Bezug auf diesen Eintrag bedeutet das, dass diese Gefährdungsgröße nicht zutrifft. Die Angabe des Attributs ist optional. Wird es nicht angegeben, geht das empfangende System von dem Default-Wert aus und verwendet diesen zur weiteren Verarbeitung. Der Default–Wert ist „false". | Da viele den Sinn von "negotiationInd" nicht verstehen, sollte dies auch anderweitig codiert werden | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
46 |
p126-03 | Kommentar allgemeiner Art | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Wird das Attribut mit „true" angegeben, so wird ausgesagt, dass die über die Observation-Klasse beschriebene Beobachtung negiert wird. In Bezug auf diesen Eintrags bedeutet das, dass diese Reiseindikation nicht durchgeführt wurde. Wird es nicht angegeben, geht das empfangende System von dem Default-Wert aus und verwendet diesen zur weiteren Verarbeitung. Der Default–Wert ist „false". | Da viele den Sinn von "negotiationInd" nicht verstehen, sollte dies auch anderweitig codiert werden | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
47 |
p133-19 | Kommentar allgemeiner Art | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Wird das Attribut mit „true" angegeben, so wird ausgesagt, dass die über die Observation-Klasse beschriebene Beobachtung negiert wird. Für diesen Fall ist das Template Rejected Vaccination zu verwenden. | Da viele den Sinn von "negotiationInd" nicht verstehen, sollte dies auch anderweitig codiert werden | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
48 |
p143-03 | Kommentar allgemeiner Art | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
negationInd = true | Da viele den Sinn von "negotiationInd" nicht verstehen, sollte dies auch anderweitig codiert werden | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
49 |
p146-19 | Kommentar allgemeiner Art | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Das Attribut @negationInd ist vom Datentyp BL und hat damit die Ausprägungen "true" oder "false". Wird das Attribut mit „true" angegeben, so wird ausgesagt, dass die über die Observation-Klasse beschriebene Beobachtung negiert wird. In Bezug auf die Diagnosendarstellung bedeutet das, dass die beschriebene Diagnose nicht zutrifft. Die Angabe des Attributs ist optional. Wird es nicht angegeben, geht das empfangende System von dem Default-Wert aus und verwendet diesen zur weiteren Verarbeitung. Der Default–Wert ist „false". | Da viele den Sinn von "negotiationInd" nicht verstehen, sollte dies auch anderweitig codiert werden | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
50 |
p177-11ff | Kommentar allgemeiner Art | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
observation | substanceAdministration | hierbei geht es darum, wann die nächste Impfung stattfinden sollte. Das ist keine Observation, sondern eine ausstehende SubstanceAdministration mit frühestem und spätesten Zeitpunkt | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
51 |
p177-12 | Kommentar allgemeiner Art | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Nächster und Letzter Impftermin | Intervall für nächste Impfung | Der Titel suggeriert bei zwei ausstehenden Folgeimpfungen, dass beide in einem bestimmten Zeitraum stattfinden sollen. Folgt man der Beschreibung, ist damit eher gemeint, in welchem Zeitraum die nächste Impfung erfolgen sollte. Daher sollte entweder der Titel oder die Beschreibung angepasst werden. | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
52 |
p194-20 | Kommentar allgemeiner Art | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Bereich "Impfstatus" | Anpassung der Formatierung | Teile des Textes sind nicht lesbar | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
53 |
p197 - p209 | Kommentar allgemeiner Art | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Codes | Warum sind die Codes so lang? | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
54 |
? ? | Thomas Liebscher | Philips GmbH | ||
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
55 |
S. 7, Kapitel 1.4 | Tippfehler | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
▪ Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. ▪ Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. ▪ Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier (http://wiki.hl7.de/index.php?title=Spezial:Linkliste/ IG:EImpfpass&hideredirs=1) . |
ersatzlos streichen, Überbleibsel aus Template | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
56 |
Inhaltsverzeichnis | Negativ, schwerwiegend | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Es hat sich eigentlich ein defacto Standard bei der Strukturierung von Implementierungsleitfäden ergeben:
1. Dokumenteninformationen 2. Einleitung 3. Aufbau 4. Use Cases 5.Informationsmodell 6. CDA Spezifikation ... NN. Übersicht CDA Header und Body ... Hier wird in Kapitel 2 Informationen zum Dokumentenaufbau (2.1, 2.2, eigentlich separates Kapite 3), zur CDA Spezifikation (2.3) und nur wenig zum eigentlichen Thema (2.4) eingeführt. Danach wird direkt in die Spezifikation gesprungen. Mir fehlt eine ordentliche Einleitung (vgl. eRezept IG), aber insbesondere die Use Cases und das Informationsmodell. Ohne diese beiden Kapitel Informationsmodell macht eine Bewertung des gewählten Mappings auf CDA keinen Sinn. |
|||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
57 |
? ? | Diana Ovelgoenne | Siemens Healthcare GmbH | ||
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
58 |
General | Negativ, kleineres Problem | Diana Ovelgoenne | Siemens Healthcare GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Es gibt schon in Art-Decor ein Projekt für Impfausweis. Gibt es ein Harmonizirung zwichen beide Implementierungsleitfaden? War gut zu erklaren am Anfang des Dokument was ist das Untershicht und wann sollen die Leute nennen was. Es ist totall unklar ob sie haben auch C-CDA oder andere international Templates als referenz genommen. | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
59 |
General | Negativ, kleineres Problem | Diana Ovelgoenne | Siemens Healthcare GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Es gibt keine Musterbild vom den Impfpass oder Use Cases, z.B. warum data wie Marital Status oder Religion gebraucht werden. Oder wie updates erfolgen. War gut wenn den workflow war auch definiert. z.B. wie bei HL7 Austria https://confluence.hl7.org/download/attachments/65077664/Austria_AffiliateReport-Sep2019-Atlanta-v2.pdf?version=1&modificationDate=1568577819886&api=v2 | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
60 |
3.1 CDA Dokument eImpfpass | Vorschlag | Diana Ovelgoenne | Siemens Healthcare GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
hl7:maritalStatusCode 0…1 | hl7:maritalStatusCode 0…0 | International Impfausweis braucht den Marital Status Code uberhaupt nicht. War gut wenn den field war constraint zum 0..0. | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
61 |
3.1 CDA Dokument eImpfpass | Vorschlag | Diana Ovelgoenne | Siemens Healthcare GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
hl7:religiousAffiliationCode 0…1 | hl7:religiousAffiliationCode 0…0 | International Impfausweis braucht den Religious Affiliation Code uberhaupt nicht. War gut wenn den field war constraint zum 0..0 | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
62 |
6.1.9 Impfung Beispiel | Tippfehler | Diana Ovelgoenne | Siemens Healthcare GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
<hl7:routeCode code="Injection" codeSystem="2.16.840.1.113883.3.1937.777.35.11.99.3" displayName="Injektion"/> <hl7:approachSiteCode code="LEFT_ARM" codeSystem="2.16.840.1.113883.3.1937.777.35.11.99.12" displayName="Linker arm"/> | <hl7:routeCode code="Injection" codeSystem="2.16.840.1.113883.3.1937.777.35.11.3" displayName="Injektion"/> <hl7:approachSiteCode code="LEFT_ARM" codeSystem="2.16.840.1.113883.3.1937.777.35.11.12" displayName="Linker arm"/> | Die OIDs sollen ohne 99 sein | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
63 |
General | Vorschlag | Diana Ovelgoenne | Siemens Healthcare GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Könnte Blutgruppe und Rh-Faktor nicht finden. Den Internationale Papier Impfausweis benutz diese data. | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
64 |
General | Negativ, schwerwiegend | Diana Ovelgoenne | Siemens Healthcare GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Sie benutzen den OID "2.16.840.1.113883.3.1937.777.35.11.12 (eImpfpass-valueset-12)" mehrmal egal ob es ist Richtig oder nicht. Dieses OID ist definiert für AproachSiteCode Z.B. steht bei Gesamtimpstatus (pdf st. 24 ) oder bei Titer und so weiter St. 25 ,59. Dann mit falsches OID ist auch ganz schwerig zu finden ob mindestens die richtige codes sind | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
65 |
7.1.4 | Tippfehler | Diana Ovelgoenne | Siemens Healthcare GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Tabelle ist abgeschnitten | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
66 |
? ? | Lars Treinat | ZTG Zentrum für Telematik und Telemedizin GmbH | ||
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
67 |
p8-30 | Vorschlag | Lars Treinat | ZTG Zentrum für Telematik und Telemedizin GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Es wäre zu überlegen, ggf. ergänzend zu der Übersicht "Übersicht CDA Header und Body" eine schematische Template-Darstellung in den Leitfaden aufzunehmen. | Dies könnte für Teile der Zielgruppe eine Hilfestellung sein, um die Struktur und die Beziehungen zwischen Header, Body, Sections und Entries leichter zu verstehen. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
68 |
p14-22 | Vorschlag | Lars Treinat | ZTG Zentrum für Telematik und Telemedizin GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
In dieser Sektion werden die Berufsgruppen des Versicherten festgehalten. Diese können für die Ermittlung des Impfstatus ausschlaggebend sein und sollten daher für diese immer herangezogen werden. | In dieser Sektion werden die Berufsgruppen des Versicherten festgehalten, denen der Versicherte angehört. Diese können für die Ermittlung des Impfstatus ausschlaggebend sein und sollten daher für diese immer herangezogen werden. | Die Erläuterung wäre damit für Personen, die nicht näher mit der Thematik Impfung zu tun haben, besser verständlich. Hier wäre z.B. an Entwickler/Implementierer zu denken, die nicht inhaltlich mit dem Thema Impfpass vertraut sind. | |||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
69 |
Negativ, schwerwiegend | Kai Heitmann | |||
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die vorliegende Ausarbeitung führt eine Reihe Sachverhalte aus der Praxis auf, die es wert sind, genauer betrachtet zu werden. Allerdings kann der jetzigen Version nicht zugestimmt werden. Handwerklich sind Fehler in der CDA-Spezifikation selbst auszumerzen, z.B. Entries im Body ohne Einbettung in eine Section etc. Des Weiteren ist schwer ersichtlich, warum überhaupt gar kein Bezug zu bestehenden Profilen genommen worden ist bzw. diese berücksichtigt worden sind, insbesondere IHE PCC, der Impfpass in der ELGA (AT) und der Vakzinations-Report von eHealth Suisse (CH). Der Zusammenhang zwischen Impfstatus, Impfungen und Abgelehnte Impfungen ist unklar bzw. unzureichend konform modelliert. Die Impfung im Datenmodell ist nicht strukturiert und mischt die Vakzination selbst mit nachgeordneten Titer- und Outcome Beobachtungen. Beschreibungen sind unzureichend oder verwirrend, z. B. „Vorindikation“ beschrieben als „Durchgemachte Krankheiten, Impfrelevante Krankheiten, die der Patient in der Vergangenheit durchgemacht hat.“ Das kann ich nicht nachvollziehen. Nahezu alle Value Sets müssen überarbeitet und mit internationalen Terminologien bestückt werden. Ich schlage vor, den vorliegenden Impfpass in einer Arbeitsgruppe erneut aufzugreifen, standardkonform zu gestalten und erneut abzustimmen. FAZIT: Die ersichtlichen notwendigen Umbaumaßnahmen erzeugen derart substanzielle Änderungen an der vorliegenden Spezifikation, so dass eine Neuabstimmung unumgänglich ist. |