# Desarrollo de software sanitario

> ¿Qué tiene de diferente la creación de software médico y cómo se estructura una aplicación sanitaria: su producto en la parte superior, la API de Anpheros, el registro FHIR y el consentimiento del paciente debajo.

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

El **software sanitario** es software que crea, almacena o actúa sobre información sobre la salud de las personas: aplicaciones para pacientes, herramientas de clínica, sistemas de laboratorio, servicios de monitorización remota, asistentes de IA. Lo que lo diferencia de otro software no es la interfaz de usuario, sino los datos: son sensibles, de larga duración, estandarizados, compartidos entre organizaciones y sujetos a consentimiento. Anpheros es la infraestructura para esa capa de datos; esta página explica las capas de una aplicación sanitaria y cuáles de ellas puede proporcionar Anpheros.

## La arquitectura general

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

Tu aplicación posee la experiencia; Anpheros posee el registro y las reglas asociadas a él.

## ¿Qué es diferente al crear software médico?

### El modelo de datos es un estándar, no una elección de diseño
Otro software puede inventar su esquema. El software médico que inventa su propio esquema no puede intercambiar datos con laboratorios, clínicas u otras aplicaciones sin un proyecto de traducción. Usar recursos de HL7 FHIR R4 y códigos estándar (LOINC, ICD-10, ATC, UCUM) desde la primera línea de código evita eso. [Plataforma FHIR](https://developers.anpheros.com/es/guides/fhir)

### Cada valor necesita una fuente
Un valor de glucosa introducido por un paciente, medido por un dispositivo, importado de un informe de laboratorio o producido por un modelo de IA significa cosas diferentes. Anpheros registra el tipo de autor (paciente, profesional, dispositivo, importación, IA), la organización y el sistema de origen para cada escritura, y conserva cada versión.

### El acceso lo decide el paciente, no solo la aplicación
Más allá del inicio de sesión y los roles del usuario, el software médico necesita consentimiento: qué aplicación puede leer qué parte del registro de qué persona, durante cuánto tiempo, y una auditoría que la persona pueda ver. [Modelo de consentimiento y acceso](https://developers.anpheros.com/es/guides/consent)

### Los datos deben sobrevivir a la aplicación
Los registros se conservan durante años y se mueven entre proveedores. Separar el registro (infraestructura) de la aplicación significa que un rediseño, una nueva aplicación o un nuevo socio no requieren la migración de datos médicos. [Infraestructura de registro médico digital](https://developers.anpheros.com/es/guides/digital-medical-record)

### Desarrollar y probar sin pacientes reales
Los datos médicos reales no deben estar en entornos de desarrollo. Anpheros tiene un sandbox —una base de datos separada con pacientes sintéticos— y claves de sandbox que físicamente no pueden acceder a los datos de producción.

### La IA necesita las mismas reglas que todos los demás
Una función de IA es otro lector del registro. Debe recibir solo lo que el paciente permitió, con fuentes, y sus resultados deben etiquetarse como generados por IA. [Aplicaciones de IA en salud](https://developers.anpheros.com/es/guides/ai-healthcare)

## Lo que usted construye y lo que Anpheros proporciona

| Capa | Usted construye | Anpheros proporciona |
|---|---|---|
| Experiencia de usuario | pantallas, flujos, notificaciones, contenido clínico | — |
| Sus usuarios y cuentas | registro, inicio de sesión, roles en su producto | consentimiento por paciente para el acceso a datos; inicio de sesión del paciente en la página de consentimiento |
| Almacenamiento de datos médicos | — | Registro FHIR R4, 26 tipos de recursos, historial, documentos |
| Codificación | elección de qué registrar | sistemas de códigos estándar, búsqueda LOINC agrupada |
| Control de acceso a registros | qué usuarios suyos ven a qué pacientes | aislamiento de proyectos, identificadores por pares, ámbitos OAuth |
| Auditoría | — | procedencia en escrituras, registro de acceso visible para el paciente |
| Integración | especificaciones de sus socios | importación de laboratorio, transacciones FHIR, webhooks, SDKs |
| IA | indicaciones, elección de modelo, seguridad de su función | API de contexto con presupuestos de tokens y etiquetas de procedencia |
| Cumplimiento | sus obligaciones regulatorias y seguridad clínica | residencia de datos en la UE, cifrado de documentos con una clave gestionada por el cliente, un acuerdo de procesamiento de datos para producción |

## Próximos pasos

- Un camino paso a paso desde el acceso hasta la producción: [Build with Anpheros](https://developers.anpheros.com/es/guides/build-with-anpheros)
- Un tutorial funcional: [Build a healthcare app](https://developers.anpheros.com/es/guides/build-a-healthcare-app)
- Las responsabilidades de un backend médico: [Medical app backend and database](https://developers.anpheros.com/es/guides/medical-app-backend)
- Diagramas y flujos de datos: [Architecture](https://developers.anpheros.com/es/guides/architecture)
- Para equipos en etapas tempranas: [Healthcare startups](https://developers.anpheros.com/es/guides/healthcare-startups)

## Relacionado

- [Infraestructura de datos médicos](https://developers.anpheros.com/es/guides/medical-data-infrastructure)
- [API de salud](https://developers.anpheros.com/es/guides/healthcare-api)
- [Seguridad, privacidad y residencia de datos](https://developers.anpheros.com/es/guides/security)