Característiques de l'arquitectura HES

1.Introducció

Aquest document descriu les característiques principals de l’arquitectura HES en diversos àmbits. Les definicions, operatives i requisits que es presentin seran d’aplicació sobre tots aquells components, aplicacions i serveis de les solucions que formin part del HES.

Les característiques que aquí es descriuen formen el que seria el cos de requeriments no funcionals – també dits atributs de qualitat - que haurà de complir qualsevol component de l’arquitectura de l’ecosistema HES. Aquestes característiques es distribueixen en tres apartats:

1. Característiques Operacionals: són aquelles que descriuen com s’ha de comportar l’arquitectura un cop està desplegada i en funcionament. Marquen com ha de ser la seva operació i funcionament.

2. Característiques Estructurals: són aquelles que descriuen com ha de ser el codi que dona servei a les aplicacions i quines característiques de qualitat interna ha de complir

3. Característiques Transversals: conformen restriccions i criteris importants en la definició de l’arquitectura que no es poden encabir en els apartats anteriors.

Aquest document està alineat amb el document d’arquitectura de referència per les solucions HES i s’alinea amb les directrius oficials definides al Manifest d’Arquitectura de Salut i amb els principis establerts pel CTTI.

La llista de característiques està basada en el recull de [RIC20].

2.Característiques de l’Arquitectura

2.1. Regles de precedència de les característiques

En cas de col·lisió de dos o més característiques, tindran precedència aquelles que són de tipus operacional sobre les altres, i les estructurals sobre les transversals. En cas de conflicte entre característiques d’una mateixa classe, les que siguin més rellevants segons l’apartat 2.2.

Les característiques definides són d’obligat compliment en coherència amb el model d’arquitectura de referència CTTI, i qualsevol conflicte ha de resoldre’s prioritzant el compliment normatiu.

En qualsevol cas, l’arquitecte responsable pot establir unes regles adaptades al context si les justifica adequadament.

2.2. Resum de les característiques més rellevants

Característica	Llindars
Operacionals
Disponibilitat	24x7 amb un 99,95% de disponibilitat
Continuïtat	RTO < 1h RPO = 0 Recuperació de dades en un punt en el temps: 48h
Rendiment	Gestió de la capacitat: En instal·lacions tipus PaaS, IaaS, Hosting: RAM: Ocupació màxima permesa del 65%. CPU: Ocupació ma permesa del 65%. Disc: Ocupació màxima permesa del 65%. En instal·lacions basades en contenidors: RAM: Ocupació màxima permesa del 85%. CPU: Ocupació màxima permesa del 85%. Disc: Ocupació màxima permesa del 85%. Temps de resposta: S’entén que el temps de resposta és des de la invocació a la capa de negoci (API o publicació d’esdeveniment). Operacions d’alta, baixa i modificació de registres únics: màxim acceptat de 60ms (mil·lisegons), dins d’un percentil 95. Operacions de consulta d’un registre concret per clau: màxim acceptat de 40ms, dins d’un percentil 95.
Recuperabilitat	< 2h en sistemes que no estiguin en alta disponibilitat multicpd 30s en cas de sistemes amb alta disponibilitat entre cpds
Fiabilitat	Alta disponibilitat en tots els components i serveis
Robustesa	Preferiblement la comunicació entre sistemes estarà basada en esdeveniments
Escalabilitat	Tots els components seran autoescalables tant verticalment com horitzontalment

