EFA Change- und Releasemanagement

Release- und Changemanagement der EFA-Spezifikationen erfolgen aktuell weitgehend „auf Zuruf“, was u.a. zur Folge hat, dass verschiedene Ausprägungen der Spezifikation unter einer Versionsnummer laufen (z.B. EFA Single-Peer und EFA Peer-to-Peer als „EFAv2.0“) und dass die geplanten jährlichen „Freezes“ der Spezifikation keinen definierten Status besitzen.

Mit diesem Papier wird daher für die EFA-Spezifikation ein Konzept zu einem Release- und Changemanagement vorgeschlagen, dass

• festlegt, wann und durch wen neue Versionsnummern der Spezifikation vergeben werden und welche Semantik diese Nummern tragen
• den Prozess zur Erstellung eines „Freeze“ regelt und den Status eines solchen „Freeze“ definiert,
• festlegt, auf welcher Spezifikationsgrundlage die Zertifizierungen von EFA-konformen Produkten zukünftig erfolgen,
• definiert, wie Änderungsanforderungen erfasst, bearbeitet und eingepflegt werden,
• wie die potenzielle Übernahme von EFA-relevanten Change-Proposals der genutzten IHE-Profile organisiert ist.

Da die EFA-Spezifikation ab der Version 2.0 durchgängig auf IHE-Profilen basiert, sind die vorgeschlagenen Prozesse eng mit den korrespondierenden Prozessen von IHE verzahnt.

Release-Management und Versionsnummern

Die IHE-IT-Infrastructure-Komitees veröffentlichen jedes Jahr im August/September eine neue Revision des IHE IT-Infrastructure Framework. Die aktuelle Revision 11 wurde im September 2014 veröffentlicht.

Die EFA-Versionsnummer „2“ und auch „2.0“ ist mittlerweile ein stehender und gut etablierter Begriff für die auf IHE-Profilen basierende EFA-Spezifikation. Es wird daher vorgeschlagen, die IHE-konforme EFA grundsätzlich als „EFAv2.0“ zu bezeichnen und Fortschreibungen der Spezifikation analog zu IHE als Revisionen zu veröffentlichen.

Neue EFA-Revisionen werden jedes Jahr im Januar bzw. Dezember des Vorjahrs veröffentlicht und umfassen alle bis zu diesem Zeitpunkt angenommenen und in die Wiki-Version der Spezifikation eingepflegten Change Requests (s.u.). Hiermit bleibt einerseits genug Zeit, Änderungsanforderungen aus der zumeist im September eine Jahres veröffentlichten aktuellsten IHE-Revision zu prüfen und andererseits bleibt den Herstellern ausreichend Zeit, die aktuellste EFA-Revision bis zu conhIT im April/Mai umzusetzen. Die jährlichen Releases ersetzen das aktuelle Konstrukt des „Freeze“ wobei mit jedem Release ein „Freeze“ des aktuellen Spezifikationstands in Form eines PDF-Dokuments einhergeht, das auf der Webseite des EFA-Vereins veröffentlicht wird.

Die im Januar 2015 eingefrorene Spezifikation der EFA wird als „EFAv2.0 Revision 1“ bezeichnet. Die „EFAv2.0 Revision 2“ wird entsprechend im Januar 2016 veröffentlicht (sofern sich im Laufe des Jahres 2015 Änderungsanforderungen aus Change Requests ergeben).

Zusammenfassung

• Versionsnummer bleibt fest auf „2.0“
• „Freeze“ der Spezifikation erfolgt jährlich im Januar, sofern sich im Laufe des Jahres Änderungen ergeben haben.
• Zu jedem „Freeze“ wird eine neue, um eins erhöhte Revisionsnummer vergeben. Das im Januar 2015 veröffentlichte Freeze erhält die Revisionsnummer „1“.

Abhängigkeiten zum IHE ITI Technical Framework

