Kommentare und Auflösungen zum Abstimmungsverfahren Patientenbezogener Medikationsplan Plus
Stand: 15. Dezember 2017
| Auszählung (Tally) | |
|---|---|
| Anzahl Kommentare | 136 |
| Angenommen | 19 |
| Angenommen mit Modifikationen | 11 |
| Nicht angenommen | 4 |
| Nicht relevant | 0 |
| Zur zukünftigen Verwendung | 4 |
| Weitergeleitet | 0 |
| Warten auf Information vom Antragsteller | 0 |
| Warten auf Information von anderer Arbeitsgruppe | 0 |
| Unbearbeitet | 98 |
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
|---|---|---|---|---|---|
| 1 | S.4. |  Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
Kommentar  | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Inhaltsverzeichnis: Die Untergliederung des Kapitel 6 ist etwas verschoben. | Vorschlag: Kapitel 6 CDA Templates 6.1 CDA Header level Templates ….usw. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 2 | S. 20 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Leere Seite | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 3 | Allg. | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Es wird nicht wirklich deutlich welche Unterschiede es zwischen PMP und MP Plus gibt. Es wird auf die Schwachstellen hingewiesen und was zu tun ist, eine Übersicht wäre evtl schön für die Argumentation was und warum es hinzugenommen worden ist. | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 4 | S.31 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Ich bleibe wie im event@home auch dabei das die Gesamtübersicht toll ist aber einzelne Schnipsel über dem jeweiligen Template der Hammer wären. | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 5 | S.24 / 21 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Warum ist das Datum im Titel? | |||||
Reconcile  | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Sollte dort in der Tat nicht stehen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 6 | S.52 / 04 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Davor wurde das mit der id schön erklärt, allerdings ist hier die Frage woher kommt die ID für das Device vor allem die root id wird interessant… | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 7 | S.53 / 12 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Hier wird nur noch die BSNR angegeben, ist das also die einzige id die als custodian verwendet werden darf? Eine Beschreibung wäre sicher hilfreich | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 8 | S.55 / 12 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Woher kommt die root id? Allgemeine Frage, nicht jede Organisation hat eine OID und es ist in Projekten fast unmöglich das Zeitgerecht hinzubekommen. Wie löst ihr das? | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 9 | S.56 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Warum wird der Name hier so detailliert beschrieben? Wäre eher was für einen allgemeineren Leitfaden ( AB + ) oder German Template Collection Autumn 2017 ;-) Btw. Cooles Beispiel | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 10 | S.61 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Schön wäre hier ein Beispiel außerhalb der Schwangerschaft, sonst erweckt es den Eindruck, dass es nur um Schwangerschaft geht. | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 11 | S.66 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Warum nutzt man das Header Element Consent nicht? | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 12 | S.166 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Warum ein Organizer mit nur einem Component? | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 13 | S. 108 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Hier wird nochmal der author angegeben, in der Gruppierung auch der Autor des Medikaments und der Gruppe ist dann etwas verwirrend da Dr. A,B,C etwas verschrieben hat und nur einer davon im Organizer stehen kann. Nochmal überdenken | Spricht für mich gegen den Organizer | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 14 | S.86 / 11 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Toll wäre hier eine direkte Beschreibung, oder eine Aufnahme ins Beispiel, hatte etwas gebraucht bis ich das mit dem Value-Set CD,CV etc. hinbekommen habe. | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 15 | S. 86 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Wie kann ich denn hier aussagen, einmal die Woche? Alle 3 Wochen etc.? | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 16 | S. 121 / 07 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Value-Set gilt als veraltet in ART-DECOR? Why? http://art-decor.org/art-decor/decor-valuesets--pmp-?id=2.16.840.1.113883.2.6.60.4.11.5&effectiveDate=dynamic | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 17 | S. 120 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Warum erst ein ACT und dann ein ACT mit der Request Order, könnte man nicht direkt den ACT RQO als Patienteninstruktion nehemn 0..*? | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 18 | S. 78 / 06 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Woher kommt die id , wie generiert man sie | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 19 | S. 75 / 21 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Woher kommt die id , wie generiert man sie | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 20 | S.88 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Wenn in value die Zeit reinkommt, was kommt dann in effectiveTime, Beschreibung wäre super | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 21 | S. 126 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Das meinte ich bei event@home, toll gemacht hier zur abstimmung das so aufzulisten! | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 22 | S. 129 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Es wird im Bild nicht klar ob die rot markierten gestrichen sind oder wichtig sind, das wäre gut für die Beschreibung. | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 23 | S. 130 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Anstelle einer grundlegenden Beschreibung von FHIR, die sich immer wiederholen würde. Aber hier gut ist, wäre es sicher sinnvoll eine Seite zu haben oder zu verlinken, wie man Simplyfier liest. Ja, wir kennen uns damit aus aber es soll Leute geben, die das nicht jeden Tag machen ;-) | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 24 | S. 131 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Warum wird der Custodian leer gelassen, in CDA ist er ja auch angegeben.?? | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 25 | S. 130ff | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Eher allg. Kommentar: Mir fehlt für die Simpyfier Definitionen irgendwie ne Beschreibung oder Beispiele. Sich das über die generischen Profildefinitionen herzuleiten, was das für den MPP heißt ist mir zu abstrakt ;-) Klar wurde es erst mit S.134, der Aha Effekt kam mir zu spät | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 26 | S. 134 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Beispiel: Im Simplyfier steht in der Composition, dass status 1..1 ist im Bsp ist es nicht enthalten? | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 27 | S. 147 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| FHIR und UKF Beispiele sollten mit zu den Materialien, die man unter ART-DECOR herunterladen kann oder die URL angeben. Denke, dass kann man gut Trennen Leitfaden + Supportmaterial | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 28 | S. 194 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| SNOMED Lizenz, fein, aber im Leitfaden wird nie SNOMED verwendet, warum also die Referenz? | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 29 | Allg. | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Toller Leitfaden, klasse Arbeit, sehr inspirirend auch für andere Arbeiten! | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 30 | S. 43, Zeile 18 |  Vorschlag | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| An dieser Stelle kann die Arztnummer (LANR) unter Angabe der dazugehörigen OID übermittelt werden. | Beispiel von author/assignedAutor/id übernehmen | Verbessert Lesbarkeit | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 31 | S. 36, Zeile 7-8 | Vorschlag | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| … . Zu beachten
ist, dass prefix- und suffix-Elemente mit einem Leerzeichen enden müssen, wenn sie nicht unmittelbar an den folgenden Namensbestandteil anschließen sollen | Satz streichen | Es sollte Aufgabe der rendering application sein, in welcher Reihenfolge und mit welchen whitespaces der Name angezeigt wird. Trailing spaces werden ja auch nicht beim Vornamen verlangt, damit der vom Nachnamen getrennt dargestellt wird. Beim suffix ist es auch unklar was der folgende Namensbestandteil sein soll und was der Use Case ist bei dem man einen trailing space im suffix braucht. | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 32 | S. 132, Zeile 29 | Kommentar allgemeiner Art | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| 7.2.10 Einverständniserklärung ...
▪ Profile: https://simplifier.net/medikationsplanplus/consent-1 ▪ Canonical: http://fhir.de/StructureDefinition/medikationsplanplus/consent | Links führen ins leere, im simplifier.net für "medikationsplanplus" existiert keine Consent Profildefinition. In der composition ist die einverständnisSection durchgestrichen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 33 | S. 133, Zeile 17 |  Tippfehler | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| denn mit dem Vorhandensein von Infrastrukturen zum Datenaustausch
... gelten inhaltliche vollständige Wiedergaben von Inhalten obsolet. | denn mit dem Vorhandensein von Infrastrukturen zum Datenaustausch … werden inhaltlich vollständige Wiedergaben von Inhalten obsolet | Alternative: gelten als obsolet Alternative: werden inhaltliche, vollständige Wiedergaben | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 34 | S. 168, Zeile 15 | Kommentar allgemeiner Art | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Dieses Value Set beinhaltet 547 Codes. Um die Publikationsgröße überschaubar zu halten, wird nur eine Auswahl (500 Codes) des ganzen Sets von Codes gezeigt. | alle 547 codes anzeigen, wenn notwendig die 47 fehlenden in einem eigenem Abschnitt | Wenn man 500 auflistet kann man auch noch 47 mehr auflisten. | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 35 | S. 121, Zeile 7 | Vorschlag | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.2.6.60.4.11.5 AKdÄ Hinweise (DYNAMIC)
oder @codeSystem muss "2.16.840.1.113883.6.96" sein | In 9.1 oder 9.2 aufführen | Das ValueSet wird weder in 9.1 noch in 9.2 aufgeführt. Es ist auch im HL7.de Wiki und im Art Decor nur in einer veralteten/deprecated Version zu finden. | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 36 | S. 121, Zeile 8 | Kommentar allgemeiner Art | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.2.6.60.4.11.5 AKdÄ Hinweise (DYNAMIC)
oder @codeSystem muss "2.16.840.1.113883.6.96" sein | idealerweise feste vorgabe eines nicht veralteten, nicht Lizenz-belasteten Code Systems, notfalls Definition eines neuen Code Systems | Ist der Einsatz von SNOMED CT Codes an dieser Stelle durch die HL7 Deutschland Lizenz gedeckt? Oder müssten Projekte die Medikationspläne mit SNOMED CT codes für Patientenhinweise arbeiten dafür eine SNOMED CT Lizenz beantragen? | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 37 | S.9 Kap 2.1 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| bildet den
▪ den CDA-basierten Medikationsplan in ISO/HL7 27932:2009 Ausgabe ▪ die Profile für den FHIR-basierten Medikationsplan und ▪ die Vorgaben für das so genannte Ultrakurzformat (UKF) in der offiziellen Fassung für Deutschland. | bildet den
▪ den CDA-basierten Medikationsplan in ISO/HL7 27932:2009 Ausgabe ▪ die Profile für den FHIR-basierten Medikationsplan und ▪ die Vorgaben für das so genannte Ultrakurzformat (UKF) in der offiziellen Fassung für Deutschland ab. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 38 | S.9 Kap 2.2 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| 2.2 Vortrajekt zum Medikationsplan Plus | 2.2 Historie zum Medikationsplan Plus | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 39 | S.20 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| leer | Seite entfernen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 40 | S.21 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Informationen zum Arzneimittel
▪ Wirkstoff ▪ Arzneimittelname ▪ Darreichungsform (ggf. Anwendungsart) ▪ Wirkstärke | Einrückung kontrollieren | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 41 | S.22 | Vorschlag | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Name („mein Plan“) | Name (z.B. Anton Müller) | Hier soll der Patientenname stehen. Dadurch soll eine stärkere Bindung / Compliance beim Patienten entstehen ("mein Plan"). Hier soll aber nicht ein Planname hin. Momentan irritierend. | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 42 | S.22 Kap 4.1.2 Tabelle | Vorschlag | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Verordnender Arzt / empfohlen durch | empfohlen durch Apotheker? Werden hier bei OTC die abgebenden Apotheker stehen? Dann gern explizit. Wer kann sonst empfehlen? | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 43 | S.22 Kap 4.1.2 Tabelle | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Unterschriften Patient | Wieso unterschreibt der Patient | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 44 | S.22 Kap 4.1.2 Tabelle | Vorschlag | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Unterschriften Arzt | Unterschriften letzter Änderer (Arzt/Apotheker) | Sollten nicht auch Apotheker unterschreiben, quasi der letzte Änderer? | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 45 | S.23 Kap 4.2 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| unbedingt auzufüllendes Feld (M) | unbedingt auszufüllendes Feld (M) | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 46 | S.23 Kap 4.2 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| unbedingt auzufüllendes Feld (M) oder ein verpflichtendes Feld ® | Mir erschliesst sich gerade nicht der semantische Unterschied von undbedingt auszufüllen und verpflichtend, insbesondere nicht, wenn ich die Verwendung in der darauffolgenden Tabelle ansehe. Vielleicht stehe ich auf dem Schlauch. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 47 | S.23 Kap 4.2 |  Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Versicherten-ID (Count) 1..1 R Patienten-ID (Identifier) 1..* R | Versicherten-ID (Identifier) 1..1 R Patienten-ID (Identifier) 1..* R | Warum ist die Versicherten-ID vom Typ Count? Identifier besser?! | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Ja, wird geändert | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 48 | S.23 Kap 4.2 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Mutter stillend? (Boolean) 0..1 | Ist die Einrückung korrekt? Gehört das nicht unter Schwangerschaft? | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 49 | S.24 Kap 4.2 | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| E-Mail (String) 1..1 (R) | Wirklich Required? Gehen wir davon aus, dass alle zwangweise eine Email haben? Wenn ja, was ist die Erwartung an die Verwendung / Verwendbarkeit der E-Mail im Prozess? Können Patienten die für Rückfragen benutzen? | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Muss übereinstimmen mit den Anforderungen im Bundeseinheitlichen Medikationsplan | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 50 | S.24 Kap 4.2 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Organisationsname (String) 0..1 R | Sollten wir nicht auch die Organisations-ID aufnehmen, u.a. BSNR? | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 51 | S.24 Kap 4.2 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Medikation 0..* R 6130 | Warum ist das 0..R? Gibt es Use Cases für einen leeren Medikationsplan? | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Auf dem papier natürlich nicht; elektronisch wird man auch Medikationspläne haben, die ausweislich ein Statement enthalten, dass der Patient keine Medikamente nimmt und dann ist die Liste selbst leer | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 52 | S.26 Kap 4.2 | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Ausdruckdatum (Datum) 1..1 R | Ausdruckdatum (Datum) 0..1 R | Was ist wenn der niemals ausgedruckt wird, weil rein elektronischer Workflow? Patient kann ihn auch in einer eGA visualisieren. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | 1..1 C (conditional, wenn ausgedruckt, dann sollte das Datum angegeben werden) | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 53 | S.27 Kap 4.2 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Einverständniserklärung 0..1 R 6113 | Einverständnis von wem und wozu? | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 54 | S.27 Kap 4.2 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die so gruppierten Datenelement finden | Die so gruppierten Datenelemente finden | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 55 | S.27 Kap 4.2 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die folgende [Abbildung 6] gibt dazu einen Überblick | Die folgende [Abbildung 6] gibt dazu einen auszugsweisen Überblick | Es fehlen die Gruppen Sonstiger Hinweis, Identifikation und Einverständniserklärung im Überblick | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 56 | S.28 Kap 5.0.1 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die folgende hierarchische Zusammenstellung gibt eine Übersicht über die einzelnen Komponenten des Medikationsplan Plus. | Wortumbruch von Medikati-onsplan überprüfen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 57 | S.28 Kap 5.0.1 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Header CDA recordTarget (pmp) (1.2.276.0.76.10.2028) | Warum haben mehrere der Komponenten einen Zusatz "(pmp)"? Gibt es ein "recordTarget" und ein "recordTarget (pmp)" die semantisch unterschiedlich sind? | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 58 | S.32 Kap 5.1.1 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Versions-Label v2015 | Versions-Label v2017 | Sollte das nicht eine aktuellere Version sein? | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 59 | S.32 Kap 5.1.1 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| 1.2.276.0.76.10.3042 Containment Wichtige Angaben | Nur Beobachtung: Wir nennen im Dokument inhaltlich gleiche Sektionen unterschiedlich. Hier Wichtige Angaben vs. weiter oben Sonstige Hinweise. Das reduziert die Klarheit für internationale Mitarbeiter globaler Konzerne :-( | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 60 | S.33 Beispiel | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| <code code="X_PMR" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Personal Medication List"/> | <code code="X_PMR" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Patientenbezogener Medikationsplan Plus"/> | Abweichung vom festgelegten Anzeigenname | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Muss übereinstimmen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 61 | S.33 Beispiel | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| <effectiveTime value="20141008123456"/> | <effectiveTime value="20141008123456+0200"/> | Wir sollten uns angewöhnen die Zeitzone mit anzugeben. Für Software wird es sonst schwierig, die korrekte Uhrzeit und Reihenfolge zu bestimmen. | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 62 | S.33 Beispiel | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| <setId extension=" " root=" "/> | Ist hier absichtlich jeweils ein 1-Zeichen-langer Leerstring drin? | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 63 | S.36 | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die Reihenfolge der Namensbestandteile soll der typischen Schreibweise entsprechen. Zu beachten
ist, dass prefix- und suffix-Elemente mit einem Leerzeichen enden müssen, wenn sie nicht unmittelbar an den folgenden Namensbestandteil anschließen sollen. | Die Reihenfolge der Namensbestandteile soll der typischen Schreibweise entsprechen. Zu beachten ist, dass bei der Verkettung von Namensbestandteilen für die Darstellung ein Leerzeichen zwischen die Namensbestandteile einzufügen ist. | Habe ich nicht verstanden und entspricht auch nicht den gezeigten Beispielen. Egal ob ein zusätzliches Leerzeichen am Ende ist, es wird immer eines bei der Verkettung eingefügt. Siehe "Sine Joanna Gräfing". Ein Leerzeichen obwohl given nicht mit Leerzeichen abschließt. Ist das eine allgemeine HL7 Regel? Rein praktisch gehe ich sowieso davon aus, dass kaum ein System am Markt existiert, welches dem Nutzer das Schema aufzwingt. Die Vor-/Zusätze werden eher in das Namensfeld kollabiert. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Es muss zwischen den Vorgaben für CDA und für FHIR eine eineitliche Sichtweise ausgearbeitet werden, so dass beide Darstellunsgformen verlust- und fehlerfrei ineinander überführt werden können. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 64 | S.43 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| An dieser Stelle kann die Arztnummer (LANR) unter Angabe der dazugehörigen OID übermittelt werden. | An dieser Stelle kann beispielhaft die Arztnummer (LANR) unter Angabe der dazugehörigen OID übermittelt werden. | Hier kann auch eine eGK Nummer mit der OID stehen. | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 65 | S.44 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Eingefügt 0 … *
von 1.2.276.0.76.10.2011 CDA participant Notfallkontakt (DYNAMIC) Notfall-Kontakt / Auskunftsberechtigte Person | Eingefügt
von 1.2.276.0.76.10.2011 CDA participant Notfallkontakt (DYNAMIC) Notfall-Kontakt / Auskunftsberechtigte Person | Hier gehört keine Kardinalität hin | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 66 | S.42 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Eingefügt 0 … 1
von 1.2.276.0.76.10.2012 CDA participant Hausarzt (DYNAMIC) Hausarzt | Eingefügt von 1.2.276.0.76.10.2012 CDA participant Hausarzt (DYNAMIC) Hausarzt | Hier gehört keine Kardinalität hin | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 67 | S.40 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Eingefügt 0 … 1 von 1.2.276.0.76.10.2020 CDA legalAuthenticator (DYNAMIC) | Eingefügt von 1.2.276.0.76.10.2020 CDA legalAuthenticator (DYNAMIC) | Hier gehört keine Kardinalität hin. Gesamtes Dokument bitte daruf nochmal überprüfen. | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 68 | S.47 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| hl7:component 1 … 1 M
Section: Medikationsplan Beinhaltet 1.2.276.0.76.10.3041 Aktuelle Medikation (DYNAMIC) | Sollen hier wirklich nur die aktuellen Medikamente rein? In welcher Sektion/Komponente sind dann die vergangenen? Oder ist die Überschrift irreführend? | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 69 | S.48 Kap 6.0.2 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Anzeigename CDA author (pmp) | Anzeigename Autor des Dokuments | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 70 | S.48 Kap 6.0.2 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| <time value="20131020"/> | Wollen wir hier durch das Beispiel kommunizieren, dass uns das Datum reicht? | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 71 | S.48 Kap 6.0.3 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Anzeigename CDA author software (pmp) | Anzeigename Verwendete Software | alternativ "Software, die bei der Erstellung des Dokuments verwendet wurde" | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 72 | S.52 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Anzeigename CDA custodian (pmp) | Anzeigename Verwaltende Organisation | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 73 | S.56 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Prof. Dr. med. Dr. rer. nat. Fritz Julius Karl Freiherr von und zu Rathenburg vor der Isar, MdB
<name> <prefix qualifier="AC">Prof. Dr. med. Dr. rer. nat. </prefix> <given>Fritz</given> <given>Julius</given> <given>Karl</given> <prefix qualifier="NB">Freiherr </prefix> <prefix qualifier="VV">von und zu </prefix> <family>Rathenburg vor der Isar</family> <suffix>MdB</suffix> </name> | Woher weiss die Software, dass nach family und vor suffix ein Komma einzufügen ist? | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 74 | S.58 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| <code code="19009-0" codeSystem="2.16.840.1.113883.6.1" displayName="Medication.current"/> | <code code="19009-0" codeSystem="2.16.840.1.113883.6.1" displayName="Aktuelle Medikation"/> | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | LOINC Codes müssen den Original Diplay Namen zeigen (siehe Lizenzvereinbarung LOINC) | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 75 | S.58 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| <title>Medikationsplan</title> | Gibt es eine Empfehlung, wie der title zu befüllen ist. Wir sind inkonsistent in den Beispielen im Dokument. Bsp. "Medikationsname Anton Müller 22.09.2017 10:00" | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 76 | S.60 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| <title>Allergien und Unverträglichkeiten</title> | <title>Allergien und Unverträglichkeiten</title> | Was sind unsere Guidelines zur Verwendung von Sonderzeichen/Umlauten in druckbaren HTML/XML Feldern? Sind die Dokumente zwangsweise mit einem Zeichensatz z.B. als UTF-8 gekennzeichnet? Sollen wir die druchbaren/anzeigefähigen String grundsätzlich HTML-encoden? | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 77 | S.60 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| <item ID="int">Unverträglichkeit: Laktose</item> | dito | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 78 | S.123 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| <code code="11449-6" codeSystem="2.16.840.1.113883.6.1" displayName="Pregnancy status"/> | <code code="11449-6" codeSystem="2.16.840.1.113883.6.1" displayName="Status Schwangerschaft"/> | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | LOINC Codes müssen den Original Diplay Namen zeigen (siehe Lizenzvereinbarung LOINC) | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 79 | S.125 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| <code code="63895-7" codeSystem="2.16.840.1.113883.6.1" displayName="Breast feeding"/> | <code code="63895-7" codeSystem="2.16.840.1.113883.6.1" displayName="Stillzeit"/> | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | LOINC Codes müssen den Original Diplay Namen zeigen (siehe Lizenzvereinbarung LOINC) | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 80 | S.128 Kap. 7.1 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Zusammenstellung er Komponenten | Zusammenstellung der Komponenten | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 81 | S.128 Kap. 7.2 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| folgen den Vorgaben des in der funktionalen | folgen den Vorgaben der in der funktionalen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 82 | S.129 Abb 7 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| des Standard-FHIR-Resources | der Standard-FHIR-Ressourcen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 83 | S.129 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| keine frei flottierende Menge | keine gängige Wortwahl | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 84 | S.130 Kap 7.2.x ff |  Negativ, schwerwiegend | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Das Bundle fasst die Composition zusammen.
StructureDefinition: medikationsplanplus-bundle ▪ Profile: https://simplifier.net/medikationsplanplus/bundle-1 ▪ Canonical: http://fhir.de/StructureDefinition/medikationsplanplus/bundle | Die reine externe Referenzierung ist schwierig, weil sie unkontrolliert Änderungen zulässt in simplifier, obwohl das Dokument / der Standard sich scheinbar nicht ändert. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Wird mit eindeutigen Versionsnummern stabil (daran wird in Simplifier gearbeitet) | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 85 | S.132 Kap 7.2.10 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Profile: https://simplifier.net/medikationsplanplus/consent-1 ▪ Canonical: http://fhir.de/StructureDefinition/medikationsplanplus/consent | Beide Seiten nicht gefunden | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 86 | S.132 Kap 7.2.8 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Profile: https://simplifier.net/medikationsplanplus/expecteddeliverydate-1 ▪ Canonical: http://fhir.de/StructureDefinition/medikationsplanplus/observation-expecteddeliverydate Profile: https://simplifier.net/medikationsplanplus/breastfeeding-1 | alle Seiten nicht gefunden | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 87 | S.131 Kap 7.2.7 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| alle Profile URLs sind kaputt | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 88 | S.131 Kap 7.2.2 | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| https://simplifier.net/medikationsplanplus/composition-1 Mouse over über composition type zeigt Comments: ToDo: Ist X_PMR hier der richtige LOINC-Code!? | Offene ToDo und Deutsch/Englisch gemischt | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Das ToDO war eine Frage von Simone, diese vorübergehenden LOINC Codes werden zu gegebener zeit durch echte ersetzt | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 89 | S.133 Kap 8 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| denn mit dem Vorhandensein von Infrastrukturen zum Datenaustausch
wie zum Beispiel einer Telematik-Infrastruktur und/oder der Verfügbarkeit mobiler Lösungen, gelten inhaltliche vollständige Wiedergaben von Inhalten obsolet | Was wollte der Autor hier eigentlich sagen ;-) | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 90 | S.133 Kap 8.1 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| („repeat, period 1 d). | ("Dauer", "Intervall") | English streichen | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 91 | S.133 Kap 8.1 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Ähnliches gilt für bestimmte Dosierungsmuster, die festliegen. Die Angabe „morgens“ bedeutet an sich „Medikament
morgens einnehmen („wann“) und dies jeden Tag wiederholen („repeat, period 1 d). Diese Statements können sich auf das „wann“ beschränken, denn dass sich dies (innerhalb ggf. vorgegebener Einnahmedauer-Grenzen) täglich wiederholt, ist bei diesem Muster klar. | Das Beispiel und die Schlussfolgerung sind m.E. unglücklich gewählt. "Morgens" geht in der Tat von Wiederholung (Dauer unbekannt) aus. Die Reduzierung auf das reine "Wann" (am Morgen) lässt keine Erkennung einer Wiederholungsabsicht zu, bzw der "Am Morgen" einmalig ist vom "Am Morgen" mit Wiederholungsabsicht nicht unterscheidbar. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 92 | S.134 | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| <MP v="1" u="MPP"
U="CA620D79D334428CBA6203181EAA1378" l="de-DE"> ... </MP> | Es ist mir ehrlich gesagt schleierhaft, woraus auf der linken Seite sich dieses UKF ableitet. Ich kann leider keine "leichte Überführbarkeit" erkennen. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Wird doch noch ausführlicher erläutert | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 93 | S.135 | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| <family value="Prinz von und zu
Mustermännchen"> <extension url="http://fhir.de/.../humanname-namenszusatz"> <valueString value="Prinz" /> </extension> <extension url="http://hl7.org/ fhir/.../humanname-own-prefix"> <valueString value="von und zu" /> </extension> <extension url="http://hl7.org/ fhir/.../humanname-own-name"> <valueString value="Mustermännchen" /> </extension> </family> | Wie soll die Konvertierung von CDA zu FHIR/UKF vonstatten gehen, wenn es andere Formatierungsregeln als im CDA für Präfixe gibt. Sollen bei der Konvertierung die Leerzeichen gelöscht werden bzw. wieder hinzugefügt? | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | siehe #63 | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 94 | S.138 Kap 8.2.2 Patient | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Wie werden Namenssuffixe abgebildet im UKF z.B. Hans Müller, MDB? | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | siehe #63 | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 95 | S.138 Kap 8.2.2 Autor | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| <A n="Dr. Fritz Überall"
<A n="Praxis Dr. Michael Müller" <A n="Sonnen-Apotheke" | Wieso wird hier der Name kollabiert in ein Feld und beim Patient nicht? Wieso kollabiere ich sogar die Organisation alternative in das Autor-Feld? Eine einfache Bijektivität wird auf jeden Fall erschwert. Aber auch semantisch ist ein Autor immer eine Person, die vielleicht Teil einer Organisation ist... | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | So ist die Vorgabe im Bundeseinheitlichen Medikationsplan. In den Langformaten muss diese behelfsmäßige Vorgabe zunächst so umgesetzt werden | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 96 | S.138 Kap 8.2.3 | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| 8.2.3 Autor/Ersteller/Ausdruckender (A) | Wieso werfen wir Autor und Ausdruckender in einen Topf. Im CDA erfassen wir den letzten Änderer und jeweils den Autor einer Medikation. Wir erfassen keinen Ausdrucker. Dadurch das im UKF Format nur einmal ein A vorkommt, können wir diese Unterscheidung letzer Änderer vs. Auto einer Position nicht aufrechterhalten. Im UKF kann es offenbar nur einen Autor geben, also keinen gemeinsamen Plan... | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Zur zukünftigen Verwendung | So ist die Vorgabe im Bundeseinheitlichen Medikationsplan. Die Langformate können hier besser unterstützen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 97 | S.139 Kap 8.2.3 | Negativ, schwerwiegend | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| "@lanr, @idf, @kik" | Im CDA ist prinzipiell möglich den Patienten als letzten Änderer des Medikatiuonsplanes zu führen. Hier nicht mehr, es fehlt die Möglichkeit einer egk. Damit kann ich in Mobil-Apps keinen Barcode mit UKF aus einer eGA ad-hoc generieren sondern kann immer nur den letzten Plan reproduzieren. Das wiederum erlaubt nicht dem Patienten, den Medikationsstatus selbst zu ändern. UKF ist nicht kompatibel. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Zur zukünftigen Verwendung | So ist die Vorgabe im Bundeseinheitlichen Medikationsplan. Die Langformate können hier besser unterstützen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 98 | S.139 Kap 8.2.4 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| der Verwaltung des Dokument betraut ist | der Verwaltung des Dokumentes betraut ist | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 99 | S.139 Kap 8.2.6 | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| <O w="89" h=177 c="1.3" p="1"/> | Während klinische Parameter im CDA offen ist und damit deutlich mehr Beobachtungen erlaubt, ist das UKF abgeschlossen. Eine Bijektivität ist nicht mehr gegeben. Der Informationsverlust / die Einschränkung kann gewollt sein, aber dann muss man das auch so dokumentieren. Es währe allerdings viel sinnvoller, eine echte Bijektivität was die enthaltenen Informationen betrifft herzustellen. Das könnte durch weitere Einschränkungen des CDA geschehen. Man muss einen PMPP nicht in einen Arztbrief umwadeln können :-) | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Zur zukünftigen Verwendung | So ist die Vorgabe im Bundeseinheitlichen Medikationsplan. Die Langformate können hier besser unterstützen. Ein Kommentar wird eingeführt: das CDA/FHIR Lanfformate sind hier bewusst flexibler. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 100 | S.140 Kap 8.2.7 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Typisch ist dabei, dass im einfachsten Fall nur ein Freitext die Allergien/Unverträglichkeiten beschreiben. | Typisch ist dabei, dass im einfachsten Fall nur ein Freitext die Allergien/Unverträglichkeiten beschreibt. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 101 | S.140 Kap 8.2.7 | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Auslösendes Agens, codiert, siehe Anmerkung 1; 1: bisher ist hier keine feste Terminologie vorgesehen | Die Verkürzung im UKF kann nur erreicht werden, wenn ein Code System festgelegt wird. Alternative muss es die Möglichkeit für die Kodierung des Code Systems geben. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Es soll in Zukunft hier am besten ein einziges Codesystem zur Anwendung kommen, wobei dann auch das Codesystem festegelegt ist und nicht ind er UKF Instanz erscheint | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 102 | S.140 Kap 8.2.7 | Negativ, kleineres Problem | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Reaktion auf die Allergie/Unverträglichkeit, codiert, siehe Anmerkung 4; 4: bisher ist hier keine feste Terminologie vorgesehen | Die Verkürzung im UKF kann nur erreicht werden, wenn ein Code System festgelegt wird. Alternative muss es die Möglichkeit für die Kodierung des Code Systems geben. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Es soll in Zukunft hier am besten ein einziges Codesystem zur Anwendung kommen, wobei dann auch das Codesystem festegelegt ist und nicht ind er UKF Instanz erscheint | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 103 | S.143 Kap 8.2.10 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Erzeugungsdatum des Medikamenteneintrags, Format YYYY-MMDDThh: mm:ss | Die Zeitzone ist CET mit automatischer Sommer-/Winterumstellung? | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 104 | S.143 Kap 8.2.10 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| 2: es kann erwartet werden, dass die Angabe von Wirkstoffen in der nahen Zukunft aus über europäischen Substanz-Indetifikatoren, z. B. IDMP angegeben werden können | 2: es kann erwartet werden, dass die Angabe von Wirkstoffen in der nahen Zukunft über europäische Substanz-Identifikatoren, z. B. IDMP erfolgen kann | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 105 | S.145 Kap 8.2.11 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Der Text selbst ist @t-Attribut untergebracht. | Der Text selbst ist im @t-Attribut untergebracht. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 106 | S.145 Kap 8.2.11 | Tippfehler | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| <X id="3 c="2017-07-15T11:02:14" t="Analekzemsalbe Milch, Thesit 2.5 HC 0.25 Milch Cordes ad 50.0"/> | <X id="3" c="2017-07-15T11:02:14" t="Analekzemsalbe Milch, Thesit 2.5 HC 0.25 Milch Cordes ad 50.0"/> | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 107 | S.145 Kap 8.2.13 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die Angaben zu einer Rezeptur sind bereits unter Medication Statement (M-Element) beschriebenen. Statt dem Element M wird aber das Element R verwendet. | Aus M sind die Elemente @p und @a wirklich relevant für eine Rezeptur? | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 108 | S.146 Kap 8.3 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Wie ist denn der Zugriff auf die URL geschützt? Wir davon ausgegangen, dass dies frei bleibt? | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 109 | S.168 | Kommentar allgemeiner Art | Thomas Liebscher | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Dieses Value Set beinhaltet 547 Codes. Um die Publikationsgröße überschaubar zu halten, wird nur eine Auswahl (500 Codes) des ganzen Sets von Codes gezeigt. | Der war gut! Wegen 47 Zeilen bei bereits verbrauchten 500 Zeilen auf 20 Seiten, sind das 2 eingesparte Seiten… Spart alle 547 Zeilen ein und stellt bitte eine Referenz auf das Code System zur Verfügung oder verschwendet die weiteren 2 Seiten auch noch :-) | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 110 | S14Z18 | ? ? | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Patientenbezogener Medikationsplan Release 1 | Bezeichnungen des aktuellen Entwurfs entsprechend anpassen, etwa: "Patientenbezogener Medikationsplan Release 2" | Zur Abgrenzung gegenüber dem vormals abgestimmten "PMP Release 1" sollte auch hier durchgängig, oder zumindest im Titel des Dokumentes, eine Versionierung genannt werden. Dies gilt umso mehr, um die Abgrenzung zum mehrfach genannten Projekt "Medikationsplan Plus" deutlich zum machen. | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 111 | S10Z12 | ? ? | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Zitat aus Sondergutachten | Erläuterung des Bezugs zwischen Sondergutachten und vorliegendem Entwurf. | Der Abschnitt 2.1 Rationale macht den Bezug zwischen dem Sondergutachten und dem vorliegenden Entwurf nicht deutlich. | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 112 | S11Z7 ff. | Negativ, kleineres Problem | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Projektvorhaben „Medikationsplan Plus“ | Bitte erläutern, warum der aktuelle Entwurf bereits vor dem Abschluss des Projektes und erfolgter Evaluierung zur Abstimmung vorgelegt wird. | Im Text wird die Evaluierung der gewonnenen Ergebnisse angesprochen. Warum erfolgt die Abstimmung jetzt, und nicht erst nach Projektabschluss und unter Berücksichtigung der Ergebnisse der Evaluierung? | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Am Ende des Projekts wird es eine weitere Abstimmungsversion geben, in das die Ergebnisse während des Betriebs eingegangen sind. Dieser Hinweis wird in der Präambel des Dokuments jetzt aufgenommen. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 113 | div. | Negativ, kleineres Problem | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| FHIR, FHIR®, „FHIR“® | Einheitliche Schreibweise, Erläuterung | Im Text wird an mehreren Stellen Bezug zu FHIR genommen, allerdings in mehrfachen Schreibweisen. Bitte vereinheitlichen, oder die unterschiedlichen Schreibweisen erläutern. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Wird geändert | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 114 | Abschnitt 2.5 | Tippfehler | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| die fachinhaltlichen Aspekte enthält | die fachinhaltlichen Aspekte enthalten | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 115 | Abschnitt 2.5 | Tippfehler | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Während die Definitionen…ist, …gelten | Während die Definitionen … sind, …gelten | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 116 | S13Z4 | Tippfehler | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| dem Deutsche Apothekerverband | dem Deutschen Apothekerverband | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 117 | Abschnitt 2.6 | Vorschlag | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Literaturliste | an übliche Standards anpassen | Das Format der Literaturliste genügt nicht den üblichen Anforderungen an wissenschaftliche Zitierweise. | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 118 | S13Z25 | Tippfehler | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Barcode des bundeseinheitlichen Medikationsplan | Barcode des bundeseinheitlichen Medikationsplans | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 119 | Abschnitt 2.5 | Negativ, kleineres Problem | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Dieses proprietäre Format sollte in einem Barcode niedergelegt werden, der mit auf dem Papierausdruck aufgebracht wird. | Bitte erläutern, warum diese Vorarbeiten hier verworfen, bzw. nicht näher berücksichtigt wurden. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | Die Begründung ist im Abschnitt danach | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 120 | Abschnitt 2.7 | Negativ, kleineres Problem | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Mögliche Nutzer… | Bitte weiter ausführen und weitere Benutzergruppen nennen. (Zahnärzte?, Psychotherapeuten?, Versicherte?) | Hier wird ein recht begrenzter Kreis von Nutzern genannt, Widersprich zu 4.1. Warum nicht Patienten und weitere Gesundheitsdienstleister, wie in 4.1? Sind Personen die Nutzer - oder die hier aufgeführten Organisationen? Welche Personen vertreten ggf. diese Organisationen? | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Es werden alle möglichen Benutzerkreise zu nennen sein | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 121 | Abschnitt 3.3 | Negativ, kleineres Problem | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Tooling… | Erläutern, inwiefern das Tooling Bestandteil der normativen Spezifikation ist. | Ist die Verwendung des Tooling Bestandteil der normativen Spezifikation? Andernfalls sollte dies deutlich gemacht werden, z. B. durch Kennzeichung als Hintergrundinformation. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Kommt in den Appendix | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 122 | S18Z26 | Negativ, kleineres Problem | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| HL7 Deutschland hat für Simplifier eine so genannte Affiliate-Vereinbarung für die Basisprofile | weglassen | Diese Information ist für normativen Text irrelevant. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Kommt in den Appendix | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 123 | Abschnitt 3.3 | Negativ, kleineres Problem | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| ART DECOR… | weglassen oder rechtliche Hintergründe erläutern. | Ist ART DECOR lizenzpflichtig? Welche Voraussetzungen sind für Implementierung des Entwurfs relevant? Müssen IT-Hersteller hier auf lizenzrechtliche o. ä. Randbedingungen Rücksicht nehmen? | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Kommt in den Appendix | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 124 | S21Z14 | Vorschlag | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Im Rahmen eines Workshops im BfArM am 5. Mai 2011… | Bitte genauer erläutern, was das für ein Workshop war (Veranstalter, Titel, Teilnehmer, Link zu Protokollen, Materialien etc.) | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 125 | S22Z28 | Negativ, kleineres Problem | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Unterschriften | Dieser Punkt wird hier genannt, aber im Weiteren nicht aufgegriffen. Wie ist der Umgang mit dieser Anforderung umgesetzt - oder warum wurde er nicht weiter berücksichtigt? | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Als Erläuterung zu diesem Tabellenitem wird auf den CDA legalAuthenticator und die entsprechneden Möglichkeiten verwiesen. Digitale Signaturen etc. liegen außerhalb des Scopes eines CDA-Leitfadens. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 126 | S23Z12 | Tippfehler | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Identifizierung der Datenelement | Identifizierung der Datenelemente | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 127 | S23Z12 | Negativ, kleineres Problem | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Identifizierung der Datenelement | Bitte erläutern, auf was sich diese "Identifizierung" bezieht. (die Nummern tauchen ansonsten im Dokument nicht mehr auf!) | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Hier muss noch eine kleine Erläuterung der Datenelement-Nummern hinzugefügt werden | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 128 | S27Z16 | Negativ, kleineres Problem | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Abbildung 6 | Erläuterungen zur grafischen Darstellung hinzufügen. | Inhalte und Aussage der Grafik erschließen sich nicht ohne weitere Erläuterung. Bitte erklärenden Text ergänzen: Was ist hier dargestellt? | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Im Anschluss an diese Abbildung wird die Abbildung im laufenden Text erläutert werden | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 129 | S28Z16 | Negativ, kleineres Problem | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Abbildung | Die Abbildung enthält eine bunte Mischung deutscher und englischer Bezeichner. Bitte erläutern, warum bzw. klären, wo der Leser mehr über die verwendeten Bezeichner erfahren kann (andere normative Quelle?). | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Ein weitere Erläuterung der zu sehenden Ietms wird hinzugefügt | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 130 | S32Z3 | Negativ, kleineres Problem | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Hier fehlt ein einleitender Text. Über den Hinweis in 5.0.2 hinaus sind hier weitere einführende Erläuterungen und/oder Verweise erforderlich. Ist hier zusätzliches Wissen zum Verständnis der Spezifikation erforderlich? Wo ist dieses Wissen ggf. verfügbar? | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Hier wird auf ein noch hinzuzufügendes Kapitel im Anhang verwiesen werden, das die einzelnen Elemente der tabellarischen Darstellung erläutert. Ansonsten ist in der Einleitung unter Abschnitt 3.2 ein Text aufzunehmen, der die Anforderungen an den Leser skizzieren soll. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 131 | S32 | Vorschlag | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| DYNAMIC | Erläuterungen und Überarbeitung für Verständlichkeit. | Was bedeutet hier "DYNAMIC", "Inklusion", "Containment"? Warum bunte Mischung deutscher und englischer Bezeichner? | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 132 | S98Z17 | Negativ, kleineres Problem | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| PZN | Erläuterung zur Formatierung der PZN ergänzen. | Der Umgang mit PZN, insbesondere solcher mit "führenden Nullen" sollte erläutert werden (Stichwort. "modifizierte PZN") | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Hier sollen die Vorgaben aus dem Bundeseinheitlichen Medikationsplan einfließen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 133 | S126Z16 | Negativ, schwerwiegend | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Templates aus Repositories (nicht zur Abstimmung stehend) | Erläuterung/Begründung hinzufügen: Woher kommen diese Festlegungen? Warum sind sie normativ (wenngleich hier nicht abzustimmen)? Liegen dem Entwurf Annahmen zugrunde, die außerhalb dieses Entwurfs liegen? Wenn ja, welche und warum? | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Einleitung unter Abschnitt 3.2 ein Text aufzunehmen, der die normativen Vorarbeiten an den Leser skizzieren soll. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 134 | S. 130 ff. | Negativ, schwerwiegend | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Vielzahl von Links | Sind diese Verweise normativ? Warum? Wie werden sie abgestimmt? Warum können sie hier als fixe Voraussetzungen angenommen werden? Bitte Vorgehensweise bei der Standardisierung erläutern! | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Muss weitergehend erläutert werden in Abschnitt 7.2 | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 135 | S11Z3 | Negativ, schwerwiegend | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Bereitstellung von XSL-Stylesheets und einer zugehörigen bijektiven Abbildung von CDA-Instanzen in ein Kurzformat | sind diese XSL-Transformationen in den bereitgestellten Materialien enthalten ( http://hl7de.art-decor.org/pmp-xml-20170811T110843.zip )? Bitte erläutern! | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Diese Stylesheet werden in der Folgeausgabe mitgeliefert | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 136 | insgesamt | Negativ, schwerwiegend | Christof Gessner | gematik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Dieser Entwurf bietet Lösungen auf verschiedenen Abstraktionsebenen an (Informationsmodell, Codierte Inhalte mit Terminologien, Datenstrukturen). Dazu werden dann drei unterschiedliche Implementierungen spezifiziert (CDA, FHIR, UKF). Die Zusammenhänge und gegenseitigen Abhängigkeiten dieser verschiedenen Bestandteile werden in der hier gewählten Darstellung nicht deutlich gemacht. Eine Aufteilung auf mehrere Einzeldokumente würde der Verständlichkeit für den jeweiligen Leserkreis dienen. In der vorliegenden Form ist eine insgesamte Zustimmung nicht möglich. Empfehlung: Die Teile die für Implementierungen (in einem der drei genannten Formate) relevant sind, separat abstimmen. Das zugrundeliegende Informationsmodell zusammen mit Festlegungen zu Identifikatoren und Codierungen separat abstimmen. Das vorliegende Dokument, nach Entfernung der genannten normativen Einzelkomponenten separat als Erläuterung publizieren (mit oder ohne zusätzliche Abstimmung über die Inhalte einer solchen Erläuterung). | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Zur zukünftigen Verwendung | Diese Problematik muss in der nächsten zeit in größerem Kreise (Interoperabilitästforum) weiter diskutiert werden. Beide Ansätze (alles in einem, jeder für sich) haben ihre Vor- und Nachteile, die wir sorgfältig abwägen müssen. | ||||