Característica	Llindars
Estructurals
Extensibilitat	Dins d’un mateix domini funcional mitjançant versions de codi. Entre dominis funcionals en base a esdeveniment i si no fos possible mitjançant una API.
Instal·labilitat	De forma automàtica via SIC en totes les capes.
Internacionalització / Localització	Els oficials a Catalunya
Portabilitat	Aplicacions i components preparats per a poder ser desplegats en infraestructures dels principals clouds públics amb poc esforç. Preferència sobre SaaS (serveis gestionats). Inclou tant components de negoci com a repositoris de dades.
Suportabilitat	Tots els components hauran d’assegurar suport 24x7 de tipus empresarial, amb temps de resposta <1h en cas d’incident crític.
Facilitat d’actualització / Gestió de l’obsolescència	Versions suportades en tot cas, preferiblement aquelles de suport de llarg termini (LTS). Actualització de versió major anual al juliol Actualització de pegats al gener Actualització de pegats crítics o de seguretat en quan es declari pel fabricant. Actualització només per mitjans automàtics - scripts, playbooks, etc. No es permeten actuacions manuals seguint un procediment escrit. Els procediments d’actualització hauran de contemplar la marxa enrere en cas de fallida de la mateixa.
Testabilitat	Tots els components hauran de poder-se provar de forma automàtica en totes les variants de prova que siguin d’aplicació.
Desplegabilitat	Tots els components hauran de poder-se desplegar de forma automàtica, incloent les bases de dades i components client que puguin ser necessaris en les estacions de treball. Els procediments de desplegament hauran de contemplar la marxa enrere en cas de fallida d’aquest.
Transaccionalitat	Utilitzar el patró SAGA per a transaccions distribuïdes, i ACID quan sigui necessari.

Característica	Llindars
Transversals
Accessibilitat	Els frontals a usuari hauran de complir els requisits legals (WCAG-AA)
Monitorització	Els components estaran monitoritzats per les eines estàndards de monitorització que proporciona el Centre de Control del CTTI.
Seguretat	Autenticació: Mitjançant el broker establert, amb preferència per GICAR Autorització: basada en atributs, als que s’hi afegeixen permisos i s’assignen a usuaris i components, amb preferència pel sistema d’autorització de GICAR
Usabilitat	Seran d’aplicació les 10 regles de Norman [NOR13]

2.3. Característiques Operacionals

2.3.1. Continuïtat

Capacitat per a recuperar-se d’un desastre. Còpies de seguretat i restauració: Recuperació de les dades en un punt en el temps.

• RTO: Temps de recuperació objectiu ha de ser menor a 1 hora.

• RPO: Punt de recuperació objectiu. L’estat del conjunt de dades determinades en un moment concret del temps que conseqüentment comporta el concepte del conjunt de dades que no poden ser recuperades. Prenent com a base de definició aquest darrer concepte, el valor ha de ser 0. Addicionalment cal indicar que com a conjunt de les dades considerades han de tenir-se en compte les dades de qualsevol dels repositoris, no únicament el repositori directament relacionat amb el/s component/s concrets d’on sorgeixi la necessitat de recuperació.

• La recuperació de dades en un punt en el temps s’ha de poder realitzar durant les 48h (hores) següents. De manera més rellevant, tenir en compte:

  • Els archive log d’Oracle.

  • Els oplog de MongoDB (mitjançant Ops Manager).

2.3.2. Disponibilitat

Defineix quan de temps el sistema ha d’estar disponible. Es considera que cal assolir l’alta disponibilitat a totes les capes, 24x7, 365 dies a l’any. Un 99.95% de disponibilitat.

Els components de les solucions HES hauran d’estar dissenyades per tal de permetre més d’una instància d’elles mateixes executant-se a l’hora, accedint concurrentment al seu model de dades.

Les solucions han de desplegar-se en alta disponibilitat multizona en els proveïdors de núvol públic.

2.3.3. Escalabilitat

Capacitat del sistema per treballar amb el rendiment previst malgrat que el nombre d’usuaris variï, augmentant o disminuint.

Preferentment, les aplicacions de negoci es desplegaran en tecnologies de contenidors que permetin definir i aplicar polítiques d’autoescalat. Els sistemes orquestradors de contenidors hauran de gestionar la seva capacitat de la mateixa manera que s’ha indicat en la característica de Rendiment, en el sentit d’actuar al acomplir-se unes condicions preestablertes amb uns valors llindars.

Els components hauran de disposar de capacitats d’autoescalat, o escalat en calent sense tall de servei.

Els serveis es desplegaran en plataformes gestionades com AWS Fargate / EKS Fargate, Azure Container Apps / AKS o Cloud Run / GKE.

Els sistemes de bases de dades, i altres, que no permetin la capacitat d’autoescalat, s’habilitaran els automatismes necessaris per a poder realitzar aquestes accions d’escalat sense intervenció d’un operador

