DiGA y ePA: oportunidades para proveedores de TI

4 min de lectura

Actualizado el 3 de noviembre de 2026 · Publicado originalmente el 8 de mayo de 2026

La historia clínica electrónica ya forma parte de la atención sanitaria cotidiana en toda Alemania. Además, determinadas aplicaciones digitales de salud cuentan con conceptos específicos de facturación médica. Para los proveedores de servicios de TI pueden surgir tareas relacionadas con interfaces, pruebas e integración en programas para consultas médicas. Que esto se traduzca en un encargo depende de las necesidades y los requisitos concretos de cada cliente.

Qué significa la ePA para los proveedores de software para consultas

La ePA para todos comenzó a implantarse en toda Alemania el 29 de abril de 2025. Desde el 1 de octubre de 2025, el personal médico y otros proveedores de servicios sanitarios están obligados a utilizarla. Para las personas aseguradas, el uso sigue siendo voluntario. Pueden oponerse a la creación de la historia clínica o a su uso posterior, explica el Ministerio Federal de Sanidad de Alemania.

Para un proyecto de software, esta diferencia plantea un caso práctico relevante: una consulta puede necesitar la ePA en su flujo de trabajo, mientras que para una persona atendida no existe una historia clínica disponible. La interfaz y los procesos internos deberían gestionar estos casos de forma comprensible. Por este motivo, tampoco es posible deducir el número de historias clínicas utilizadas activamente a partir del número de personas afiliadas al seguro médico obligatorio.

¿Qué es un sistema primario? En el contexto de la ePA, el término designa el software con el que un centro accede a las funciones de la historia clínica, por ejemplo, un sistema de gestión de consultas médicas.

Qué prestaciones relacionadas con las DiGA se remuneran

Las aplicaciones digitales de salud, abreviadas como DiGA, apoyan la atención de determinadas enfermedades. Las prestaciones médicas o psicoterapéuticas que se remuneran adicionalmente dependen de cada aplicación y de las normas de facturación vigentes.

La Asociación Nacional de Médicos del Seguro Obligatorio de Alemania enumera conceptos individuales de facturación. Para la aplicación «Invirto», por ejemplo, describe un concepto de seguimiento y evaluación con requisitos sobre los profesionales facultados para facturarlo. Estos conceptos no constituyen una remuneración general por cualquier acompañamiento de cualquier DiGA.

El baremo unificado de valoración de 2024 ya incluía conceptos de seguimiento y evaluación para determinadas aplicaciones. De ello no puede deducirse un nuevo derecho general a remuneración a partir de abril de 2026. Para los fabricantes y sus socios de TI, el punto de partida es, por tanto, el proceso asistencial concreto de cada aplicación.

Dónde se necesita trabajo concreto sobre interfaces

La guía de implementación de gematik describe distintas interfaces de la ePA. Para el servicio de medicación menciona interfaces FHIR destinadas a gestionar la lista y el plan de medicación. Para la gestión documental describe un perfil del estándar IHE XDS.b. Quien planifique una integración debe examinar, por tanto, el caso de uso correspondiente y las especificaciones aplicables.

Un segundo aspecto que debe comprobarse son los derechos de acceso. Según la guía, el sistema de historias clínicas verifica la autorización de acceso de cada centro. Si no existe autorización o esta se ha retirado, no se pueden leer contenidos ni incorporar documentos. Para el desarrollo, esto significa que las pruebas también deben incluir los accesos denegados y los avisos adecuados al personal de la consulta.

En la guía, gematik hace referencia a un modelo del sistema de historias clínicas de la ePA para fines de desarrollo y prueba. Este modelo puede ayudar en la preparación. Las pruebas y acreditaciones adicionales que necesita un producto concreto deben determinarse para cada tipo de producto.

Cómo pueden evaluar los proveedores posibles encargos

Desde el punto de vista editorial, se plantean tres ámbitos de actuación: la integración en software para consultas, el apoyo técnico a los fabricantes de DiGA y el examen de proyectos concretos de contratación. De ello no se desprende un volumen de encargos acreditado ni una garantía de proyectos futuros.

Antes de presentar una oferta, los proveedores deberían identificar al cliente y el producto afectado. ¿Se trata de mostrar una lista de medicación, intercambiar documentos o desarrollar una función dentro de una DiGA? De ello dependen las interfaces, los derechos de acceso y las pruebas. En una licitación también deben consultarse el alcance de las prestaciones, los requisitos de solvencia y los plazos en los documentos de contratación correspondientes.

Para calcular los costes, conviene aclarar pronto las responsabilidades: ¿quién proporciona el entorno de pruebas? ¿Quién se ocupa de los aspectos funcionales y quién revisa la implementación? Estas preguntas permiten concretar mejor el esfuerzo necesario que una suposición general sobre un mercado en rápido crecimiento.

Preguntas frecuentes

Fuente de la imagen: generada con IA (noviembre de 2026)

Traducido del original en alemán con inteligencia artificial. La versión alemana es la de referencia.