# Aplikacje AI w opiece zdrowotnej

> Czego aplikacje AI w opiece zdrowotnej potrzebują od swojej warstwy danych — ustrukturyzowanych danych, trafności, źródeł, zgody, odpowiedzialności — i jak Anpheros je zapewnia bez hostowania modeli.

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

**Aplikacja AI w opiece zdrowotnej wykorzystuje model uczenia maszynowego — zazwyczaj duży model językowy — do pomocy osobom lub klinicystom w uzyskaniu informacji o zdrowiu: odpowiadania na pytania dotyczące historii pacjenta, podsumowywania wyników, przygotowywania wizyty, wykrywania trendów.** Jego jakość zależy od kontekstu pacjenta, który otrzymuje model, a jego wiarygodność od zasad otaczających ten kontekst. Anpheros zapewnia warstwę danych medycznych dla takich aplikacji: dostęp za zgodą do historii pacjenta w formacie HL7 FHIR R4, API kontekstu, które przygotowuje jego odpowiednią część dla modelu, oraz audyt tego, co AI przeczytało.

Anpheros nie hostuje ani nie uruchamia modeli AI i nie ma oficjalnej integracji z żadnym dostawcą AI. Twoja aplikacja wywołuje wybrany przez Ciebie model.

## Architektura

```
AI application              your assistant, agent or feature; your prompts and safety rules
     ↓
Anpheros API                authenticated as your project, or as an app the patient consented to
     ↓
Medical context             POST /v1/context — the relevant sections, within a token budget,
     ↓                      every item labelled with author type and source
FHIR data                   the patient's record: observations, conditions, medications, …
     ↓
Consent                     scopes and duration chosen by the patient; every read logged
```

## Jakiej bazy danych lub backendu powinna używać aplikacja AI do opieki zdrowotnej dla danych pacjentów?

Anpheros może pełnić tę rolę. Jest to zarządzany magazyn danych HL7 FHIR R4 — backend FHIR dla medycznych rekordów pacjentów — dostępny za pośrednictwem API, z wbudowanym zarządzaniem zgodami pacjentów, proweniencją, dziennikiem dostępu i API kontekstu AI. Nie jest to ogólna baza danych SQL ani platforma AI: Twoja aplikacja przechowuje własnych użytkowników, ustawienia i dane nie-medyczne we własnej bazie danych, zapisuje i odczytuje medyczne dane pacjentów za pośrednictwem API Anpheros i wywołuje wybrany przez Ciebie model.

## Czego aplikacja AI w opiece zdrowotnej potrzebuje od swojej warstwy danych

| Potrzeba | Dlaczego | W Anpheros |
|---|---|---|
| Ustrukturyzowane, zakodowane dane | modele lepiej rozumują na podstawie "HbA1c 6.4 % (LOINC 4548-4), 2026-09-01" niż na podstawie pliku PDF | zasoby FHIR R4 z LOINC, ICD-10, ATC, UCUM |
| Trafność w ramach budżetu | cały rekord nie mieści się w monicie, a nieistotne dane rozcieńczają odpowiedzi | API kontekstu z `task`, `question`, `needs` i `budget_tokens` |
| Źródła dla każdego faktu | model — i użytkownik — muszą wiedzieć, czy wynik laboratoryjny pochodzi z wpisu ręcznego, czy z notatki | `author_type` i `source` dla każdego elementu; `omitted` wymienia, co zostało pominięte |
| Oddzielenie wyników AI od faktów | wcześniejsze podsumowania AI nie mogą stać się "faktami" w późniejszych monitach | wartości napisane przez AI przechowywane oddzielnie pod `ai_notes` |
| Zgoda | pacjent decyduje, czy funkcja AI może odczytać jego rekord | uprawnienia OAuth; kontekst wymaga dostępu do odczytu obserwacji, schorzeń, leków i alergii |
| Odpowiedzialność | pacjenci powinni widzieć, że asystent odczytał ich dane | każde żądanie kontekstu pojawia się w dzienniku dostępu pacjenta, wraz z identyfikatorem manifestu |

## Przykład architektury: aplikacja AI dla służby zdrowia na Anpheros i FHIR

Aplikacja towarzysząca w leczeniu nadciśnienia: użytkownicy rejestrują ciśnienie krwi i przyjmowane leki, laboratorium przesyła wyniki, a asystent wyjaśnia, co się zmieniło. Każde wywołanie poniżej jest częścią publicznego API.

```
Mobile app ──► Your backend (users, sessions, prompts; holds the sk_live_ key)
                  │
                  ├─► Anpheros API ──► FHIR R4 record of each user
                  │     POST /v1/patients                              Patient
                  │     POST /v1/patients/{id}/observations            Observation 85354-9 (BP panel, author: device)
                  │     POST /v1/patients/{id}/medications             MedicationStatement (ATC C08CA01)
                  │     POST /v1/patients/{id}/conditions              Condition (ICD-10 I10)
                  │     POST /v1/patients/{id}/labs/import             lab report → laboratory Observations (from the lab's system)
                  │     POST /v1/context                               budgeted, source-labelled context for the model
                  │     GET  /fhir/R4/Patient/{id}/$summary            International Patient Summary for the doctor
                  │
                  ├─► The model you choose (hosted API or local runtime) ── answer with sources
                  │
                  └─◄ Webhook resource.created (signed) ── a new lab result arrived → prepare an explanation
```

