Kommentare und Auflösungen zum Abstimmungsverfahren Arztbrief 2014
Stand: 15. Juli 2015
Auszählung (Tally) | |
---|---|
Anzahl Kommentare | 353 |
Angenommen | 198 |
Angenommen mit Modifikationen | 62 |
Nicht angenommen | 33 |
Nicht relevant | 4 |
Zur zukünftigen Verwendung | 9 |
Weitergeleitet | 15 |
Warten auf Information vom Antragsteller | 2 |
Warten auf Information von anderer Arbeitsgruppe | 30 |
Unbearbeitet | 0 |
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
---|---|---|---|---|---|
1 | 2.1 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
elektronischen Übermittlung von Arztbriefen | Es geht nicht um die reine Übermittlung - sprich Kommunikation - von Arztbriefen. Es geht um den Arztbrief an sich. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | geändert in: das Ziel dieses Dokuments ist die Beschreibung des elektronischen Arztbriefs. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
2 | 2.1 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Kommunikation zwischen Niedergelassenen und Krankenhäusern | Hier könnte der Eindruck entstehen, dass nur sektorenüberreifend kommuniziert wird, Ziel muss aber die sektorenübergreifende Kommunikation sein | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | geändert in: Im Rahmen der Kommunikation zwischen Akteuren im Gesundheitswesen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
3 | 2.2. | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
als freiwillige Anwendung betrachtet. Somit ergeben sich mit Einführung einer nationalen Telematikinfrastruktur verschiedene Vorgaben | Ich verstehe den kausalen Zusammenhang nicht zwischen Freiwilligkeit und den damit verbundenen Vorgaben. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | geändert in: als freiwillige Anwendung betrachtet. Es ergeben sich mit Einführung einer nationalen Telematikinfrastruktur verschiedene Vorgaben | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
4 | 2.3 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Dies wird z. B. erreicht durch das Versenden von Papier und Formularen. Jeder weiter führende elektronische Ansatz muss auch diese Art der Interoperabilität gewährleisten. Darüber hinausgehend wäre das andere Ende die Anwendungs-Interoperabilität. Dies beinhaltet die Wiederverwendbarkeit von Informationen, Kontext-abhängige Analysemöglichkeiten und angemessenes Speichern und Verwalten von klinischen Dokumenten. | Wenn der Brief in Papierform versendet wird, ist dieser i.d.R. signeirt. Diese Anforderung sollte natürlich auch der elektronische Weg vorsehen. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Die Möglichkeit zur Signatur muss auch in elektronischer Form bestehen bleiben. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
5 | 2.3 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
VHitG-Initiative „Intersektorale Kommunikation" | Sprechen wir noch immer vom VHitG? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | bvitg-Initiative „Intersektorale Kommunikation" | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
6 | 2.4 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Fehlt hier möglicherweise auch noch so etwas wie Autorisierung und Authentisierung | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Weitergeleitet | Sind unseres erachtens Probleme der Infrastruktur, der Arztbrief ansich enhält ja keine solchen Informationen. Sollte daher klar getrennt werden | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
7 | 3.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Schemas vs Schemata | Die Begrife Schemata und Schemas werden verwendet. Bitte vereinheitlichen | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Es hat sich der Begriff XML-Schemas eingebürgert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
8 | 3.4 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Viele (insbesondere internationale) Spezifikationen basieren auf CDA: IHE PCC, ELGA, CDA-CH2 um nur einige zu nennen. | Viele (insbesondere internationale) Spezifikationen basieren auf CDA (z.B. IHE PCC, ELGA, CDA-CH2), um nur einige zu nennen. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Geändert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
9 | 3.4 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
CDAr2 | CDA Release 2 | Insgesamt gesehen werden die bezichnungen nicht einheitlich verwendet. | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
10 | 4.1 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
HL7 als Kommunikationsprotokoll | Diese Darstellung ist zu kurz. HL7 ist mehr. Auf Seite 16 Abs. 4.2 entwickelt HL7 sogar. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Muss hier echt beschrieben werden was HL7 ist, macht etc? Der Satz wurde angepast. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
11 | 4.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
einem der bedeutungsreichsten internationalen Standardentwickler | einer der bedeutungsreichsten internationalen Standardentwicklerorganisationen | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Satz geändert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
12 | 4.2 | Negativ, kleineres Problem | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Beispiele: [XML], [cdaconf1, cdaconf2] | Fehlendes Literaturverzeichnis | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Hinzugefügt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
13 | 4.2 | Negativ, kleineres Problem | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Fehlendes Glosaar, fehlendes Abkürzungsverzeichnis | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Auf das Interoperabilitätsglossar (Enzyklopädie) wird hingewiesen, ein Abkürzungsverzeichnis hinzugefügt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
14 | 4.3.1 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
also dauerhafte Existenz in den sendenden oder empfangenden Systemen gekennzeichnet | also dauerhafte Existenz in den sendenden und/oder empfangenden Systemen gekennzeichnet | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | geändert in: CDA Dokumente sind Persistenz, das heißt dauerhaft Existent in den sendenden oder empfangenden Systemen. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
15 | 4.3.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Eine Organisation zeichnet | Eine Organisation ist | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | geändert in: Eine Organisation ist verantwortlich für die Verwaltung eines CDA Dokuments. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
16 | 4.3.6 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
den authentifizierten Inhalt sichtbar authentifizierten Inhalt sichtbar zu machen. | Was ist damit gemeint? Ein einem Versendern zuordnenbarer Inhalt sosichtbar gemacht werden???? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Satz ergänzt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
17 | 4.4. | Negativ, kleineres Problem | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Abbildugnsverzeichnis und - nummerierung fehlen | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Sind nun alle ergänzt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
18 | 4.4. | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Darstellung in der Abbildung ist missverstädnlich: Es sieht so aus, als wäre im Header ein Clinical Dokument. Header und Body machen aber das Clinical Document aus. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | ist doch schon geändert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
19 | 4.4.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
CDA Entries/ Body Entries | Werden die beiden Begriffe syonym verwendet? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | In CDA Entries geändert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
20 | 4.4.2 | Negativ, kleineres Problem | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Abb. Auf Seite 21 ist kaum lesbar. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Korrigiert für das PDF | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
21 | 4.4.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Diese Auswahlliste von Aktivitäten | Steht Aktivität synonym für act | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht relevant | Ja, klar, aber müssen wir hier noch das RIM erklären? | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
22 | 4.4.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
beziechnet. | bezeichnet. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | ok | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
23 | 4.4.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
das ganz | das ganze | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | ok | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
24 | 4.4.2 | Negativ, kleineres Problem | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Abb. Auf Seite 23 ist nicht lesbar. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Korrigiert für das PDF | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
25 | 4.4.3 | Negativ, kleineres Problem | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Tabellennummerierung iund Tabellenverzeichnis fehlt | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Sind nun alle ergänzt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
26 | 4.4.3 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Des weiteren kann hier auf die optionale oder verpflichtende Nutzung von Entry-Level-Templates hingewiesen werden. | Was ist damit gemeint? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Möglicherweise existieren passende Entry-Level-Templates zu der Sektion. Hier kann auf die optionale oder verpflichtende Nutzung von Entry-Level-Templates hingewiesen werden. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
27 | 4.5 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Implementation Guide | Implementationsleitfaden | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Implementierungsleitfaden (engl. Im Guide) | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
28 | 5.1 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Überweisunggen, | Überweisungen, | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
29 | 5.1 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Im allgemeinen | Im Allgemeinen | Macht es Sinn nur einen Abschnitt 5.1 auf der Ewbene zu verwenden. Es gibt kein 5.2 | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Schreibfehler angepasst, Unterteilung weitergeführt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
30 | 5.1 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
mehrere Möglichkeiten , | mehrere Möglichkeiten, | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
31 | 5.1 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Liste könnte erweitert werden um KV Connect, Kom-Le, Safemail | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
32 | 6 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
m.E. ist das ClinicalDocument nichtnur eine Klasse des Headers sondern umschließt auch den gesamten Body. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Hae? Ne auch der Header ist im ClinicalDocuemtn drin… | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
33 | 6.2.1.1 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Abbildung enthält am Rand noch Reste eines Textfeldes | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | sehe ich nicht… | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
34 | 6.2.1.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
des Dokumentes | des Dokuments | einheitliche Verwendung | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Dokuemnts | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
35 | 6.2.1.2 | Negativ, schwerwiegend | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Tabelle macht keine Aussagen über Datentyp und Kardinalität | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Redundante Tabelle, nun als Verweise auf Dokumentenstruktur und Dokumenten-Level-Template | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
36 | 6.2.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Sie sind hier deshalb nur kurz der Übersicht halber aufgelistet sind | Sie sind hier deshalb nur kurz der Übersicht halber aufgelistet | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Der Header umfasst neben bereits aufgelisteten einfachen Metadaten noch folgende Beziehungen, diese sind hier der Übersicht halber aufgelistet. Die Verwendung im Arztbrief wird unter Arztbriefstruktur aufgelistet und deren genauen Details später noch genauer spezifiziert. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
37 | 6.2.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Tabellenbezeichnung fehlt gänzlich | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | angepasst | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
38 | 6.3.1 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Falls nur die Metainformationen (Header) strukturiert übertragen werden und der Body nur aus einem Dokument (z. B. PDF) besteht, sollte man nonXMLBody verwenden (CDA Level1), das Dokumente entweder referenziert oder eingebettet wiedergeben kann. | Falls nur die Metainformationen (Header) strukturiert übertragen werden und der Body nur aus einem Dokument (z. B. PDF) besteht, sollte man nonXMLBody verwenden (CDA Level1). Im nonXMLBody kann das Dokumente entweder referenziert oder eingebettet werden. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
39 | 6.3.1.1 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Wie bereits angedeutet gibt | Wie bereits angedeutet, gibt | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Wurde ja am Anfang erwähnt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
40 | 6.3.1.1 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
In diesem Fall besteht der Body lediglich aus einer relativ einfachen XML-Struktur, in der das Dokument kodiert | In diesem Fall besteht der Body lediglich aus einer relativ einfachen XML-Struktur, in die das Dokument kodiert | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | In diesem Fall besteht der Body lediglich aus einer verkürzten XML-Struktur, in der das Dokument eingebettet ist. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
41 | 6.3.1.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
dass der CDA Body für den Arztbrief aus ein bis vielen Abschnitten (section) besteht | dass der CDA Body für den Arztbrief aus einem bis vielen Abschnitt(en) (section) besteht | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
42 | 6.3.1.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Als Beispiel ist hier ein „Kapitel" Anamnese zu nennen, dass sich | Als Beispiel ist hier ein „Kapitel" Anamnese zu nennen, das sich | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
43 | 6.3.1.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Hier ist als Beispiel der Diagnose-Code für eine Entlass-Diagnose angedeutet. | Dies wird aber ausd er Abbildung nicht ersichtlich | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | ist doch schon geändert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
44 | 6.3.1.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
„Level 1 bis 3 unten | Level 1 bis 3 unten | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
45 | 6.3.1.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
CDA-Dokument oder CDA-Dokument | einheitliche Schreibweise | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
46 | 6.3.1.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Abb. Auf Seite 32: "???" muss noch ersetzt werden | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Grafik ist sowieso entfernt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
47 | 6.3.1.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Was machen "author" und "informant" im "StructuredBody"? | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Auch im Body können diese vorkommen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
48 | 6.3.1.4 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Entry Diagnose | Entry "Diagnose" | in "" oder kursiv | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
49 | 6.3.2.1 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Diese Festlegung kann sowohl die textuelle Darstellung mit text und title betreffen als auch die Vorgabe | Diese Festlegung kann sowohl die textuelle Darstellung mit <text> und <title> betreffen als auch die Vorgabe | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | ? | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
50 | generell | ? ? | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Sind Code-Fragemente in den blauen Boxen keine Abbildungen (s. Kap 6) | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Beispielfragmente in blauen Kästchen sind keine Abbildungen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
51 | 6.3.3.1.5 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Standard | Welcher Standard ist gmeint | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
52 | 6.3.3.1.7 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Standard | Welcher Standard ist gmeint | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
53 | 6.3.1.8 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Tabelle 15: Stil-Codes für den narrativen Text | Tavelle 15 ?????? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Tabelle oder? Tabellennummern werden noch konsolidiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
54 | 6.3.3.3.1 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Abbildung 21: ObservationMedia CDA | Abbildung 21 ???? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Abbildungsnummern werden noch konsolidiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
55 | 6.3.3.3.1 | Negativ, kleineres Problem | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Spaltennamen der Tabelle sind nicht erklärt: DT, Conf, | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Die Erläuterungen zu den Notationen der ART-DECOR Templates sind extern verfügbar, ein entsprechender Link ist hinzugefügt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
56 | 6.3.3.3.2 | Negativ, kleineres Problem | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Entspricht Spaltenname "Status" etwa "Conf" | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Die Erläuterungen zu den Notationen der ART-DECOR Templates sind extern verfügbar, ein entsprechender Link ist hinzugefügt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
57 | 6.3.3.3.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
wird es in den Niederlanden kaum benutzt werden. | Spielt dies eine Rolle? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | wo steht das? | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
58 | 6.3.3.3.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Resolutionen | Auflösungen | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
59 | 6.3.3.3.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Videobilder | Videosequenzen | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
60 | 6.4 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Ausprägung | Was ist mit der Spalte "Ausprägung" gemeint? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | das muss ein Informatiker kennen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
61 | 6.4 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
fax | Fax | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
62 | 7.1 | Negativ, kleineres Problem | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die 3. Ebene fehlt: 7.1.0 | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | korrigiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
63 | 7.1.0.4 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
um welchen Dokumenttyp handelt es sich | Typ des Dokuments | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
64 | 7.1.0.4 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Tabelle: Übersicht über die (in diesem Leitfaden besprochenen) CDA-Header-Elemente, deren Datentyp bzw. Bedeutung und deren Kardinalität | Tabelle: Übersicht über die (in diesem Leitfaden besprochenen) CDA-Header-Elemente, deren Datentyp bzw. Bedeutung, deren Kardinalität und deren Status | Ist "Status" synonym für "Conf." | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Steht unter Konformität - zu überlegen ob Tabellenkürzel überall zu ändern | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
65 | Generell | Negativ, kleineres Problem | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Ausprägungen für "Conf" sind sehr utnerscheildich: M, O, R, NP, empfohen, verpflichtend,F | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Die Erläuterungen zu den Notationen der ART-DECOR Templates sind extern verfügbar, ein entsprechender Link ist hinzugefügt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
66 | 7.1.0.5 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
zu den Definition der ELGA | zu den Definitionen der ELGA | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Geändert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
67 | 7.1.0.5 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
unstrukturierter Body (d.h. Abschnitte) | unstrukturierter Body (d.h. Abschnitt) | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
68 | 7.1.0.5 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Generell: Es fehlen mit die Loinc-Code und müssen die ELGA-Hinweise rein? | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Die ELGA-Hinweise sind als Referenz zur österreichischen Spezifikation gedacht; LOINC Codes sind hier unüblich | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
69 | 7.1.0.5 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
In mehreren Zeilen steht nur der Verweis auf ELGA ohne weitere Spalten-Inhalte | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Die dort erwähnten Dinge kommen bisher nur bei ELGA vor. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
70 | 8 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Header-Level-Templates | Header-Templates | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Angepasst | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
71 | 8.1 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
In Zeile Beschreibung steht noch der Hinweis "Bearbeiten" | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | oha, ist nun weg | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
72 | 8.1 | Negativ, kleineres Problem | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Tabelle ist nicht vollständig zu sehen | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | korrigiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
73 | 8.1 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Was bedeuttet der mehrfach aufgeführte Begrff "DYNAMIC" | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Ist nun in der allgemeinen Erläuterung der ART-DECOR Template Darstellung aufgeführt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
74 | 8.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Müssen die Einträge der Art "Eingefügt von …" aufgeführt werden? | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Ja, sie sind Bestandteil der Definition eines Templates | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
75 | Generell | Negativ, kleineres Problem | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
In vielen Abschnittenvon Kap. 8 steht "Der Wert von @code muss gewählt werden…", m.E. muss da jeweilsd er passende Wert stehen z.B. signatureCode (s.S. 60) | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Die Erläuterungen zu den Notationen der ART-DECOR Templates sind extern verfügbar, ein entsprechender Link ist hinzugefügt. Die Value Sets sind nun im anhang als Liste mit Links genannt. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
76 | 9.2.1/ 9.3 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Icons mit den gleichen Anmerkungen sind unterschiedlich | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Sind sowieso ersetzt bzw gestrichen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
77 | 9.4.2. | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Identifikation von Templates erfolgt ausschließlich über id mit einem LOINC-Code. Bei vielen anderen Elementen verwendet man code und codesystem zur Identifikation. Wieso weicht man hier davon ab? | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Instanzen von Sections müssen auch ohne templateId klassifizierbar sein. Deshalb führen wir für alle Sections zB einen code. Insofern ist das hier nicht anders. Template-Definitionen haben eine id. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
78 | 9.7 | Negativ, kleineres Problem | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
inn 9.7 wird angekündigt, dass Diagenosen auf Level 1 bis 3 dargestelltw erden können. Die konkrete darstellung in Kap 9.7 zeigt aber nur Level 1 Darstellung. Level 2 und Level 3 werden erst in Kap. 11 eingeführt. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Hinweis, dass Diagnosen auf Level 3 nur nicht-normativ im Leitfaden stehen. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
79 | 9.13 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
das Bsp. auf Seite 99 ist nicht korrekt: Element tempalteId und code sind mandatory, werden aber im Bsp. nicht aufgeführt. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | sind angegeben | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
83 | 11.1.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Abbildung 1: | Nummerierung | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Abbildungsnummern werden noch konsolidiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
84 | 11.1.3 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
vorangegangen Dienstes | vorangegangenen Dienstes | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Weitergeleitet | Diagnosen-Entries etc sind nun ausgelagert und werden separat behandelt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
85 | 11.1.3 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
In der Tabelle werden Unterabschnitte adressiert. Ist das gewollt? | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Weitergeleitet | Diagnosen-Entries etc sind nun ausgelagert und werden separat behandelt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
86 | 11.2.2 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Weitergeleitet | Diagnosen-Entries etc sind nun ausgelagert und werden separat behandelt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
87 | ? ? | Dr. Erich Gehlen | DURIA | ||
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Inahlte ind er Abb. Sind teilweise schlecht lesbar. Die Nummerierung passt nicht | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Weitergeleitet | Diagnosen-Entries etc sind nun ausgelagert und werden separat behandelt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
88 | 11.3.3 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Das Ende des Abschnitts fehlt | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Weitergeleitet | Diagnosen-Entries etc sind nun ausgelagert und werden separat behandelt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
89 | 11.3.4 | Tippfehler | Dr. Erich Gehlen | DURIA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Das Ende des Abschnitts fehlt | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Weitergeleitet | Diagnosen-Entries etc sind nun ausgelagert und werden separat behandelt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
90 | Vorschlag | Frank Oemig | AGFA | ||
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Hauptkapitel sollten auf einer neuen Seite beginnen | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
91 | 10 | Negativ, kleineres Problem | Frank Oemig | AGFA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Alle auf nationale Verhältnisse angepassten und veröffentlichten CDA-Schemas können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden. | Alle auf nationale Verhältnisse angepassten und veröffentlichten CDA-Schemas können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden. Wenn die Anwendungssoftware jedoch entgeltlich vertrieben wird, so ist eine Mitgliedschaft bei HL7 erforderlich. | konkreten Hinweis einbauen | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Wird noch offiziell erklärt. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
92 | 11 | Vorschlag | Frank Oemig | AGFA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Motivation | Workbox entfernen | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
93 | 12 | Vorschlag | Frank Oemig | AGFA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Liste prüfen | Workbox entfernen | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
94 | 34 | Negativ, schwerwiegend | Frank Oemig | AGFA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Level 2 | Level 2 besagt, dass konkrete Vorgaben existieren, die eingehalten werden müssen. Eine maschinenauswertbare Identifikation kann entweder über Codes oder Template-Ids erfolgen. | Beispiel anpassen, ggf. 2. Beispiel | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Es ist nun ein entsprechender Text aufgenommen, der die Festlegung von Codes für den Arztbrief verbindlich vorschreibt. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
95 | 41 | Vorschlag | Frank Oemig | AGFA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Abb.21 kleiner | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Ist korrigiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
96 | 43 | Negativ, kleineres Problem | Frank Oemig | AGFA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
PN.DE | 2. Spalte von links | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | In 3. Spalte nachdrücklicher erwähnt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
97 | 44 | Tippfehler | Frank Oemig | AGFA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
7.1.0.4 | 7.1.1 | falsche Nummerierung | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
98 | 44 | Kommentar allgemeiner Art | Frank Oemig | AGFA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Conf. | Haben wir irgendwo die Codes erläutert? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | ja, bei Konformität | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
99 | 44 | Tippfehler | Frank Oemig | AGFA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
7.1.0.4.1 | 7.1.1.1 | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
100 | 47 ff. | Negativ, kleineres Problem | Frank Oemig | AGFA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Template-Tabellen | Die Tabellen müssen so formatiert sein, dass sie von der Breite her auf eine Seite passen. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Die neueren Rendering-Verfahren lassen die tabellen besser aussehen. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
101 | 54 | Negativ, schwerwiegend | Frank Oemig | AGFA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Ich bin mit der Darstellung der Spezialisierung nicht einverstanden, da nicht klar herauskommt, worin die Spezialisierung besteht und was die Unterschiede sind! | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Zur zukünftigen Verwendung | Die Darstellung in ART-DECOR geht nie vom Delta der Einschränkungen in Bezug auf ein Elterntemplate aus, sondern enthält immer die Anweisungen zur Erezugung einer korrketen Instanz und damit auch alle ungeänderten Elemente des Eltern-Templates. Ggf kann man durch besondere Berechnungen eine spezialisiertes Template so darstellen,d ass die unveränderten Anteile zB grau statt schwarz erscheinen. Das ist auch in ART-DECOR erwogen worden, aber außerordentlich komplex. Wir sehen entsprechenden Algorithmusvorschlägen und weiteren Diskussionen gerne entgegen. Insofern ist dieser Punkt zurzeit nicht auflösbar. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
102 | Negativ, schwerwiegend | Frank Oemig | AGFA | ||
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
"Spezialisierung" | Hier sollte neben der OID auch der Name angegeben sein, da sonst eine Nachvollziehbarkeit unnötig erschwert wird. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Insofern die OID im Repository bekannt ist wird der Name zusätzlich angezeigt. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
103 | Negativ, schwerwiegend | Frank Oemig | AGFA | ||
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Templates für Anamnese und Medikation leiten sich jeweils von einer gemeinsamen Vorgabe ab. Das kommt aber nicht mehr heraus. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Welche ist die gemeinsame Vorgabe? Section? Dass diese Templates eine Spezialisierung von Section sind, ist aufgenommen und zu sehen. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
104 | Negativ, schwerwiegend | Frank Oemig | AGFA | ||
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Sämtliche Grafiken bei den Abschnitten und Entries fehlen. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Die kleinen R-MIM Grafiken werden nicht mehr gezeigt (früherer Beschluss). R-MIMs fügen keine zusätzlichen Informationen hinzu. Statt dessen ist in der Planung, ein funktionales Klassenmodell zu erstellen und zu referenzieren. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
105 | Negativ, kleineres Problem | Frank Oemig | AGFA | ||
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Nicht alle Abschnitte haben Beispiele. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Beispiele werden sukkzessive ergänzt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
106 | Vorschlag | Frank Oemig | AGFA | ||
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Bei den Codes in den Sektionen sollte der DisplayName zur Information als optional mit angegeben werden. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Der ist doch im CE Element? | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
107 | 127 | Negativ, kleineres Problem | Frank Oemig | AGFA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Beispiel ergänzen | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Beispiele werden sukkzessive ergänzt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
108 | 133 | Negativ, kleineres Problem | Frank Oemig | AGFA | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Grafik aktualisieren | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Grafik aus den HL7-Mittilungen übernommen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
109 | S.24 | Tippfehler | Daniel Hellmuth | Siemens | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
vorgenannten | vielleicht besser: vorher genannten oder s.o ? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | vorher genannten | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
110 | S.27 | Tippfehler | Daniel Hellmuth | Siemens | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Kardinalität | Text ist falsch . Kardinalität und Datentyp sind in der Tabelle "Übersicht über..." nicht enthalten | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
111 | S.28 | Tippfehler | Daniel Hellmuth | Siemens | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Warum ist in der Tabelle "Header - Assoziationen" der CDA Body und keine Tabellenbeschriftung? | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
112 | S.42 | Negativ, kleineres Problem | Daniel Hellmuth | Siemens | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Tabelle "Vokabular" entspricht weder dem HL7 vokabular noch der mime type tabelle auf unsere hl7 wiki. Warum diese separate Tabelle? | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Value Set aus ART-DECOR transkludiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
113 | S.132 | Tippfehler | Daniel Hellmuth | Siemens | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
gilt die Beschreibung der -umsetzungsstufen nur für die eEPA? | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | IHE ITI, rest in elektronische Akte geändert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
114 | S144 | Negativ, kleineres Problem | Daniel Hellmuth | Siemens | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Beispiel auf das in 14.1 verwiesen wird ist weder als link noch im Anhang enthalten. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Das Gesamtbeispiel ist nicht im Leitfaden als soclches enthalten, es ist nun aber ein Link hinzugefügt. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
115 | S.2 | Negativ, kleineres Problem | Daniel Hellmuth | Siemens | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
logo brightone | das logo kann entfernt werden. Die Firma gibt es meines Wissens nicht mehr | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Logo mit dem Hinweis versehen "bis Dezember 2013", Siemens Logo hinzugefügt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
116 | S.9 | Tippfehler | Daniel Hellmuth | Siemens | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Dr. Titel fehlen | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
117 | S.10 | Negativ, kleineres Problem | Daniel Hellmuth | Siemens | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
offenes TODO | muss ein Verweis auf die Mitgliedschaft hin? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Wird noch offiziell erklärt. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
118 | S.11 | Negativ, kleineres Problem | Daniel Hellmuth | Siemens | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Baustellenzeichen und Satz können meiner Meinung nach entfernt werden. Ich finde den Arztbrief und dessen Verwendung zum ersten mal hier ausführlich erklärt | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Wir stimmen mit dem Kommentaror überein: alle Bausetllenzeichen wurden entfernt und ggf. der Text entsprechend ergänzt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
119 | S.17 | Kommentar allgemeiner Art | Daniel Hellmuth | Siemens | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Ich würde die den Eigenschaften keine eigene Überschrift geben… | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Ist sonst von der Formatierung unschön und passt, sollte so bleiben | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
120 | Seite 9 | Kommentar allgemeiner Art | Martin Staemmler | FH-Stralsund | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
copyright Symbol | copy right ausschreiben | lesbarkeit | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Nicht alles braucht ein Symbol | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
121 | Seite 11 | Kommentar allgemeiner Art | Martin Staemmler | FH-Stralsund | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Baustelle bemerkung | löschen | erledigt | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
122 | Seite 10 | Vorschlag | Martin Staemmler | FH-Stralsund | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Hinweis zu kom. Nutzungrechten | notwendig, bitte einfügen | todo | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Steht doch schon drin. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
123 | Seite 12 | Vorschlag | Martin Staemmler | FH-Stralsund | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Hinweis IHE Cookbook | unklar ob nur für Security, dann ok, ansonsten eher nicht | todo | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | IHE Cookbook im Abschnitt Abgrenzung nun ausdrücklich genannt und im Literturverzeichnis aufgeführt erwähnt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
124 | Seite 25 | Kommentar allgemeiner Art | Martin Staemmler | FH-Stralsund | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
SCIPHOX erhält Aufgabe | unklar, ob es SCIPHOX noch gibt und die Aufgabeereldigen kann, Begriff/Rolle SCIPHOX nicht erklärt | todo | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Hinweis auf SCIPHOX streichen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
125 | Seite 27 | Kommentar allgemeiner Art | Martin Staemmler | FH-Stralsund | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Abbildung Clin. Doc. Klasse unsauber ausgeschnitten | Ränder bessererfassen | todo | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
126 | Seite 46 | Kommentar allgemeiner Art | Martin Staemmler | FH-Stralsund | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Zeile 22, 38, 52 Einträge in Spalte Kommentar eine Zeile zu tief gerutscht | todo | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
127 | ab Seite 47 und folgende | Kommentar allgemeiner Art | Martin Staemmler | FH-Stralsund | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
in Kapitel 8 wird jeweils ein Abschnitt "benutzt von Template ID" eingefügt, der an manchen Stellen auf Versionen im Erstellungstool zielt (z.B. Arztbrief zu zwei Zeiten) | jeweiligen Abschnitt "Benutzt von " auf einen Eintrag kürzen, oder "Benutzt von" entfernen, da teilweise selbst referenzierend (Arztbrief) | todo | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | ART-DECOR zeigt grundsätzlich alle Templates an die verwendet werden bzw in denen das bestreffende Template vorkommt. Das hat nichts mit Leitfäden oder Veröffentlichung zu tun und kann daher auch nicht auf iregdnetwas reduziert werden. Wir werden eine entsprechende Erklärung in den allgemeinen erläuetrungsteil zu ART-DECOR mit aufnehmen. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
128 | Seite 84 | Vorschlag | Martin Staemmler | FH-Stralsund | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Section "Fragestellung" bezieht sich auf eine Überweisung, damit ist die Überschrift wenig aussagekräftig gewählt | bessere Überschrift oder mehr Optionen für eine Fragestellung wählen | todo | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Heist Grund der Überweisung | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
129 | Seite 84, Seite 85 | Kommentar allgemeiner Art | Martin Staemmler | FH-Stralsund | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
? Und i Anmerkung mit ähnlichem Text aber unetrscheidliche Kennzeichnung (?, i) | vermutlich entfernen und LOINC einfügen | todo | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
130 | Seite 89 | Vorschlag | Martin Staemmler | FH-Stralsund | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
nur zwei Diagnosen (Aufnahme, Entlassung) vorgesehen, was ist mit "Einweisungs-" oder "Verlegungs-" diagnose oder gar Abrechnungsdiagnose ? | ok, Verlegung = Entlassung und Aufnahme, aber vom amb. --> stat. per "Einweisungsdiagnose", Abrechnung mag entfallen | todo | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Weitergeleitet | Sind das nicht Teile anderer Leitfäden oder kann später ergänzt werden? | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
131 | Seite 93 | Kommentar allgemeiner Art | Martin Staemmler | FH-Stralsund | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Zeile 64, copy & paste Fehler Allergie aus vorigem Abschnitt 9.8 | Text anpassen | todo | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Angepasst | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
132 | Seite 95 | Kommentar allgemeiner Art | Martin Staemmler | FH-Stralsund | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Zeile 30, copy & paste Fehler Allergie aus vorigem Abschnitt 9.8 | Text anpassen | toto | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Titel soll lauten "Medikation bei Entlassung" | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
133 | Seite 127 | Kommentar allgemeiner Art | Martin Staemmler | FH-Stralsund | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
zweimal Baustelle - hier ist das Dokument noch unvollständig | bitte ergänzen | todo | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Kommentare entfernen und Beispiel ergänzen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
134 | Seite 132 | Kommentar allgemeiner Art | Martin Staemmler | FH-Stralsund | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Zeile 35 "Die technische Spez. Der eEPA" hier fehlt der Bezug zu einem anderen Kapitel bzw. externen Dokument, mir ist eine solche Spez. leider auch nicht bekannt | bitte Bezug herstellen | todo | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Bezug zum IHE TF herstellen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
135 | generell | Kommentar allgemeiner Art | Martin Staemmler | FH-Stralsund | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
noch einige Kommentare und offene Punkte, die aufzulösen wären | auflösen, bearbeiten | todo | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
136 | S. 12 Zeile 7 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Hierbei kann man zwei Gegenpole beobachten. Zum einen ist da die Facette der Mensch-zu-Mensch Kommunikation. Dies wird z. B. erreicht durch das Versenden von Papier und Formularen. Jeder weiter führende elektronische Ansatz muss auch diese Art der Interoperabilität gewährleisten. | Der ganze Absatz stellt Forderungen, die ich sich nicht wirklich auf die Spezifikation selbst zu beziehen scheinen. Hier sollte gekürzt und fokussiert werden | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Der Abschnitt soll das Feld von Interoperabilität aufzeigen und deutlich machen, dass diese Spezifikationen diesem Feld genüge tut. Insofern wird der Text belassen. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
137 | S. 12 Z 29 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
In einer späteren Ausbaustufe kann die Einweisung/Überweisung definiert werden. | d.h. die ist noch nicht durch diese Spezifikation abgedeckt? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Nein, ist sie nicht. Ein Arztbrief ist NIE eine Einweisung oder Überweisung. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
138 | S. 12 Z 36 | Kommentar allgemeiner Art | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
es wird vom sendenden System dauerhaft gespeichert | Ist das zwingend notwendig? Was ist mit Systemen die es ins Archiv auslagern, oder dem Empfänger eine digitale dauerhafte Speicherung überlassen (der sender kann seiner Archivierungspflicht auch mit Papier nachkommen). | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Hier geht es primär um die Aussage und Eigenschaften, dass Dokumente dauerhaft gespeichert werden. Um diesen Aspekt zu betonen, wird ""vom sendenden System"" im letzten Teil des Satzes entfernt. Die Speicherung im Archiv widerspricht dieser Aussage ja nicht. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
139 | S. 12 Z 39 | Kommentar allgemeiner Art | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
in der eigenen Datenbank gespeichert und die Nachricht als solche danach gelöscht | hier sprechen wir über den Empfänger, nicht wie oben der sender. Der Empfänger hat aber im Gegensatz zum Ersteller keine Archivierungspflicht, ausser er begründet seine medizinischen Entwscheidungen damit. D.h. der Empfänger dürfte die Infos aus dem Arztbrief extrahieren und wegschmeissen. Dadurch wird es aber doch nicht zur Nachricht, oder? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Dieser Absatz adressiert nicht die diversen Pflichten, sondern die Paradigmenunterschiede von Dokumenten und Nachrichten. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
140 | S. 12 Z 54 | Vorschlag | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
OP-Berichte, Laborberichte, andere Befunde sind kein Fokus | Muss man nicht ausschliessen, aber sollte hier oder weiter oben erwähnt werden. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
141 | S. 13 Z 18 | Tippfehler | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Nachrichten | Dokumente | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
142 | S. 13 Z 21 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
XML-basierte Implementierung | Ist die XML Implementierung hier nicht normativ?? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Grundsätzlich lassen sich auch andere Formen denken. Die XML-Darstellung ist normativ, die verwendeten Schemas nicht. Text wurde leicht angepasst. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
143 | S. 17 Z 43 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Dokument als Ganzes, Teilinformationen daraus können nicht ohne Bezug auf das Dokument verwendet werden. | muss man das so hart ausschliessen? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Keine Information aus einem Dokument sollte dem Grundsatz nach ohne Zusammenhang mit dem Dokument extrahiert und anderswo gespeichert werden. Alleine schon die Tatsache, dass ein Dokument in einer beuen Version andere Informationen umfassen kann, macht dieses "Tracking" notwendig. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
144 | S. 17 Z 60 | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
mit einem einzigen Stylesheet | Ist dies wirklich eine Anforderung? Warum? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | ersetzt durch "geeignet" | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
145 | S. 25 Z 68 | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
auch andere Arten von Dokumenten wie Ein-/Überweisungen, Befunde, Bilder, etc. | Der Aufbau von anderen Dokumenten wird in diesem Leitfaden nicht behandelt | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | ersetzt durch "Die Prinzipien der Gliederung gelten aber auch für andere Arten von Dokumenten wie Ein-/Überweisunggen, Befunde, etc. " | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
146 | S. 27 Z 28 | Tippfehler | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
so wie sie in den hier beschriebenen Anwendungsszenarien zur Anwendung kommen. | so wie sie in den im Anhang beschriebenen Anwendungsszenarien … | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
147 | S. 27 Z 52 | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
und deren Kardinalität | Kardinalitäten sind nicht in der Tabelle angegeben | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | angepasst | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
148 | S. 28 Z 13 | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
und deren Kardinalität | Kardinalitäten sind nicht in der Tabelle angegeben | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | angepasst | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
149 | S. 28 Z 21 | Tippfehler | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
sind: | - | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | "sind" löschen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
150 | S. 28 Z 39 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Urheber / Authentifikation / Unterzeichner | Unterzeichner | Die Alternativen im Titel verwirren nur. Urheber ist ausserdem eher Autor | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | nun "weitere Unterzeichner" | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
151 | S. 12 Z 22 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Genauer definieren, was der Arztbrief eigentlich ist und was er können soll! | Vor allem auch definieren welche Dokumententypen nicht dazugehören. Ist der OP-Bericht drin? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Hinzugefügt unter Abgrenzung: dieser Leitfaden beschreibt den Arztbrief (Discharge summarization note [physician], LOINC-Code 11490-0); andere Dokumententypen wie z. B. OP-Berichte sind hiermit nicht beschrieben (aber dem Prinzip nach gleich aufgebaut). | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
152 | S. 31 Z 16 | Tippfehler | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
"Level 1 bis 3" unten | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | ändern: "siehe Abschnitt „Levels: 1 bis 3"" | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
153 | S. 35 Z 13 | Vorschlag | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Es liegt auf der Hand, dass die Spezifikation der Abschnitte eng verbunden ist mit dem Typ des Dokuments, z.B. ein OP-Bericht. In Briefen wird man relativ wenig Vorgaben machen, während in Formularen oder Berichten relativ genaue Vorgaben zu | Fokus des Leitfadens auf Arztbriefe klarmachen | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | geänderte Formulierung: Es liegt auf der Hand, dass die Spezifikation der Abschnitte eng verbunden ist mit dem Typ des Dokuments, z.B. ein OP-Bericht. In Arztbriefen - wofür dieser Leitfaden entwickelt wurde - macht man hier relativ wenig Vorgaben, während in Formularen oder Berichten relativ genaue Vorgaben zu erwarten sind. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
154 | S. 36 Z 33 | Tippfehler | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
XML technisch gesprochen validieren CDA Dokumente jeden Levels gegen das generische CDA Schema. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information vom Antragsteller | Was ist hier das Problem trotzdem Verbesserung der Formulierung: ""unabhängig vom Level"" | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
155 | S. 37 Z 31 | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
weiter gehend strukturieren | weitergehend strukturiert darstellen | Struktur als Darstellungsaspekt von Entry Level Strukturierung unterscheiden (wording) | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | angepasst | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
156 | S. 37 Z 42 | Vorschlag | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
(at)listType ist die Liste | hilfreiche Klarstellung: Müssen auch unsortiere Listen in der gegebenen Reihenfolge dargestellt werden? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | InfoxBox einfügen: Die Reihenfolge der Darstellung richtet sich nach der Reihenfolge im CDA Dokument | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
157 | S. 40 Z 63 | Vorschlag | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
unsortiertstyleCode=Bold Italics> | Wie funktionieren Kombinationen? Kann man beliebige Kombinationen in beliebiger Reihenfolge angeben? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | ergänzen, dass Reihenfolge beliebig | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
158 | S. 42 Z 6 | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Conf spalte | Erklärung der Conf Spalte fehlt | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Darstellung der Attribute nun a.a.O. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
159 | S. 42 Z 21 | Vorschlag | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
OMVL | Wofür steht das? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Zur zukünftigen Verwendung | Das ist der Name der Regel. Alle Regeln müssen eindeutig identifizierbar sein. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
160 | S. 42 Z 32 | Vorschlag | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Hier wäre Guidance wichtig: bei bildern, video und audio wird erklärt was wann sinn macht. wann sollte ich plain text, pdf oder CDA kapseln? | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | An dieser Stelle wird beschrieben, wie man auf andere Inhalte verweist. Aus dieser Angabe kann man entnehmen, welches Objekt referenziert. Wenn es sich um ein PDF-Dokument handelt, dann sollte hier "application/pdf" angegeben werden. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
161 | S. 42 Z 71 | Vorschlag | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
CDA Level 1 | Erläuterung fehlt | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Weitergeleitet | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
162 | S. 43 Z 51 | Vorschlag | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
v3dtr1:CE v3dtr1:CD | Unterscheidung zwischen den CD und CE nicht erklärt | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Die detaillierten Unterschiede sind in dem entsprechenden Leitfaden nachzulesen. UM das zu vereinfachen haben wir hier die verwendeten Datentypen mit Referenz aufgelistet. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
163 | s. 43 Z 64 | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Hier sollte eine vollständige Auflistung stehen. Durch die Punkte wird unvollständigkeit angedeutet | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | nun alphabetisch und volständig | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
164 | S. 44 Z 35 | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Ist die Realm nicht fixiert? | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Nicht zwangsweise, nun zugefügt: hier in der Regel "DE" | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
165 | S. 44 Z 69 | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
xmlns:voc="urn:h17-org:v3/voc" | Ist der NS notwendig? Wenn ja sollte er wie der default NS weiter oben erläutert werden | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | nein, ist nun weg | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
166 | S.45 Z 28 | Vorschlag | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
der Autor muss eine natürliche Person sein | Besser: das Autor Element darf nur für natürliche Personen verwendet werden, nicht für Informationssysteme oder medizin-technische Geräte | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
167 | S. 45 Z 32 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Informant (informant) | wurde in 6.2.2 als "noch nicht verwendet" markiert | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | wird doch verwendet, angepasst | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
168 | S. 45 Z 34 | Vorschlag | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Organisation die für die verwaltung des Dokuments verantwortlich ist | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | "die das Dokument verwaltende Organisation" | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
169 | S. 45 Z 45 | Vorschlag | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Unterscheidung zum legalAuthenticator sollte erläutert werden | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Erläuterung ergänzen. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
170 | S. 46 Z 21 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Wozu sind die ELGA Definitionen hier? Sind sie Teil des Leitfadens? | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Aufgenommen in der Tabelle sind auch Referenzen zu den Definition der ELGA (Österreich) zur Information. Die Hinweise in bezug auf die ELGA Spezifikation geben dem Leser nochmal Hinweise, wo es Überschneidungen / Identität gibt, oder wo es Unterschiede gibt. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
171 | S. 46 Z 23 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
ELGA: Entlassungsdiagnose | Abschnitt definition fehlt | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | zugefügt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
172 | S. 46 Z 34 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Risiken | Viele Elemente scheinen nirgendwo genauer spezifiziert zu sein. Die Tabelle muss aufgeräumt werden | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Zur zukünftigen Verwendung | Das kann man sicherlich noch besser machen, im Moment führen die Links jedoch auch schon zu ausreichenden Beschreibungen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
173 | S. 47 Z 16 | Vorschlag | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Ein Arztbrief kann somit entweder unstrukturiert als PDF o.ä. Dokument übermittelt werden, oder sich aus strukturierten Abschnitten zusammensetzten. | Hinweis ist unnötig | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Hier besser nochmal Klarstellung auf Format (binär/XML) und Struktur (inhaltlich) aufführen, auch wenn das vielleicht unnötig erscheint. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
174 | S. 55 Z 18 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
hl7:functionCode CE 0 .. 1 | Hier sollte ein fixer Wert stehen oder das Element per constraint entfernt werden | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Value Set Referenz hinzugefügt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
175 | S. 55 Z 21 | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
hl7:time TS.DATE.MIN | Erläuterung wie das Feld zu interpretieren ist fehlt (d.h. wie unterscheidet sich das Feld vom ClinicalDocument/effectiveTime?) | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | siehe nun Datentypen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
176 | S. 55 Z 32 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
hl7:code CE 0 .. 1 | Hier müsste beantwortet werden: Wofür ist das gut? Welche Werte sind erlaubt? Wie unterscheidet es sich vom functionCode? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Dies ist an dieser Stelle offen, Hinweis hinzugefügt ""; es sollte eine entsprechendes Value Set erstellt werden | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
177 | S. 61 Z 13 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Beschreibung: Unterzeichner des Dokuments | Hier fehlt wie es sich vom legalAuthenticator unterscheidet | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Ergänzt um "Unterzeichner des Dokumentes (weitere neben dem vor dem Gesetz verantwortlichen Unterzeichner)" | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
178 | S. 63 Z 20 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
hl7:time TS 0 .. 1 | Wie unterscheidet sich dies vom ClinicalDocument/effectiveTime Element? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | In der Regeln nicht, ist oft gleichzusetzen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
179 | S. 64 Z 15 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Beschreibung: Informant, Personen, die Informationen zu dem Arztbrief beigesteuert haben | Unterscheidung zu Participants unklar. Ich würde hier auf natürliche Personen die nicht als Leistungserbringer agieren einschränken | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Hinweis: i.d.R. natürliche Personen, die nicht als Leistungserbringer agieren | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
180 | S. 64 Z 58 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Informant assignedEntity | Hilfe wann assigned Entity und wann related Entity genutzt werden soll fehlt. Z.B. Sozialhelfer, Betreuer/Erzieher vs. Verwandte | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | assigned entities sind Heilberufler, die in der Liste aufgeführten Berufe fallen unter related entity; Hinweis hinzugefügt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
181 | S. 64 Z 63 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Informant assignedEntity ID 1..* | Können wir das heir auf 0..* aufweichen? Sonst ggf. expl. hinweis auf nullFlavors, da bei nicht-Leistungserbringern üblicherweise keine sinnvolle ID bekannt ist | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | 1..* R heißt, dass es auch weggelassen werden kann (mit Angabe von nullFlavor) | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
182 | S. 66 Z 25 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Weitere Beteiligte: Mit dieser Assoziation und den entsprechenden Klassen können weitere für die Dokumentation wichtige beteiligte Personen oder Organisationen wie Angehörige, Verwandte, Versicherungsträger sowie weitere in Beziehung zum Patienten stehende Parteien genannt werden. | Unterscheidung zu Informant unklar: "Im Gegensatz zum Informant, der Informationen zum Dokument beigesteuert hat, werden hier Leistungserbringer und andere Personen oder Organisationen geführt, die für die weitere Behandlung des Patienten relevant sein können." | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Hinweis ergänzt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
183 | S. 66 Z 50 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Participant typeCode | Ich würde hier Werte ausschliessen, die mit anderen Header Elementen kollidieren: author, informant, data entry person, performer, verifier, authenticator, legal authenticator, receiver, record target. Da ein großteil der Werte hier kaum sinn macht, wäre ein neues ValueSet mit einer Positivliste sehr hilfreich für implementierer (z.B. baby, escort, consultant, device, coverage agent, guarantor, location, destination). Was durch spezielle participations weiter unten definiert ist, kann man ja hier weglassen. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Verboten wäre das nicht, aber Hinweis ergänzt: Typischerweise sind hier nur typeCodes zu verwenden, die nicht durch eine bereits existierende spezialisierte Participantion ausgedrückt werden wie z. B. author, authenticator etc. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
184 | S. 66 Z 58 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Participant functionCode | Hinweis, das die ParticipationFunction nur bei bestimmten ParticipationTypes Sinn macht (zB admitter + admittingPhysician) | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Dies ist das allgemeine unspezialisierte Template; Hinweis hinzugefügt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
185 | S. 66 Z 70 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Participant associatedEntity classCode | Auch hier müssen implementierer besser unterstützt werden: ein valueset fehlt, dass sinnvoll einschränkt: zB caregiver, employee, service delivery location, regulated product, policy holder, contact, emergency contact, next of kin, guardian, dependent | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Zur zukünftigen Verwendung | Dies ist das allgemeine unspezialisierte Template, Vorformulierte Hinweise aus der Praxis sollten übernommen werden | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
186 | S. 68 Z 22 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
HeaderParticipantEinweiser | Derzeit nur über die TemplateID ersichtlich, dass es sich um einen Einweiser handelt (associatedEntity/@classCode=PROV ist sehr vage). Das sollte über den participationType = ADM (admitter) abgebildet sein, ggf. auch über den function code = ADMPHYS (admitting physician) | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Zur zukünftigen Verwendung | Dies ist konform der ELGA Spezifikation, also ein Sachverhalt, der länderübergreifend diskutiert werden muss | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
187 | S. 70 Z 35 | Vorschlag | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
(hphand) participant associatedEntity id | Empfehlung für Arztnummer wäre gut, zB. KBV LANR | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
188 | S. 70 Z 65 | Vorschlag | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
(hphand) participant associatedEntity scopingOrganization id | Empfehlung für eine ID für Arztpraxen wäre gut (z.B. Institutskennzeichen oder KBV Arztnummer Praxis) | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Weitergeleitet | zu diskutieren | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
189 | S. 72 Z 9 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
hl7:time IVL_TS 0 .. 1 | min. auf Datumsgranularität festlegen? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | In einem allgemeinen Template schwerlich einzuschränken | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
190 | S. 72 Z 12 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
<time> <low value="20131101"/> <high value="20131121"/> </time> | Klarstellen: Sind offene Intervalle erlaubt? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Beispiel ergänzt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
191 | S. 74 Z 37 | Tippfehler | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
weitere Beteiligte | Titel auf "Versicherter / Versicherung" beschränken | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
192 | S. 75 Z 46 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
(Header Participant Kostentraeger) participant time | Klarstellen: Nur offene Intervalle, oder auch geschlossene? Auch Zeitpunkte erlaubt? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Kommentar im template wird als ausreichend erachtet | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
193 | S. 76 Z 42 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
In scopingOrganization wird unter id das Institutionskennzeichen (IKNR) des Kostenträgers mit @extension = die eigentliche IKNR und @root = "1.2.276.0.76.4.5" (Dies ist die OID für IKNummern in Deutschland) angegeben | sollte die ID dann nicht 1..1 sein? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information vom Antragsteller | Was ist hier mit diesem Kommentar gemeint? | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
194 | S. 77 Z 26 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
(hier: nicht nur stationäre Aufenthalte, sondern auch Patientenkontakt in der Praxis eines Niedergelassenen beispielsweise) | Der Zusatz in Klammern macht für Entlass und Verlegungsdokumentation keinen Sinn. Niedergelassene entlassen und verlegen nicht. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Kommentar ergänzt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
195 | S. 77 Z 25 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Wenn die Dokumentation ein Entlass- oder Verlegungsdokument ist, muss die Information in dieser Klasse mitgegeben werden, | Klarstellen: Ist das "muss" hier als normative Forderung zu verstehen? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Angepasst | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
196 | S. 77 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Text rechts abgeschnitten | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Angepasst | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
197 | S. 78 Z 49 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Sollen ambulante Besuche (zB. in der Arztpraxis) über ein offenes Intervall ausgedrückt werden? Wäre hier nicht auch ein value TS als Option notwendig? | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Ambulante Besuche finden auch innerhalb eines Intervalls statt (heute von 10 bis 11 Uhr), Beispiel ergänzt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
198 | S. 79 Z 16 | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Hier wäre ein eher strategischer Hinweis angebracht, ob es sich lohnt den Einweiser oder andere seperat geführte Participants hierhin zu duplizieren | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Zur zukünftigen Verwendung | Wenn die responsible Party dasselbe ist, dann ist das hier zu duplizieren; hier geht es wie ausgewiesen um den Verantworltichen für den Aufenthalt; Der Einweiser hat hier typischerweise nichts zu suchen; ggf. kann hier nach Vorlage ein weiterer Hinweis gegeben werden | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
199 | S. 79 Z 30 | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Hier wäre ein Hinweis sinnvoll, wann Implementierer die represented Organization verwenden sollen und wann die location/serviceProvider Organization. Die location ist mandatory, warum sollte ich das hier noch duplizieren? Belegarzt Szenario? | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | responsibleParty.representedOrganization und location.serviceProvider Organization können dasselbe sein, müssen es aber nicht; die Definitionen werden als ausreichend angesehen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
200 | S. 81 Z 6 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
9.1 Section: Non-XML-Body | Die Verwendung von in CDAs eingebetteten PDFs sollte nicht begünstigt werden. Dies erhöht die Implementierungskosten v.a. für Webanwendungen unnötig und birgt neue Sicherheitsrisiken und Autorisierungsprobleme. Wenn jemand zwanghaft ein PDF in ein CDA verpacken will, wird er das auch ohne die Hilfestellung des Leitfadens schaffen. Der Arztbrief 2015 sollte einen sinnvollen Mindest-Standard darstellen. Wenn jeder seine PDFs durch einen Minimal-Header in ein Arztbrief verwandeln kann, verwässert das die Aussagekraft einer Konformität zum AB 2015. Ein weiteres Risiko ist eine unnötige Duplizierung der Transportinformationen aus Aktensystemen in einen CDA header (v.a. bei IHE XDS Projekten) ohne jeglichen Mehrwert, wenn der Inhalt nur aus PDFs besteht. Was haben wir gewonnen wenn XDS Projekte alle PDFs in CDA wrappen um Arztbrief 2015-konform zu sein? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Mehrfach diskutiert im Interoperabilitätsforum | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
201 | S. 84 Z 32 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Anmerkung: LOINC Codes mit einem vorangestellten X, wie hier X-SALUT, werden kurzfristig durch tatsächliche numerische LOINC Codes ersetzt | Wenn die durchgängige Verwendung von LOINC gefordert wird, ist das gut. Wenn das X-codes zur Folge hat, bin ich skeptisch. Wie realistisch ist es, dass Regenstrief einen Code für die Begrüßung zur Verfügung stellt? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Wenn man es tatsächlich macht, wahrscheinlich | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
202 | S. 85 Z 40 | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Anmerkung: LOINC Codes mit einem vorangestellten X, wie hier X-RFR, werden kurzfristig durch tatsächliche numerische LOINC Codes ersetzt | X-RFR wird nicht verwendet, Kommentar entfernen | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | entfernt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
203 | S. 89 Z 60 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
9.7 Section: Diagnosen | Einen Code für eine allgemeine Diagnose Section gibt es nicht? Was ist mit Dauerdiagnosen? Was passiert bei ambulanten Besuchen bei denen es ja keine Aufnahme / Entlassung gibt? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Auch bei ELGA kennt man "allgemeine Diagnosen" nicht, zu diskutieren | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
204 | S. 98 Z 56 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
(at)code 1 .. 1 F X-FINREM | Warnung wegen X-code fehlt | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Hinzugefügt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
205 | S. 100 Z 62 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
URI | sollte das nicht nur URL heissen? Sind auch URNs erlaubt? reine Dateinamen sind doch eigentlich weder URLs noch URIs | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Das muss de facto URL heißen, ist angepasst; reine Dateinamen sind local URLs | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
206 | S. 102 Z 44 | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
In der Tumordokumentation gilt die erweiterte Tabelle | welche erweiterte Tabelle? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Diagnosen-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
207 | S. 103 Z 51 | Tippfehler | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Dienstes | Ereignis, nicht Dienst | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
208 | S. 104 Z 26 | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Für die Verarbeitung von Diagnosedaten über ein rechnergestütztes System ist die Vergabe von Ids empfehlenswert, um gezielt auf den Datensatz der Diagnose zugreifen zu können. | Sollten wir es dann nicht auf 1..1 festlegen. Für Ausnahmen gibt es immer noch nullFlavors … | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Diagnosen-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
209 | S. 104 Z 29 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
In der XML-Repräsentation wird die Diagnose-ID im Attribut @extension und die OID des Systems im Attribut @root angegeben. | Von der Verwendung von extensions sollte abgeraten werden. Eine OID oder UUID als root ist vorzuziehen. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Diagnosen-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
210 | S. 104 Z 46 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
( siehe auch Anhnag 10) | Ich konnte keinen Anhang 10 finden. Hier sollte aber auf jeden Fall ein Value Set definiert werden. Ich würde darüber v.a. Haupt diagnose und neben diagnose bei aufnahme und entlassung ausdrücken, bei ambulanten Fällen die akuten vs. dauerdiagnosen | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Diagnosen-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
211 | S. 104 Z 62 | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
beschriebene Beobachtung negiert wird | Verweis auf Auschlussdiagnose Kennzeichen fehlt | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Diagnosen-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
212 | S. 105 Z 31 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
erläuternde Text | Klarstellen: Geht es hier um den Freitext für eine Diagnose? Oder soll hier der Displayname der ICD diagnose verwendet werden? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Diagnosen-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
213 | S. 105 Z 34 | Tippfehler | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die strukturierte Darstellung sieht wie folgt aus. | Der Satz macht hier keinen Sinn | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Satz streichen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
214 | S. 105 Z 54 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
11.1.3.6 Diagnosezeitraum | Ist es auch möglich einen Zeitpunkt oder die Mitte eines auf beiden Seiten offenen Intervalls anzugeben (center)? Was mache ich, wenn ich nicht weiss seit wann der Patient an der Krankheit leidet? Müsste ich hierüber nicht auch "zustand nach" ausdrücken (d.h. high liegt in der Vergangenheit)? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Diagnosen-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
215 | S. 106 Z 24 | Tippfehler | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
OID-Register | DIMDI? HL7? Welches Register? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Verweis auf OID-Register streichen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
216 | S. 106 Z 61 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
value | Value wurde schon für den Diagnose Code selbst verwendet (auch auf Ebene 2). Wie kann die Diagnose Sicherheit über ein gleichnamiges Element ausgedrückt werden? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Diagnosen-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
217 | S. 107 Z 12 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Diagnosesicherheit wird aus der unten gezeigten Tabelle entnommen | Erstens betrifft dies nicht nur die Diagnose Sicherheit sondern alle 4 Kennzeichen (V und Z haben nichts mit Sicherheit zu tun). 2. Wenn wir alle 4 Werte über andere Felder ausdrücken können, brauchen wir den Qualifier doch nicht mehr, richtig? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Diagnosen-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
218 | S. 107 Z 27 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Lokalisation zu Diagnosen wird über das Element targetSiteCode angegeben. Wird die Lokalisation im Freitext angegeben, erfolgt die Darstellung über das Unterelement orginalText. Bei fehlender Codierung muss im Element targetSiteCode das Attribut @nullFlavor angegeben werden. | Verweis auf die Tabelle unten fehlt | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Diagnosen-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
219 | S. 108 Z 12 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
z.B. durch einen Arzt dokumentiert werden | Der Arzt wäre dabei aber der dataEnterer, was nicht mit der Definition zusammenpasst. Der dataEnterer macht keine Observations, er transkribiert nur vorhandene Informationen und wird nicht als dataEnterer geführt, wenn er selbst der Author ist. Brauchen wir das Dokumentationsdatum überhaupt getrennt vom Diagnosedatum? Was ist die klinische Relevanz vom Zeitpunkt an dem es aufgeschrieben wurde? Das hat vielleicht forensischen Nutzen, aber das müsste man eh im erstellendem Primärsysteme gesichert nachweisen ... Ich empfehle das Dokumentationsdatum zu entfernen. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Diagnosen-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
220 | S. 108 Z 28 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Ist keine explizite Klasse dataEnterer vorhanden, so wird eine Participation-Klasse durch die Angabe des Attributes typeCode mit dem Wert ENT zu einer Klasse data Enterer. Über die Klasse participationRole kann die Person näher beschrieben werden. | es ist ein alternativer Modellierungsvorschlag der im Leitfaden unangebracht ist. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Diagnosen-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
221 | S.109 Z 64 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Sicherheit der Diagnose / Umsetzung / G | Auch Gesichert lässt sich über einen uncertaintyCode ausdrücken (=N) | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Diagnosen-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
222 | S. 109 Z 66 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
uncertaintyCode = UN | Ich würde auch lieber einen uncertaintyCode als einen Qualifier verwenden. Hier ist aber nicht definiert, wo das hin gehört (in der Tabelle oben fehlt es, wahrscheinlich weil CDA das element dummerweise weggekürzt hat). ActUncertainty definiert übrigens nur U als uncertain (d.h. Verdacht auf), nicht UN | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Diagnosen-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
223 | S. 109 Z 69 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Zustand nach | Wird dies nicht durch eine effectiveTime mit high value in der Vergangenheit ausgedrückt? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Diagnosen-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
224 | S. 113 Z 16 | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Hinweise zu gültigen Codesystemen sind im Anhang genannt | Welcher Anhang? Ich finde dort nur Use Cases | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Diagnosen-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
225 | S. 117 Z 71 | Tippfehler | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
1.2.6 | Referenz passt nicht | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Referenz entfernen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
226 | S. 125 Z 54 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
sich immer um stattgefundene Prozeduren | Warum kann man keine geplanten Prozeduren ausdrücken (INT)? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Diagnosen-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
227 | S. 130 Z 38 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
11.5 Diagnose-Entries | Warum gibt es diesen Abschnitt? Er ist doch redundant | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Diagnosen-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
228 | S. 132 Z 35 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die technische Spezifikation der eEPA definiert wie Primärsysteme Patienteninformationen über die IHE XDS | Was macht dieser Abschnitt hier? Sollte er nicht ganz entfernt werden? Was ist hiervon noch nicht gesagt worden? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Muss noch diskutiert werden | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
229 | S. 137 Z 40 | Vorschlag | Tarik Idris | InterComponentWare AG | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Use Case: Nachtragen / Anhängen weiterer Information | Das klang zuerst nach Addendum, dann ging es aber um Replacements. Hier sollte der Titel auf "Ersetzen vorläufiger Informationen" geändert werden | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Die Use Cases | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
230 | 6.3.3.3 | Negativ, schwerwiegend | Christof Gessner | gematik | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
-- | (Erläutereungen zu Umgang mit externen referenzen / Anlagen, Hinweise auf Lösungen für den Transport CDA incl. Attachments) einfügen | Der IG sollte an dieser Stelle das Thema ansprechen. Ziel: Vorgaben für "konformen" Umgang mit externen referenzen und Anlagen. Möglichst auch die Bedeutung für Signatur deutlich machen. Ebenfalls: Risko für Vertraulichkeit durch Aufruf externer URL (referrer). | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Muss noch diskutiert werden | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
231 | 9.1.1 | Negativ, schwerwiegend | Christof Gessner | gematik | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
URL: <reference value="http://xx.yy.de/pfds/ 56754856734.pdf"/> | Sicherheitsrisiko. Aufruf externer URL, insbesondere als http, stellt Risiko dar für Verletzung der Vertraulichkeit. In bestimmten Umgebungen (gematik-Konnektor) können solche Referenzen nicht aufgelöst werden. Daraus resultiert ggf. dass das Dokument nicht oder nicht vollständig angezeigt werden kann. Daraus ergeben sich Probleme bei der Signatur des Arztbriefs. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Muss noch diskutiert werden | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
232 | 10.1 | Negativ, kleineres Problem | Christof Gessner | gematik | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
referenzierte Beilage | Erläuterung, ggf. zusätzliche constraints. Am besten ein separater Abschnitt, der das Vorgehen bei externen Referenzen spezifiziert und abgrenzt von "embedded". | In Überschrift und Text wird von "eingebetteter Beilage" gesprochen. Das passt nicht zu einer Referenz auf ein externes Dokument. | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Die Beschreibung enthält (ausreichend): Die Anhänge können entweder als Referenz oder als direkte Inklusion des Objektes übermittelt werden. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
233 | 10.1 | Vorschlag | Christof Gessner | gematik | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Beilage | Anlage | Sprachgebrauch in Deutschland, abweichend von Österreich. | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
234 | 11.4 | Negativ, schwerwiegend | Christof Gessner | gematik | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Externes Dokument | Hier bitte typische Lösungsszenarien für den Transport eingebetter Imformation bzw. den Umgang mit externen Bezügen (via URL?) ansprechen. relevanz für Signierfähigkeit! | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Transport und Signatur liegen außerhalb dieses Leitfadens, siehe Abschnitt Abgrenzung; Lösungsszenarien ausarbeiten als Aufgabe eingebracht in das Interoperabilitätsforum | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
235 | 9.1.2 | Negativ, schwerwiegend | Christof Gessner | gematik | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
URL | constraints einfügen für "dokumentinterne URL" | im Falle eingebetteter Dokumente gelten zusätzliche Regeln für die zulässigen URL | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Ausarbeitung als Aufgabe eingebracht in das Interoperabilitätsforum | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
236 | 2.4 | Negativ, kleineres Problem | Christof Gessner | gematik | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
digitale Signatur, Verwendung von Stylesheets, Security | Visualisierung des CDA. Daraus ergibt sich, dass wesentliche Aussagen für folgende Nutzung des CDA nicht im vorliegenden Leitfaden enthalten sind: digitale Signatur, Verwendung von Stylesheets, Security | Bezug zu Referenzierung externer Dokumente sowie zum Umgang mit Header / narrativen Inhalten / Entries. Der IG sollte diese Problematik in einem separaten Abschnitt zumindest ansprechen und ggf. auf Lösungswege verweisen. | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Die Punkte sind hier genannt, weil sie in diesem Leitfaden nicht besprochen werden; Ausarbeitung/Best Practices als Aufgabe eingebracht in das Interoperabilitätsforum | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
237 | 4.3.3 | Negativ, kleineres Problem | Christof Gessner | gematik | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
(weitere Erläuterungen zu den Inhalten und ggf. externen Referenzen in Bezug auf Signierfähigkeit) | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Externe Referenz hinzugefügt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
238 | 8.6, 8.7 | Negativ, schwerwiegend | Christof Gessner | gematik | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Erläuterung der Bedeutung in Bezug auf Signatur im Rahmen der deutschen Rechtslage (SigG, digitale Signatur). Abgrenzung, sofern diese Inhalte hier nicht behandelt werden. | Diese beiden Einträge bedürfen zusätzlicher Erläuterung. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Signatur liegen außerhalb dieses Leitfadens, siehe Abschnitt Abgrenzung; Ausarbeitung/Best Practices als Aufgabe eingebracht in das Interoperabilitätsforum | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
239 | 4.3.6 | Negativ, kleineres Problem | Christof Gessner | gematik | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Lesbarkeit | (hier fehlen Angaben, wie die Lesbarkeit in Bezug auf die Daten im Header zu verstehen ist) | Die Anwendung von Stylesheets auf die header-Information sollte angesprochen werden. | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Text ergänzt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
240 | 6.3.3.1.8 | Negativ, schwerwiegend | Christof Gessner | gematik | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Der Empfänger ist nicht verpflichtet, den Text tatsächlich so visuell darzustellen, wie es die Vorschläge andeuten. | … im Rahmen einer digitalen Signatur sind darüber hinaus weitere Vereinbarungen erforderlich. | Sofern ein mit Stylesheet visualisiertes CDA signiert werden soll, ist diese Formulierung nicht ausreichend | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Signatur liegen außerhalb dieses Leitfadens, siehe Abschnitt Abgrenzung; Ausarbeitung/Best Practices als Aufgabe eingebracht in das Interoperabilitätsforum | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
241 | 1.6 | Vorschlag | Christof Gessner | gematik | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
...Stylesheets…frei verfügbar… | (Hinweis auf kürzlich diskutierte Sicherheitsrisiken im Zshg. mit Stylesheets) | An dieser oder anderer Stelle sollte auf mögliche Risiken bzw. deren Mitigation verwiesen werden. Andernfalls Abgrenzung von Visualisierung. | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Weitergeleitet | zu diskutieren | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
242 | Allgemein | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Keine Legende zu den Conformitäten in den Tabellen. Das Kapitel 4.5. "Konformität" behandelt ebenfalls etwas anderes. | Einfügen eines Kapitels um die verschiedenen Konformitäten "M", "R", "O", etc. zu erklären. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Weitergeleitet | In dem Kapitel Konformität geht es um die ganzheitliche Betrachtung von CDA-konformen Dokumenten. Gefordert wird hier die Erklärung des Konformanzkonstruktes Optionalität, was eigentlich vorausgesetzt wird. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
243 | S44, Z54-55 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
setID und versionNumber sind "R" | Änderung entwender auf O (mit einer Klausel, dass entweder beide da sein sollen oder keines) im Falle, dass man die Anwendung des Konzepts "Versionsnummer" offen lassen möchte. Andernfalls das Konzept der Versionsnummer erzwingen durch "M". In jedem Fall sollte man eine diesbezügliche Erläuterung mit anführen. | In der Praxis ist es so, dass man bereits bei der ersten Version eines Dokuments entscheiden muss, ob man das Konzept "Versionsnummer" verwenden möchte oder nicht (und damit, ob man diese beiden Felder angibt oder nicht), da man schon hier eine eindeutige setId festlegen muss, die dann auch für die Folgeversionen gilt. Wird demnach das Konzept nicht verwendet, sollten die beiden Elemente eher weggelassen als nullFlavored werden. | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | In der neuen Fassung der Spezifikation sind dort Konformanzangaben mehr enthalten. In der Template-Sepzifikation ist setId und versionNumber mandatory. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
244 | S45, Tabelle | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Es gibt keine Spalte in der Tabelle, die anzeigt welche Detailspezifikation hier referenziert wird. Lediglich ein Klick bringt den Leser zur entsprechenden Stelle im ArtDecor, und damit zum richtigen Template | Spalte einfügen, um das jeweilige Kapitel im Leitfaden zu referenzieren und darauf springen zu können. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | die Einträge sind bereits Hyperlinks auf die entsprechenden Stellen im Text. Dauz muss man mit der Maus darüberfahren. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
245 | S45, Tabelle | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Unstrukturierter-/Strukturierter Body | Es wird formal nicht festgelegt, dass diese beiden Varianten sich gegenseitig ausschließen. Nur der abschließende Satz erläutert dies und verwendet sogar das Wort "somit" (welches impliziert, dass es eine formale Regel gibt, die aber nirgends steht) | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Zusätzliche Information in einer Hinweisbox. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
246 | S45, Tabelle | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Manche Werte der 4. Spalte stehen nicht in derselben Zeile wie die zugehörigen Werte der 1-3. Spalte | Ist das ein Fehler oder versucht man damit etwas auszudrücken? Falls ja, dann erschließt sich der Grund nicht, bitte eine Erläuterung als Bemerkung anführen. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Diese Einträge referenzieren Abschnitte, die in der ELGA-Sepzifkation vorkommen und kein direktes Äquivalent in unserer Spezifikation haben. Zusätzlicher Hinweis in der Einleitung. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
247 | S45, Tabelle | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Text "ELGA: ärztliche Anamnese" | Korrekter Name: "Anamnese". Evtl. ändern in "Anamnese" (ärztlich) | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
248 | S45, Tabelle | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Text "ELGA: erhobene Befunde" | Korrekter Name: "Erhobene Befunde" | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
249 | S45, Tabelle | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Text "ELGA: Entlassdiagnose" | Korrekter Name: "Diagnose bei Entlassung" | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
250 | S45, Tabelle | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Text "ELGA: Allergien, Unverträglichkeiten" | Korrekter Name: "Allergien, Unverträglichkeiten und Risiken" | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
251 | S45, Tabelle | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Text "ELGA: weitere Maßnahmen" | Korrekter Name: "Weitere empfohlene Maßnahmen" | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
252 | S45, Tabelle | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Text "ELGA: durchgeführte Maßnahmen" | Korrekter Name: "Durchgeführte Maßnahmen" | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
253 | S45, Tabelle | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Text "ELGA: letzte Medikation" | Korrekter Name: "Letzte Medikation" | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
254 | S45, Tabelle | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Text "ELGA: empfohlene Medikation" | Korrekter Name: "Empfohlene Medikation" | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
255 | S45, Tabelle | Negativ, kleineres Problem | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Text "ELGA: empfohlene Medikation" | Die Spalten 2 und 3 haben keine Werte. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht relevant | Sie haben auch keine Entsprechung im deutschen Arztbrief | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
256 | S45, Tabelle | Negativ, schwerwiegend | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Text "ELGA: verabreichte Medikation während des Aufenthalts" | Sektionen "Jetzige Medikation" und "Medikation bei Entlassung" zusammenführen. | Die ELGA Sektion "Verabreichte Medikation während des Aufenthalts" soll jene Medikation enthalten, die während des Aufenthalts verabreicht wurde. "Medikation bei Entlassung" würde der ELGA Sektion "Letzte Medikation"entsprechen und ist damit gleich wie "Jetzige Medikation". Außerdem: Korrekter Name: "Verabreichte Medikation während des Aufenthalts" | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | "Verabreichte Medikation während des Aufenthalts" betrifft offentsichtlich nur das Krankenhaus; "Medikation bei Entlassung" ist nicht immer "Jetzige Medikation"; Name korrigiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
257 | S45, Tabelle | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Text: "ELGA: Aufenthaltszusammenfassung" | Korrekter Name: "Zusammenfassung des Aufenthalts" | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
258 | S45, Tabelle | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Text: "ELGA: abschließende Bemerkungen" | Korrekter Name: "Abschließende Bemerkungen" | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
259 | S45, Tabelle | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Text: "ELGA: Beilagen" | Hinzufügen einer Bemerkung, dass bei der ELGA Sektion "Beilagen" externe Dokumente nicht referenziert, sondern vielmehr als Base64 eingebettet werden. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
260 | S45, Tabelle | Negativ, kleineres Problem | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Text: "ELGA: Patientenverfügung" | Steht in einer Zeile ohne korrespondierender Sektion in Spalte 1 | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht relevant | Sie haben auch keine Entsprechung im deutschen Arztbrief | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
261 | S45, Tabelle | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Autor: "der Autor muss eine natürliche Person sein" | Der Text klingt wie ein Constraint, die Überschrift der Spalte lautet allerdings "Kommentar". Ist das ein Constraint? Falls ja, sollte das eindeutiger dargestellt werden. | ELGA erlaubt Geräte als Autor (zb für on-demand Dokumente wie die Medikationsliste) Ist zusätzlich missverständlich, da die Detailspezifikation des "Autor - Generisch" sehr wohl Geräte zulässt (Kapitel 8.2). | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Das ist ein Constraint. Das generische Template erläutert die Anforderungen auf höherer Ebene, die dann noch weiter eingechränkt werden. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
262 | S47ff | Negativ, kleineres Problem | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Kapitel "recordTarget" | Die Spezifikation für das "recordTarget" scheint im Wesentlichen das CDA Schema in diesen Bereich abzubilden, welches im Minimalfall nur die Angabe der Patienten-ID (ohne Name, etc.) erlaubt. Es sollte zumindest der Name des Patienten verpflichtend anzugeben sein. In ELGA ist der Patienten-Name [M], das Geschlecht [R] und das Geburtsdatum [R]. | Dies ist nicht optimal für die Praxis. Außerdem widerspricht es auch ein wenig der Beschreibung des Templates in dem es heißt: "... umfasst neben der Identifikation und dem Namen, Adressen etc. auch optionale Zusatzangaben ..." | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Ist angepasst | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
263 | S52 | Negativ, schwerwiegend | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Das XML Beispiel für "Autor ist ein Gerät" enthält kein <time> Element, welches verpflichtend ist | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Hinzugefügt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
264 | S73 | Negativ, kleineres Problem | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Beschreibung des "Angehörigen" ist dieselbe wie beim "Einweisenden Arzt" (Copy&Paste Fehler?) | Beschreibung richtigstellen | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Geändert, falsche Transklusion | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
265 | S73 | Negativ, kleineres Problem | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
time Element wird definiert, zur Angabe eines Einweisungsdatums. Dieses ist beim "Angehörigen" aber nicht angebracht. | Time-Element Constraint entfernen | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Geändert, falsche Transklusion | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
266 | S75 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Text "Hier ist immer ein Quartalsende angegeben (MM/JJ) => YYYYMMDD" | Wort "immer" ist missverständlich, da die Kard 0..1 ist. Bitte umformulieren. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
267 | S76 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Text "Schematron assert" | Ist das Teil der Spezifikation oder ein Export-Fehler aus dem ArtDecor? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Zur zukünftigen Verwendung | Das ist der Hinweis, dass es sich hier um eine schamtron-basierte Regel handelt, die asu drei Teilen besteht. Vielleicht müsste man das noch einmal separat erläutern… | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
268 | S82 | Negativ, kleineres Problem | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Unstrukturierter Body mit referenziertem Dokument: @representation ist mit Kard 0..1 definiert und "muss B64 sein" | In diesem Fall muss @representation weggelassen werden (0..0) | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Angepasst | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
269 | S83 | Negativ, kleineres Problem | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Unstrukturierter Body mit referenziertem Dokument: @representation ist mit Kard 0..1 definiert und "muss B64 sein" | In diesem Fall muss @representation angegeben werden (1..1). Außerdem sollte <reference> in diesem Fall wohl 0..0 sein | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Angepasst | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
270 | S84 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Der Sektionstitel des Kapitels 9.3 ist "Fragestellung", aber der Template-Name ist "Grund der Überweisung". Auch im weiteren Verlauf des Kapitels wird von "Grund der Überweisung" gesprochen. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
271 | S85 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Anmerkung spricht von einem Code "X-RFR", aber dieser kommt gar nicht vor | Anmerkung entfernen | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
272 | S85 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Beschreibung der Sektion ist lediglich die Wiederholung des Sektions-Titels und keine wirkliche Beschreibung der Sektion | Eine ausführlichere Beschreibung der Sektion angeben. | "Anamnese" ist eigentlich ein Überbegriff über verschiedene Arten der Ananmese, sie steht aber auf einer Ebene mit den anderen Anmnesen (Frühere Erkrankungen, Familienanamnese). Durch diese strukturelle Schwäche verstärkt ist in diesem Fall ist nicht klar, was genau mit "Jetzige Anamnese" gemeint ist. | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Der Titel ist jetzt in Pluralform, was die unterschiedlichen Anamnesetypen verdetulichen soll, die dann als Unterpunkte angeführt werden. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
273 | S86 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Beschreibung der Sektion ist lediglich die Wiederholung des Sektions-Titels und keine wirkliche Beschreibung der Sektion | Obwohl der Titel der Sektion in diesem Fall den Inhalt ziemlich klar ausdrückt, wäre eine ausführlichere Beschreibung an dieser Stelle gut. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | "Liste der bisherigen Krankheiten des Patienten" | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
274 | S87 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Beschreibung der Sektion ist lediglich die Wiederholung des Sektions-Titels und keine wirkliche Beschreibung der Sektion | Obwohl der Titel der Sektion in diesem Fall den Inhalt ziemlich klar ausdrückt, wäre eine ausführlichere Beschreibung an dieser Stelle gut. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | "Angaben über Erkrankungen macht, die bei Verwandten des Patienten aufgetreten sind" | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
275 | S88 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Beschreibung der Sektion ist lediglich die Wiederholung des Sektions-Titels und keine wirkliche Beschreibung der Sektion | Eine ausführlichere Beschreibung der Sektion angeben. | Es ist nicht klar, ob diese Sektion nur die "Titel" der erhobenen Befunde beinhalten soll (wie im angegebenen Beispiel), oder die Befunde selbst. In ELGA ist dieser Bereich ausführlich beschrieben (mit Untersektionen), mit den entsprechenden Vermerken, wann Befunde vollständig eingebettet werden müssen | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Zur zukünftigen Verwendung | Das lassen wir an dieser Stelle bewusst offen. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
276 | S90 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Aufnahmediagnose: Die Beschreibung der Sektion ist lediglich die Wiederholung des Sektions-Titels und keine wirkliche Beschreibung der Sektion | Obwohl der Titel der Sektion in diesem Fall den Inhalt ziemlich klar ausdrückt, wäre eine ausführlichere Beschreibung an dieser Stelle gut. | In ELGA wurde die Aufnahmediagnose durch den "Aufnahmegrund" (hier: Fragestellung) ersetzt. Was genau ist nun der Unterschied von "Aufnahmediagnose" zu "Fragestellung"? | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Eine "Aufnahmediagnsoe" ist eine Diagnose, die während der Aufnahme gestellt wird, das ist nicht die Fragestellung der Überweisung. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
277 | S90 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Entlassungsdiagnose: Die Beschreibung der Sektion ist lediglich die Wiederholung des Sektions-Titels und keine wirkliche Beschreibung der Sektion | Obwohl der Titel der Sektion in diesem Fall den Inhalt ziemlich klar ausdrückt, wäre eine ausführlichere Beschreibung an dieser Stelle gut. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | "Diagnose, mit der der Patient entlassen wurde" | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
278 | S91 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Kapitel 9.7.3 | Dieses Kapitel kommt an dieser Stelle völlig unerwartet. Die Beschreibung deutet darauf hin, dass es sich um ein allgemeines Kapitel zur "Nutzung von Tabellen" handelt, dann ist es aber an der falschen Position. Der Inhalt des Beispiels bezieht sich aber auf das Vorkapitel "Diagnosen". Falls es dort dazugehört, ist es ebenfalls falsch angeordnet und es fehlt eine Referenz darauf. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Titel ändern: extformatierung für Diagnosen (auf Level 1) Die Textformatierung wird schon weiter oben in der Spezifikation erläutert. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
279 | S92 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Sektion: "Allergien, Unverträglichkeiten, Risiken" | Die Abschnitte "Allergien, Unversträglichkeiten" und "Risiken" sind in der Tabelle auf Seite 45 getrennt. Hier jedoch gibt es nur eine gesamte Sektion dafür. Das ist missverständlich. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | zusammengeführt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
280 | S92 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Beschreibung der Sektion ist lediglich die Wiederholung des Sektions-Titels und keine wirkliche Beschreibung der Sektion | Obwohl der Titel der Sektion in diesem Fall den Inhalt ziemlich klar ausdrückt, wäre eine ausführlichere Beschreibung an dieser Stelle gut. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | "Beschreibung der Allergien, Unverträglichkeiten und Risiken und deren beobachteten Nebenwirkungen, sowie sonstiger Risiken." | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
281 | S93 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Beschreibung der Sektion ist lediglich die Wiederholung des Sektions-Titels und keine wirkliche Beschreibung der Sektion | Obwohl der Titel der Sektion in diesem Fall den Inhalt ziemlich klar ausdrückt, wäre eine ausführlichere Beschreibung an dieser Stelle gut. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | "Erhobene Medikation bei Aufnahme des Patienten." | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
282 | S94 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Beschreibung der Sektion ist lediglich die Wiederholung des Sektions-Titels und keine wirkliche Beschreibung der Sektion | Obwohl der Titel der Sektion in diesem Fall den Inhalt ziemlich klar ausdrückt, wäre eine ausführlichere Beschreibung an dieser Stelle gut. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | "Sämtliche verabreichte Medikation während des Aufenthalts" | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
283 | S92-94 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Medikationssektionen allgemein. | Die Namen der Sektionen in Tabelle auf Seite 45 passen tw. nicht mit hier beschriebenen Medikationssektionen zusammen. Hier fehlt der Zusammenhang. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Titel der übergeordneten Sektion ändern: Medikationen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
284 | S95 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Beschreibung der Sektion ist lediglich die Wiederholung des Sektions-Titels und keine wirkliche Beschreibung der Sektion | Obwohl der Titel der Sektion in diesem Fall den Inhalt ziemlich klar ausdrückt, wäre eine ausführlichere Beschreibung an dieser Stelle gut. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | "Kurzbeschreibung sämtlicher während des Aufenthalts durch-geführten Maßnahmen, wie OPs, Eingriffe oder sonstige Maßnahmen." | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
285 | S95 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Prozeduren und Maßnahmen | Der Name der Sektion findet sich nicht in Tabelle auf Seite 45. Hier fehlt der Zusammenhang. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | in der Liste aufnehmen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
286 | S97 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Beschreibung der Sektion ist lediglich die Wiederholung des Sektions-Titels und keine wirkliche Beschreibung der Sektion | Obwohl der Titel der Sektion in diesem Fall den Inhalt ziemlich klar ausdrückt, wäre eine ausführlichere Beschreibung an dieser Stelle gut. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | "Empfehlung für weitere noch durchzuführende Maßnahmen" | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
287 | S98 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Beschreibung der Sektion ist lediglich die Wiederholung des Sektions-Titels und keine wirkliche Beschreibung der Sektion | Obwohl der Titel der Sektion in diesem Fall den Inhalt ziemlich klar ausdrückt, wäre eine ausführlichere Beschreibung an dieser Stelle gut. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | "Ein am Ende des Briefes formulierter Freitext entsprechend einer Grußformel. zB.: mit kollegialen Grüßen" | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
288 | S99 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Beschreibung der Sektion enthält den Satz: "Diese Sektion sollte ein Entry enthalten" | Das impliziert, dass nur 1 Entry angegeben werden darf, es sollten aber beliebig viele Beilagen möglich sein. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | "(mind.)" ergänzen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
289 | s98 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Hier wird ein LOINC Code "X-…" verwendet | Es fehlt allerdings der üblich Hinweis, dass "X-…" Codes bald durch richtige ersetzt werden. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
290 | s99 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Hier wird ein LOINC Code "X-…" verwendet | Es fehlt allerdings der üblich Hinweis, dass "X-…" Codes bald durch richtige ersetzt werden. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
291 | S101ff | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Gesamtes Kapitel "Diagnose-Entry". | Es wird empfohlen, die Diagnose auf der Basis des IHE PCC Concern Entry (1.3.6.1.4.1.19376.1.5.3.1.4.5.1) bzw. IHE PCC Problem Concern Entry (1.3.6.1.4.1.19376.1.5.3.1.4.5.2) aufzubauen. ELGA hat diesen Weg gewählt. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Weitergeleitet | Das ist zu diskutieren: Grundsätzlich lassen sich mit PCC Concern Entry auch Diagnosen übermitteln. Es ist aber nicht ganz dasselbe. Dazu kommen die zusätzlichen Anfordeurngen bzw. Details, die wir hinterlegt haben. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
292 | S120 und S124 | Negativ, kleineres Problem | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Satz: "Eines der Elemente LabeledDrug oder Material muss vorhanden sein" bzw. Kapitel 11.2.6.3, wo LabeledDrug verwendet wird | Obwohl dies nicht prominent aus der Spezifikation hervorgeht, scheint das Template auf dem IHE PCC Medication template (1.3.6.1.4.1.19376.1.5.3.1.4.7) zu basieren. Dies geht jedenfalls aus dem Vermerk "genutzte Templates" in Tabelle auf Seite 115 hervor. Wenn dem so ist, dann ist nur "Material" erlaubt. Siehe IHE PCC Product Entry (1.3.6.1.4.1.19376.1.5.3.1.4.7.2) template specification. Außerdem sollte dieser Zusammenhang mit IHE PCC als parent deutlicher hervorgehoben werden (kann äußerst leicht übersehen werden). | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Medikation-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
293 | S124 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Kapitel "Massnahme Entry" | Es wird empfohlen, die Massnahmen auf der Basis des IHE PCC Procedure Entry (1.3.6.1.4.1.19376.1.5.3.1.4.19) aufzubauen. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Weitergeleitet | In der IHE Spezifikation ist nicht viel enthalten. Eskönnte hier überlegt werden, inwieweit man unsere Vorgabe als Spezialisierung darstellt!? | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
294 | S128 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Kapitel "Externe Referenzen" | Es wird empfohlen, die externen Referenzen auf der Basis des IHE PCC External References Entry (1.3.6.1.4.1.19376.1.5.3.1.4.4) aufzubauen. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Weitergeleitet | Ist zu diskutieren. Derzeit nutzen wir die Klasse observationMEdia anstelle von reference! | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
295 | S130 | Vorschlag | Jürgen Brandstätter, Stefan Sabutsch | HL7 Austria | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Kapitel "Diagnose-Entries" | Es ist nicht klar, in wie weit sich dieses Kapitel von Kapitel 11.1 "ICD Diagnose Entry" abgrenzt. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Wird entfernt und nur als Referenz zwecks Zusatzinformation aufgeführt. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
296 | 4.4.2 S.22 Zeile 12 | Tippfehler | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
beziechnet | bezeichnet | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
297 | 6. S.26 Zeile 50 | Negativ, kleineres Problem | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Das statische Modell umfasst . den Header mit einer zentrale Klasse ClinicalDocument sowie einer Reihe von assozierten Header- Klassen (Patient, Autor, Empfanger, etc.) und | ClinicalDocument ist nicht nur Teil des Headers | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Satz umgedreht | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
298 | 6.3.1.2 S. 31 Zeile 16 | Vorschlag | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
(siehe „Level 1 bis 3 unten) | hier besser Verweis mit Kapitel-Nummer auf Abschnitt "level" | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | vgl. #152 | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
299 | 6.3.1.2 S. 31 Zeile 28 | Negativ, kleineres Problem | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Jede Sektion muss genau ein „Text"-Element enthalten, das nicht leer sein darf. | Es wird nicht klar, woraus sich dies ableitet. Im Schaubild darunter ist die Kardinalität [0..1] | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Das Schaubild wurde entfernt, die Notwendigkeit von section.text ergibt sich aus den Template-Definitionen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
300 | 6.3.1.3.1 S.32 zeile 54 | Negativ, kleineres Problem | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
6.3.1.3.1 Section.text: Text des Abschnitts (ED [0..1]) … 6.3.1.3.2 Section.title: Titel des Abschnitts (ST [0..1]) und Section.text: Text des Abschnitts (ST [1..1]) | Die beiden Überschriften widersprechen sich bei angegebenem Datentyp und Kardinalität für Section.text | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Das Schaubild wurde entfernt, der Text leicht angepasst | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
301 | 6.3.1.3.3 S.33 Zeile 8 | Negativ, kleineres Problem | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Im Beispiel…. | Hier ist kein Beispiel angegeben | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | nun: Als Beispiel | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
302 | 6.3.1.5 S.33 Zeile 62 | Negativ, kleineres Problem | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
…unterhalb der Abschnitte… | …innerhalb der Abschnitte… | Entries sind Bestandteil der sections | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Geändert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
303 | 6.3.2.2 S.34 Zeile 50 | Negativ, schwerwiegend | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Eine andere Möglichkeit der Kennlichmachung ist die Zuordnung einer Template-Identifikation. | Dies hört sich so an, als ob diese Möglichkeit (template ID) nicht zum Einsatz kommt. Im folgenden Abschnitt wird dann aber darauf verwiesen. Dies sollte ggf. umformuliert werden und die templateId auch im Beispiel aufgenommen werden. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Text ergänzt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
304 | 6.3.2.2 S.34 Zeile 50 | Tippfehler | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Kennlichmachung | Kenntlichmachung | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
305 | 6.3.2.3 S.36 zeile 59 | Negativ, kleineres Problem | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Zu dem Abschnitt kann auch eine Sprache gewählt werden, wenn diese von der für das ganze Dokument (mittels languageCode im Header, siehe dort) gewählten abweicht. Weitere Informationen finden sich bei der Beschreibung des Elements languageCode des Headers. | Dieser Teil scheint an die falsche Stelle gerutscht zu sein. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Abschnitt umgezogen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
306 | 6.3.3.3.1 S.42 Zeile 6 | Vorschlag | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Conf | Spaltentitel und mögliche Ausprägungen sollten im Dokument erläutert werden | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
307 | 6.3.3.3.2 S.42 zeile 47 | Negativ, kleineres Problem | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Obwohl Unterstützung… | Dieser Satz sollte für eine dt. Spezifikation entfernt werden. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Tabelle eh durch Value Set ersetzt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
308 | 6.3.3.3.2 S.42 zeile 59 | Kommentar allgemeiner Art | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Resolutionen | Auflösungen | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
309 | 6.3.3.3.3 S.43 Zeile 11 | Negativ, kleineres Problem | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Das darin enthaltene… | Es ist unklar, worauf sich "darin" bezieht | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Satz angepasst | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
310 | 6.3.3.3.3 S.43 Zeile 25 | Negativ, kleineres Problem | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
<value xsi:type="ED" mediaType="image/jpeg"> <reference value="left_hand_image.jpeg"/> </value> | Das Beispiel sollte korrigiert werden. Eine Referenz-Angabe nur mit einem Dateinamen (ohne URL) ist nicht möglich | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Im Beispiel ist die URL eine relative Pfadangabe, was erlaubt ist (aber wohl auch nicht best practice) | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
311 | 6.4 S.43 Zeile 36 | Kommentar allgemeiner Art | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Eine detaillierte Erläuterung findet sich im Wiki. | Diesen Satz streichen. Unten ist ein Verweis inkl. Link angegeben. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
312 | 7.1 S44 Zeile 15 | Tippfehler | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
setzen | setzt | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
313 | 7.1.0.4 S.44 zeile 35 | Tippfehler | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
eignesetzt | eingesetzt | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
314 | 7.1.0.4 S.44 zeile 35 | Vorschlag | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Bereichsangabe | Es ist hier der Hoheitsbereich gemeint, analog zu AT in Österreich? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Hoheitsangabe | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
315 | 7.1.0.5 S.45 zeile 28 | Negativ, kleineres Problem | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
der Autor muss eine natürliche Person sein | Laut S. 52 kann das auch ein Gerät sein. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Text ergänzt, mit "Author (Person)" ist hier tatsächlich nur eine natürliche Person gemeint | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
316 | 7.1.0.5 S.46 Zeile 44 | Tippfehler | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
vollständiuge | vollständige | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
317 | 9.1 S.81 Zeile 17 | Tippfehler | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
, dass | , das | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
318 | 9.1.1 S.82 Zeile 15 | Negativ, kleineres Problem | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
CONF @representation muss "B64" sein | für referenzierte Dokumente ist dies nicht korrekt | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Geändert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
319 | 9.2 S. 84 Zeile 9 | Negativ, kleineres Problem | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
@root 1 .. 1 F 1.2.276.0.76.10.3001 | templateId ist hier als 1..1 angegeben, fehlt aber im o.g. XML-Beispiel | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Geändert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
320 | 9.2 S. 84 Zeile 20 | Vorschlag | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Beispiel <code code="X-SALUT" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/> | Im Sinne der besseren Lesbarkeit könnte/sollte der DisplayName ergänzt werden | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Angepasst | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
321 | 9.3 S.85 Zeile 41 | Negativ, kleineres Problem | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Anmerkung: LOINC Codes mit einem vorangestellten X, wie hier X-RFR, werden kurzfristig durch tatsächliche numerische LOINC Codes ersetzt. | X-RFR wird nirgends im Dokument verwendet | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Weggelassen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
322 | 9.4 S.85 Zeile 46 | Negativ, kleineres Problem | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
9.4 Section: Anamnese | Dies ist irreführend, da es keine übergeordnete section "Anamnese" gibt, sondern nur die u.g. sections | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Überschrift geändert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
323 | 9.7 S.89 Zeile 60 | Negativ, kleineres Problem | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
9.7 Section: Diagnosen | Dies ist irreführend, da es keine übergeordnete section "Diagnosen" gibt, sondern nur die u.g. sections für "Aufnahmediagnose" und "Entlassdiagnose" | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Die Überschrift wird als nicht irreführend eingestuft, der Text wurde angepasst | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
324 | 9.7.3 S.91 zeile 39 | Vorschlag | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
9.7.3 Textformatierung (Level 1) | Dieses Kapitel kann entfallen, da über "6.3.3.1.2 Tabellen" abgedeckt. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | geänderter Titel, da das hier ein Beispiel für Diagnosen ist | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
325 | 9.9.1 S. 93 zeile 64 | Tippfehler | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
CONF Elementinhalt muss "Allergien, Unverträglichkeiten, Risiken" sein | copy-paste-fehler vom vorigen Kapitel | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | "Medikation bei Aufnahme" | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
326 | 9.9.3 S. 94 zeile 32 | Tippfehler | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
CONF Elementinhalt muss "Allergien, Unverträglichkeiten, Risiken" sein | copy-paste-fehler vom vorigen Kapitel | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
327 | 9.10 S. 95 zeile 41 | Tippfehler | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
In dem Abschnitt Therapie werden | In dem Abschnitt Prozeduren und Maßnahmen werden | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | |||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
328 | 9.11 S.96 zeile 39 | Kommentar allgemeiner Art | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
9.11 Section: Zusammenfassung des Aufenthalts (Epikrise) | 9.11 Epikrise (Zusammenfassung des Aufenthalts) | Da die section "Epikrise" benannt werden muss, sollte es hier "Epikrise (Zusammenfassung des Aufenthalts)" heissen. | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Angepasst | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
329 | 9.13 S.99 Zeile 15 | Kommentar allgemeiner Art | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Diese Section sollte ein Entry enthalten | Wie soll vorgegangen werden, wenn z.B. zwei oder mehr Bilder relevant sind? Dies sollte erläutert werden. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Hinweis, dass auch mehrere Entries eingefügt werden können. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
330 | 9.13 S.99 Zeile 30 | Negativ, kleineres Problem | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
<title> Anhang 1 </title> | Beispiel widerspricht der u.g. CONF-Bedingung | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Beispiel angepasst | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
331 | 12.2 S.133 Zeile 61 | Negativ, kleineres Problem | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
oder hexadezimal | Was ist damit gemeint? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Satz geändert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
332 | 13.1.1.1 | Kommentar allgemeiner Art | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Beispiele in den Storyboards sollten die XML-Darstellung zeigen und nicht den gerenderten Inhalt | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Storyboards zeigen immer nur den gerenderten Inhalt, für XML-Beispiele gibt es die XML-Materialien | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
333 | 13.2 S.143 zeile 36 | Negativ, kleineres Problem | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
13.2 Anamnesekategorien | Die Angaben in diesem Kapitel scheinen im Widerspruch zu "9.4 Section: Anamnese" zu stehen. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Der Paragraf wurde entsprechend geändert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
334 | 14.1 S.144 zeile 42 | Kommentar allgemeiner Art | Michael Hofer | iSOFT Health GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
vollständiges Beispiel | Link sollte deutlicher erkennbar sein und URL sollte für ggf. Ausdruck mit angegeben sein | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Links werden besser sichtbar gemacht | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
335 | S. 10, Zeile 22 | Kommentar allgemeiner Art | Lars Treinat | ZTG GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
"Muss hier noch ein Hinweis auf die Mitgliedschaft hin, wenn die daraus entstehende Software endgeltlich vertrieben wird?" | Bitte ggf. noch ausformulieren. | Dieser Hinweis sieht irgendwie unfertig aus. | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | entfernen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
336 | S. 11, Zeile 22 | Kommentar allgemeiner Art | Lars Treinat | ZTG GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
"Genauer definieren, was der Arztbrief eigentlich ist und was er können soll!" | Bitte ggf. noch ausformulieren. Denkbar wäre: "Der elektronische Arztbrief soll über die menschenlesbare Darstellung von Behandlungsinformationen hinaus, die Grundlage für eine (teil-)automatisierte Datenübernahme in die Primärsysteme der an der Behandlung beteiligten Ärzte und Institutionen bilden." | Dieser Hinweis sieht irgendwie unfertig aus. | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Hinweis entfernen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
337 | S. 12, Zeile 54 | Kommentar allgemeiner Art | Lars Treinat | ZTG GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
"Liste prüfen!" | Falls nicht mehr benötigt, löschen. | Dieser Hinweis sieht irgendwie unfertig aus. | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Hinweis entfernen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
338 | S. 56, Zeile 42 | Kommentar allgemeiner Art | Lars Treinat | ZTG GmbH | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
"1.2.276.0.76.10.1011 Labormeldung nach §7 Abs. 1, 2 und 3 IfSG 2014‑07‑13" | Bitte prüfen, ob diese Unterscheidung sinnvoll ist. | Hier wird auf zwei Subtypen von Labormeldung referenziert. Wenn man diese differenziern will, sollten diese zwei Subtypen unterschieden werden in "Labormeldung nach § 7 Abs. 1 und 2" (namentliche Meldung an das Gesundheitsamt) und "Meldung nach § 7 Abs. 3 IfSG" (nicht-namentliche Meldung an das RKI). | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | Dies wird über die Templates in ART-DECOR organisiert. Die Nennung bedeutet, dass das Template auch in den Labormeldungen Verwendung findet. Hierdurch soll der Aspekt der Wiederverwendung von Templates verdeutlicht werden. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
339 | Kap. 2.3 | Negativ, kleineres Problem | Dr. Rainer Fehling | Kassenärztliche Vereinigung Westfalen-Lippe | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Hierbei kann man zwei Gegenpole beobachten. | Diesen Gegensatz sehe ich nicht: Dient nicht jeder übertragene Arztbrief im Endeffekt der Mensch-Mensch-Kommunikation? Definieren nicht z.B. alle CodierSysteme "nur" ein Vokabular (Terminologie), das für eine sichere (eindeutige) Kommunikation insb. zwischen Personen, die in unterschiedlichen Kontexten agieren, unbedingt notwendig ist? | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Was eine "sichere (eindeutige)" Kommunikation ist, bleibt kontextabhängig, zu mindest in der menschlichen kommunikation. Es geht in diesem Abschnitt um das Spannungsfeld, dass sich für Interoperabiltät auftut und das man mit entsprechenden Methodiken effizient und "sicher (eindeutig)" abbilden kann/muss. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
340 | Kap. 5.1, Liste Transportwege | Negativ, kleineres Problem | Dr. Rainer Fehling | Kassenärztliche Vereinigung Westfalen-Lippe | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
▪ D2D ▪ FTP | ▪ D2D ▪ KV-CONNECT ▪ FTP | D2D wird im Laufe des Jahres 2015 vollständig durch KV-CONNECT abgelöst werden | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Ergänzung im Text | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
341 | Kap. 8.1 | Negativ, kleineres Problem | Dr. Rainer Fehling | Kassenärztliche Vereinigung Westfalen-Lippe | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
<id root="1.2.276.0.76.4.5.100400853" extension="8003004447"/> | <id root="1.2.276.0.76.4.8" extension="8003004447"/> | Wenn ich das richtig verstehe, wird im Bspl. die alte KVK-Nr. übertragen; heute ist für gesetzlich Versicherte aber die eGK-Nr. zu nutzen. -- Diese sollte auch im Standardbeispiel enthalten sein. Siehe auch HL7-Dokument http://www.hl7.de/download/documents/vd-082005/Versichertendaten_Leitfaden-v7.pdf, S. 17 (Allerdings: die geforderte eGK-Nr. muss nicht zwingend als ID dienen.) | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Beispiel korrigiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
342 | Kap. 8.1, Maximal-Beispiel | Negativ, kleineres Problem | Dr. Rainer Fehling | Kassenärztliche Vereinigung Westfalen-Lippe | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
<religiousAffiliationCode code="" displayName="" codeSystem=""/> | Nicht-leeres Beispiel wählen | Das Schema des (alten) vhitg-Arztbriefs verbietet hier einen leeren Eintrag. Wurde dies bewusst geändert, oder ist nur das Beispiel unglücklich gewählt? | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Beispiel war unglücklich, nun ist es glücklich | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
343 | Kap. 8.1, Maximal-Beispiel | Negativ, kleineres Problem | Dr. Rainer Fehling | Kassenärztliche Vereinigung Westfalen-Lippe | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
<preferenceInd>true</preferenceInd> | <preferenceInd value="true"/> | Die andere Schreibweise widerspricht dem "alten" Schema. Bitte Schema nur ändern, wo dringend notwendig, damit Arztbriefe nach vhitg unverändert genutzt werden können (z.B. im KV-CONNECT-Umfeld). | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Beispiel korrigiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
344 | Kap. 8.3ff | Negativ, kleineres Problem | Dr. Rainer Fehling | Kassenärztliche Vereinigung Westfalen-Lippe | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
LANR (lebenslange Arztnummer) und BSNR (Betriebsstättennr) ergänzen. | Im Bereich der Niedergelassenen werden die meisten Dokumente mit einem Peronalienfeld mit vorgegebenem Inhalt versehen. Die Angaben dieses Feldes sollten auch im vorliegenden Leitfaden vorgesehen werden. Dazu gehören u.a. die BSNR und die LANR. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Ein entsprechender Paragraf wurde hinzugefügt: Identifikationen | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
345 | Kap. 8.5 | Tippfehler | Dr. Rainer Fehling | Kassenärztliche Vereinigung Westfalen-Lippe | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
displayName="discharging physican" | 2 Alternativen: A. displayName="discharging physician" B. displayName="Entlassender Arzt" | A. Tippfehler korrigieren B. Warum angezeigte Bezeichnung nicht auf Deutsch? | |||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen mit Modifikationen | A: korrigiert B: der Originaltext ist in englisch | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
346 | Kap. 8.15 | Negativ, kleineres Problem | Dr. Rainer Fehling | Kassenärztliche Vereinigung Westfalen-Lippe | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
eGK-Versicherten-Nr. im Beispiel nutzen | Auch hier fehlt im Bspl. die eGK-Versicherten-Nr. | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Im Beispiel hinzugefügt | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
347 | Kap. 9.1 | Kommentar allgemeiner Art | Dr. Rainer Fehling | Kassenärztliche Vereinigung Westfalen-Lippe | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Section: Non-XML-Body | Ein Non-XML-Body mag interessant sein in Umgebungen, in denen es sinnvoll/wichtig ist, alle Dokumente in CDA-Form zu halten. Dies ist bei den Niedergelassenen (-> KV-CONNECT) nicht der Fall; hier können/sollten un-strukturierte Dokus (PDF) auch so bleiben, so dass eine Einbettung nicht weiterhilft. - 9.1.1: Eine Referenzierung könnte allerdings auch im Niedergelassenenbereich helfen, die Informations-Übermittlung zu vereinheitlichen (ohne die Eigenständigkeit des z.B. PDF zu beeinflussen). | ||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht relevant | Diese Umsetzungsmöglichkeit ist nach langer Diskussion aufgenommen worden, um den Herstellern eine Chance zu geben, für die eine direkte vollständige Umsetzung in Sektionen nicht möglich ist. | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
348 | Kap. 9 | Kommentar allgemeiner Art | Dr. Rainer Fehling | Kassenärztliche Vereinigung Westfalen-Lippe | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Derzeit werden an verschiedenen Stellen (z.B. in NRW unter Führung des MGEPA) Standards für den Informationsaustausch im Rahmen des Überleitungsmanagements diskutiert. In der Entlassdokumentation geht es dabei immer auch um die "weitere Versorgung" inkl. weiterer Behandlung, empfohlener Pflegeort, Datum der Reha, …. Die Abbildung dieser Section kann ich im vorliegenden Leitfaden nicht erkennen. Falsch? Ergänzbar? | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Ein Dokument zum Überleitungsmanagement ist in Vorbereitung, es macht Gebrauch von Abschnitten aus dem Arztbrief, ist aber eine eigenständige Dokumenten-Definition | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
349 | Allgemein | Vorschlag | Sylvia Thun | HS Niederrhein | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Können wir ein Beispiel für OPS-Kodierung von Prozeduren beifügen? Das wird üblicherweise im Arztbrief auch so gemacht. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Prozeduren-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
350 | Allgemein | Vorschlag | Sylvia Thun | HS Niederrhein | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Bei den Allergien würde ich auch gerne eine Kodierung mit Alpha-ID oder unseres eigenen Allergie-Value Set sehen. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Zur zukünftigen Verwendung | Kodierte Allergien sind zurzeit noch nicht aufgenommen und sollen bei den entsprechenden Entries berücksichtigt werden | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
351 | Allgemein | Vorschlag | Sylvia Thun | HS Niederrhein | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Lokalisation der Diagnose hat Snomed Kodes. Die sollten wir vermeiden bzw. dick in rot die Verwendung untersagen. Lt. IHTSDO ist es NICHT gestattet im Rahmen von HL7 Snomed Kodes zu nutzen. | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Diagnose-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
352 | Allgemein | Vorschlag | Norbert Sigmond | DIMDI | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Die Beispiele und die Referenzen (Klassifikationen ICD, OPS, ATC und zugehörige OIDs) sollten aktualisiert bzw. an die aktuell gültigen Klassifikationen angepaßt werden (2015 statt 2004/2006 etc.) | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Diagnose-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
353 | Allgemein | Vorschlag | Norbert Sigmond | DIMDI | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Kode usw. wird überall mit C geschrieben. Bei uns wird dies üblicherweise mit “k” geschrieben, ebenso auch in den DKR (Deutschen Kodierrichtlinien) der deutschen Selbstverwaltung | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Nicht angenommen | Laut Duden sind BEIDE Schreibweisen erlaubt, zB codieren: von Duden empfohlene Schreibung: codieren Alternative Schreibung: kodieren | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
354 | Allgemein | Vorschlag | Norbert Sigmond | DIMDI | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Es ist kein Datenfeld für die Alpha-ID vorgesehen. Sollte eines ergänzt werden, damit Diagnosen auch über die Alpha-ID statt nur über die ICD beschrieben werden können? | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Diagnose-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
355 | Allgemein | Vorschlag | Norbert Sigmond | DIMDI | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Wie ist es mit Orpha-Kodes? Sollte dafür ein optionales Datenfeld vorgesehen werden? Diese werden zurzeit über ein DIMDI-Projekt mit Alpha-ID-Einträgen verknüpft. Weitere Informationen zum Projekt “Seltene Erkrankungen” finden Sie unter: www.dimdi.de/dynamic/de/klassi/downloadcenter/alpha-id/seltene-erkrankungen/, www.dimdi.de/static/de/klassi/aktuelles/news_0137.html, www.dimdi.de/static/de/klassi/aktuelles/news_0376.html | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Warten auf Information von anderer Arbeitsgruppe | Diagnose-Teil ist nun ausgelagert und wird separat diskutiert | ||||
ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
356 | Allgemein | Vorschlag | Dr. med. Christian Herrmann | KRH Klinikum Region Hannover: | |
Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
Wünschenswert wäre aus meiner Sicht ein möglichst streng gehaltenes XML Schema welches als Schiedsrichter fungieren könnte. Ist geplant so etwas auch zu entwickeln? Wäre dieses Thema etwas für die Abstimmung und Kommentare? | |||||
Reconcile | Entscheidung | Kommentar | Abstimmung | ||
Angenommen | Im Rahmen dieses Leitfadens sind so geannnte Schematrons veröffentlicht, die auf den Templates basieren und die neben der W3C Schema Validierung eine strilkte Validierung von Arztbrief-Instanzen ermöglichen |