Els sistemes que no es puguin automatitzar gestionaran la seva capacitat de la mateixa manera que s’ha indicat en la característica de Rendiment, per evitar caigudes per esgotament de recursos (escalat vegetatiu, pla de capacitat).

Nota: en el cas de l’escalat horitzontal de bases de dades es pot arribar a distingir entre escalat en lectures i escalat en escriptures. El primer es pot automatitzar i executar-se en calent, el segon implica un repartiment de càrregues en un nou conjunt de principal-secundaris que pota necessitar d’una finestra de manteniment més àmplia.

2.3.4. Fiabilitat

El sistema ha de ser a prova de fallades. Els serveis hauran de desplegar‑se en plataformes amb control‑plane gestionat, evitant punts únics de fallida.

2.3.5. Recuperabilitat

Té a veure amb la continuïtat del negoci. Indica els valors de llindar en què l’aplicació hauria d’estar aixecada i donant servei un altre cop.

En desplegaments multizona, el failover ha de ser inferior a 30s utilitzant capacitats natives del proveïdor cloud.

2.3.6. Rendiment

S’inclou en aquesta característica les proves de rendiment, l’anàlisi de pics, l’anàlisi de la freqüència de les funcions utilitzades, la capacitat requerida i el temps de resposta

• Per capacitat s’entén sota diversos aspectes requerits: RAM (GB), HD (GB), CPU (cores, milicores), IOPS (quantitat d’informació persistida als suports d’emmagatzematge per segon)

• En previsió d’anomalies o fallides derivades d’un ús absolut de la capacitat associada, s’haurà d’incrementar de la manera més automatitzada possible quan:

  • En instal·lacions tipus PaaS, IaaS, Hosting:

    • RAM: Ocupació màxima permesa del 65%.

    • CPU: Ocupació màxima permesa del 65%.

    • HD: Ocupació màxima permesa del 65%.

  • En instal·lacions basades en contenidors:

    • RAM: Ocupació màxima permesa del 85%.

    • CPU: Ocupació màxima permesa del 85%.

    • HD: Ocupació màxima permesa del 85%.

• Temps de resposta: S’entén que el temps de resposta és des de la invocació a la capa de negoci (API o publicació d’esdeveniment)

  • Operacions d’alta, baixa i modificació de registres únics: màxim acceptat de 60ms (mil·lisegons), dins d’un percentil 95 – el 95% de les mostres estan dins d’aquest llindar.

  • Operacions de consulta d’un registre concret per clau: màxim acceptat de 40 ms, dins d’un percentil 95.

Per a calcular la durada esperada d’una interacció, la composició de diferents accessos únics donarà la durada d’una interacció des de la capa més exterior, la del frontals d’una solució donada. Com a exemple, es pot calcular la durada estimada d’una reserva de cita a un metge com l’agregació dels serveis: cercar un pacient (40ms) + cercar un metge (40ms) + cercar un despatx de consulta (40ms) + registre d’una cita nova (60ms) + preparació de la presentació com a resposta a l’usuari final (60ms) donaria un total de temps de resposta estimat de 240ms.

Els llindars de consum hauran d’estar integrats amb regles d’autoescalat nadiu del proveïdor cloud.

Les mètriques de rendiment s’hauran d’enviar al sistema d’observabilitat corporatiu del CTTI

2.3.7. Robustesa

El sistema ha de tenir capacitat de gestionar errors i condicions límit mentre s’executa, fins i tot si la falla ve derivada per una causa externa com la connectivitat per xarxa, hi ha un tall d’alimentació, o una fallada de maquinari.

Els components es cridaran entre ells en forma d’esdeveniments, en cas que un d’ells no funcioni no afecta al funcionament.

En cas de no poder cridar per esdeveniments, les indisponibilitats de les aplicacions es guardaran en una cua que serà utilitzada per reintents. L’usuari rebrà un avís que la seva operació serà tractada en diferit.

En cas de no poder utilitzar una cua per reintents, les aplicacions disposaran d’un pla de contingència o camí alternatiu per a realitzar l’acció.