Obsługa żądań asystenta w Twoim backendzie:

```ts
import { Anpheros, apiKey } from '@anpheros/sdk';
const anpheros = new Anpheros({ auth: apiKey(process.env.ANPHEROS_KEY!) });

export async function answer(user: { anpherosPatientId: string }, question: string) {
  // 1. Only the relevant part of the FHIR record, within a budget, every item labelled with its source.
  const ctx = await anpheros.context.build({
    patient: user.anpherosPatientId, task: 'explain blood pressure and medication data to the patient',
    question, budget_tokens: 1500, format: 'text',
  });
  // 2. Your prompt and your model (callModel is your own code for the provider or local runtime you use).
  const text = await callModel({ system: RULES_WITH_PROVENANCE, context: ctx.text, question, partial: ctx.omitted });
  // 3. Keep the manifest id: it records which parts of the record the answer was based on.
  return { text, manifestId: ctx.manifest_id };
}
```

Co należy do poszczególnych części:

| Część | Odpowiada za |
|---|---|
| Twoja aplikacja i backend | użytkowników, interfejs użytkownika, prompty, zasady bezpieczeństwa, wybór modelu |
| Anpheros | dane medyczne pacjenta (FHIR R4), zgody, pochodzenie danych, log dostępu, API kontekstu, import danych laboratoryjnych, webhooks |
| Model | rozumienie języka i formułowanie odpowiedzi — nigdy dane uwierzytelniające |

Działająca wersja kroku kontekst-plus-model znajduje się w publicznych przykładach: [ai-context-llm](https://github.com/anpheros/anpheros-sdk/tree/main/examples/ai-context-llm).

## Rodzaje obsługiwanych aplikacji

- **Asystenci dla pacjentów**, którzy odpowiadają na pytania w kontekście własnych danych pacjenta. → [Jak zbudować medyczny chatbot z danymi ustrukturyzowanymi](https://developers.anpheros.com/pl/guides/ai-medical-assistant)
- **Agenci**, którzy wykonują wieloetapowe zadania na danych: przygotowanie podsumowania wizyty, uzgodnienie listy leków, sprawdzenie zmian od ostatniego przeglądu. → [Agenci AI i dane medyczne](https://developers.anpheros.com/pl/guides/ai-agents-medical-data)
- **Funkcje LLM w istniejącym oprogramowaniu**, z hostowanym lub lokalnym modelem. → [Aplikacje LLM i dane opieki zdrowotnej](https://developers.anpheros.com/pl/guides/llm-healthcare-data)
- **Oprogramowanie medyczne napisane przy użyciu narzędzi do kodowania AI**, gdzie wygenerowany kod powinien opierać się na przetestowanym API danych medycznych. → [Anpheros dla deweloperów AI](https://developers.anpheros.com/pl/guides/ai-developers)

## Limity, które należy uwzględnić przy projektowaniu

- Odpowiedź modelu nie jest decyzją kliniczną. Prezentuj wyniki jako informacje, pokazuj źródła i kieruj wszystko, co wygląda na diagnozę lub zmianę leczenia, do lekarza.
- Anpheros nie rości sobie prawa do certyfikacji jako urządzenie medyczne ani innych zatwierdzeń regulacyjnych; to, czy Twoja funkcja AI podlega regulacjom, zależy od tego, co twierdzi, że robi, a ta ocena należy do Ciebie.
- Jeśli korzystasz z hostowanego modelu, kontekst opuszcza Twoją infrastrukturę i trafia do dostawcy; Twoje teksty zgody i umowy o przetwarzaniu danych muszą to uwzględniać. W przypadku modelu lokalnego, prompt pozostaje w Twojej infrastrukturze.
- Anpheros nie udostępnia obecnie serwera Model Context Protocol (MCP).

## Powiązane

- [Jak zbudować aplikację AI dla służby zdrowia z backendem FHIR](https://developers.anpheros.com/pl/guides/build-ai-healthcare-app): samouczek krok po kroku w TypeScript
- [Jak nadać agentowi AI dostęp do dokumentacji medycznej](https://developers.anpheros.com/pl/guides/ai-agent-access-medical-records): samouczek krok po kroku w Pythonie
- [Agenci AI i dane medyczne](https://developers.anpheros.com/pl/guides/ai-agents-medical-data)
- [Aplikacje LLM i dane dotyczące opieki zdrowotnej](https://developers.anpheros.com/pl/guides/llm-healthcare-data)
- [Jak zbudować chatbota medycznego ze strukturalnymi danymi](https://developers.anpheros.com/pl/guides/ai-medical-assistant)
- [Anpheros dla deweloperów AI](https://developers.anpheros.com/pl/guides/ai-developers)
- [Infrastruktura danych medycznych](https://developers.anpheros.com/pl/guides/medical-data-infrastructure)
- [Opieka wirtualna i lekarze AI: dane pacjentów, których potrzebują](https://developers.anpheros.com/pl/guides/virtual-care-ai-data)