Alle beteiligten Akteure (Server wie Clients) tragen eine (Teil-)Verantwortung für die Sicherstellung einer performanten REST-API. Zweck einer performanten REST-API ist, dass die typischen Arbeitsabläufe der jeweiligen Nutzer (z. B. Arzt, Pflege, Verwaltung) ohne wahrnehmbare Verzögerung durchgeführt werden können. Insbesondere dürfen für klinisch kritische Funktionen keine Wartezeiten entstehen, die eine zeitgerechte Patientenversorgung beeinträchtigen.
Zur Sicherstellung dieser Performance-Bedarfe können in einem ersten Schritt die Antwortzeiten der REST-Endpunkte (Server) als Baseline geprüft werden - d. h. im Best-Case und unabhängig von Last-Anforderungen. Weitere Performance-Aspekte für Server zu Antwortzeiten unter Last, Lasten und Durchsatz sollten diesen Baseline Anforderungen folgen.
Da zur Gewährleistung der Performance während der Entwicklung sowohl Client- als auch Server-Hersteller beitragen müssen, werden unten weitere Hinweise zur Client-Implementierung formuliert. Die folgenden Festlegungen gelten dagegen für Server.
Die Performance-Kategorien und entsprechende Anforderungen beziehen sich zum jetzigen Zeitpunkt alle auf den Aspekt Antwortzeit als Baseline.
Die Antwortzeit bezeichnet dabei einen Request/Reply-Zyklus zwischen einem Client und einem Server, der die Zeitspanne von der Absendung einer Anfrage durch den Client bis zum vollständigen Empfang der Antwort durch den Client in der Test-Umgebung umfasst und deckt sich damit weitgehend mit dem Konzept der Bearbeitungszeit wie hier definiert. Dabei wird hier zusätzlich eine Antwortzeit ohne signifikante Lasteinwirkung angenommen.
Die Antwortzeit dabei bezeichnet einen Request/Reply-Zyklus zwischen einem Client und einem Server, der die Zeitspanne von der Absendung einer Anfrage durch den Client bis zum vollständigen Empfang der Antwort durch den Client in der Test-Umgebung umfasst und deckt sich damit weitgehend mit dem Konzept der Bearbeitungszeit wie hier definiert.
Als kritisch (PK1 bis PK4) gelten REST-Abfragen, die von klinischen Nutzern in unmittelbar behandlungsrelevanten, zeitkritischen Situationen genutzt werden und deren Bereitstellung für den anfragenden Client nahezu zur Laufzeit stattfinden sollten. Daher sind hierfür sehr kurze Antwortzeiten ohne wahrnehmbare Verzögerung anzustreben.
Die Antwortzeit bezeichnet einen Request/Reply-Zyklus zwischen einem Client und einem Server, der die Zeitspanne von der Absendung einer Anfrage durch den Client bis zum vollständigen Empfang der Antwort durch den Client in der Test-Umgebung umfasst /und deckt sich damit weitgehend mit dem Konzept der Bearbeitungszeit wie hier definiert.
Für diese Performance-Kategorien gilt:
GET baseURL/Patient/89186842GET baseURL/Observation/67890GET baseURL/DocumentReference/54321
baseURL/DocumentReference?_id=54321baseURL/Patient?identifier=12345baseURL/Patient?birthdate=1982-01-13baseURL/MedicationRequest?patient=Patient/89186842Patient.id bekannt.
baseURL/Condition?code=http://fhir.de/CodeSystem/bfarm/icd-10-gm|R10.0&patient=89186842baseURL/Condition?patient=Patient/89186842baseURL/Observation?category=http://terminology.hl7.org/CodeSystem/observation-category|vital-signs&patient=Patient/89186842.identifier unbekannt und dass ein sehr großer Ergebnisraum der Suchanfrage möglich ist.
baseURL/Patient?name=MüllerbaseURL/_has:Encounter:patient:location=Location/ward123Als vorwiegend unkritisch gelten Abfragen (PK5 bis PK6), die z. B.
Für diese Performance-Kategorien sind längere Antwortzeiten grundsätzlich tolerierbar; bei zu erwartenden längeren Laufzeiten sind asynchrone Verfahren möglich.
Für diese Performance-Kategorien gilt:
baseURL/Procedure?encounter.location=Location/ward123baseURL/Location?type=http://terminology.hl7.org/CodeSystem/location-physical-type|wabaseURL/Observation?code=http://loinc.org|2160-0&combo-code-value-quantity=gt1.0|mg/dLbaseURL/$bookbaseURL/MedicationRequestFür diese Performance-Kategorien werden im Test-System des Zertifizierungsverfahrens die entsprechenden Performance-Anforderungen (z.B. Antwortzeiten - ggf. unter Berücksichtigung der Perzentile -; aber vorerst keine Lasten, Durchsatz etc.)implementiert.
Hinweis zur Server-Implementierung bei Patienten- und Encounter-unabhängigen Suchen:
Bei den Patienten- und Encounter-unabhängigen Suchen DARF ab einer bestimmten Komplexität der Suchanfrage ein Server OperationOutcomes mit Codes wie z.B. too-costly zurückgeben (es liegt also im Ermessen des Herstellers).
Vor einer solchen Lösung SOLLEN aber geeignete Mechanismen - wie Pagination - in Betracht gezogen werden.
Ein Beispiel für too-costly - alle Observations der letzten Jahre : baseURL/Observation?_lastUpdated=ge2020
Auch Client-Hersteller tragen eine eigene Verantwortung bei der Gewährleistung der Performance für den Betrieb der definierten API-Schnittstelle. Dazu gehören insbesondere eine effiziente Abfragestrategie (z. B. Paging statt großer Ergebnismengen), fachlich sinnvolle Suchfilter (z. B. Zeiträume und Organisationseinheiten), die Vermeidung unnötiger Wiederholungsabfragen sowie die Nutzung geeigneter Caching- und Aktualisierungsmechanismen (z. B. ETag/If-None-Match). Ziel ist, nur die für den eigenen Anwendungsfall benötigten Daten in angemessener Zeit zu laden.
Beispiel für eine Vitalparameter-App (ein Patient) unter dem Szenario: Beim Öffnen der Patientenakte soll die App die zuletzt dokumentierten Vitalparameter (Puls, Blutdruck, Temperatur) schnell anzeigen und anschließend bei Bedarf den Zeitraum erweitern.
Konkrete Umsetzung der Performance-Aspekte:
_lastUpdated Suchparameter, um nur neue oder aktualisierte Daten seit der letzten Abfrage zu erhalten.