La comunicació basada en esdeveniments s’haurà d’implementar utilitzant la plataforma EventHub Kafka corporativa

2.3.8. Observabilitat

El sistema ha de ser capaç de respondre qualsevol dubte sobre el funcionament de les aplicacions o recursos en qualsevol moment independentment de la complexitat.

S’han d’instrumentar sistema i aplicacions per tal de poder recopilar mètriques, dades, volums, etc.. i enviar-los a un sistema capaç d’emmagatzemar i analitzar aquesta informació i així poder obtenir la compressió completa del sistema.

Així com mètriques de negoci fen el seguiment de “endpoint” estratègics del sistema per poder obtenir mètriques d’entrada o de temps de processament.

Les eines concretes aportades actualment son “Prometheus” acompanyat de “Grafana” que s’hauran d’ampliar amb mes eines per obtenir tota la informació

Tots els desenvolupaments realitzats no es consideraran complets fins que tinguin incorporat un anàlisis e instrumentació per suportar la seva observabilitat.

• Monitorització d’infraestructura.

• Monitorització d’usuaris reals.

• Visualització de registre.

• Visualització de la situació de transaccions distribuïdes.

2.4. Característiques Estructurals

2.4.1. Aprofitament/Reutilització

Capacitat per aprofitar components comuns a múltiples solucions.

Totes les solucions desenvolupades han de ser dissenyades amb el màxim grau d’abstracció possible per facilitar la seva reutilització i ser detectades ràpidament com a elements reaprofitables.

Un component reutilitzable tindrà una consideració transversal i per tant haurà de gaudir d’una infraestructura dedicada per protegir la seva resiliència i la dels components que el criden.

2.4.2. Configurabilitat

Capacitat dels usuaris per canviar aspectes de la configuració del programari (mitjançant interfícies usables)

No es contemplen capacitats d’aquesta mena en aquesta versió.

2.4.3. Desplegament automàtic

Els desplegaments hauran d’executar-se mitjançant les plataformes corporatives definides pel CTTI (SIC3.0, SIC+ per núvol públic, GHEC), i tota infraestructura haurà de ser declarada com a codi (IaC).

2.4.4. Entorns

Els entorns d’execució de l’HES seran DES, INT, PRE i PRO.

DES estarà a càrrec del proveïdor de desenvolupament hi haurà de respectar els productes i components i les seves versions, oferts pel CTTI en la resta d’entorns.

INT estarà gestionat per CTTI i contemplarà els productes i components i les seves versions de l’entorn de PRO, malgrat que l’arquitectura pugui estar simplificada a nivell de duplicació de components o altres característiques pròpies de PRO

PRE estarà gestionat per CTTI i replicarà exactament l’arquitectura proposada a PRO excepte en el seu dimensionament que com a mínim haurà de ser d’un 70% del de PRO

PRO estarà gestionat per CTTI i en ell seran d’aplicació totes les característiques que s’esmenten en aquest document.

Els entorns d’INT, PRE i PRO hauran de desplegar-se en configuracions multizona en els proveïdors de núvol públic segons el model de NET0.

2.4.5. Extensibilitat

Capacitat d’afegir noves peces a l’aplicació amb la mínima repercussió de servei en curs.

• Dins del mateix domini funcional es contemplaran noves versions del codi.

• Entre dominis funcionals:

  • Preferiblement via esdeveniments asíncrons.

  • En cas que no sigui possible, mitjançant interfícies API (la tipologia adient serà segons la interlocució dels dominis funcionals), Aquest punt l’aprofundim en el punt d’ Interoperabilitat.

En cap cas l’extensibilitat estarà basada a traves de connexions directes a les bases de dades.

Les extensions entre dominis s’hauran d’implementar mitjançant EventHub Kafka o API REST gestionades a través de l’API Manager del CTTI.

2.4.6. Facilitat d’actualització/Gestió de l’obsolescència

Facilitat per a actualitzar de manera fàcil i ràpida d’una versió prèvia a una versió actual tant per a programari a servidors com a clients.

