Kommentare und Auflösungen zum Abstimmungsverfahren Patiententeilnehmerverzeichnis

Stand: 10. Juni 2016

Auszählung (Tally)
Anzahl Kommentare	11
Angenommen	6
Angenommen mit Modifikationen	4
Nicht angenommen	1
Nicht relevant	0
Zur zukünftigen Verwendung	0
Weitergeleitet	0
Warten auf Information vom Antragsteller	0
Warten auf Information von anderer Arbeitsgruppe	0
Unbearbeitet	0

 

ID	Referenz	Typ	Antragsteller	Organisation	Im Namen von
1	3 Struktureller Aufbau
	Vorschlag	Christof Gessner	MxDx Medizinische Informatik
Kommentar	Existierende Formulierung	Vorgeschlagene Änderung	Begründung
	Das Patiententeilnahmeverzeichnis ist als Structured Document entworfen.		Bitte Verweis auf Definition oder Standard angeben.
Reconcile	Entscheidung	Kommentar			Abstimmung
	Angenommen	Es wird der Link zum genannten Produkt mit aufgenommen
ID	Referenz	Typ	Antragsteller	Organisation	Im Namen von
2	"3.2"	Tippfehler	Christof Gessner	MxDx Medizinische Informatik
Kommentar	Existierende Formulierung	Vorgeschlagene Änderung	Begründung
	bekannt Komponenten	bekannte Komponenten
Reconcile	Entscheidung	Kommentar			Abstimmung
	Angenommen
ID	Referenz	Typ	Antragsteller	Organisation	Im Namen von
3	author/assignedAuthor/code	Vorschlag	Christof Gessner	MxDx Medizinische Informatik
Kommentar	Existierende Formulierung	Vorgeschlagene Änderung	Begründung
			Angabe eines Codesystems erforderlich?
Reconcile	Entscheidung	Kommentar			Abstimmung
	Angenommen	Ein Code anzugeben ist nicht notwendig
ID	Referenz	Typ	Antragsteller	Organisation	Im Namen von
4	informationRecipient/@typeCode	Vorschlag	Christof Gessner	MxDx Medizinische Informatik
Kommentar	Existierende Formulierung	Vorgeschlagene Änderung	Begründung
			Erläuterung der Bedeutungen der beiden Codes?
Reconcile	Entscheidung	Kommentar			Abstimmung
	Nicht angenommen	Steht schon in der Beschreibung des Templates und auch angedeutet in der Beschreibung des Elements
ID	Referenz	Typ	Antragsteller	Organisation	Im Namen von
5	1.2.276.0.76.10.4081
	Vorschlag	Christof Gessner	MxDx Medizinische Informatik
Kommentar	Existierende Formulierung	Vorgeschlagene Änderung	Begründung
	Vertrags-Type (kodiert)		Angabe eines Codesystems erforderlich?
Reconcile	Entscheidung	Kommentar			Abstimmung
	Angenommen	Ja, es sollte ein Code angegeben werden. Die nähere Nutzung unterliegt einer Profilierung. Wenn kein Code bekannt ist, dann auch nullFlavor angegeben werden.
ID	Referenz	Typ	Antragsteller	Organisation	Im Namen von
6	8.2.4 Contract Participant Reasoncode
	Vorschlag	Christof Gessner	MxDx Medizinische Informatik
Kommentar	Existierende Formulierung	Vorgeschlagene Änderung	Begründung
	Hier werden die kodierten Gründe genannt (werden)		hinweis auf Abstimmungsprozess einfügen
Reconcile	Entscheidung	Kommentar			Abstimmung
	Angenommen mit Modifikationen	Dies ist gedacht als Platzhalter
ID	Referenz	Typ	Antragsteller	Organisation	Im Namen von
7	POMF_MT000001DE.xsd => Zeile 153	Vorschlag	Horst Kakuschke	HÄVG Rechenzentrum GmbH
Kommentar	Existierende Formulierung	Vorgeschlagene Änderung	Begründung
	<xs:attribute name="typeCode" type="x_InformationRecipient" use="optional" default="PRCP"/>	<xs:attribute name="typeCode" type="x_InformationRecipient"/>	In der zugehörigen Schematron-Validierung wird das Attribut typeCode auf eine erforderliche Angabe "PRCP" geprüft, ohne den Default-Wert zu berücksichtigen. Wird bei der Serialisierung eines PatientParticipationListDocuments nun der im Schema angegebene Default-Wert berücksichtigt (und damit dieser Wert "PRCP" nicht explizit serialisiert), führt das zu Fehlern bei der Validierung gegen das Schematron. Um hier auch der Maxime "das XML-Dokument sollte ohne Kenntnis des Schemas lesbar sein" zu folgen, würde sich statt der Anpassung des Schematrons eine Änderung des XML-Schemas anbieten, indem dort die Angabe des Attributs typeCode auf "required" geändert wird.