Die EFAv2.0 besitzt sehr viele Abhängigkeiten zum IHE ITI Technical Framework. Diese Abhängigkeiten treten in zwei Varianten auf:

1. Direkte Abhängigkeit: EFAv2.0 profiliert Transaktionen und Daten-Definitionen des IHE ITI-Frameworks. Änderungen an diesen Stellen im IHE ITI-Framework haben unmittelbaren Einfluss auf die EFA-Spezifikation.
2. Indirekte Abhängigkeiten: EFAv2.0 definiert für viele Funktionalitäten keine eigenen Lösungen, sondern verweist auf die im IHE ITI Framework spezifizierten Lösungen (teilweise sogar indirekt über das IHE Cookbook). Änderungen an diesen Stellen im IHE ITI-Framework haben zwar keinen Einfluss auf die EFA-Spezifikation, aber auf EFA-konforme Produkte.

Für Hersteller sind vor allem die direkten Anwendungen relevant, da die Aufwände zur Umsetzung der EFA in hohem Maße davon abhängen, in wie weit eine beim Hersteller bestehende Umsetzung von IHE Revisionsständen zur EFA-Spezifikation konform ist. Für Anwender sind in Bezug auf die Interoperabilität einer EFA-Plattform zu weiteren IHE-konformen Produkten beide Formen der Abhängigkeit relevant, da potenziell nur Lösungen zueinander interoperabel sind, die auf der gleichen Revision des IHE ITI Frameworks basieren.

Um hier für Hersteller und Anwender eine größtmögliche Transparenz zu schaffen, werden die folgenden Maßnahmen umgesetzt:

• Mit Veröffentlichung einer neuen Revision des IHE ITI Frameworks (üblicherweise im August/September) wird seitens Fraunhofer FOKUS validiert, welche direkten und indirekten Abhängigkeiten sich daraus zur aktuellen EFA-Revision ergeben. Um diesen Prozess zu vereinfachen, werden bereits unterjährig in regelmäßigen Abständen in IHE ITI diskutierte Change Proposals verfolgt, die potenziell in die neue Revision einfließen werden. Dies eröffnet den EFA-Partnern die Option, sich aktiv in die Umsetzung dieser Change Proposals einzubringen.
• Aus direkten Abhängigkeiten abgeleitete Änderungsanforderungen an die EFA-Spezifikation werden seitens des Fraunhofer FOKUS als EFA Change Proposals eingebracht und nach dem in diesem Papier beschriebenen Verfahren behandelt.
• Änderungsanforderungen an EFA-Produkte, die aus indirekten Abhängigkeiten resultieren, werden im EFA-Wiki dokumentiert und fließen als Anhang in neue EFA-Revisionen ein. Dieses gibt EFA-Anwendern zumindest Hinweise zu möglichen Interoperabilitätsproblemen einer EFA-Umsetzung mit anderen IHE-konformen Produkten.
• Zu jeder EFA-Revision wird vermerkt, zu welchen Revisionen des IHE ITI Framework diese konform ist. In der aktuellen EFA-Spezifikation nicht umgesetzte direkte Abhängigkeiten zur aktuellen Revision des IHE ITI Frameworks werden explizit benannt.

Die aktuelle EFA-Spezifikation basiert auf der Revision 10 des IHE ITI Frameworks vom August 2013. Die hier benannten Maßnahmen greifen erstmalig mit der Veröffentlichung der Revision 12 des IHE ITI Frameworks im Spätsommer 2015.

Zusammenfassung

• Abhängigkeiten zur aktuellen Revision des IHE ITI Frameworks werden bewertet und entweder als EFA Change Proposals behandelt oder transparent gemacht.
• Die Konformität einer EFA-Revision zu Revisionen des IHE ITI Frameworks wird in der EFA Spezifikation explizit vermerkt.

Change Management