Totes les peces que composen l’arquitectura del HES hauran d’estar suportades pel fabricant o comunitat corresponents.

S’escolliran preferiblement versions de llarg termini del productes (Long Term Support – LTS) sempre que estiguin disponibles

S’establiran dos períodes anuals per a realitzar les actualitzacions de productes: al gener i al juliol. Tenint en compte que els productes segueixen el versionat semàntic (major, menor, pegat) al juliol s’actualitzarà a la versió major i al gener a la versió menor més recent dins de la versió major instal·lada. Tot sempre i quan hi hagi noves evolucions exposades des de la darrera actualització.

En cas de risc de seguretat alt o de mal funcionament, s’aplicarà la versió de pegat recomanada pel fabricant o comunitat mantenidors del producte de forma immediata.

Totes les peces disposaran de scripts d’actualització que permetin la seva posada al dia de forma automatitzada. En el cas de codi font generat es desplegarà exclusivament mitjançant el SIC+. En el cas de productes, s’empaquetaran en gestors d’automatització com Helm, Ansible, Pulumi o aquell que ofereixi el fabricant o comunitat. S’avaluarà si es adient que, en el cas de generar el binari, aquest s’emmagatzemi al servei de repositori de binaris del CTTI basat en Harbor. Tots els scripts d’actualització comptaran amb suport a la marxa enrere en cas de fallida.

2.4.7. Instal·labilitat

Capacitat de poder instal·lar una solució de la manera més senzilla possible.

La instal·lació haurà d’estar completament codificada en IaC i integrada a les plataformes CI/CD del CTTI (SIC+).

2.4.8. Internacionalització

Suport per poder representar literals en diversos idiomes dins d’una mateixa aplicació. Com a mínim es contemplaran els idiomes oficials, podent habilitar altres segons criteris funcionals.

2.4.9. Interoperabilitat

Capacitat del sistema per integrar-se amb la resta d’elements del seu context funcional de manera fàcil i senzilla. Els criteris seran molt semblants a els de la característica de l’Extensibilitat.

Les solucions han de possibilitar que puguin realitzar-se integracions amb ells de terceres parts, més enllà dels seus propis components. Per fer-ho possible de manera fàcil i senzilla hauran d’exposar una interfície basada en cues d’esdeveniments preferentment, o en el seu defecte per APIs (ReST o GraphQL) [API21]. Per a totes dues vies cal:

• Definir els contractes associats a les estructures de dades intercanviades en les peticions i respostes.

• Cal seguir els estàndards. En el cas, de les API ReST seguir la guia “best practice” del CTTI, i en el cas de GraphQL seguir les pròpies del llenguatge.

• Cal tenir documentada la definició de l’API generada dins del manual d’adhesions, i un recull al DTE. Sigui, seguint les guies CTTI. Com, documentar la definició dels serveis mitjançat eina descriptiva auto-generada (per exemple Swagger)

• Preferiblement que qualsevol de les dues siguin de l’àmbit sanitari.

2.4.10. Localització

Suport per al format visual d’informacions de múltiples usos culturals idiomàtics en camps de dades, en informes, … per a dades de tipus dates, unitats de mesura i monedes quantitats monetàries així poder realitzar una particularització acurada de la seva visualització. Com a mínim es contemplaran els criteris de localització oficials, podent habilitar altres segons criteris funcionals.

2.4.11. Mantenibilitat

capacitat per poder aplicar canvis en l’evolució del sistema fàcilment. El disseny de la solució ha de tenir el grau màxim de desacoblament entre els seus components per tal de que, a l’hora de aplicar-los un evolutiu o correctiu, cal complir que:

• Sigui fàcilment identificable sobre quin dels components s’ha de realitzar, i que només, calgui aplicar-ho a un únic d’aquests.

• Reducció deute tècnic, el més aviat possible, a cada iteració o sprint. Tant sigui per codi heretat o deliberat (no seguir estàndards existents o recomanats). Com per re-factorització desordenada o inadvertida a conseqüència de la baixa cohesió o alt acoblament.

• Cal anotar o identificar clarament l’obsolescència de les eines o llenguatges heretats de les solucions digitals, per poder resoldre el més aviat possible.

