Veröffentlicht am 21. April 2016 von Pavel Smirnov
Drei neue Anforderungen, die im neuen ONC Health IT Certification Program verabschiedet wurden, betreffen die Öffnung von Patientengesundheitsdaten für Drittanbieteranwendungen über eine ONC-zertifizierte API. Diese Anforderungen sind: § 170.315(g)(7) Anwendungszugang – Patientenauswahl, § 170.315(g)(8) Anwendungszugang – Datenkategorieanfrage und § 170.315(g)(9) Anwendungszugang – Anfrage aller Daten.
Andy Slavitt, kommissarischer Administrator der Centers for Medicare and Medicaid Services, tweetete am 16. April
Obwohl die aktuelle Version der Zertifizierungsregel die Verwendung eines bestimmten Interoperabilitätsstandards für die API-Implementierung noch nicht vorschreibt, deutet sie klar darauf hin, dass die Durchsetzung von Standards sehr bald kommen wird.
„… wir beabsichtigen, in der nächsten geeigneten Regelgebung einen standardbasierten Ansatz für dieses Kriterium vorzuschreiben, und wir ermutigen Anbieter, die Verwendung bestehender und aufkommender API-Standards zu pilotieren."
Und im Jahr 2016 besteht kein Zweifel daran, was dieser Standard sein wird. Die Regelungen von ONC und CMS enthalten zahlreiche Verweise auf den FHIR-Standard (Fast Healthcare Interoperability Resources) und das Projekt Argonaut. FHIR ist in die ONC Interoperability Roadmap aufgenommen. FHIR erhält große Unterstützung von allen führenden EHR-Anbietern wie Epic, Cerner, athenahealth usw. Sie alle nehmen an der Erprobung der FHIR-API teil, die für ihre EHRs im Rahmen des Projekts Argonaut entwickelt wurde. Eine vollständige Liste der am Argonaut-Projekt beteiligten Organisationen finden Sie auf der HL7 FHIR-Website.
Obwohl die Konformität mit FHIR von der ONC-Zertifizierung noch nicht gefordert wird, wäre es ein Fehler, vom Standard abzuweichen und – selbst vorübergehend – eine proprietäre API zu implementieren. Die Zertifizierung der API ist nicht der letzte Schritt beim Nachweis von Meaningful Use. Leistungserbringerorganisationen müssen ihren Patienten Zugang zu einer ONC-zertifizierten API bereitstellen, die von Drittanbieteranwendungen genutzt werden kann. Und man weiß, welche API die Mehrheit der Drittanbieteranwendungen erwarten wird. Die Einbindung von Patienten in ihre eigene Gesundheitsversorgung war schon immer eine Herausforderung. Um diese Herausforderung zu meistern, benötigt eine Leistungserbringerorganisation Zugang zu den besten Anwendungen auf dem Markt. Sie kann es sich schlicht nicht leisten, sich auf eine begrenzte Auswahl von Anwendungen zu beschränken, die für eine nicht standardisierte API entwickelt wurden.
Elektronischer Patientenzugang zu Gesundheitsinformationen
Maßnahme 1 – Mehr als 80 % aller eindeutigen Patienten, die vom EP behandelt werden (i) Der Patient (oder der vom Patienten bevollmächtigte Vertreter) erhält innerhalb von 24 Stunden nach Verfügbarkeit beim Leistungserbringer Zugang zur Online-Einsicht, zum Herunterladen und zur Übertragung seiner Gesundheitsinformationen; ODER (ii) Dem Patienten (oder dem vom Patienten bevollmächtigten Vertreter) wird Zugang zu einer ONC-zertifizierten API gewährt, die von Drittanbieteranwendungen oder -geräten genutzt werden kann, um Patienten (oder ihren bevollmächtigten Vertretern) innerhalb von 24 Stunden nach Verfügbarkeit beim Leistungserbringer Zugang zu ihren Gesundheitsinformationen zu ermöglichen.
Sie benötigen eine FHIR-API für Ihre Gesundheitsanwendung. Epic, Cerner und andere große Akteure arbeiten seit mindestens einigen Jahren daran. Die erste Phase des Projekts Argonaut startete im Januar 2015. Sie haben bereits erhebliche Zeit und Ressourcen in den Aufbau einer zuverlässigen FHIR-API und deren Erprobung mit anderen Organisationen investiert. Aber was, wenn Ihnen seit 2015 die Ressourcen dafür gefehlt haben? Gibt es einen Weg, ein qualitativ hochwertiges Ergebnis zu erzielen, ohne monatelange wertvolle Entwicklungszeit aufzuwenden?
Einige Kommentatoren äußerten Bedenken hinsichtlich der potenziellen Kosten, die mit der API-Implementierung verbunden sind.
Die von ONC veröffentlichten geschätzten Entwicklungsstunden für API-Anforderungen belaufen sich auf 900–1.200 Stunden ohne relevante Sicherheitsanforderungen und auf 1.200–1.800 Stunden einschließlich relevanter Sicherheitsanforderungen.
Tatsächlich gibt es einen Weg! Health Samurai entwickelt seit 2012 den enterprise-tauglichen FHIR-Server Aidbox. Aidbox entspricht der aktuellsten stabilen FHIR-Spezifikation. Aidbox implementiert einen OAuth 2.0-Autorisierungsanbieter und richtlinienbasierte Zugriffskontrolle. Aidbox arbeitet über HTTPS und verfügt über eine vollständige Protokollierung aller Ereignisse im System. Es erfüllt auch alle Sicherheitsanforderungen für die ONC-zertifizierte API:
- Section 170.315(d)(1) „Authentifizierung, Zugriffskontrolle und Autorisierung;"
- Section 170.315(d)(9) „vertrauenswürdige Verbindung;" und
- Section 170.315(d)(10) „Protokollierung von Aktionen zu Gesundheitsinformationen" oder § 170.315(d)(2) „protokollierbare Ereignisse und Manipulationssicherheit."
Aidbox wird seit seiner Entstehung im Projekt Argonaut erprobt. Health Samurai bietet Aidbox auf Abonnementbasis an, wobei das Abonnement kostengünstig ist.
Health Samurai stellt Ihnen einen qualitativ hochwertigen FHIR-Server zur Verfügung und unterstützt Ihre Entwickler dabei, die Datenbank Ihrer Anwendung mit unserem FHIR-Backend Aidbox zu verbinden. Sie erhalten eine ONC-zertifizierte API für Ihre Gesundheitsanwendung und sind in weniger als einem Monat bereit für Meaningful Use Stage 3.
Health Samurai nimmt aktiv an der HL7 FHIR-Arbeitsgruppe teil und leistet Beiträge zum HL7 FHIR-Standard. Health Samurai hält Aidbox stets aktuell mit der FHIR-Spezifikation, sodass Sie sich nie um die Aktualisierung Ihrer ONC-zertifizierten API sorgen müssen.
Wenn Sie Unterstützung bei einer ONC-zertifizierten API für Ihre Gesundheitsanwendung wünschen, kontaktieren Sie uns bitte unter hello@health-samurai.io oder rufen Sie uns an unter +1.818.731.1279.
Siehe auch: 21st Century Cures Act Compliance und Standardized API for EHRs Cheat Sheet.
