ContacteIntroducció
Els Architecture Decision Records (ADRs) del Departament de Salut recullen les decisions d’arquitectura de referència de caràcter obligatori per a tots els proveïdors. Estan basats en el Manifest d’Arquitectura de Referència de Salut (versió 01-12-2025).
Infraestructura i Cloud
ADR-001 — Desplegament obligatori en hiperescalars de núvol públic
Context
Les solucions del Departament de Salut han de garantir alta disponibilitat, elasticitat i eficiència en cost. Els entorns on-premises tradicionals no permeten l’autoescalat ni el model de despesa per consum necessari per a serveis sanitaris amb demanda variable.
Decisió
Tots els components de presentació i negoci s’han de desplegar en hiperescalars de núvol públic (AWS, Azure o Google Cloud), sota un model cloud-native.
Conseqüències
- El proveïdor d’aplicació és responsable únic de la configuració, instal·lació i monitoratge end-to-end.
- El proveïdor ha de garantir que no es generin costos inesperats per mala definició d’IaC.
- Calen coneixements de cloud públic en tots els equips de desenvolupament.
Alternatives considerades
- Núvol privat CTTI — descartat per limitacions d’elasticitat i autoescalat.
- Infraestructura on-premises — descartada per model CapEx i impossibilitat d’escalar per demanda.
ADR-002 — Alta disponibilitat multizona obligatòria en totes les capes
Context
Els serveis de salut requereixen la màxima disponibilitat. Una caiguda d’un centre de dades o zona de disponibilitat no pot afectar la continuïtat operativa dels sistemes crítics sanitaris.
Decisió
Totes les capes (frontend, backend, base de dades) han d’implementar alta disponibilitat multizona amb distribució balancejada de recursos en diferents ubicacions.
Conseqüències
- Requereix disseny d’arquitectura actiu-actiu o actiu-passiu entre zones.
- Increment de cost d’infraestructura (compensat per reducció de risc operatiu).
- Les bases de dades han de tenir replicació síncrona o quasisíncrona entre zones.
ADR-003 — Autoescalat horitzontal/vertical i aturada d’entorns no productius
Context
El model de despesa fixa (CapEx) implica sobreaprovisionament de recursos. La variabilitat de la demanda dels serveis sanitaris fa imprescindible un model elàstic i sostenible.
Decisió
Tots els sistemes han de configurar autoescalat horitzontal o vertical. Els entorns no productius s’han d’aturar automàticament fora d’horari laboral per estalvi de recursos.
Conseqüències
- Model de despesa OpEx (consum real) en lloc de CapEx (reserva fixa).
- Cal definir polítiques d’escala (mètriques, thresholds, cooldowns) per cada servei.
- Els entorns de dev/pre han de tenir schedules d’arrencada/aturada configurats.
Arquitectura de Frontals Web
ADR-004 — React com a framework únic per a frontals web
Context
L’ecosistema de frontals de Salut conté múltiples solucions que han d’integrar-se en forma de pàgina única. La diversitat de frameworks (Angular, Vue, React…) dificulta la integració, augmenta la càrrega de manteniment de versions i impedeix la reutilització de components.
Decisió
Tots els nous frontals web han d’estar basats en React. No s’acceptaran propostes amb altres frameworks sense justificació d’innovació aprovada per l’Àrea d’Arquitectura.
Conseqüències
- Facilita la integració de microfrontals com a Single-SPA.
- Permet compartir el Design System de Salut entre totes les solucions.
- Els proveïdors han de garantir experiència en React i l’ecosistema associat.
Alternatives considerades
- Angular — rebutjat per incompatibilitat amb microfrontal basat en Single-SPA de l’ecosistema actual.
- Vue.js — rebutjat per menor adopció interna i dificultat d’integració consistent.
ADR-005 — Single-SPA per a microfrontals i Design System de Salut per a components gràfics
Context
Les solucions de Salut estan formades per múltiples equips que desenvolupen mòduls independents. Cal un mecanisme estandarditzat per compondre aquests mòduls en una experiència d’usuari unificada i consistent.
Decisió
El component Shell principal que hostatja microfrontals ha d’implementar-se obligatòriament amb Single-SPA. Tots els components gràfics han d’utilitzar la llibreria del Design System de Salut.
Conseqüències
- Consistència visual garantida a través de totes les aplicacions de Salut.
- Desplegament independent de cada microfrontal sense afectar els altres.
- Cal formació en Single-SPA per als equips de frontend.
Referències
Arquitectura de Components de Negoci
ADR-006 — Arquitectura desacoblada en capes: presentació, negoci i dades
Context
Les arquitectures monolítiques impedeixen l’escalabilitat independent de capes, dificulten el manteniment i la substitució de components, i creen punts de fallida únics en tot el sistema.
Decisió
Totes les iniciatives o dominis funcionals han de presentar una arquitectura desacoblada entre presentació, negoci i dades. Cada capa ha de poder actualitzar-se o substituir-se de forma autònoma.
Conseqüències
- Contractes d’API clars entre capes (OpenAPI 3 per a interfícies REST).
- Possibilitat de desplegaments independents per capa.
- Increment de complexitat inicial en el disseny.
ADR-007 — Contenidors gestionats o funcions serverless per a serveis de backend
Context
La gestió manual d’infraestructura de contenidors (control-plane) suposa una càrrega operativa elevada per als equips de proveïdors. Cal prioritzar solucions que redueixin la superfície de gestió.
Decisió
Per a contenidors, es prioritzaran ECS Fargate o EKS Fargate (AWS), Container Apps o AKS (Azure), Cloud Run o GKE (Google Cloud). S’accepten funcions serverless per processos adequats a aquest model.
Conseqüències
- Reducció de responsabilitat operativa en la capa de control-plane.
- Els equips es centren en el codi d’aplicació, no en la gestió de nodes/workers.
- Cal definir límits de CPU/memòria adequats per evitar sobre-costos.
ADR-008 — API REST amb especificació OpenAPI 3 per a interacció síncrona
Context
La interoperabilitat entre sistemes de salut és crítica. Calen contractes d’API ben definits, documentats i versionats per garantir integracions robustes entre les diverses iniciatives del Departament.
Decisió
La interacció síncrona entre sistemes s’ha de basar en API REST. La implementació ha de possibilitar la generació de la documentació com a codi (code-first o design-first) segons l’especificació OpenAPI 3. Les principals fonts de dades interoperen amb FHIR, openEHR, HL7 o IHE.
Conseqüències
- La documentació d’API es genera automàticament des del codi o la spec OAS3.
- Els canvis trencadors en l’API han de gestionar-se amb versionat adequat.
- Les APIs han de publicar-se a l’API Manager CTTI.
Referències
ADR-009 — Kafka Eventhub per a interacció asíncrona entre sistemes
Context
Moltes integracions entre sistemes de salut (CDC, ETL, events clínics) requereixen un model de comunicació asíncrona per garantir desacoblament, durabilitat de missatges i tolerància a fallades.
Decisió
La interacció asíncrona s’ha d’implementar sobre la plataforma corporativa Eventhub basada en Confluent Kafka, amb autorització OAuth i esquemes JSON/AVRO. Cal revisar la configuració de throughput per no saturar els recursos del broker.
Avís de migració (2025)
La plataforma Eventhub es troba en procés de migració de mTLS a OAuth com a mecanisme d’autenticació. mTLS queda deprecat i no s’acceptarà en cap nou desenvolupament. Els sistemes existents han d’actualitzar-se a OAuth dins del termini establert per la plataforma.
Conseqüències
- Els connectors Kafka Connect oficials gestionen les integracions amb Oracle, MongoDB, Postgres…
- Els processos analítics han d’executar-se en infraestructures desacoblades dels transaccionals.
- Cal definir les polítiques de retenció, particions i grups de consumidors.
- Tots els nous clients Kafka han de configurar autenticació OAuth; no s’aprovarà configuració mTLS en revisions d’arquitectura.
Referències
Arquitectura de Base de Dades
ADR-010 — MongoDB Atlas DBaaS com a motor de BD operacional de referència
Context
Les arquitectures de microserveis generen i consumeixen objectes de dades de format variable. Cal un motor de BD operacional que s’adapti a models flexibles, amb alta disponibilitat gestionada, escalabilitat automàtica i despesa per consum.
Decisió
MongoDB Atlas en modalitat DBaaS és el motor de base de dades operacional de referència per a qualsevol nova iniciativa. La cadena de connexió ha d’utilitzar adreces privades (Private Endpoints) dins el proveïdor cloud, evitant l’accés per Internet.
Justificació
- Models no estructurats i flexibles, ideals per a arquitectures de serveis.
- Alta disponibilitat multi-zona o multi-cloud. Autoescalament vertical. OpEx.
- OPS gestionades: BYOK, online archiving, point-in-time recovery, aturada programada.
- Query Insights, Performance Advisor i suport Professional/Enterprise.
- Vector Search per integracions d’IA i analítica.
Alternatives considerades
- PostgreSQL gestionat — acceptable per requeriments estrictament relacionals (vegeu ADR-011).
- MongoDB self-managed — descartat per overhead operatiu de gestió.
Referències
ADR-011 — BD relacional gestionada com a alternativa justificada (RDS Aurora, Azure SQL, Cloud SQL, Oracle ExaCC)
Context
Alguns casos d’ús requereixen ACID estricte, joins complexos o integritat referencial que justifiquen una BD relacional. En aquests casos, la solució ha de seguir igualment els principis d’alta disponibilitat i gestionada. El Departament de Salut disposa a més d’Oracle Exadata en modalitat ExaCC (Exadata Cloud@Customer) al CPD4 per a càrregues transaccionals on-premises que requereixen màxim rendiment.
Decisió
En cas de necessitar BD relacional (amb justificació tècnica o funcional aprovada per Arquitectura), el motor ha de ser un servei gestionat (RDS Aurora Postgres, Azure Database SQL o Cloud SQL) amb HA multizona, autoescalament, PITR, i RPO/RTO pròxims a zero. Per a càrregues transaccionals on-premises amb requeriments de rendiment elevat, s’accepta Oracle Exadata ExaCC al CPD4 com a plataforma aprovada.
Conseqüències
- Requereix aprovació explícita de l’Àrea d’Arquitectura i QA.
- No s’accepten instal·lacions de PostgreSQL/MySQL a mida en VMs.
- Cal documentar la justificació al DA amb evidències tècniques.
- L’ús d’Oracle ExaCC al CPD4 queda restringit a sistemes transaccionals on-premises; les noves iniciatives cloud han d’optar pels motors gestionats del proveïdor cloud.
ADR-012 — Separació estricta entre dominis: prohibició de BD compartida entre dominis
Context
Les arquitectures on múltiples serveis o dominis comparteixen la mateixa BD generen acoblament tècnic elevat, punts de fallida únics i dificultats per evolucionar o escalar cada domini de forma independent.
Decisió
No es permeten interaccions ni acoblaments entre dominis a nivell de base de dades. Cada domini és responsable únic de les seves dades. Les interaccions entre dominis s’han de fer via API REST o missatgeria asíncrona.
Excepcions
- Si coexisteixen motors de BD dins d’un mateix domini, cal garantir recuperabilitat consistent i coordinada entre ells.
ADR-013 — Elastic Cloud o Algolia per a BD de text, i BD en memòria gestionada per a sessions/caché
Context
Determinats requeriments de cerca de text complet o de rendiment en accés a dades de sessió no es poden cobrir eficientment amb MongoDB Atlas o BDs relacionals.
Decisió
Per a cerca de text: Elastic Cloud o Algolia com a DBaaS. Per a sessió o caché en memòria: solucions gestionades pel proveïdor cloud (ex. ElastiCache, Azure Cache for Redis). Si es requereix solució a mida (on-prem), ha de complir HA i recuperabilitat.
Conseqüències
- No s’accepten Elasticsearch o Redis self-managed en VMs sense justificació.
- Les dades de sessió no han de persistir-se en BD operacionals principals.
Seguretat i Control d’Accés
ADR-014 — Plataforma de Seguretat de Salut (PDS) com a IdP centralitzat (OAuth2/OIDC, SAML2)
Context
La gestió d’identitats i autoritzacions fragmentada en cada aplicació genera duplicació, inconsistències de seguretat i dificulta la gestió centralitzada d’accessos en l’àmbit sanitari, on els rols i atributs clínics són crítics.
Decisió
Les solucions han d’integrar-se amb la Plataforma de Seguretat de Salut (PDS) com a proveïdor d’autenticació i autorització transversal, basat en OAuth2/OIDC o SAML2. No s’implementaran sistemes d’autenticació propis.
Justificació
- Delegació d’autenticació a VALID (ciutadans), GICAR (professionals), GSA i ECAP.
- Fluxos d’autorització específics per cada iniciativa, basats en rols i atributs clínics.
- Gestió centralitzada d’accessos i auditoria.
Referències
Observabilitat i Monitorització
ADR-015 — Observabilitat estandarditzada: logs, mètriques, sondes i traçabilitat distribuïda
Context
La diversitat de solucions de monitoratge fragmenta la visibilitat operacional i dificulta la correlació d’incidents entre serveis interconnectats. El Centre de Control necessita una visió homogènia de tots els sistemes crítics de Salut.
Decisió
Tots els sistemes han de generar de forma homogènia: logs d’aplicació, mètriques de sistema i indicadors de negoci, sondes de navegació/serveis, i dependències d’altres sistemes. Han d’integrar-se amb les eines transversals del CTTI per a monitoratge del Centre de Control.
Conseqüències
- Obligatori per a aplicacions classificades com a crítiques.
- Cal implementar traçabilitat distribuïda per a serveis que interoperen entre si.
- Els logs han de seguir el format i nivells establerts al llibre blanc d’observabilitat CTTI.
Referències
Governança i Processos
ADR-016 — Document d’Arquitectura (DA) obligatori en format AiDA amb vistes C4Model
Context
Sense una formalització estandarditzada de l’arquitectura de cada solució, és impossible avaluar el compliment del manifest, identificar riscos d’integració o mantenir una visió coherent del sistema d’informació de Salut.
Decisió
Tota nova solució ha de formalitzar la seva arquitectura via l’eina AiDA (des d’octubre 2025) seguint el procediment ISOL. Les vistes de context i desplegament han de presentar-se en format C4Model. No s’aprovaran DAs amb apartats incomplets, inconsistències o comentaris sense resoldre.
Conseqüències
- Cap nova solució pot avançar al cicle de vida de producció sense DA aprovat.
- Les discrepàncies respecte el manifest han de documentar-se al DA.
- L’Àrea d’Arquitectura disposa de 5 dies laborables per validar un DA.
Referències
ADR-017 — CI/CD obligatori via SIC3.0 (núvol privat) i SIC+ (núvol públic)
Context
Cada proveïdor utilitza pipelines de desplegament propis, cosa que genera heterogeneïtat, dificulta l’auditoria dels desplegaments i impedeix el control corporatiu dels processos d’entrega de programari.
Decisió
És obligatori utilitzar els sistemes corporatius de CI/CD del CTTI: SIC3.0 per a desplegaments en núvol privat o API Manager, i SIC+ per a desplegaments al núvol públic. No es permeten pipelines de desplegament propis dels proveïdors.
Conseqüències
- Auditoria centralitzada de tots els desplegaments a producció.
- Cal adaptar les branques i estratègies de Git al model SIC.
- Els proveïdors han de formar els seus equips en l’ús de les plataformes SIC.
Referències
ADR-018 — Feature Toggles per a activació dinàmica de funcionalitats sense tall de servei
Context
Els sistemes de salut no poden permetre talls de servei per activar o desactivar funcionalitats. La disponibilitat contínua és un requeriment crític per als serveis assistencials.
Decisió
Cal incorporar mecanismes de Feature Toggles a tots els components de negoci per activar o desactivar funcionalitats dinàmicament, sense requerir desplegaments, reinicis o talls de servei.
Conseqüències
- Permet desplegaments progressius (canary releases, dark launches).
- Cal gestionar el cicle de vida dels toggles per evitar deute tècnic acumulat.
- Ha de ser auditable: quina funcionalitat, per qui i quan s’ha activat/desactivat.