• Es mantingui la documentació tècnica suficient i actualitzada, per tal d’evitar desenvolupaments erronis, poc específics o solapament de lògiques. Tant de negoci, com de processos desestructurats.

2.4.12. Portabilitat

Capacitat per poder executar una solució en diferents plataformes amb la mateixa base tecnològica.

Donada la tendència actual dels sistemes d’informació, aquests han de poder-se executar en plataformes al núvol. Tots els productes i aplicacions que s’instal·lin al context de HES estaran preparats per poder ser migrats al núvol amb poc esforç als serveis gestionats com Fargate, AKS, Cloud Run i DBaaS com MongoDB Atlas.

2.4.13. Suportabilitat

Tipus/Grau de suport necessari per la solució.

Tots els components hauran de tenir suport 24x7. En la mesura del possible es contractarà suport del fabricant, en cas de que el component estigui basat en un producte, amb temps de resposta menor a 1h, en cas d’incidents crítics o que es perdi l’operativitat del funcionament. En cas de no tenir un fabricant i hi hagi el recolzament d’una comunitat de programari lliure darrere el producte, els desenvolupadors hauran de tenir permisos per a realitzar canvis en el repositori de codi o participar com a contribuïdor en el repositori de codi. Es podran fer forks del repositori originari només en cas d’emergència i de manera temporal. El contingut del pegat realitzat haurà de revertir a la comunitat mitjançant la corresponent pull request al repositori original.

El suport haurà d’incloure integració amb les alertes i monitoratge del Centre de Control del CTTI.

2.4.14. Testabilitat

Els components d’una solució han de ser provats de forma automàtica: proves unitàries, funcionals, de rendiment, registre de proves exploratòries i qualsevol altre tipus de prova que es plantegi.

Els tests hauran d’incloure verificació d’observabilitat i traçabilitat distribuïda.

2.4.15. Transaccionalitat distribuïda

Aplicar el patró SAGA [SAG21] quan es plantegin transaccions distribuïdes amb la participació de diferents microserveis. En cas de necessitat de transaccions ACID, s’utilitzaran les bases de dades que tinguin aquesta facilitat.

Les transaccions distribuïdes hauran de basar-se en esdeveniments mitjançant EventHub Kafka.

2.5. Característiques Transversals

2.5.1. Accessibilitat

Accés a tots els usuaris, sense distinció. Per requeriment legal, les interfícies d’usuaris comptaran amb la doble A de l’estàndard WCAG.

L’accessibilitat haurà de garantir-se utilitzant el Design System de Salut en els frontals i microfrontals web, tal com estableixen les directrius del CTTI.

2.5.2. Arxivabilitat

Historificació o esborrat de dades inactives. Per mantenir els sistemes de bases de dades operacionals al màxim grau d’eficiència, les solucions hauran de ser dissenyades per tal de permetre l’arxivat d’un subconjunt de les seves dades sense comprometre les funcionalitats generals de la pròpia solució. L’arxivat utilitzarà opcions d’emmagatzematge de llarg termini i cost baix.

2.5.3. Compliment legal

Les solucions estaran dissenyades per tal d’acomplir amb les restriccions legislatives vigents referent a la protecció de dades i altres que siguin d’aplicació.

El compliment de la normativa legal en matèria de seguretat i protecció de dades s’haurà de garantir també mitjançant la integració amb la Plataforma de Seguretat de Salut (PDS), els sistemes d’identitat corporatius (VALID, GICAR) i la Plataforma d’Auditoria (PAUD) basada en l’estàndard ATNA/FHIR

2.5.4. Integritat

La integritat de les dades és el manteniment i la garantia de la precisió i la consistència de les dades durant tot el seu cicle de vida i és un aspecte crític per al disseny, implementació i ús de qualsevol sistema que emmagatzema, processa o recupera dades.

Els sistemes que emmagatzemen dades hauran de disposar de mecanismes que evitin la corrupció tant en el moment de l’escriptura com en el moment de recuperació, amb la utilització de maquinari redundat i regles de verificació de la informació recuperada.

2.5.5. Monitorització

