Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

Zgoda i model dostępu

Kto co widzi: izolacja projektu, identyfikatory par, przyznania, własność zapisu, pochodzenie i co pacjent widzi o każdej aplikacji z dostępem.

Zasada: za zgodą pacjenta organizacja widzi cały rekord — w tym dane zapisane przez inne kliniki — ale może zmieniać lub usuwać tylko te dane, które sama zapisała. Każda wersja każdego zasobu rejestruje projekt, który go zapisał, oraz organizację, w imieniu której został zapisany.

Kto co widzi

• Projekt (klucz API) widzi pacjentów, których utworzył. W ramach upoważnienia (token OAuth) aplikacja widzi dokładnie jednego pacjenta, niezależnie od wszystkich autorów, ograniczonego do przyznanych zakresów i filtrów kategorii. Wszystko inne zwraca 404, nigdy 403, więc identyfikatorów nie można sondować.
• Identyfikatory parami: każdy projekt otrzymuje własny identyfikator dla tej samej osoby; identyfikatory wewnętrzne nigdy nie opuszczają platformy. Odniesienia do pacjentów spoza Twojego zakresu są maskowane przez nieprzezroczysty, specyficzny dla projektu token.
• Katalog (Organization, Practitioner, PractitionerRole): czytelny po identyfikatorze w całej płaszczyźnie, aby odniesienia się rozwiązywały; przeszukiwalny tylko w ramach Twojego projektu; używalny jako X-Anpheros-Acting-As / X-Anpheros-On-Behalf-Of tylko wtedy, gdy jest Twój.
• Sandbox i produkcja to różne bazy danych. Klucz sandbox fizycznie nie może uzyskać dostępu do prawdziwych pacjentów.

Prawa zapisu i własność

• project_id dla każdej wersji zasobu = autor zapisu. Aktualizacja/usunięcie przez inny projekt → 403 z wyjaśnieniem; zamiast tego zapisz własny zasób.
• Provenance.agent.onBehalfOf = klinika/organizacja w momencie zapisu: X-Anpheros-On-Behalf-Of, w przeciwnym razie organizacja działającego PractitionerRole, w przeciwnym razie organizacja projektu.
• Każdy zapis generuje zasób Provenance i wiersz audytu (kto, co, kiedy, na podstawie jakiego grantu, jakiej aplikacji, z jakiego odcisku palca źródła).

Co widzi pacjent

/me/patients/{id}/grants wymienia każdą aplikację z dostępem, jej zakresy i datę wygaśnięcia; …/access-log wymienia, co każda aplikacja odczytała lub zapisała — w ramach zgody oraz z własnym kluczem projektu. Cofnięcie zgody wchodzi w życie przy następnym żądaniu; aplikacja nie może się ponownie odświeżyć. Dzięki format=fhir dziennik dostępu wraca jako Bundle zasobów FHIR R4 AuditEvent, ukształtowany według IHE Basic Audit Log Patterns (typ rest, interakcja jako podtyp, aplikacja i osoba działająca za jej pośrednictwem jako agenci, pacjent i zasób jako encje, brak danych klinicznych), dzięki czemu inny system może połączyć go z widokiem osoby, która uzyskała dostęp do jej rekordu.

Co rejestruje każdy zasób Provenance i jak go ustawić: Wyjaśnienie pochodzenia danych medycznych.

SMART Health Links (udostępnianie przez QR lub link)

Osoba może udostępnić swój rekord bez pośrednictwa aplikacji: POST /me/patients/{id}/shl tworzy SMART Health Link dla podzbioru emergency (alergie, leki, problemy, szczepienia — bez wyników ani historii) lub pełnego International Patient Summary, z opcjonalnym kodem dostępu i datą ważności. Odpowiedź zawiera URI shlink:/… (dla kodu QR) i adres przeglądarki na /shl/view, który otwiera go w dowolnej przeglądarce. Kto go zeskanuje, wysyła zapytanie na adres URL manifestu i otrzymuje podsumowanie jako JWE (dir + A256GCM) zaszyfrowane kluczem znajdującym się w linku; działa każdy czytnik SMART Health Link.

• Treść jest generowana przy każdym otwarciu (flaga L, status can-change), dzięki czemu karta przechowywana w telefonie pozostaje aktualna.
• Kod dostępu (flaga P) jest sprawdzany na serwerze; po 10 nieudanych próbach link przestaje działać.
• GET /me/patients/{id}/shl zawiera listę linków wraz z informacją, jak często i kiedy każdy z nich został otwarty; …/shl/{link}/revoke pozwala na natychmiastowe wyłączenie jednego z nich. Każde otwarcie jest rejestrowane w logu dostępu.
• Wewnętrzny identyfikator osoby nigdy nie opuszcza platformy: dokument nazywa go pseudonimem linku.

Agenci AI proponują, człowiek decyduje

Za zgodą człowieka, zapis dokonany przez agenta AI (aplikację zarejestrowaną jako agent, na przykład asystenta połączonego przez MCP) lub jakikolwiek zapis z author_type ai nie jest stosowany natychmiast. Platforma go waliduje i odpowiada 202 Accepted z identyfikatorem propozycji (nagłówek Anpheros-Proposal); nic się nie zmienia w rekordzie. Osoba widzi to w GET /me/patients/{id}/proposals — co to jest, która aplikacja to wysłała — i akceptuje lub odrzuca (…/proposals/{proposal}/accept lub …/reject). Zaakceptowana propozycja jest zapisywana dokładnie tak, jak została wysłana, oznaczona jako napisana przez AI (HL7 AI Transparency). Projekty, które mogą zobaczyć rekord, otrzymują cienki proposal.created webhook. Zapisy dokonane za pomocą własnego klucza projektu, w rekordach utworzonych przez projekt, nie są wstrzymywane.

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card