# Tworzenie oprogramowania dla służby zdrowia

> Czym różni się tworzenie oprogramowania medycznego i jak warstwowo zbudowana jest aplikacja medyczna: Twój produkt na górze, Anpheros API, rekord FHIR i zgoda pacjenta poniżej.

Source: https://developers.anpheros.com/pl/guides/healthcare-software

**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](https://developers.anpheros.com/pl/guides/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](https://developers.anpheros.com/pl/guides/consent)

### 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](https://developers.anpheros.com/pl/guides/digital-medical-record)

### 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](https://developers.anpheros.com/pl/guides/ai-healthcare)

## 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](https://developers.anpheros.com/pl/guides/build-with-anpheros)
- Działający samouczek: [Tworzenie aplikacji medycznej](https://developers.anpheros.com/pl/guides/build-a-healthcare-app)
- Obowiązki backendu medycznego: [Backend i baza danych aplikacji medycznej](https://developers.anpheros.com/pl/guides/medical-app-backend)
- Schematy i przepływy danych: [Architektura](https://developers.anpheros.com/pl/guides/architecture)
- Dla zespołów na wczesnym etapie rozwoju: [Startupy medyczne](https://developers.anpheros.com/pl/guides/healthcare-startups)

## Powiązane tematy

- [Infrastruktura danych medycznych](https://developers.anpheros.com/pl/guides/medical-data-infrastructure)
- [API dla ochrony zdrowia](https://developers.anpheros.com/pl/guides/healthcare-api)
- [Bezpieczeństwo, prywatność i rezydencja danych](https://developers.anpheros.com/pl/guides/security)