# Entwicklung von Gesundheitssoftware

> Was ist anders bei der Entwicklung medizinischer Software und wie eine Gesundheitsanwendung aufgebaut ist: Ihr Produkt oben, die Anpheros API, der FHIR-Datensatz und die Patienteneinwilligung darunter.

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

**Gesundheitssoftware ist Software, die Informationen über die Gesundheit von Menschen erstellt, speichert oder verarbeitet – Patienten-Apps, Kliniktools, Laborsysteme, Fernüberwachungsdienste, KI-Assistenten.** Was sie von anderer Software unterscheidet, ist nicht die Benutzeroberfläche, sondern die Daten: Sie sind sensibel, langlebig, standardisiert, werden zwischen Organisationen ausgetauscht und unterliegen der Einwilligung. Anpheros ist die Infrastruktur für diese Datenebene; diese Seite erklärt die Ebenen einer Gesundheitsanwendung und welche davon Anpheros bereitstellen kann.

## Die allgemeine Architektur

```
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
```

Ihre Anwendung besitzt die Benutzererfahrung; Anpheros besitzt den Datensatz und die Regeln dazu.

## Was ist anders beim Erstellen von medizinischer Software

### Das Datenmodell ist ein Standard, keine Designentscheidung
Andere Software kann ihr eigenes Schema erfinden. Medizinische Software, die ihr eigenes Schema erfindet, kann ohne ein Übersetzungsprojekt keine Daten mit Laboren, Kliniken oder anderen Anwendungen austauschen. Die Verwendung von HL7 FHIR R4 Ressourcen und Standardcodes (LOINC, ICD-10, ATC, UCUM) von der ersten Codezeile an vermeidet dies. [FHIR-Plattform](https://developers.anpheros.com/de/guides/fhir)

### Jeder Wert benötigt eine Quelle
Ein Glukosewert, der von einem Patienten eingegeben, von einem Gerät gemessen, aus einem Laborbericht importiert oder von einem KI-Modell generiert wurde, bedeutet unterschiedliche Dinge. Anpheros erfasst den Autorentyp (Patient, Praktiker, Gerät, Import, KI), die Organisation und das Quellsystem für jeden Schreibvorgang und behält jede Version bei.

### Der Zugriff wird vom Patienten entschieden, nicht nur von der Anwendung
Über Benutzeranmeldung und Rollen hinaus benötigt medizinische Software die Zustimmung: welche Anwendung welche Teile welcher Personendaten lesen darf, wie lange, und eine Überprüfung, die die Person einsehen kann. [Zustimmungs- und Zugriffsmodell](https://developers.anpheros.com/de/guides/consent)

### Daten müssen die Anwendung überdauern
Aufzeichnungen werden jahrelang aufbewahrt und zwischen Anbietern ausgetauscht. Die Trennung der Aufzeichnung (Infrastruktur) von der Anwendung bedeutet, dass eine Neugestaltung, eine neue App oder ein neuer Partner keine Migration medizinischer Daten erfordert. [Infrastruktur für digitale medizinische Aufzeichnungen](https://developers.anpheros.com/de/guides/digital-medical-record)

### Entwickeln und testen ohne echte Patienten
Echte medizinische Daten sollten nicht in Entwicklungsumgebungen vorhanden sein. Anpheros verfügt über eine Sandbox – eine separate Datenbank mit synthetischen Patienten – und Sandbox-Schlüssel, die physisch keine Produktionsdaten erreichen können.

### KI benötigt die gleichen Regeln wie alle anderen
Eine KI-Funktion ist ein weiterer Leser der Aufzeichnung. Sie sollte nur das erhalten, was der Patient erlaubt hat, mit Quellen, und ihre Ausgaben sollten als KI-generiert gekennzeichnet werden. [KI-Gesundheitsanwendungen](https://developers.anpheros.com/de/guides/ai-healthcare)

## Was Sie erstellen und was Anpheros bereitstellt

| Ebene | Sie erstellen | Anpheros stellt bereit |
|---|---|---|
| Benutzererlebnis | Bildschirme, Abläufe, Benachrichtigungen, klinische Inhalte | — |
| Ihre Benutzer und Konten | Registrierung, Anmeldung, Rollen in Ihrem Produkt | Einwilligung pro Patient für Datenzugriff; Patientenanmeldung auf der Einwilligungsseite |
| Speicherung medizinischer Daten | — | FHIR R4-Datensatz, 26 Ressourcentypen, Verlauf, Dokumente |
| Kodierung | Auswahl dessen, was aufgezeichnet wird | Standard-Codesysteme, gebündelte LOINC-Suche |
| Zugriffskontrolle auf Datensätze | welche Ihrer Benutzer welchen Patienten sieht | Projektisolation, paarweise IDs, OAuth-Scopes |
| Audit | — | Herkunft bei Schreibvorgängen, für den Patienten sichtbarer Zugriffslog |
| Integration | Spezifika Ihrer Partner | Laborimport, FHIR-Transaktionen, Webhooks, SDKs |
| KI | Prompts, Modellauswahl, Sicherheit Ihrer Funktion | Kontext-API mit Token-Budgets und Herkunfts-Labels |
| Compliance | Ihre regulatorischen Verpflichtungen und klinische Sicherheit | EU-Datenspeicherung, Verschlüsselung von Dokumenten mit einem kundenseitig verwalteten Schlüssel, eine Datenverarbeitungsvereinbarung für die Produktion |

## Nächste Schritte

- Ein schrittweiser Weg vom Zugriff zur Produktion: [Build with Anpheros](https://developers.anpheros.com/de/guides/build-with-anpheros)
- Ein funktionierendes Tutorial: [Eine Gesundheits-App erstellen](https://developers.anpheros.com/de/guides/build-a-healthcare-app)
- Die Verantwortlichkeiten eines medizinischen Backends: [Medizinisches App-Backend und Datenbank](https://developers.anpheros.com/de/guides/medical-app-backend)
- Diagramme und Datenflüsse: [Architektur](https://developers.anpheros.com/de/guides/architecture)
- Für Teams in der Anfangsphase: [Gesundheits-Startups](https://developers.anpheros.com/de/guides/healthcare-startups)

## Verwandte Themen

- [Medizinische Dateninfrastruktur](https://developers.anpheros.com/de/guides/medical-data-infrastructure)
- [Healthcare API](https://developers.anpheros.com/de/guides/healthcare-api)
- [Sicherheit, Datenschutz und Datenresidenz](https://developers.anpheros.com/de/guides/security)