Reconcile	Entscheidung	Kommentar			Abstimmung
	Angenommen	Das Schematron wird entsprechend angepasst: wenn ein typeCode genannt wird muss er PRCP sein, kann aber auch weggelassen werden.
ID	Referenz	Typ	Antragsteller	Organisation	Im Namen von
8	Kap 9.1.1	Negativ, schwerwiegend	Ingo Wolf	gematik Gesellschaft für Telematikanwendungen der Gesundheitskarte mbH
Kommentar	Existierende Formulierung	Vorgeschlagene Änderung	Begründung
	Im Rahmen dieses Vertrages hat er die Rolle des betreuenden Hausarztes für eine Reihe von Versicherten der BKK Bayern übernommen und erhält quartalsweise ein Verzeichnis mit den Teilnahmeinformationen zu diesem Patientenkreis.	Eine geeignete Formulierung sollte gewählt werden, aus der hervorgeht, wie der Hausarzt die Teilnehmerinformationen erhält.	Es bleibt unklar wie die Daten zwischen dem Verzeichnis und dem Arzt transportiert werden. Ein Transport muss aus Interoperabilitätssicht ergänzt werden.
Reconcile	Entscheidung	Kommentar			Abstimmung
	Angenommen mit Modifikationen	Transport- und Sicherheitsaspekte sind nicht Gegenstand dieses Leitfadens; es wurde ein entwprechender Paragraf aufgenommen
ID	Referenz	Typ	Antragsteller	Organisation	Im Namen von
9	S.6	Tippfehler	Mathias Aschhoff	ZTG GmbH
Kommentar	Existierende Formulierung	Vorgeschlagene Änderung	Begründung
	Patiententeilnehmerzeichnisse	Patiententeilnehmerverzeichnisse
Reconcile	Entscheidung	Kommentar			Abstimmung
	Angenommen
ID	Referenz	Typ	Antragsteller	Organisation	Im Namen von
10		Kommentar allgemeiner Art	Mathias Aschhoff	ZTG GmbH
Kommentar	Existierende Formulierung	Vorgeschlagene Änderung	Begründung
	PatientParticipationListDocument		Warum nicht ClinicalDocuement?
Reconcile	Entscheidung	Kommentar			Abstimmung
	Angenommen mit Modifikationen	Weil es kein ClinicalDocument ist (d.h. es hat keinen Bezug zu genau einem Patienten, sonder zu vielen)
ID	Referenz	Typ	Antragsteller	Organisation	Im Namen von
11	-	Vorschlag	Simone Heckmann	HL7-DE / Health-Comm GmbH
Kommentar	Existierende Formulierung	Vorgeschlagene Änderung	Begründung
		Ausblick auf Mapping nach FHIR	Die vorliegende Spezifikation mag ausreichen, um Teilnehmerlisten im Sinne eines Dokumentes auszutauschen, eigenen sich jedoch nicht für eine "Online"-Nutzung bspw. im Rahmen einer klinischen Studie (vgl. hierzu z.B. das C3-PRO-Framework). Komplexe Abfragen ("Gib mir eine Liste aller männlichen Teilnehmer an der Studie XY im Alter zwischen 60 und 65 Jahren" oder "Ist Patient XY Teilnehmer des Programms Z?") sind ebensowenig möglich wie Updates einzelner Patienteninformationen (z.B. Adressänderung). Im Hinblick auf eine Nutzung der Daten jenseits des aktuellen Szenarios sollte der LEitfaden zumindest einen Ausblick auf ein Mapping der Listen in FHIR-Resourcen bieten, um die Daten zur Nutzung in Online-DIensten verfügbar machen zu können
Reconcile	Entscheidung	Kommentar			Abstimmung
	Angenommen mit Modifikationen	Sicherlich kann bei Erweiterung des Anwendungsszenarios Richtung "Online"-Dienste darüber nachgedacht werden, andere Austauschmechanismen wie FHIR zu nutzen. Für den hier beschriebenen Zweck, insbesondere primär der vierteljährliche Austausch von Listen, ist der hierbeschreibene Ansatz adäquat.