Kommentare und Auflösungen zum Abstimmungsverfahren Patiententeilnehmerverzeichnis

Aus Hl7wiki
Version vom 10. Juni 2016, 09:27 Uhr von Wikiadmin (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „{{#CustomTitle:Kommentare und Auflösungen zum Abstimmungsverfahren ''Patiententeilnehmerverzeichnis''}} Stand: 10. Juni 2016 <table xmlns="urn:schemas-micros…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

Stand: 10. Juni 2016

Auszählung (Tally)
Anzahl Kommentare11
Angenommen6
Angenommen mit Modifikationen4
Nicht angenommen1
Nicht relevant0
Zur zukünftigen Verwendung0
Weitergeleitet0
Warten auf Information vom Antragsteller0
Warten auf Information von anderer Arbeitsgruppe0
Unbearbeitet0

 

IDReferenzTypAntragstellerOrganisationIm Namen von
13 Struktureller Aufbau&#xD;Symbol oppose vote as.svg VorschlagChristof GessnerMxDx Medizinische Informatik
Kommentar Si-vote.svgExistierende FormulierungVorgeschlagene ÄnderungBegründung
Das Patiententeilnahmeverzeichnis ist als Structured Document entworfen.Bitte Verweis auf Definition oder Standard angeben.
Reconcile Si-reconc.svgEntscheidungKommentarAbstimmung
AngenommenEs wird der Link zum genannten Produkt mit aufgenommen

IDReferenzTypAntragstellerOrganisationIm Namen von
2"3.2"Symbol oppose vote at.svg TippfehlerChristof GessnerMxDx Medizinische Informatik
Kommentar Si-vote.svgExistierende FormulierungVorgeschlagene ÄnderungBegründung
bekannt Komponenten bekannte Komponenten
Reconcile Si-reconc.svgEntscheidungKommentarAbstimmung
Angenommen

IDReferenzTypAntragstellerOrganisationIm Namen von
3author/assignedAuthor/codeSymbol oppose vote as.svg VorschlagChristof GessnerMxDx Medizinische Informatik
Kommentar Si-vote.svgExistierende FormulierungVorgeschlagene ÄnderungBegründung
Angabe eines Codesystems erforderlich?
Reconcile Si-reconc.svgEntscheidungKommentarAbstimmung
AngenommenEin Code anzugeben ist nicht notwendig

IDReferenzTypAntragstellerOrganisationIm Namen von
4informationRecipient/@typeCodeSymbol oppose vote as.svg VorschlagChristof GessnerMxDx Medizinische Informatik
Kommentar Si-vote.svgExistierende FormulierungVorgeschlagene ÄnderungBegründung
Erläuterung der Bedeutungen der beiden Codes?
Reconcile Si-reconc.svgEntscheidungKommentarAbstimmung
Nicht angenommenSteht schon in der Beschreibung des Templates und auch angedeutet in der Beschreibung des Elements

IDReferenzTypAntragstellerOrganisationIm Namen von
51.2.276.0.76.10.4081&#xD;Symbol oppose vote as.svg VorschlagChristof GessnerMxDx Medizinische Informatik
Kommentar Si-vote.svgExistierende FormulierungVorgeschlagene ÄnderungBegründung
Vertrags-Type (kodiert) Angabe eines Codesystems erforderlich?
Reconcile Si-reconc.svgEntscheidungKommentarAbstimmung
AngenommenJa, es sollte ein Code angegeben werden. Die nähere Nutzung unterliegt einer Profilierung. Wenn kein Code bekannt ist, dann auch nullFlavor angegeben werden.

IDReferenzTypAntragstellerOrganisationIm Namen von
68.2.4 Contract Participant Reasoncode&#xD;Symbol oppose vote as.svg VorschlagChristof GessnerMxDx Medizinische Informatik
Kommentar Si-vote.svgExistierende FormulierungVorgeschlagene ÄnderungBegründung
Hier werden die kodierten Gründe genannt (werden)hinweis auf Abstimmungsprozess einfügen
Reconcile Si-reconc.svgEntscheidungKommentarAbstimmung
Angenommen mit ModifikationenDies ist gedacht als Platzhalter

IDReferenzTypAntragstellerOrganisationIm Namen von
7POMF_MT000001DE.xsd => Zeile 153Symbol oppose vote as.svg VorschlagHorst KakuschkeHÄVG Rechenzentrum GmbH
Kommentar Si-vote.svgExistierende FormulierungVorgeschlagene ÄnderungBegrü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 Si-reconc.svgEntscheidungKommentarAbstimmung
AngenommenDas Schematron wird entsprechend angepasst: wenn ein typeCode genannt wird muss er PRCP sein, kann aber auch weggelassen werden.

IDReferenzTypAntragstellerOrganisationIm Namen von
8Kap 9.1.1Symbol oppose vote mj.svg Negativ, schwerwiegendIngo Wolfgematik Gesellschaft für Telematikanwendungen der Gesundheitskarte mbH
Kommentar Si-vote.svgExistierende FormulierungVorgeschlagene ÄnderungBegrü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 Si-reconc.svgEntscheidungKommentarAbstimmung
Angenommen mit ModifikationenTransport- und Sicherheitsaspekte sind nicht Gegenstand dieses Leitfadens; es wurde ein entwprechender Paragraf aufgenommen

IDReferenzTypAntragstellerOrganisationIm Namen von
9S.6Symbol oppose vote at.svg TippfehlerMathias AschhoffZTG GmbH
Kommentar Si-vote.svgExistierende FormulierungVorgeschlagene ÄnderungBegründung
PatiententeilnehmerzeichnissePatiententeilnehmerverzeichnisse
Reconcile Si-reconc.svgEntscheidungKommentarAbstimmung
Angenommen

IDReferenzTypAntragstellerOrganisationIm Namen von
10Symbol oppose vote ac.svg Kommentar allgemeiner ArtMathias AschhoffZTG GmbH
Kommentar Si-vote.svgExistierende FormulierungVorgeschlagene ÄnderungBegründung
PatientParticipationListDocumentWarum nicht ClinicalDocuement?
Reconcile Si-reconc.svgEntscheidungKommentarAbstimmung
Angenommen mit ModifikationenWeil es kein ClinicalDocument ist (d.h. es hat keinen Bezug zu genau einem Patienten, sonder zu vielen)

IDReferenzTypAntragstellerOrganisationIm Namen von
11 - Symbol oppose vote as.svg VorschlagSimone HeckmannHL7-DE / Health-Comm GmbH
Kommentar Si-vote.svgExistierende FormulierungVorgeschlagene ÄnderungBegründung
Ausblick auf Mapping nach FHIRDie 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 Si-reconc.svgEntscheidungKommentarAbstimmung
Angenommen mit ModifikationenSicherlich 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.