Centers for Medicare and Medicaid Services (CMS) Interoperability and Patient Access rule introduction (Centers for Medicare and Medicaid Services (CMS) Interoperability and Patient Access rule introduction (Centers for Medicare and Medicaid Services (CMS) Interoperability and Patient Access rule introduction

Ważne

Usługa Azure API for FHIR zostanie wycofana 30 września 2026 r. Postępuj zgodnie ze strategiami migracji, aby przejść do usługi Azure Health Data Services FHIR® do tej daty. Ze względu na wycofanie usługi Azure API for FHIR nowe wdrożenia nie będą możliwe od 1 kwietnia 2025 r. Usługa FHIR usług Azure Health Data Services to rozwinięta wersja usługi Azure API for FHIR, która umożliwia klientom zarządzanie usługami FHIR, DICOM i MedTech z integracją z innymi usługami platformy Azure.

W tej serii samouczków omówimy ogólne podsumowanie zasad współdziałania Medicare i Medicaid Services (CMS) oraz wymagania techniczne opisane w tej regule. Omówimy różne przewodniki implementacji, do których odwołuje się ta reguła. Udostępniamy również szczegółowe informacje na temat konfigurowania interfejsu API platformy Azure dla standardu FHIR® w celu obsługi tych przewodników implementacji.

Omówienie reguły

CmS wydało regułę współdziałania i dostępu pacjentów 1 maja 2020 r. Ta zasada wymaga bezpłatnego i bezpiecznego przepływu danych między wszystkimi stronami zaangażowanymi w opiekę nad pacjentami (pacjentami, dostawcami i płatnikami), aby umożliwić pacjentom dostęp do informacji o zdrowiu, gdy ich potrzebują. Współdziałanie nękało branżę opieki zdrowotnej od dziesięcioleci, powodując silosowane dane, które powodują negatywne wyniki zdrowotne z wyższymi i nieprzewidywalnymi kosztami opieki. CMS wykorzystuje swoje uprawnienia do regulowania Medicare Advantage (MA), Medicaid, Children's Health Insurance Program (CHIP) i kwalifikowanych wystawców planu zdrowia (QHP) na federalnych ułatwionych giełdach (FFEs), aby wymusić tę zasadę.

W sierpniu 2020 r. CMS szczegółowo opisał sposób, w jaki organizacje mogą spełnić mandat. Aby zapewnić bezpieczną i ustandaryzowaną wymianę danych, firma CMS zidentyfikowała wersję 4 (R4) w wersji 4 (R4®) zidentyfikowaną przez usługę CMS jako podstawowy standard wymagany do wymiany danych.

Istnieją trzy główne elementy orzeczenia w sprawie współdziałania i dostępu pacjentów:

• Interfejs API dostępu do pacjentów (wymagany 1 lipca 2021 r.) — płatników regulowanych przez cmS (zgodnie z wcześniejszymi definicjami) jest wymagany do zaimplementowania i utrzymania bezpiecznego, opartego na standardach interfejsu API, który umożliwia pacjentom łatwe uzyskiwanie dostępu do oświadczeń i napotykania informacji, w tym kosztów, a także zdefiniowany podzestaw informacji klinicznych przy użyciu wybranych przez siebie aplikacji innych firm.

• Interfejs API katalogów dostawcy (wymagany 1 lipca 2021 r.) — płatników regulowanych przez cmS jest wymagany przez tę część reguły, aby udostępnić informacje o katalogu dostawcy publicznie za pośrednictwem interfejsu API opartego na standardach. Dzięki udostępnieniu tych informacji deweloperzy aplikacji innych firm mogą tworzyć usługi, które pomagają pacjentom znaleźć dostawców dla konkretnych potrzeb opieki i lekarzy znaleźć innych dostawców koordynacji opieki.

• Wymiana danych payer-to-Payer (pierwotnie wymagana 1 stycznia 2022 r. - Obecnie opóźniona) – płatników regulowanych przez CMS są, na wniosek pacjenta, wymagane do wymiany z innymi płatnikami niektórych danych klinicznych pacjentów. Chociaż nie ma potrzeby przestrzegania jakiegokolwiek standardu, zaleca się stosowanie standardu FHIR do wymiany tych danych.

Kluczowe pojęcia dotyczące standardu FHIR

Jak wspomniano wcześniej, FHIR R4 jest wymagany do spełnienia tego mandatu. Ponadto istnieje kilka przewodników implementacji, które zawierają wskazówki dotyczące reguły. Przewodniki implementacji zapewniają dodatkowy kontekst na podstawie podstawowej specyfikacji FHIR. Obejmuje to definiowanie dodatkowych parametrów wyszukiwania, profilów, rozszerzeń, operacji, zestawów wartości i systemów kodu.

Interfejs API platformy Azure dla standardu FHIR ma następujące możliwości, które ułatwiają konfigurowanie bazy danych dla różnych przewodników implementacji.

• Obsługa interakcji RESTful
• Przechowywanie i weryfikowanie profilów
• Definiowanie i indeksowanie niestandardowych parametrów wyszukiwania
• Konwertowanie danych

Przewodniki implementacji interfejsu API dostępu pacjentów

Interfejs API dostępu do pacjentów opisuje przestrzeganie czterech przewodników implementacji FHIR:

• CARIN IG for Blue Button®: Płatniki są zobowiązani do oświadczeń pacjentów i napotkania danych dostępnych zgodnie z CARIN IG for Blue Button Implementation Guide (C4BB IG). Grupa IG C4BB udostępnia zestaw zasobów, które płatniki mogą wyświetlać użytkownikom za pośrednictwem interfejsu API FHIR i zawiera szczegółowe informacje wymagane dla danych oświadczeń w interfejsie API współdziałania i dostępu do pacjentów. W tym przewodniku implementacji użyto zasobu ExplanationOfBenefit (EOB) jako głównego zasobu, pobierając inne zasoby w miarę ich odwołowania.

• HL7 FHIR Da Vinci PDex IG: Payer Data Exchange Implementation Guide (PDex IG) koncentruje się na zapewnieniu, że płatniki dostarczają wszystkie odpowiednie dane kliniczne pacjentów, aby spełnić wymagania interfejsu API dostępu do pacjentów. Korzysta z profilów US Core w zasobach R4 i obejmuje (co najmniej) spotkania, dostawców, organizacji, lokalizacji, dat usługi, diagnoz, procedur i obserwacji. Chociaż te dane mogą być dostępne w formacie FHIR, mogą również pochodzić z innych systemów w formacie danych oświadczeń, komunikatów HL7 V2 i dokumentów C-CDA.

• HL7 US Core IG: HL7 US Core Implementation Guide (US Core IG) jest szkieletem wcześniej opisanego PDex IG. Chociaż protokół PDex IG ogranicza niektóre zasoby jeszcze bardziej niż us Core IG, wiele zasobów przestrzega standardów w us Core IG.

• HL7 FHIR Da Vinci - PDex US Drug Formulary IG: Część D Medicare Advantage plany muszą udostępniać informacje formuł za pośrednictwem interfejsu API pacjenta. Robią to przy użyciu PDex US Drug Formulary Implementation Guide (USDF IG). USDF IG definiuje interfejs FHIR do informacji formuły leków ubezpieczyciela zdrowotnego, który jest listą markowych i ogólnych leków na receptę, za które ubezpieczyciel zdrowotny zgadza się zapłacić. Głównym przypadkiem użycia jest to, aby pacjenci mogli zrozumieć, czy istnieją alternatywne leki dostępne dla jednego, który został im przepisany, i porównać koszty leków.

Przewodnik implementacji interfejsu API katalogu dostawcy

Interfejs API katalogu dostawcy opisuje przestrzeganie jednego przewodnika implementacji.

• HL7 Da Vinci PDex Plan Network IG: Ten przewodnik implementacji definiuje interfejs FHIR dla planów ubezpieczeniowych ubezpieczyciela zdrowotnego, ich skojarzonych sieci oraz organizacji i dostawców, którzy uczestniczą w tych sieciach.

Touchstone

Touchstone to doskonały zasób do testowania przestrzegania różnych przewodników implementacji. W kolejnych samouczkach koncentrujemy się na zapewnieniu, że interfejs API platformy Azure for FHIR został skonfigurowany do pomyślnego przeprowadzenia różnych testów rozwiązania Touchstone. Witryna Touchstone zawiera obszerną dokumentację, która ułatwia rozpoczęcie pracy.

Następne kroki

Teraz, gdy masz podstawową wiedzę na temat reguły współdziałania i dostępu pacjentów, przewodników implementacji i dostępnego narzędzia do testowania (Touchstone), przeprowadzimy cię przez proces konfigurowania interfejsu API platformy Azure for FHIR dla usługi CARIN IG for Blue Button.

Przewodnik implementacji CARIN dla niebieskiego przycisku

Uwaga

FHIR® jest zastrzeżonym znakiem towarowym HL7 i jest używany z uprawnieniem HL7.