Capacitat per monitoritzar l’estat en que es troben els components, establir llindars per integrar les alertes i avisos amb el sistema actual de la resta de components.

Els components hauran de generar, com a mínim, logs d’aplicació, mètriques de sistema i de negoci, sondes de navegació i d’invocació de serveis, així com traces distribuïdes, d’acord amb el llibre blanc d’observabilitat del CTTI. Totes aquestes dades s’integraran amb les eines corporatives de monitorització i observabilitat del Centre de Control del CTTI.

2.5.6. Privacitat

Habilitat per amagar informació a qualsevol actor que no tingui l’atribut adient per accedir o gestionar aquesta informació. S’inclouen en aquestes informacions les referides i involucrades a les comunicacions i a les pròpies traces (logs) dels components de la solució.

Les dades relacionades amb els usuaris hauran d’estar encriptades al ser emmagatzemades. L’encriptació s’ha de fer a nivell lògic (motor de bdd) i a nivell físic (nivell disc).

2.5.7. Seguretat

Es complirà amb els estàndards de seguretat vigents publicats per l’Agència de Ciberseguretat.

Autenticació: Requeriments de seguretat per assegurar l’accés controlat per part de qualsevol tipus d’actor, com usuaris finals o altres components externs a la solució.

L’autenticació es realitzarà mitjançant la Plataforma de Seguretat de Salut (PDS), basada en OAuth2/OIDC o SAML2, que integra VALID per a ciutadans, GICAR per a professionals i, quan s’escaigui, credencials de sistemes de Salut com GSA o ECAP.

Totes les comunicacions amb els serveis i entre serveis seran encriptades. Les claus d’encriptació seran rotades periòdicament, cada 180 dies.

Autorització: Els mecanismes d’autorització hauran de basar-se en atributs i rols gestionats a través de la PDS, que permet definir fluxos específics per cada iniciativa adherida

Resposta a incidents: els sistemes afectats hauran de tenir capacitat de respondre a un incident de seguretat en menys de 6 hores. Això inclou les capacitats per portar a producció qualsevol pegat de producte o aplicació de forma automàtica.

2.5.8. Traçabilitat

Les solucions hauran de publicar els esdeveniments d’auditoria a la Plataforma d’Auditoria de Salut (PAUD), seguint l’estàndard ATNA/FHIR, mitjançant mecanismes asíncrons. A més, s’haurà d’habilitar traçabilitat distribuïda per correlacionar peticions entre serveis que interoperen.

Els canvis en el codi font estaran reflectits en les corresponents notes de versió (release notes) en el propi projecte git.

Els canvis en els mòduls guardaran la traçabilitat respecte al requeriment funcional o la característica de l’arquitectura que pretenen cobrir, documentada efectivament en l’eina de gestió del cicle de vida i la qualitat vigent.

2.5.9. Usabilitat

Facilitat d’us. Ús obligatori del Design System de Salut.

Seran d’aplicació les 10 regles de Norman [NOR13]:

• Visibilitat de l’estat del sistema

• Relació entre el sistema i el món real

• Control i llibertat de l’usuari

• Consistència i estàndards

• Prevenció d’errors

• Reconèixer abans que recordar

• Flexibilitat i eficiència de l’ús

• Disseny estètic i minimalista

• Ajudar als usuaris a reconèixer, diagnosticar i corregir errors

• Disponibilitat d’ajudes i documentació

3.Referències

• [NOR13] Norman DA. The design of everyday things. Revised and expanded edition. New York, New York: Basic Books; 2013. 347 p.

• [SAG21] Microservices Pattern: Sagas [Internet]. microservices.io. [citat 19 novembre 2021]. Disponible a: http://microservices.io/patterns/data/saga.html

• [RIC20] Richards M, Ford N. Fundamentals of software architecture: an engineering approach. First edition. Beijing Boston Farnham Sebastopol Tokyo: O’Reilly; 2020. 400 p.

• [API21] Guia estandardització API

  • Pròpia REST: https://canigo.ctti.gencat.cat/blog/2016/01/api/

  • GraphQL: https://spec.graphql.org/draft/#sec-Overview