Kommentare und Auflösungen zum Abstimmungsverfahren eRezept
Stand: 26. November 2019
Auszählung (Tally) | |
---|---|
Anzahl Kommentare | 89 |
Angenommen | 55 |
Angenommen mit Modifikationen | 8 |
Nicht angenommen | 7 |
Nicht relevant | 0 |
Zur zukünftigen Verwendung | 12 |
Weitergeleitet | 4 |
Warten auf Information vom Antragsteller | 3 |
Warten auf Information von anderer Arbeitsgruppe | 0 |
Unbearbeitet | 0 |
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
---|---|---|---|---|---|
1 |
p19-02 | Vorschlag | Lars Treinat | persönliches Mitglied | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Hier sollte explizit darauf hingewiesen werden, dass es sich um ein elektronisches Dokument mit besonderen Anforderungen an Vertraulichkeit, Authentizität und Integrität handelt, da besondere Kategorien personenbezogener Daten nach Art. 9 DSGVO enthalten sind und damit ein hoher Schutzbedarf besteht. Dies ist bei der Implementierung durch geeignete technische und organisatorische Maßnahmen zu berücksichtigen, die an dieser Stelle nicht eingehend betrachtet werden. Die Umsetzung entsprechender Maßnahmen liegt in der Zuständigkeit der beteiligten Akteure in ihrer Rolle als "Verantwortlicher" im Sinne des Art. 4 DSGVO. | Bei der technischen Umsetzung und Einführung entsprechender Prozesse ist damit zu rechnen, dass ggf. Widerstand gegen eine elektronische Umsetzung bisher papierbasierter Prozesse leichter Gehör findet, wenn diese Aspekte nicht zumindest in grundsätzlicher Form adressiert wurden. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Am Ende von Kap. 4.3. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
2 |
p0010-29 | Tippfehler | Dr.-Ing. Danny Ammon | Universitätsklinikum Jena, Datenintegrationszentrum | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
mehreren | mehrerer | Tippfehler | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
3 |
p0011-08 | Tippfehler | Dr.-Ing. Danny Ammon | Universitätsklinikum Jena, Datenintegrationszentrum | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Leitfaden | Leitfadens | Tippfehler | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
4 |
p0011-24 | Tippfehler | Dr.-Ing. Danny Ammon | Universitätsklinikum Jena, Datenintegrationszentrum | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Ihren | ihren | Tippfehler | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
5 |
p0012-04 | Tippfehler | Dr.-Ing. Danny Ammon | Universitätsklinikum Jena, Datenintegrationszentrum | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
lies | ließ | Tippfehler | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
6 |
p0019-05 | Vorschlag | Dr.-Ing. Danny Ammon | Universitätsklinikum Jena, Datenintegrationszentrum | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Akteure und Transportwege | Sanitätshaus ergänzen | Verordnung von Hilfsmitteln wird oft in Sanitätshäusern eingelöst (weiterer Akteur neben Apotheke) | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
7 |
p0021-08 | Tippfehler | Dr.-Ing. Danny Ammon | Universitätsklinikum Jena, Datenintegrationszentrum | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Localisation | Localization | im Dokument einheitlich schreiben, vgl. p0011-06 | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
8 |
p0024 | Vorschlag | Dr.-Ing. Danny Ammon | Universitätsklinikum Jena, Datenintegrationszentrum | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Im Domänenmodell erben die Klassen "Patient" und "Autor" direkt von der abstrakten Klasse Person. | Modellierung über Rollen: Patient und Autor sind Rollen, in denen Personen an Anwendungsfällen des eRezepts teilnehmen. | Passfähigkeit des Domänenmodells zum HL7 RIM ("Person" als "Entität", die in einer Rolle "Patient" an einem bestimmten "Vorgang" teilnimmt). Würde auch den Zusammenhang Domänenmodell – Anwendungsfälle verbessern. | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Für die Abbildung in eine technische Spezifikation ist es egal, aus Konsistenzgründen ist eine Modellierung als Rolle aber sicherlich besser. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
9 |
p0025-24 | Tippfehler | Dr.-Ing. Danny Ammon | Universitätsklinikum Jena, Datenintegrationszentrum | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
spezifiiert | spezifiziert | Tippfehler | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
10 |
p0195-18 | Tippfehler | Dr.-Ing. Danny Ammon | Universitätsklinikum Jena, Datenintegrationszentrum | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
https://simplifier.net/kbvitavgexsstfhirvos/74PRVMPatient | https://simplifier.net/kbvitavgexsstfhirvos/74prvospatient | Link funktioniert nicht | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Die KBV hat einige Namen und Identifikatoren geändert, so dass sich die Links ebenfalls verändert haben. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
11 |
p0199-11 | Vorschlag | Dr.-Ing. Danny Ammon | Universitätsklinikum Jena, Datenintegrationszentrum | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
FHIR Release 4 Candidate http://build.fhir.org | FHIR R4: http://hl7.org/fhir/ | Offizielles Release 4 verlinken (current build ändert sich stets) | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | http://hl7.org/fhir/R4 | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
12 |
p22 | Negativ, kleineres Problem | Horst Kakuschke | HÄVG Hausärztliche Vertragsgemeinschaft AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Der Begriff „Leistungserbringer“ ist bei den beiden Diagrammen auf dieser Seite leicht unterschiedlich verwendet: das erste Diagramm positioniert den Arzt auf gleicher Ebene neben Leistungsbringern, beim zweiten Diagramm ist Arzt als Spezialisierung von Leistungserbringer gezeigt. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Es handelt sich hier um unterschiedliche Darstellungen. Im ersten Diagramm geht es um den Prozess, wobei der Arzt nur eine Rezept ausstellen kann, und nicht der Leistungserbringer. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
13 |
P25-22 | Negativ, schwerwiegend | Horst Kakuschke | HÄVG Hausärztliche Vertragsgemeinschaft AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Zu den Apothekenfeldern gehören auch noch Abgabekosten (z.B. Notdienstgebühr) | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | noch ergänzen | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
14 |
p24, p25, p26 | Negativ, schwerwiegend | Horst Kakuschke | HÄVG Hausärztliche Vertragsgemeinschaft AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Bei den Informationsmodellen sind m.E. auch Teilabgaben zu berücksichtigen. Daher sind einerseits mehrere Abgaben zu einer Verordnung möglich, eine Abgabe muss aber auch die Information enthalten, welcher Teil der Verordnung abgegeben wurde. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Das eRezept war so intendiert, dass nur zusammen abzugebende Medikamente gemeinsam aufgeführt werden sollen. Das kann natürlich trotzdem noch zu Teilabgaben führen. ES kann lt. Modell aber mehrere eAbgaben geben, da eine Verlinkung nur rückwärts erfolgt. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
15 |
P43-16 | Negativ, schwerwiegend | Horst Kakuschke | HÄVG Hausärztliche Vertragsgemeinschaft AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Apotheken-Nummer/ IK => Kostenträger.KassenNr | nicht zugeordnet | Die IK der abgebenden Apotheke steht in keinem Zusammenhang mit dem Kostenträger (der i.d.R. die Krankenkasse des Versicherten ist) | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | korrekt -> prüfen (Im Modell kommt die Apotheke nicht direkt vor, sondern nur über die Organisation. Hier muss dann aber noch ein "Leistungserbringer" ergänzt werden.) | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
16 |
P118-08 | Negativ, schwerwiegend | Horst Kakuschke | HÄVG Hausärztliche Vertragsgemeinschaft AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Zahlung Section | Zahlung Section | Siehe oben: die Abgabekosten fehlen hier | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | ergänzen | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
17 |
P116-15 | Vorschlag | Horst Kakuschke | HÄVG Hausärztliche Vertragsgemeinschaft AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Gebühren Section | Gebührenpflicht Section | Hier wird ja die Gebührenpflichtigkeit (bzw. Gebührenbefreiung) ausgedrückt, nicht die zu zahlenden bzw. gezahlten Gebühren | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Diese Änderung macht den konkreten Inhalt in Abgrenzung zur Zuzahlung klar. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
18 |
p19-19 | Kommentar allgemeiner Art | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Weitere Wege? | Löschung des Satzes, dafür Einleitung in dem Abschnitt, dass es mehrere Transportwege gibt, von denen einige exemplarisch aufgezeigt werden. | Sieht aus wie eine Arbeitsversion | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | gestrichen | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
19 |
p19-15 | Kommentar allgemeiner Art | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Darstellung der Wege | vielleicht bildhaft visualisieren? | Schnellere Erkennbarkeit von parallelen (1. und 2.) bzw. Unterschieden (1. und 3.) möglich | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Zur zukünftigen Verwendung | prüfen. Da die Transportwege für diese Spezifikation nicht relevant sind, wurde hier die "kurze" Darstellung gewählt. Vielleicht sollte dazu zumindest ein kurzer Einleitungssatz geschrieben werden. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
20 |
p26-31 ff | Kommentar allgemeiner Art | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
6.5.0.1 - 6.5.0.4 | Änderung der Hierarchieebene | warum nicht Abschnitt 6.5.1 - 6.5.4? | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Muss geprüft werden. So etwas passiert, wenn Texte wiederverwendet werden, dann aber die Einordnung in die Hierarchie nicht stimmt. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
21 |
p32 ff | Vorschlag | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Abschnitt 6.6.1, 6.6.2 | mir ist unklar, was mit diesem Abschnitt erreicht werden soll. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Weitergeleitet | Diese Passage ist aus dem Medikationsplan direkt übernommen und sollte zusätzliche Hinweise zur Dosierung geben, falls notwendig. Hier wäre zu diskutieren, inwieweit das wirklcih hilfreich und notwendig ist. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
22 |
p34 ff | Kommentar allgemeiner Art | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Anpassung Formatierung | Teile des Textes sind nicht erkennbar | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
23 |
p198-05 | Kommentar allgemeiner Art | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
https://simplifier.net/basisprofilde/s-kbv-personengruppe https://simplifier.net/basisprofilde/s-kbv-personengruppe2 | https://simplifier.net/basisprofilde/s-kbv-personengruppe2 | Nennung eines CodeSystems im Abschnitt "ValueSets" | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Zur zukünftigen Verwendung | Die Abschnitte zu FHIR sind nur informativ. Hier müsste zuerst diskutiert werden, wie hier vor dem Hintergrund verfahren werden soll, weil die KBV hier eigene proprietäre Profile erstellt. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
24 |
p197-08 | Kommentar allgemeiner Art | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
-- | Ergänzung https://simplifier.net/basisprofilde/s-kbv-personengruppe | Ergänzung des CodeSystems, das auf S. 198 gelöscht wird | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Zur zukünftigen Verwendung | vgl. #23 | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
25 |
p190-18 | Kommentar allgemeiner Art | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
2.16.840.1.113883.1.11.14581/dynamic | Ergänzung des Inhalts (ART-DECOR-Emport fehlt?) | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
26 |
p189-22 | Kommentar allgemeiner Art | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Keine Versionen mit Status new, draft, final, review or pending. | Inhalt oder Link einfügen | Inhalt fehlt | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Weitergeleitet | prüfen, wo der Inhalt herkommt bzw. geblieben ist; Value Set 2.16.840.1.113883.3.1937.777.27.11.2 | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
27 |
p126-19 | Vorschlag | Mareike Przysucha | Hochschule Osnabrück | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.458 Geschlecht (eGK)(DYNAMIC)
oder Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.3.1.135.8.11.25 Geschlecht2 (eGK)(DYNAMIC) |
warum zwei ValueSets? Warum nicht das zweite ValueSet? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Es handelt sich hier klassisch um eine Klassifikation, deren Semantik sich durch Aufnahme von "divers" ändert. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
28 |
S.10, Kap 2.1 | Tippfehler | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Dieses Formular wird jedoch zur Realisierung mehreren Anwendungsfälle (personenbezogenes Rezept, Sprechstundenbedarf, ..) genutzt, die nachfolgend näher erläutert werden. | Dieses Formular wird jedoch zur Realisierung mehrerer Anwendungsfälle (personenbezogenes Rezept, Sprechstundenbedarf, ..) genutzt, die nachfolgend näher erläutert werden. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | vgl. #2 | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
29 |
S.10, Kap 2.3 | Tippfehler | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
im weiteren Verlauf in den Abschnitt "Aufbau" und "Technische Spezifikationen" erläutert, | im weiteren Verlauf in den Abschnitten "Aufbau" und "Technische Spezifikationen" erläutert, | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
30 |
S.10, Kap 2.3 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
im weiteren Verlauf in den Abschnitt "Aufbau" und "Technische Spezifikationen" erläutert, | Satzfragment, nochmal gesamten Satz kontrollieren | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Formulierung prüfen | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
31 |
S.11, Kap 2.4.1 | Tippfehler | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Neben den Niederlanden hat auch Österreich in Ihren Spezifikationen | Neben den Niederlanden hat auch Österreich in seinen Spezifikationen | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
32 |
S.14, Kap 3.2 | Tippfehler | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Des Weiteren sind die FHIR-Profile zum eRezept auf dem so genannten R4 (wo möglich, sonst STU 3) von [3] [4] aufgebaut. | Des Weiteren sind die FHIR-Profile zum eRezept auf dem FHIR Release R4[3] (wo möglich, sonst STU 3[4]) aufgebaut. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
33 |
S.14, Kap 3.2 | Tippfehler | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
HL7 Deutschland: Elektronischer Arztbrief 2015[5] und "Arztbrief Plus"[6] | HL7 Deutschland: "Arztbrief 2014/2015"[5] und "Arztbrief Plus"[6] | Der offizielle Name im IG (http://download.hl7.de/documents/cdar2-arztbrief/Arztbrief2014-v100.pdf) ist "Arztbrief 2014/2015
auf Basis der HL7 Clinical Document Architecture Release 2 für das deutsche Gesundheitswesen", auch wenn der Dateiname irreführend Artzbrief2014 heisst und auf der korrespondierenden Wikiseite (http://wiki.hl7.de/index.php?title=Arztbrief_2014_(Projekt)) das Projekt Artzbrief 2014 aber der Implementierungsleitfaden Arztbrief 2015 heisst. Vielleicht mal das Wiki aufräumen. Ich weiss, das Projekt lief damals wirklich lange. |
|||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Wiki aufräumen ist immer eine gute Idee. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
34 |
S.14, Kap 3.2 | Tippfehler | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
▪ Implementierungsleitfaden "elektr. Arbeitsunfähigkeitsbescheinigung" | ▪ Implementierungsleitfaden "Elektronische Arbeitsunfähigkeitsbescheinigung" | Bitte noch Referenz in 18.2 hinzufügen | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
35 |
S.14, Kap 3.2 | Tippfehler | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
sowie von HL7 Deutschland e. V. zur Verfügung gestellte CDA-Templates und FHIR-Profilen. | sowie von HL7 Deutschland e. V. zur Verfügung gestellten CDA-Templates und FHIR-Profilen: | Tippfehler | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
36 |
S.15, Kap. 3.3. | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
HTML-Dokumentation steht auf http://hl7de.artdecor. org/index.php?prefix=vomgt- zur Verfügung | Unter dem angegebenen Link steht bisher ausschließlich eAU zur Verfügung (Stand 20.8.). Vielleicht nochmal generieren. Die Live Version enthält alles. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | korrekt, die Materialien müssen nochmal neu generiert werden | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
37 |
S.16, Abb. 3 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
[Abbildung 3] Beispiel der Darstellung von FHIR-Profilen in ART-DECOR®, die auf simplifier.net gehostet werden | Die Abbildung selbst fehlt. Bitte hinzufügen. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information vom Antragsteller | unklar, was da genau passiert ist -> prüfen -> da ist eine Abbildung | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
38 |
S.18, Kap. 4.2 | Tippfehler | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Safemail | SafeMail | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
39 |
S.18, Kap. 4.3 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Eine eVerordnung/ ein eRezept kann papierbegleitend, aber auch papierersetzend umgesetzt werden. Im letzteren Fall ist diese mit einer rechtssicheren elektronischen Signatur (fortgeschritten oder QES) zu ergänzen:
▪ Datenschutz-/-sicherheit ▪ IT-Sicherheit ▪ Verschlüsselung ▪ Signaturen |
Eine eVerordnung/ ein eRezept kann papierbegleitend, aber auch papierersetzend umgesetzt werden. Im letzteren Fall ist diese mit einer rechtssicheren elektronischen Signatur (fortgeschritten oder QES) zu ergänzen. | Es ist nicht klar, was die Stichpunktsammlung da soll. Im Satz ging es erstmal nur um Signatur. Eventuell wollte der Autor daraus noch mehr schreiben unter der Überschrift "Rechtssichere Übertragung". | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Liste wird erstmal gelöscht. Bei Bedarf kann diese später wieder ergänzt werden. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
40 |
S. 19, Kap. 4.4 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Folgende Akteure kommen in Kontakt mit einer Verordnung/ einem Rezept
▪ Vertragsarzt ▪ Krankenhaus ▪ Versicherter ▪ Apotheke/ Krankenhausapotheke ▪ Kostenträger ▪ Kassenärztliche Vereinigung |
Folgende Akteure kommen in Kontakt mit einem Rezept
▪ Vertragsarzt ▪ Krankenhaus ▪ Versicherter ▪ Apotheke/ Krankenhausapotheke ▪ Kostenträger ▪ Kassenärztliche Vereinigung |
Bei einer Verordnung (darunter fallen u.a. auch Heilmittelverordnungen) würden weitere Akteure (z.B. Physiotherapeuten, Sanitätshäuser, …) auftauchen. In diesem IG geht es aber erstmal nur um Muster 16. | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Text ergänzen. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
41 |
S.19, Kap. 4.5 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
1. Arzt – Patient – Apotheke – Apothekenrechenzentrum – Krankenkasse – Kassenärztliche Vereinigung
2. Krankenhaus – Patient – Apotheke – Apothekenrechenzentrum – Krankenkasse – Kassenärztliche Vereinigung 3. Arzt – Patient – Apotheke – Apothekenrechenzentrum – Berufsgenossenschaft – Kassenärztliche Vereinigung Weitere Wege? |
1. Arzt – Patient/Angehöriger/Bevollmächtigter – Apotheke – Apothekenrechenzentrum – Krankenkasse – Kassenärztliche Vereinigung
2. Krankenhaus – Patient/Angehöriger/Bevollmächtigter – Apotheke – Apothekenrechenzentrum – Krankenkasse – Kassenärztliche Vereinigung 3. Arzt – Patient/Angehöriger/Bevollmächtigter – Apotheke – Apothekenrechenzentrum – Berufsgenossenschaft – Kassenärztliche Vereinigung Weitere Wege? |
1. Es ist nicht immer der Patient, der das Rezept "überbringt".
2. Rezepte gehen auch von Ärzten an (mobile/stationäre) Pflegedienste, die diese dann einlösen. Die habe ich unter Bevollmächtigte zusammengefasst, man könnte diese Wege aber auch explizit als weitere Wege darstellen, wenn es wichtig ist, dass hier auch weitere Organisationen und Orte mit beteiligt sind 3. Wenn ein Patient (bspw. nach Schlaganfall) im Anschluss an seinen Krankenhausaufenthalt stationäre oder ambulante (Tages-) Reha bekommt, so erhält der Patient in diesen Einrichtungen häufig auch seine Medikamente, ohne dass er diese mitbringen muss. Das ist aber m.E. ein Fall für den Medikationsplan und nicht für das Rezept. Bin mir aber bei direketer Verlegung nicht sicher, ob nicht doch die Reha-Enrichtung das Rezept auch bekommt. |
|||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
42 |
S. 20, Kap 5 | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
eVerordnung/eVerschreibung im Use-Case-Diagramm | 1. Hier wird das erste mal der Begriff eVerschreibung eingeführt. Wenn man das Dokument weiter durchliest, wird irgendwann klar, dass "eVerordnung" den Vorgang meint und "eVerschreibung" das Artefakt/Dokument. Allerdings wird auch in der Abbildung nicht konsistent eVerschreibung und eVerordnung eingesetzt. Sollte konsistent verwendet und hier schon mal die Begriffe erklärt werden. 2. Der Use Case "eRezept erstellen" leitet von "eVerschreibung erstellen" ab und verwendet "eRezept", welches von "eVerordnung" ableitet. Gleichzeitig verwendet aber "eVerschreibung erstellen" nicht "eVerordnung". | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Zur zukünftigen Verwendung | Sollte man nochmal besser erläutern.
Darüber hinaus sollte das Dokument eVerordnung in 5.0 durch eVerschreibung ersetzt werden. Das Use Case Diagramm muss dann entsprechend auch noch angepasst werden. |
||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
43 |
S. 20, Kap 5 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Abbildung Use-Case-Diagramm | Die Abbildung hat keine Unterschrift und Nummer, fehlt damit auch im Abbildungsverzeichnis 18.3. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
44 |
S.20, Kap. 5 | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Es gibt keinen Use Case "Medikation verordnen" in der Abbildung. Die Unterkapitel 5.x sollten systematisch nach den in der Abbildung benannten Use Cases getrennt werden und dabei die definierten Bezeichner konsistent verwendet werden. Das Kapitel 5 sollte klar darstellen, welche Use Cases im Scope des IG sind und welche außerhalb des Scopes. M.E. kann der gesammte Absatz zu Heil- und Hilfsmittel als Out-of-Scope gestrichen oder zumindest markiert werden. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Zur zukünftigen Verwendung | Mit 5.1 war gemeint, dass sich der Use Case aus bestimmten Teilen des Use Case Diagramms ergibt. Die Intention des Diagramms und der anderen Modelle war, eine überleitende Gemeinsamkeit herzustellen. Wenn das nicht gewünscht ist, dann kann man aus diesem Leitfaden vieles rausstreichen. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
45 |
S.22, Kap. 6.2.1 | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Zuerst einmal lässt sich der Prozess in drei Teile zerlegen:
▪ eVerordnung: Arzt - Patient ▪ eAbgabe: Patient - Leistungserbringer - Patient ▪ eAbrechnung: Leistungserbringer - Kostenträger |
Zuerst einmal lässt sich der Prozess eVerordnung in drei Teile zerlegen:
▪ eVerschreibung ▪ eAbgabe ▪ eAbrechnung |
Es wird nicht klar, was die Aufzählungen der Rollen jeweils darstellen soll: Rollen oder Beteiligte an Unterprozessschritten? Vorschlag: weglassen, da es ja nur um die Darstellung der 3 Teile des Gesamtprozesses eVerordnung geht. Bitte auch hier konsistent sein in der Benamung (siehe folgendes Abbild) von eVerordnung und eVerschreibung. | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Kann man überarbeiten, vielleicht als Tabelle, um die Klarheit zu erhöhen? Aktuell soll die Aufzählung die Akteursketten in den drei Einzelprozessen auflisten. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
46 |
S.22, Kap. 6.2.2 | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Genauso können einzelne Akteure weiter spezialisiert werden, je nachdem, um welche Verschreibung es sich handelt. | Genauso können einzelne Akteure weiter spezialisiert werden, je nachdem, um welche Verordnung es sich handelt. | In der Abbildung heisst es eVerordnung. Bitte wirklich konsistent Begriffe und dahinterliegende Semantik (Prozess oder Artefakt) verwenden. | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | korrekt | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
47 |
Kap. 6 ff | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Sämtliche Abbildungen sollten durchnumeriert und beschriftet werden (landen dann auch im Abbildungsverzeichnis). Aber es würde vor allem die Referenzierung in Kommentaren erleichtern… | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
48 |
Kap. 6.2.3 | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
letzte Abbildung Templatebeziehungen | Die Zuzahlung ist doch etwas im Prozess der "eVerordnung einlösen" und nicht in "eVerordnung abrechnen". Sollte es daher nicht Teil vom eAbgabe-Dokument sein, welches den Prozess "eRezept einlösen" dokumentiert? Aus den gleichen Überlegungen: Warum gibt es im Dokument "eAbrechnung" nochmal die Informationen zur abgegebenen Medikation und deren Preis (redundant zu eAbgabe). Ich rechne doch nicht ein anderes Medikament ab, als das was ich abgegeben habe?! | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information vom Antragsteller | Die Überlegung dahinter war, dass die eAbgabe die abgegebene Medikation dokumentiert, was vielleicht für die Akte wichtig ist. Während bei der eAbrechnung auch Zuzahlungen relevant sind. Umgekehrt ist die Zuzahlung für die Akte nicht relevant. Das sollte nochmal diskutiert werden. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
49 |
Kap 6.3 | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Domänenmodell Abbildung | Unübersichtliches Domänenmodell, da eine Vielzahl von für das eRezept irrelevanten weiteren Klassen aufgenommen wurden. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Ziel dieser Abbildung war, die Grundlage für weitere Leitfäden zu schaffen, die das dann einfach wiederverwenden können. Darüber hinaus sollten weitere Zusammenhänge aufgezeigt werden.
Eine Separation ist nicht so einfach möglich, da es dierse Querbezieuhungen gibt, so dass das Gesamtmodell, obwohl sehr umfangreich, insgesamt besser ist. (Ansonsten vgl. #44) |
||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
50 |
S.199, Kap 18.2 | Tippfehler | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
3. FHIR Release 4 Candidate http://build.fhir.org | 3. FHIR Release 4 http://hl7.org/fhir/R4/ | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | vgl. #11 | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
51 |
S.199, Kap 18.2 | Tippfehler | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
4. FHIR STU 3, http://build.fhir.org | 4. FHIR STU 3, http://hl7.org/fhir/STU3/ | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | vgl. #11 | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
52 |
S.25, Kap. 6.4, erste Abb | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Kassen-IKNr string LANR string | Datentypen IN Abbildung nochmal überprüfen. Die IK-Nummer und die LANR sind formal gesehen identifier. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | in Art-Decor Dataset | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
53 |
S.25, Kap. 6.4, erste Abb | Tippfehler | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Arztname | Bitte ausfüllen analog zum Patientennamen | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | in Art-Decor Dataset | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
54 |
S.25, Kap. 6.4 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Auf der linken Seite stehen die drei Dokumente, die spezifiziert werden müssen. | Im Informationsmodell sind auf der linken Seite 4 Akte (entsprechend HL7 RIM Farbkodierung) abgebildet. Davon sind die oberen 3 sicher gemeint, die jeweils in ein eigenes CDA-Dokument abgebildet werden sollen. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Korrekt, das war gemeint. Das kann man sicherlich auch besser formulieren und vielleicht optisch erkennbar gestalten. Außerdem muss in der Abbildung die eAbgabe sich auf die Abgabe-Medikation beziehen. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
55 |
S.26, Kap. 6.5 | Tippfehler | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Ein Dosierschemas besteht typischerweise aus Zeitangaben (der Einnahme) und der Dosis (Medikamentenmenge). | Ein Dosierschema besteht typischerweise aus Zeitangaben (der Einnahme) und der Dosis (Medikamentenmenge). | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
56 |
S.28, Kap. 6.5.0.2 | Tippfehler | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die folgenden Tabellen geben eine Übersicht über Einnahmezeitpunkte (Ereignisse bzw. die zu verwendenden Codes) sowie möglichen Mahlzeitenhinweisen. | Die folgenden Tabellen geben eine Übersicht über Einnahmezeitpunkte (Ereignisse bzw. die zu verwendenden Codes) sowie mögliche Mahlzeitenhinweise. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
57 |
S.28, Kap. 6.5.0.2 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Das Value Set sollte ins Kapitel 14 Terminologien, genauer das dafür vorgesehene Kapitel 14.6. verschoben werden. Dort fehlt es interessanterweise. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Allerdings ist zu prüfen, inwieweit das machbar ist, weil die Textstelle aus dem Medikationsplan ohne Änderung übernommen wurde. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
58 |
S.31, Kap. 6.5.0.3 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Value Set zu Zeiteinheiten | Das Value Set ist redundant in 14.7 bereits enthalten und sollte einfach referenziert werden. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Das Textfragment ist so komplett übernommen worden. Hier ist zu prüfen, inwieweit das verbessert werden kann. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
59 |
S.33/34, Kap. 6.6.3 | Tippfehler | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Tabelle abgeschnitten am rechten Seitenrand | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | vgö. #22 | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
60 |
S.36, Kap.7 | Tippfehler | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Ein Mapping zwischen den Schemata aus der TI und dem beschriebenen CDA-Templates ist möglich. | Ein Mapping zwischen den Schemata aus der TI und den beschriebenen CDA-Templates ist möglich. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
61 |
S.37, Tabelle | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
9a Apothekennummer Apotheken-Nummer
/ IK Kostenträger .KassenNr |
Das Mapping scheint nicht richtig zu sein. Apothekennummer auf Kostenträger? Außerdem fehlt das Mapping im CDA. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | korrekt: Leistungserbringer .Identifkation | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
62 |
S.37, Tabelle | Tippfehler | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
13c Vorname " author .assignedAuthor .assignedPerson .name.given | 13c Vorname Person.Name author .assignedAuthor .assignedPerson .name.given | bitte fortfolgend auch die " ersetzen. | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
63 |
S.37, Tabelle | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
12
Fälschungssicheres Ausfüllen des Vordrucks |
In den Bemerkungen kann darauf hingewiesen werden, dass diese Eigenschaft durch elektronische Signatur der Dokumente erreicht werden kann, dies aber außerhalb des Skopes ist | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
64 |
S.37, Tabelle | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
13f ASV-Teamnummer Person.id
author .assignedAuthor .id.[root= "1.2.276.0.76.4.99999"] .id.@extension 1.2.276.0.76.4.99999 noch die richtige OID für das Codesystem zuordnen |
Das Mapping von ASV-Teamnummer auf Person.id oder Author ist inhaltlich falsch. Die Teamnummer entspricht mehr einer (virtuellen) Organisations-ID und identifiziert keine einzelne Person. Sollte eventuell eine weitere Organisation .Identifikation und author .representedOrganisation verwendet werden. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | neue Klasse "Team" im Modell | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
65 |
S.40, Tabelle | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
7b Impfstoff Inhaltsstoff.Inhaltsstoff
Feld 8=8, Value Set für ClinicalDocument .code definieren, oder Kennzeichen bei dem Medikament? 7c Sprechstunden Bedarf Praxisrezept anderes recordTarget Template 1.2.276.0.76.3.1. 135.8.10.118 |
Inhalt des Kommentarfeldes sieht nach Cut&Paste aus Zeile 7a aus. Was hat denn der Inhaltsstoff mit dem Document.Code zu tun? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Zur zukünftigen Verwendung | nicht ganz: Die Checkboxen werden mit bestimmten Werten gefüllt. Eine originäre Umsetzung ist nicht erstrebenswert. Das betrifft mehrere Zeilen der Tabelle, die gemeinschaftlich gelöst werden müssen. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
66 |
S.43, Tabelle | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Befreiung von der
Notdienstgebühr " " NOCTU 1.2.276.0.76.3.1 .135.8.11.25 |
Befreiung von der
Notdienstgebühr " " NOCTUFREI 1.2.276.0.76.3.1 .135.8.11.25 |
die gewählten Codes auf Seite 42, 2a und 2b geben direkt Auskunft ob befreit (GEBFREI) oder gebührenpflichtig (PFLICHTIG). Die Bedeutung von NOCTU ist aber im negierten Sinn, eben gerade keine Notdienst/Nachtgebühr. Daher konsistent bitte NO-NOCTU oder NOCTUFREI oder sinnemäß wählen. | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
67 |
S.43, Tabelle | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
8 Begründungspflicht noch abbilden nicht verwenden | Was denn? Noch abbilden oder nicht verwenden? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Zur zukünftigen Verwendung | prüfen und bessere Lösung wählen | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
68 |
Tabelle 1 | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Es fehlen grundsätzlich noch viele Mappings in der CDA-Template Spalte. Häufig korreliert mit leeren Bemerkungsfeldern. Es ist daher unklar, ob es hier einfach eine offene Mapping-Aufgabe ist oder kein Mapping besteht oder keines erwünscht/benötigt ist. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Freiwillige vor…. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
69 |
S.58,Kap. 10.1 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Hier sollte das administrative Geschlecht des Patienten übermittelt werden. In KBVFormularen
spielt allerdings nur die Information über das Geschlecht eine Rolle, was auf der eGK enthalten ist. Dies wird über eine separate Observation übermittelt. Deshalb entfällt diese Element. |
Nicht jedem ist der semantische Unterschied zwischen dem administrativen Geschlecht und dem Geschlecht auf der eGK klar. Man könnte daher Hintergrundinfo hinzufügen, die das herleitet. Nicht kritisch. Verweis auf http://wiki.hl7.de/index.php?title=Geschlecht reicht m.E. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Als Hilfestellung in reocrdTarget ergänzt. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
70 |
S. 97, Kap. 11.2 | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
hl7:patientRole 1 … 1 (CDA...mgt) @classCode cs 0 … 1 F PAT | Ein Sprechstundenbedarf hat doch keinen Patientenbezug. Kann m.E. daher gar keine korrekt befüllt patientRole haben.Sollte das Konformitätskriterium damit icht auf NP gesetzt werden, statt irgendwelche lokalen Patienten-Ids zu erfinden? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | patientRole ist im Zusammenhang mit recordTarget zu sehen, was generischer als "Patient" aufzufassen ist.
Im Modell muss die Beziehung deshslb von eVerschreibung zu Patient aber auf 0..1 gesetzt werden. In den Templates ist das schon rihctig ausgedrückt. Der classCode ist jedoch nochmal zu prüfen. |
||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
71 |
S.142, Kap. 13.10 | Tippfehler | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
XXX:quantity | pharm:quantity | an mehreren Stellen in den Beispielen zu ersetzen | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Weitergeleitet | Da dieses Template nur importiert ist, kann hier keine Änderung direkt vorgenommen werden. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
72 |
S.195, Kap. 14.11 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Beschreibungen der Value Set Tabelle sind nicht umgebrochen und damit nicht vollständig lesbar | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | auf Querformat umstellen: die Value Set Exports aus ART-DECOR besitzen unterschiedliches Format. Hier ist unklar, warum der anscheinend neuere Export viel mehr Platz benötigt?! | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
73 |
S.199, Kap 18.1 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Hier sollten wohl noch Beispiele rein. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Die Beispiele sollten in das begleitende Package, da eine direkte Auflistung den Umfang des Dokuments sprengt. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
74 |
S.9 | Kommentar allgemeiner Art | Mathias Aschhoff | RZV | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Das Thema eVerordnung/eRezept sollte in einem gesonderten Kapitel erläutert werden.
zunächst werden nur die Begriffe eVerordnung und eRezept verwendet. Später wird klar (im Informationsmodell) was da alles dran hängt. Hier würde erstmal ein oder statt ein / helfen später sollte Literatur oder ähnliches aufeführt werden, um aufzuschlüsseln was eine eAbgabe etc. bedeutet. |
|||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Zur zukünftigen Verwendung | gute Idee, da sich aber keiner für diese Spezifikation interessiert, ist der Aufwand aber nicht mehr gerechtfertigt, obwohl auf dem DIT dieses mehrfach gefordert wurde. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
75 |
S.9 | Kommentar allgemeiner Art | Mathias Aschhoff | RZV | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Darstellung von FHIR Profilen über den Leitfaden sollte überdacht werden. Es werden alle Infos im Dokument zur Verfügung gestellt und zu FHIR nur Links | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Zur zukünftigen Verwendung | Der Leitfaden enthält ein Infornationsmodell, um zwischen verschiedenen Technologien brücken zu können. Dazu ist FHIR dann notwendig. Nur wenn die entsprechenden FHIR-Arbeiten losgelöst von der hier skizzierten Vision und auf ein reduziertes Ziel proprietär durchgeführt werden, dann sind diese Arbeiten sinnlos. Aus diesem Grund wurde hier auch noch nicht viel Aufwand investiert und die Stellen enthalten nur die Referenzen. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
76 |
S.13 | Kommentar allgemeiner Art | Mathias Aschhoff | RZV | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Reihe Ausgewählter Templates | schwer dann zu sagen was genau, daher schwer bei der Kommentierung nun zu beurteilen. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Zur zukünftigen Verwendung | Ziel sollte eine integrierte Lösung des Problem sein, das mit "Medikation" tituliert werden kann. Wenn aber alle Projekte unabhängig voneinander irgendetwas adressieren, dann erübrigt sich jede weitere Diskussion. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
77 |
S.18 | Kommentar allgemeiner Art | Mathias Aschhoff | RZV | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
oben wird das Thema Signatur klar ausgeklammert und kommt hier wieder. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Zur zukünftigen Verwendung | Das ist das Problem mit solchen Materialien, weil der eine etwas erwähnt haben möchte, andere es aber nicht…. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
78 |
S.19 | Kommentar allgemeiner Art | Mathias Aschhoff | RZV | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
doppelt siehe Kapitel Nutzer oder? | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Zur zukünftigen Verwendung | Der Absatz zu den Akteuren sollte aus Kap. 2.5 entfernt werden. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
79 |
S.26 ff und S. 36 ff | Kommentar allgemeiner Art | Mathias Aschhoff | RZV | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Ich bin der Meinung, dass dies als Beispiele als Anlage hinzugefügt werden sollte und nicht als Kapitel | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Können wir gerne so machen. Vgl. #73 | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
80 |
S. 45 | Kommentar allgemeiner Art | Mathias Aschhoff | RZV | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Für die Kardinalitäten wird auf ein anderen Wiki Eintrag hingewiesen, für die anderen Dinge wie LANR, BSNR etc nicht. Hier sollten konsequent allgemeingültige Kapitel in den z.B. Arztbrief oder FAQ ausgeleitet werden und verwiesen werden. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information vom Antragsteller | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
81 |
S.55 und 93 | Kommentar allgemeiner Art | Mathias Aschhoff | RZV | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
warum nicht der recordTarget aus dem Arztbrief 1.2.276.0.76.10.2001 | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Weil noch Zusatzangaben und Anpassunge notwendig sind. Es könnte aber überlegt werden, das hier als Spezialisierung zu erstellen, wenn das Basistemplate dies zulässt. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
82 |
S.96 | Kommentar allgemeiner Art | Mathias Aschhoff | RZV | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Warum nicht über CDA.InformationRecipient abgebildet | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Weil das Rezept, bspw. eine Charge Impfstoff, nicht für einen Patienten, sondern für die Praxis ist. InformationRecipient ist damit nicht geeignet. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
83 |
S. 108 | Kommentar allgemeiner Art | Mathias Aschhoff | RZV | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Wäre das nicht was allgemeingültiges das im Arztbrief nachgezogen werden sollte? | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Weitergeleitet | Sollte zumindest diskutiert werden. Eine separate Insurance Section ist nur notwendig, wenn alls eGK-Daten benötigt werden, was in einem einfachen Arztbrief nicht der Fall ist. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
84 |
4.4000000000000004 | Vorschlag | Diana Ovelgoenne | Siemens Healthcare GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Folgende Akteure kommen in Kontakt mit einer Verordnung/ einem Rezept
▪ Vertragsarzt ▪ Krankenhaus ▪ Versicherter ▪ Apotheke/ Krankenhausapotheke ▪ Kostenträger ▪ Kassenärztliche Vereinigung |
Folgende Akteure kommen in Kontakt mit einer Verordnung/ einem Rezept
▪ Vertragsarzt ▪ Krankenhaus ▪ Versicherter / Patient ▪ Apotheke/ Krankenhausapotheke ▪ Kostenträger ▪ Kassenärztliche Vereinigung |
Patient wird in dem ganzen Dokument benutzt. Trotzdem fehlt der Akteure in der Liste. | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | vgl. #40 | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
85 |
6.5.0.2 Ereignis-gesteuert, ggf. mit Offset 1.2.276.0.76.11.463 | Vorschlag | Diana Ovelgoenne | Siemens Healthcare GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Legende: Typ L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavors werden im @nullFlavor Attribut statt in @code | Wäre gut, wenn Level 0 & 1 auch erklärt werden. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Die Legende wird automatisch mit dem Export erzeugt. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
86 |
6.6.3 | Vorschlag | Diana Ovelgoenne | Siemens Healthcare GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Tabelle ist abgeschnitten. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | vgl. #22 | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
87 |
8.1.2 | Tippfehler | Diana Ovelgoenne | Siemens Healthcare GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
"Best Practive" | "Best Practice" | Tippfehler | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
88 |
13.13 Einzeldosierungen effectiveTime Beispiel 3 | Tippfehler | Diana Ovelgoenne | Siemens Healthcare GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
</effectiveTime>
<doseQuantity> <low value="1" unit="{Hübe}"/> <high value="2" unit="{Hübe}"/> </doseQuantity> |
In 2.16.840.1.113883.2.6.60.4.11.23 steht Hub und nicht Hübe.Wenn sich der Display text eines Code Singular zum Plural unterscheidet sollte besser Codesystem und CodeValue verwendet werden. Sonst könnte evtl. die Validierung Probleme geben. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Dies wird als Export so übernommen. | ||||
|
|||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
89 |
14.8 RouteCode | Negativ, kleineres Problem | Diana Ovelgoenne | Siemens Healthcare GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
2.16.840.1.113883.1.11.14581/dynamic | Das Wiki link ist mehr oder weniger leer. Ist dass richtig? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | sicherlich nicht, das ist ein fehlender Export |