Aktuell werden Change Proposals informell per Mail an das Fraunhofer FOKUS gemeldet und dann im Wiki registriert. Die Abarbeitung erfolgt unregelmäßig durch die 7er-Gruppe.

Es wird vorgeschlagen, auch diesen Prozess stärker zu formalisieren und an das Vorgehen bei IHE anzulehnen. Hierzu wird ein Change-Proposal-Formular erstellt, das von der Webseite des EFA-Vereins und über das Wiki abgerufen werden kann. Ausgefüllte Formulare werden an das Fraunhofer FOKUS gesandt und dort in eine wiki-konforme Form gebracht und in das Wiki eingestellt. Alle Mitglieder der 7er-Gruppe und alle Hersteller zertifizierter Produkte werden per Mail über das Vorliegen des Change Request informiert. Über das Wiki können Stellungnahmen zu dem Change Request eingebracht werden.

Zur Bearbeitung der Change Requests wird eine monatliche Telefonkonferenz angesetzt. Ziel ist es, diese perspektivisch mit einem analogen Verfahren des „IHE Cookbooks“ zusammenzuführen (Annahme ist, dass Change Requests gerade aus neuen Entwicklungen bei IHE und nationalen Implementierungen der IHE-Profile heraus angestoßen werden und daher eine gemeinsames Bearbeiten von Change Requests sinnvoll ist). In der monatlichen Telefonkonferenz werden keine Entscheidungen über Abnahme, Annahme, Lösung getroffen, sondern es wird vielmehr von den Teilnehmern ein Entscheidungs- und ggf. Lösungsvorschlag ausgearbeitet.

Jährlich im Mai und November finden F2F-Treffen der 7er-Gruppe statt, zu denen auch die Hersteller EFA-konformer Lösungen eingeladen werden . Auf diesen Treffen werden alle offenen und in den Telefonkonferenzen aufbereiteten Change Requests abschließend diskutiert und entweder abgelehnt oder angenommen. Die Annahme kann schon einen konkreten Lösungsvorschlag beinhalten oder aber auch „nur“ konkrete Anforderungen an die Lösung definieren, auf deren Basis bis zum nächsten Treffen ein Lösungsvorschlag zu erarbeiten ist. Entscheidungen über Ablehnung, Annahme oder Wiedervorlage erfordern eine Zustimmung von mehr als 50% der bei den jeweiligen Sitzungen anwesenden Organisationen der 7er-Gruppe und EFA-Hersteller. Für nicht anwesende Organisationen ist eine vorab zu erfolgende Stimmabgabe per eMail möglich. Entscheidungen zu Annahmen und Ablehnungen, für die mehr als 25% Gegenstimmen abgegeben wurden, werden EFA-Verein und bvitg zur Bestätigung vorgelegt. Beide Organisationen haben ein Vetorecht gegen die Entscheidung, was automatische eine Wiedervorlage zur Folge hat. Einladungen zu den F2F-Treffen werden mit einem Vorlauf von mindestens 4 Wochen versandt. In der letzten Telefonkonferenz vor Versand der Einladung wird festgelegt, welche Change Proposals im F2F-Treffen zur Entscheidung vorgelegt werden. Diese werden in der Einladung benannt und mit Versand der Einladung „eingefroren“.

Alle angenommenen Change Requests werden bis spätestens Dezember eines Jahres durch das Fraunhofer FOKUS in die Wiki-Version der Spezifikation eingearbeitet und sind Bestandteil des im darauf folgenden Januar veröffentlichten neuen Release der EFAv2.0-Spezifikation.

Zusätzlich werden die angenommenen Änderungen auf dem Dezember-Treffen des Interoperabilitätsforums zusammenfassend vorgestellt, um auch die anderen nationalen eHealth-Projekte zu informieren und die projektübergreifende Konformität von verschiedenen IHE-basierten Spezifikationen zu unterstützen. Zusätzlich besteht die Möglichkeit, in den monatlichen Telefonkonferenzen als auch für andere Projekte wichtige Fragestellungen identifizierte Change Requests in das Interoperabilitätsforum einzubringen und dort in Bezug auf die Auswirkungen von Lösungsoptionen auf andere Projekte zu diskutieren.

