Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
Tworzenie oprogramowania medycznego
Co jest inne w tworzeniu oprogramowania medycznego i jak jest warstwowa aplikacja medyczna: Twój produkt na górze, Anpheros API, rekord FHIR i zgoda pacjenta poniżej.
Oprogramowanie dla służby zdrowia to oprogramowanie, które tworzy, przechowuje lub przetwarza informacje o stanie zdrowia ludzi – aplikacje dla pacjentów, narzędzia kliniczne, systemy laboratoryjne, usługi zdalnego monitorowania, asystenci AI. Tym, co odróżnia je od innego oprogramowania, nie jest interfejs użytkownika, ale dane: są one wrażliwe, długoterminowe, standaryzowane, udostępniane między organizacjami i podlegają zgodzie. Anpheros to infrastruktura dla tej warstwy danych; ta strona wyjaśnia warstwy aplikacji medycznej i które z nich Anpheros może zapewnić.
Ogólna architektura
Healthcare application your product: UI, workflows, notifications, business rules
↓
Anpheros API REST v1 and FHIR R4, OAuth 2.1 / SMART on FHIR, webhooks, SDKs
↓
FHIR medical data one HL7 FHIR R4 record per patient, versioned, with provenance
↓
Consent / authorisation per-application grants chosen and revocable by the patient
Twoja aplikacja zarządza doświadczeniem użytkownika; Anpheros zarządza rekordem i zasadami z nim związanymi.
Czym różni się tworzenie oprogramowania medycznego
Model danych to standard, a nie wybór projektowy
Inne oprogramowanie może wymyślać własne schematy. Oprogramowanie medyczne, które wymyśla własny schemat, nie może wymieniać danych z laboratoriami, klinikami ani innymi aplikacjami bez projektu tłumaczeniowego. Używanie zasobów HL7 FHIR R4 i standardowych kodów (LOINC, ICD-10, ATC, UCUM) od pierwszej linii kodu pozwala tego uniknąć. Platforma FHIR
Każda wartość potrzebuje źródła
Wartość glukozy wpisana przez pacjenta, zmierzona przez urządzenie, zaimportowana z raportu laboratoryjnego lub wygenerowana przez model AI ma różne znaczenia. Anpheros rejestruje typ autora (pacjent, praktykujący lekarz, urządzenie, import, AI), organizację i system źródłowy dla każdego zapisu, a także przechowuje każdą wersję.
Dostęp jest decydowany przez pacjenta, nie tylko przez aplikację
Oprócz logowania użytkownika i ról, oprogramowanie medyczne wymaga zgody: która aplikacja może odczytywać którą część rekordu której osoby, na jak długo, oraz audytu, który osoba może zobaczyć. Model zgody i dostępu
Dane muszą przetrwać aplikację
Zapisy są przechowywane przez lata i przenoszone między dostawcami. Oddzielenie rekordu (infrastruktury) od aplikacji oznacza, że przeprojektowanie, nowa aplikacja lub nowy partner nie wymaga migracji danych medycznych. Infrastruktura cyfrowego rekordu medycznego
Twórz i testuj bez prawdziwych pacjentów
Prawdziwe dane medyczne nie powinny znajdować się w środowiskach deweloperskich. Anpheros posiada piaskownicę (sandbox) – oddzielną bazę danych z syntetycznymi pacjentami – oraz klucze piaskownicy, które fizycznie nie mogą uzyskać dostępu do danych produkcyjnych.
AI potrzebuje tych samych zasad co wszyscy inni
Funkcja AI jest kolejnym czytelnikiem rekordu. Powinna otrzymywać tylko to, na co pozwolił pacjent, wraz ze źródłami, a jej wyniki powinny być oznaczone jako wygenerowane przez AI. Aplikacje AI w opiece zdrowotnej
Co budujesz i co zapewnia Anpheros
| Warstwa | Ty budujesz | Anpheros zapewnia |
|---|---|---|
| Doświadczenie użytkownika | ekrany, przepływy, powiadomienia, treści kliniczne | — |
| Twoi użytkownicy i konta | rejestracja, logowanie, role w Twoim produkcie | zgoda na dostęp do danych na pacjenta; logowanie pacjenta na stronie zgody |
| Przechowywanie danych medycznych | — | rekord FHIR R4, 26 typów zasobów, historia, dokumenty |
| Kodowanie | wybór tego, co rejestrować | standardowe systemy kodowania, wyszukiwanie LOINC w pakiecie |
| Kontrola dostępu do rekordów | który z Twoich użytkowników widzi którego pacjenta | izolacja projektu, identyfikatory par, zakresy OAuth |
| Audyt | — | pochodzenie zapisów, dziennik dostępu widoczny dla pacjenta |
| Integracja | specyfika Twoich partnerów | import wyników badań laboratoryjnych, transakcje FHIR, webhooks, SDK |
| AI | prompty, wybór modelu, bezpieczeństwo Twojej funkcji | API kontekstowe z budżetami tokenów i etykietami pochodzenia |
| Zgodność | Twoje obowiązki regulacyjne i bezpieczeństwo kliniczne | rezydencja danych w UE, szyfrowanie dokumentów kluczem zarządzanym przez klienta, umowa o przetwarzaniu danych dla produkcji |
Dalsze kroki
- Ścieżka krok po kroku od dostępu do produkcji: Budowanie z Anpheros
- Działający samouczek: Tworzenie aplikacji medycznej
- Obowiązki backendu medycznego: Backend i baza danych aplikacji medycznej
- Schematy i przepływy danych: Architektura
- Dla zespołów na wczesnym etapie rozwoju: Startupy medyczne
Powiązane tematy
- Infrastruktura danych medycznych
- API dla ochrony zdrowia
- Bezpieczeństwo, prywatność i rezydencja danych
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card