[geprüfte Version] | [Markierung ausstehend] |
|
|
− | ==Abnahmeprüfung für ELGA e-Befunde== | + | ==Hinweise zur Konformitätsprüfung== |
− | Zur Sicherstellung einer möglichst hohen Qualität von Inhalt, Struktur und Format der CDA-Dokumente ist ein Abnahmeprozess implementiert, der durch die ELGA GmbH durchgeführt wird.
| + | Die Schematron-Konformitätsprüfmechanismen ("Schematron-Regeln") werden vom Modellierungstool Art-Decor automatisch aus den Templates generiert. Nicht alle erlaubten Attribute müssen in den Templates ausspezifiziert sein. Sind diese nicht explizit angeben, gelten die Vorgaben des angegebenen HL7 Datentyps bzw. den weiteren Einschränkungen im Kapitel Datentyp-Definitonen dieses Leitfadens. Diese Vorgaben MÜSSEN eingehalten werden. |
− | Vor der Produktivsetzung eines ELGA CDA-Befundes muss daher ein Prüf- und Freigabebericht durch Verantwortliche des CDA-generierenden Systems bzw. des ELGA-Bereiches bei der ELGA GmbH, Postfach [mailto:cda@elga.gv.at cda@elga.gv.at] bzw. am [https://jira-neu.elga.gv.at/servicedesk/customer/portal/3 online service portal], beantragt werden.
| |
| | | |
− | Erst nach positiver Prüfung und Freigabe durch die ELGA GmbH sind die ELGA-CDA-Dokumente eines Dokumenterstellers in ELGA zugelassen.
| + | Attribute oder Elemente eines CDA-Dokuments, die den Datentyp-Definitonen und den Template-Spezifikationen widersprechen oder darin nicht beschrieben wurden (also fremde Inhalte im Sinne der "closed templates" Elemente, die der "Maximum-Set" Vorschrift widersprechen), werden von den Schematron-Regeln grundsätzlich als falsch erkannt. Nicht als falsch erkannt werden Elemente und Attribute, die entsprechend den HL7 V3 Datentypen erlaubt sind, aber in den ELGA-Datentyp-Definitionen nicht enthalten oder verboten sind. Diese können nur durch die Schematron-Prüfmechanismen entdeckt werden, wenn sie im Template explizit als verboten modelliert wurden (was nicht immer der Fall ist). |
| | | |
− | Für eine endgültige Abnahme ist ein komplettes Set von ELGA-CDA-Dokumenten zu übermitteln:
| + | '''Fehlertoleranz:''' Sollten nicht erlaubte Elemente oder Attribute in einem CDA-Dokument vorhanden sein (z.B. aufgrund von Software-Fehlern), SOLL die weiterverarbeitende Software so implementiert sein, dass dies nicht zu Fehlern in der Weiterverarbeitung der Dokumente führt. |
− | *Je erstellendem SW-System (KIS/LIS/RIS etc.) müssen 3 Beispielbefunde je Dokumentenklasse (ärztlicher Entlassungsbrief, Befund bildgebende Diagnostik, Laborbefund) inkl. einer Befund-Folgeversion geliefert werden.
| |
− | *Angabe der Art der Beispieldateien:
| |
− | **Produktive anonymisierte Echtbefunde von Patienten oder
| |
− | **Test-Befunde von Test-Patienten, die in der Qualität und Quantität der Befüllung produktiven Echtbefunden entsprechen.
| |
− | *Die Befunde sollen eine möglichst vollständige und realitätsnahe Befüllung aller Felder aufweisen und inhaltlich so korrekt sein, dass auf ein korrektes Mapping der Inhalte durch das erstellende System geschlossen werden kann.
| |
− | *Beispiele mit aufeinander folgenden Versionen eines Befundes sind anzugeben.
| |
− | *Beispiele mit eingebettetem PDF sind vorzulegen (PDF/A-1a bzw. PDF/A-1b konform).
| |
− | *Die Befunde müssen vor der Übermittlung erfolgreich geprüft werden:
| |
− | | |
− | #Darstellung mit Webbrowser und Referenz-Stylesheet.
| |
− | #Prüfung mit dem von der ELGA GmbH bereitgestellten Schema- und Schematronregelset (z.B. Online-Validator).
| |
− | #Prüfung auf PDF/A-1a bzw. PDF/A-1b Konformität (z.B. durch den Online-Validator oder andere Tools, wie VeraPDF.org).
| |
− | #Integrationstest: Die Verwendung bzw. Darstellung der Befunde ist vor dem Echtbetrieb im GIT zu prüfen. Für jeden Dokumententyp muss die korrekte Anzeige im ELGA-Portal geprüft werden, sowohl in der Online-Ansicht als auch in der Druckansicht. (Alternative bei Verwendung der GDA-SWH-Umgebung: ELGAWebGUI auf GINA-Box)
| |