Die in der 7er-Gruppe vertretenen Hersteller benennen einen „Release-Manager“, der die vereinbarungsgemäße Übernahme von Änderungen in die Spezifikation überprüft und bestätigt. Die Veröffentlichung einer neuen EFAv2.0-Revision erfolgt erst, wenn alle im Vergleich zur vorherigen Spezifikation vorgenommenen Änderungen durch den „Release-Manager“ der Hersteller freigegeben wurden.

Zusammenfassung

• Das Change-Management-Verfahren wird analog zum IHE-Prozess formalisiert und mit festen Terminen hinterlegt.
• Bearbeitung und Entscheidung von Change Requests erfolgen getrennt.
• Entscheidungen werden mit einfacher Mehrheit gefällt, wobei ein starkes Minderheitenvotum ein Vetorecht für EFA-Verein und bvitg aktiviert.
• Einarbeitung und Freigabe von abgestimmten Änderungen werden auf verschiedene Akteure verteilt.
• Eine Zusammenführung des Change Management von EFAv2.0 und IHE Cookbook wird angestrebt. Eine Verzahnung mit dem Interoperabilitätsforum ist in den Change-Management-Prozessen angelegt.

Grundlage von Zertifizierungen

Zertifizierungen werden bis zur Vereinbarung eines neuen Verfahrens weiterhin Selbsterklärungen der Hersteller auf Basis der im Wiki veröffentlichten Formulare und des dort dokumentierten Verfahrens durchgeführt.

Abweichend von diesem Verfahren erfolgen Bestätigungen der Selbsterklärungen durch das Fraunhofer FOKUS nur noch innerhalb von zwei definierten Zertifizierungszeiträumen:

• Zertifizierungszeitraum 1: März bis conhIT eines Jahres
  • Grundlage ist die im Januar des betreffenden Jahres veröffentliche Revision der EFAv2.0-Spezifikation
  • Die EFA-Revisionsnummer wird in das bei erfolgreicher Zertifizierung ausgestellte Formular aufgenommen. Zusätzlich wird informativ angegeben, welche Releases des IHE ITI-Frameworks vom zertifizierten Produkt unterstützt werden.
  • Zertifizierte Produkte dürfen unter Angabe der Revisionsnummer uneingeschränkt und unbefristet mit dem EFA-Logo beworben werden. Eine Bewerbung ohne Angabe der Revisionsnummer ist bis zur Veröffentlichung einer neuen Revision erlaubt.

• Zertifizierungszeitraum 2: Juli bis medica eines Jahres
  • Grundlage ist die im Januar des betreffenden Jahres veröffentliche Revision der EFAv2.0-Spezifikation. Hersteller können in ihren Implementierungen bereits die im Mai angenommenen Change Requests berücksichtigen. Die umgesetzten Change Requests werden in der Selbsterklärung benannt.
  • Die EFA-Revisionsnummer wird in das bei erfolgreicher Zertifizierung ausgestellte Formular aufgenommen. Zusätzlich wird informativ angegeben, welche Releases des IHE ITI-Frameworks vom zertifizierten Produkt unterstützt werden.
  • Zertifizierte Produkte dürfen unter Angabe der Revisionsnummer uneingeschränkt und unbefristet mit dem EFA-Logo beworben werden. Eine Bewerbung ohne Angabe der Revisionsnummer ist bis zur Veröffentlichung einer neuen Revision erlaubt.

Hersteller können für bereits zertifizierte Produkte eine Delta-Zertifizierung für eine neue Revision beantragen, sofern diese auf derselben Revision des IHE ITI Frameworks basiert wie das zu zertifizierende Produkt. Diese Einschränkung kann auf zwei Arten erfüllt werden:

• Das Produkt wurde durch den EFA-Verein bereits für eine EFA-Revision zertifiziert, der die gleiche Revision des IHE ITI Frameworks zugrunde liegt wie der aktuellen EFA-Revision (Beispiel: Das Produkt wurde für EFAv2.0 Revision 1 auf Basis IHE ITI Framework Revision 10 zertifiziert. Eine Delta-Zertifizierung auf die EFAv2.0 Revision 2 wird angestrebt, die zur Revision 10 des IHE ITI Frameworks konform ist. Der Hersteller muss bestätigen, dass er alle in die EFA-Revision 2 eingeflossenen EFA Change Requests umgesetzt hat).
• Das Produkt wurde durch den EFA-Verein bereits für eine EFA-Revision zertifiziert, der eine ältere Revision des IHE ITI Frameworks zugrunde lag. In diesem Fall muss der Hersteller neben der Bestätigung der Umsetzung aller relevante Change Requests für eine Delta-Zertifizierung ein IHE Conformance Statement für die aktuell von der EFA genutzte Revision des IHE ITI Frameworks vorlegen (Beispiel: Das Produkt wurde für EFAv2.0 Revision 1 auf Basis IHE ITI Framework Revision 10 zertifiziert. Eine Delta-Zertifizierung auf die EFAv2.0 Revision 2 auf Basis des IHE ITI Frameworks Revision 12 wird angestrebt. Der Hersteller muss ein IHE ITI Conformance Statement für die in der EFA genutzten Profile auf Basis des IHE ITI Frameworks 12 vorlegen und bestätigen, dass er alle in die EFA-Revisionen 2 eingeflossenen Change Requests umgesetzt hat).

Für eine solche Delta-Zertifizierung wird das Fraunhofer FOKUS ein entsprechendes Formular erstellen und über das Wiki und die Webseite des EFA-Verein zum Download bereitstellen. Die Darstellungen zum Zertifizierungsprozess werden entsprechend angepasst.

Zusammenfassung

• Das Zertifizierungsverfahren wird so angepasst, dass es besser mit dem Release- und Changemanagement verzahnt ist. Hierdurch ist eine hohe Transparenz über die einer Zertifizierung zugrunde liegende EFA-Revision gegeben.
• Es wird eine zusätzliche Delta-Zertifizierung eingeführt, in die IHE Conformance Statements eingebracht werden können

Anhang A: Erstellen einer EFA-Revision aus dem HL7/EFA-Wiki

Alle im Verlauf eines Jahres angenommenen Change Requests werden bis spätestens Dezember des Jahres durch das Fraunhofer FOKUS in die Wiki-Version der Spezifikation eingearbeitet. Aus dem Wiki wird anschließend automatisiert ein Word-Dokument erzeugt, das Grundlage der im folgenden Januar veröffentlichten neuen Revision der EFAv2.0-Spezifikation ist. Für die Umwandlung des vernetzten Wiki in ein sequenzielles Word-Dokument gelten die folgenden Vorgaben:

• Die Übernahme der Wiki-Seiten in das Word-Dokument erfolgt innerhalb der ECCF-Matrix von links oben nach rechts unten entlang der horizontalen Perspektiven.
• Auf der Titelseite des Dokuments steht das Datum der Generierung des Dokuments.
• Für das Dokument wird eine OID vergeben, die auf der Titelseite des Dokuments angegeben ist.
• Alle Kapitel sind nummeriert (auch im Text). Alle Seiten sind nummeriert und enthalten in der Fußzeile Nummer und Datum der Revision.
• Abbildungen und Tabellen sind durchnummeriert.
• Die im Unterschied zur letzten Revision durchgeführten Änderungen sind in dem Dokument als Anlage aufgelistet (z.B. als Verweise auf die umgesetzten Change Requests)