diff --git a/.gitignore b/.gitignore index 75c9363..fdcd584 100644 --- a/.gitignore +++ b/.gitignore @@ -6,3 +6,13 @@ fsh-generated/ template/ input-cache/ output/ + +*.bkp + +__pycache__ + +# draw.io autosave files +_diagrams/.$* + +# the publisher writes this to the root on every build +Requirements-fromNarrative.json diff --git a/.markdownlint.jsonc b/.markdownlint.jsonc index b06c803..9cbec6a 100644 --- a/.markdownlint.jsonc +++ b/.markdownlint.jsonc @@ -7,5 +7,10 @@ // kramdown attaches `{: .table ...}` to the table above it; a GFM parser // reads that line as one more (malformed) row. "MD055": false, - "MD056": false + "MD056": false, + // IHE use cases repeat "Descripción del caso de uso" / "Flujo del proceso" + // under each case; only siblings must be unique. + "MD024": { "siblings_only": true }, + // Bootstrap tabs (the template ships the plugin) are the only raw HTML. + "MD033": { "allowed_elements": ["ul", "li", "a", "div"] } } diff --git a/Makefile b/Makefile index e2b2e78..102a699 100644 --- a/Makefile +++ b/Makefile @@ -5,12 +5,13 @@ # anywhere else. .DEFAULT_GOAL := help -.PHONY: help preview site docs all format tools clean +.PHONY: help preview site docs diagrams all format tools clean help: @echo "make preview write, with live reload http://localhost:4000" @echo "make site build the site dist/site/index.html" @echo "make docs build PDF, DOCX, llms.txt dist/" + @echo "make diagrams render the PlantUML sources input/images/" @echo "make all site + docs" @echo "make format format the pages input/pagecontent/" @echo "make tools download the IG Publisher .work/tools/" @@ -25,6 +26,10 @@ site: docs: @_scripts/build-docs.sh +# Needs the publisher jar (make tools): PlantUML ships inside it. +diagrams: + @_scripts/build-diagrams.sh + all: site docs # Fixes blank lines, list markers, heading and emphasis style, trailing spaces; diff --git a/_diagrams/central-architecture-diagram.drawio b/_diagrams/central-architecture-diagram.drawio new file mode 100644 index 0000000..33d6e23 --- /dev/null +++ b/_diagrams/central-architecture-diagram.drawio @@ -0,0 +1,179 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_diagrams/hix-actores-hospital.plantuml b/_diagrams/hix-actores-hospital.plantuml new file mode 100644 index 0000000..72ab4ee --- /dev/null +++ b/_diagrams/hix-actores-hospital.plantuml @@ -0,0 +1,53 @@ +@startuml hix-actores-hospital +!pragma layout smetana +hide stereotype +skinparam shadowing false +skinparam defaultFontName Verdana +skinparam defaultFontSize 11 +skinparam nodesep 12 +skinparam ranksep 18 +skinparam rectangle { + BorderColor #555555 + RoundCorner 12 + FontStyle bold +} +skinparam rectangle<> { + BackgroundColor white + BorderColor #444444 + BorderStyle dashed + RoundCorner 0 + FontStyle plain + FontSize 10 +} +skinparam arrow { + Color #333333 + FontSize 9 +} +left to right direction +rectangle "Hospital (consumidor)" as HOSP #DAE8FC { + rectangle "IUA Authorization Client" <> as H1 + rectangle "MHD Document Consumer" <> as H2 + rectangle "PIXm / PDQm Consumer" <> as H3 +} +rectangle "Authorization Server (STS)" as STS #F5F5F5 { + rectangle "IUA Authorization Server" <> as STS1 + rectangle "OpenID Provider" <> as STS2 + rectangle "PIXm Consumer" <> as STS3 +} +rectangle "Record Locator Service (Mediador)" as RLS #D5E8D4 { + rectangle "IUA Resource Server" <> as RLS1 + rectangle "IUA Authorization Client" <> as RLS0 + rectangle "MHD Document Responder" <> as RLS2 + rectangle "MHD Document Consumer (delegated)" <> as RLS3 + rectangle "PIXm / PDQm Consumer (delegated)" <> as RLS4 +} +rectangle "Custodio" as CUST #FFE6CC { + rectangle "IUA Resource Server" <> as CUST1 + rectangle "MHD Document Responder" <> as CUST2 +} +H1 --> STS1 : [ITI-71] Get Access Token\natención: purpose_of_use = TREAT\nemergencia: purpose_of_use = ETREAT +H3 --> RLS4 : atención: [ITI-83] resuelve su identificador local\nemergencia: [ITI-78] busca por datos demográficos +H2 --> RLS2 : [ITI-67] Find Document References\n[ITI-68] Retrieve Document +STS1 <-- RLS0 : [HIX-1] Custodian Token Exchange +RLS3 --> CUST2 : [ITI-68] Retrieve Document\ntoken derivado, aud = custodio +@enduml diff --git a/_diagrams/hix-actores-laboratorio.plantuml b/_diagrams/hix-actores-laboratorio.plantuml new file mode 100644 index 0000000..7886c0b --- /dev/null +++ b/_diagrams/hix-actores-laboratorio.plantuml @@ -0,0 +1,50 @@ +@startuml hix-actores-laboratorio +!pragma layout smetana +hide stereotype +skinparam shadowing false +skinparam defaultFontName Verdana +skinparam defaultFontSize 11 +skinparam nodesep 12 +skinparam ranksep 18 +skinparam rectangle { + BorderColor #555555 + RoundCorner 12 + FontStyle bold +} +skinparam rectangle<> { + BackgroundColor white + BorderColor #444444 + BorderStyle dashed + RoundCorner 0 + FontStyle plain + FontSize 10 +} +skinparam arrow { + Color #333333 + FontSize 9 +} +left to right direction +rectangle "Laboratorio (custodio)" as LAB #DAE8FC { + rectangle "IUA Authorization Client" <> as L1 + rectangle "PIXm Patient Identity Source" <> as L2 + rectangle "MHD Document Source" <> as L3 + rectangle "MHD Document Responder" <> as L4 + rectangle "IUA Resource Server" <> as L5 +} +rectangle "Authorization Server (STS)" as STS #F5F5F5 { + rectangle "IUA Authorization Server" <> as STS1 + rectangle "OpenID Provider" <> as STS2 + rectangle "PIXm Consumer" <> as STS3 +} +rectangle "Record Locator Service (Mediador)" as RLS #D5E8D4 { + rectangle "IUA Authorization Client" <> as RLS0 + rectangle "IUA Resource Server" <> as RLS1 + rectangle "MHD Document Consumer (delegated)" <> as RLS3 +} +L1 --> STS1 : [ITI-71] Get Access Token\npurpose_of_use = TREAT +L2 --> RLS : [ITI-104] Patient Identity Feed\nidentidad local + identificador nacional +L3 --> RLS : [ITI-65] Provide Document Bundle\npuntero con custodio y securityLabel +STS1 <-u- RLS0 : [HIX-1] Custodian Token Exchange +RLS3 --> L4 : [ITI-68] Retrieve Document\ntoken derivado, aud = laboratorio\ncuando otro miembro recupera +L4 -[hidden]-> RLS1 +@enduml diff --git a/_diagrams/hix-actores-paciente.plantuml b/_diagrams/hix-actores-paciente.plantuml new file mode 100644 index 0000000..4fd929f --- /dev/null +++ b/_diagrams/hix-actores-paciente.plantuml @@ -0,0 +1,51 @@ +@startuml hix-actores-paciente +!pragma layout smetana +hide stereotype +skinparam shadowing false +skinparam defaultFontName Verdana +skinparam defaultFontSize 11 +skinparam nodesep 12 +skinparam ranksep 18 +skinparam rectangle { + BorderColor #555555 + RoundCorner 12 + FontStyle bold +} +skinparam rectangle<> { + BackgroundColor white + BorderColor #444444 + BorderStyle dashed + RoundCorner 0 + FontStyle plain + FontSize 10 +} +skinparam arrow { + Color #333333 + FontSize 9 +} +left to right direction +rectangle "Aplicación del paciente" as APP #DAE8FC { + rectangle "IUA Authorization Client" <> as APP1 + rectangle "MHD Document Consumer" <> as APP2 +} +rectangle "Authorization Server (STS)" as STS #F5F5F5 { + rectangle "IUA Authorization Server" <> as STS1 + rectangle "OpenID Provider" <> as STS2 + rectangle "PIXm Consumer" <> as STS3 +} +rectangle "Record Locator Service (Mediador)" as RLS #D5E8D4 { + rectangle "IUA Resource Server" <> as RLS1 + rectangle "IUA Authorization Client" <> as RLS0 + rectangle "MHD Document Responder" <> as RLS2 + rectangle "MHD Document Consumer (delegated)" <> as RLS3 + rectangle "PIXm / PDQm Consumer (delegated)" <> as RLS4 +} +rectangle "Custodio" as CUST #FFE6CC { + rectangle "IUA Resource Server" <> as CUST1 + rectangle "MHD Document Responder" <> as CUST2 +} +APP1 --> STS1 : [HIX-2] Patient Application Launch\npurpose_of_use = PATRQT, FAMRQT o PWATRNY\npaciente = identidad maestra +APP2 --> RLS2 : [ITI-67] Find Document References\n[ITI-68] Retrieve Document\ntoken aud = RLS, confinado al paciente +STS1 <-- RLS0 : [HIX-1] Custodian Token Exchange +RLS3 --> CUST2 : [ITI-68] Retrieve Document\ntoken derivado, aud = custodio +@enduml diff --git a/_diagrams/hix-delegacion.plantuml b/_diagrams/hix-delegacion.plantuml new file mode 100644 index 0000000..8a976c5 --- /dev/null +++ b/_diagrams/hix-delegacion.plantuml @@ -0,0 +1,48 @@ +@startuml hix-delegacion +!pragma layout smetana +skinparam shadowing false +skinparam defaultFontName Verdana +skinparam defaultFontSize 11 +skinparam rectangle { + BackgroundColor white + BorderColor #555555 + RoundCorner 8 +} +skinparam arrow { + Color #333333 + FontSize 9 +} +skinparam note { + BackgroundColor #FFFDF0 + BorderColor #999999 + FontSize 9 +} +left to right direction + +rectangle "Miembros" as MIEMBROS #F4F4F4 { + rectangle "Miembro\nsolicitante" as M +} + +rectangle "Infraestructura central" as CENTRO #EEF5EE { + rectangle "Authorization\nServer" as AS + rectangle "Record Locator\nService (PEP)" as RLS + rectangle "Document\nRegistry" as REG +} + +rectangle "Custodios" as CUSTODIOS #F4F4F4 { + rectangle "Custodio A" as A + rectangle "Custodio B" as B +} + +M --> RLS : token del miembro\naud = RLS +RLS --> AS : intercambio [HIX-1]\nresource = custodio X +AS --> RLS : token derivado\naud = custodio X\nsub = miembro\nact = RLS +RLS --> REG : token\naud = Document Registry +RLS --> A : token\naud = Custodio A +RLS --> B : token\naud = Custodio B +note bottom of B + Cada destino valida el token por sí mismo, + con las claves públicas del Authorization Server, + sin llamar a nadie. +end note +@enduml diff --git a/_diagrams/hix-flujo-identidad.plantuml b/_diagrams/hix-flujo-identidad.plantuml new file mode 100644 index 0000000..9853f34 --- /dev/null +++ b/_diagrams/hix-flujo-identidad.plantuml @@ -0,0 +1,39 @@ +@startuml hix-flujo-identidad +skinparam shadowing false +skinparam defaultFontName Verdana +skinparam defaultFontSize 11 +skinparam sequenceMessageAlign center +skinparam ParticipantPadding 10 +skinparam sequence { + ArrowColor #333333 + LifeLineBorderColor #999999 + ParticipantBorderColor #555555 + ParticipantBackgroundColor white + GroupBorderColor #999999 +} + +participant "Fuente autoritativa\n(p. ej. EDUS)" as SRC +participant "Registro de\nidentidad maestra" as PMIR +participant "Record Locator\nService" as RLS +participant "Custodio" as K +participant "Consumidor" as C + +== Identidad maestra == +SRC -> PMIR : [ITI-93] Mobile Patient Identity Feed\n(identidad verificada) +PMIR -> PMIR : crea o actualiza\nla identidad maestra +PMIR --> SRC : 200 + +== Identidad local de un miembro == +K -> RLS : [ITI-104] Patient Identity Feed\n(Patient local + identificador comunitario) +RLS -> RLS : dominio = organización del token +RLS -> PMIR : [ITI-104] (delegado) +PMIR -> PMIR : vincula la identidad local\ncon la identidad maestra +PMIR --> RLS : 200, o 422 si la persona\nno existe en la comunidad +RLS --> K : resultado + +== Resolución == +C -> RLS : [ITI-83] Cross-reference Query\n(identificador local o comunitario) +RLS -> PMIR : [ITI-83] (delegado) +PMIR --> RLS : identificadores de la persona +RLS --> C : identificadores permitidos\npor la política +@enduml diff --git a/_diagrams/hix-flujo-localizacion.plantuml b/_diagrams/hix-flujo-localizacion.plantuml new file mode 100644 index 0000000..b7d65b4 --- /dev/null +++ b/_diagrams/hix-flujo-localizacion.plantuml @@ -0,0 +1,55 @@ +@startuml hix-flujo-localizacion +skinparam shadowing false +skinparam defaultFontName Verdana +skinparam defaultFontSize 11 +skinparam sequenceMessageAlign center +skinparam ParticipantPadding 8 +skinparam sequence { + ArrowColor #333333 + LifeLineBorderColor #999999 + ParticipantBorderColor #555555 + ParticipantBackgroundColor white + GroupBorderColor #999999 +} + +participant "Consumidor" as C +participant "Authorization\nServer" as AS +participant "Record Locator\nService" as RLS +participant "Registro de\nidentidad maestra" as PMIR +participant "Document\nRegistry" as REG +participant "Directorio" as DIR +participant "Custodio" as K + +== Localización == +C -> AS : [ITI-71] Get Access Token +AS --> C : token (audiencia: RLS) +C -> RLS : [ITI-67] Find Document References\n(patient) [ITI-72] +RLS -> AS : [ITI-102] Introspect Token +AS --> RLS : activo, organización, propósito +RLS -> PMIR : [ITI-83] identidad maestra +PMIR --> RLS : identidad maestra +RLS -> AS : [HIX-1] intercambio\n(resource = Document Registry) +AS --> RLS : JWT (aud = registro, sub = consumidor,\nact = RLS, vida ≤ 120 s) +RLS -> REG : [ITI-67] [ITI-72] +REG --> RLS : punteros +RLS -> RLS : decisión de divulgación por puntero\nURL de contenido → RLS +RLS --> C : Bundle de punteros divulgados + +== Recuperación == +C -> RLS : [ITI-68] Retrieve Document\n(URL del RLS) [ITI-72] +RLS -> AS : [ITI-102] Introspect Token +RLS -> RLS : relee el puntero\nrecomprueba la divulgación +RLS -> DIR : [ITI-90] custodio → endpoint +DIR --> RLS : endpoint activo del custodio +RLS -> AS : [HIX-1] Custodian Token Exchange\n(resource = custodio) +AS --> RLS : JWT (aud = custodio, sub = consumidor,\nact = RLS, vida ≤ 120 s) +RLS -> K : [ITI-68] Retrieve Document [ITI-72] +K -> K : validación local del JWT +alt el custodio responde + K --> RLS : documento + RLS --> C : documento +else el custodio no responde + RLS --> C : OperationOutcome (transitorio) +end +note over C, K : Cada llamada del RLS a un servicio central o a un custodio va precedida de un intercambio [HIX-1] a nombre del solicitante; se muestra solo donde importa.\nCada actor registra sus eventos [ITI-20] bajo el identificador de correlación de la operación. +@enduml diff --git a/_diagrams/hix-flujo-paciente.plantuml b/_diagrams/hix-flujo-paciente.plantuml new file mode 100644 index 0000000..42e8e53 --- /dev/null +++ b/_diagrams/hix-flujo-paciente.plantuml @@ -0,0 +1,44 @@ +@startuml hix-flujo-paciente +skinparam shadowing false +skinparam defaultFontName Verdana +skinparam defaultFontSize 11 +skinparam sequenceMessageAlign center +skinparam ParticipantPadding 10 +skinparam sequence { + ArrowColor #333333 + LifeLineBorderColor #999999 + ParticipantBorderColor #555555 + ParticipantBackgroundColor white + ActorBorderColor #555555 + ActorBackgroundColor white + GroupBorderColor #999999 +} + +actor "Persona" as P +participant "Aplicación\ndel paciente" as APP +participant "Authorization\nServer" as AS +participant "Fuente autoritativa\n(p. ej. EDUS)" as SRC +participant "Registro de\nidentidad maestra" as PMIR +participant "Record Locator\nService" as RLS + +== Enrolamiento (una vez) == +P -> AS : crea su cuenta +AS -> SRC : verificación de identidad +SRC --> AS : identidad verificada +AS --> P : cuenta enlazada a la\nidentidad verificada + +== Lanzamiento [HIX-2] == +APP -> AS : authorization code + PKCE,\ncontexto de lanzamiento de paciente +AS -> P : autenticación y consentimiento +P --> AS : autoriza +AS -> PMIR : [ITI-83] identidad verificada → identidad maestra +PMIR --> AS : identidad maestra +AS --> APP : token (audiencia: RLS,\ncontexto de paciente = identidad maestra) + +== Acceso == +APP -> RLS : [ITI-67] / [ITI-68] [ITI-72] +RLS -> AS : [ITI-102] Introspect Token +AS --> RLS : activo, contexto de paciente +RLS -> RLS : confina la operación\nal paciente del contexto +RLS --> APP : punteros o documento +@enduml diff --git a/_diagrams/hix-flujo-publicacion.plantuml b/_diagrams/hix-flujo-publicacion.plantuml new file mode 100644 index 0000000..d3e57a3 --- /dev/null +++ b/_diagrams/hix-flujo-publicacion.plantuml @@ -0,0 +1,40 @@ +@startuml hix-flujo-publicacion +skinparam shadowing false +skinparam defaultFontName Verdana +skinparam defaultFontSize 11 +skinparam sequenceMessageAlign center +skinparam ParticipantPadding 10 +skinparam sequence { + ArrowColor #333333 + LifeLineBorderColor #999999 + ParticipantBorderColor #555555 + ParticipantBackgroundColor white + GroupBorderColor #999999 +} + +participant "Custodio" as K +participant "Authorization\nServer" as AS +participant "Record Locator\nService" as RLS +participant "Registro de\nidentidad maestra" as PMIR +participant "Document\nRegistry" as REG + +K -> K : almacena el documento\nen su repositorio +K -> AS : [ITI-71] Get Access Token +AS --> K : token (audiencia: RLS) +K -> RLS : [ITI-65] Provide Document Bundle\n(metadatos, URL relativa) [ITI-72] +RLS -> AS : [ITI-102] Introspect Token +AS --> RLS : activo, organización, propósito +RLS -> RLS : custodio = organización del token\nURL relativa\netiqueta de confidencialidad presente +RLS -> PMIR : [ITI-83] paciente local → identidad maestra +PMIR --> RLS : identidad maestra +RLS -> AS : [HIX-1] Token Exchange\n(resource = Document Registry) +AS --> RLS : JWT (aud = registro, sub = custodio,\nact = RLS, vida ≤ 120 s) +RLS -> REG : [ITI-65] puntero con\nsubject = identidad maestra [ITI-72] +REG --> RLS : 200 +RLS --> K : 200 +alt la comunidad rechaza la publicación + RLS --> K : 4xx con OperationOutcome + K -> K : revierte el documento local +end +note over K, REG : Cada llamada del RLS a un servicio central o a un custodio va precedida de un intercambio [HIX-1] a nombre del solicitante.\nCada actor registra sus eventos [ITI-20] bajo el identificador de correlación de la operación. +@enduml diff --git a/_diagrams/hix-master-patient-index.plantuml b/_diagrams/hix-master-patient-index.plantuml new file mode 100644 index 0000000..7666183 --- /dev/null +++ b/_diagrams/hix-master-patient-index.plantuml @@ -0,0 +1,31 @@ +@startuml hix-master-patient-index +!pragma layout smetana +skinparam shadowing false +skinparam defaultFontName Verdana +skinparam defaultFontSize 11 +skinparam rectangle { + BackgroundColor white + BorderColor #555555 + RoundCorner 8 +} +skinparam arrow { + Color #333333 + FontSize 9 +} + +rectangle "Hospital A" as A #F4F4F4 +rectangle "Fuente autoritativa de identidad\n(p. ej. EDUS)" as SRC #F8F8F8 +rectangle "Clínica B" as B #F4F4F4 + +rectangle "Registro de identidad maestra" as MPI #EEF5EE { + rectangle "Identidad local\n\nDominio del Hospital A\nPatient/349832" as LA + rectangle "Identidad maestra\nuna por persona\n\nDominio verificado cédula 1-0234-0567" as MASTER + rectangle "Identidad local\n\nDominio de la Clínica B\nPatient/123e4567" as LB +} + +A --> LA : ITI-104\nPatient/349832 + cédula +SRC --> MASTER : ITI-93\ncrea +B --> LB : ITI-104\nPatient/123e4567 + cédula +LA -right-> MASTER : enlace +MASTER <-left- LB : enlace +@enduml diff --git a/_scripts/__pycache__/pageorder.cpython-314.pyc b/_scripts/__pycache__/pageorder.cpython-314.pyc deleted file mode 100644 index a1f9032..0000000 Binary files a/_scripts/__pycache__/pageorder.cpython-314.pyc and /dev/null differ diff --git a/_scripts/assemble.py b/_scripts/assemble.py index 7acb281..2c5186f 100644 --- a/_scripts/assemble.py +++ b/_scripts/assemble.py @@ -10,10 +10,25 @@ work = Path(sys.argv[1]) cfg = pageorder.config() +DEPENDENCY_TABLE = "\n".join( + ["| Paquete | Versión | Aporta |", "| --- | --- | --- |"] + + [f"| {name} | {version} | {reason} |" for name, version, reason in pageorder.dependencies(cfg)] +) + names = [] for name, title, depth in pageorder.pages(cfg): body = (ROOT / "input" / "pagecontent" / name).read_text() body = re.sub(r"^\{:.*\}$", "", body, flags=re.M) + # kramdown abbreviations (`*[PMIR]: ...`) become tooltips on the site; pandoc has no equivalent + body = re.sub(r"^\*\[[^\]]+\]: .*$", "", body, flags=re.M) + # The dependency table is a fragment the publisher generates and Jekyll + # includes. Pandoc gets the same rows straight from sushi-config.yaml. + body = body.replace("{% include dependency-table.xhtml %}", DEPENDENCY_TABLE) + + # The publisher copies input/images/ to the root of the site, so a page + # refers to a figure by its bare name. Pandoc runs from the repository and + # needs the real path. + body = re.sub(r"\]\((?!\w+:)([^)/]+\.svg)\)", r"](input/images/\1)", body) # A page's content starts at ### because the site renders the title as the # h2. A top-level page becomes an h1 here, so its content moves up one level diff --git a/_scripts/build-diagrams.sh b/_scripts/build-diagrams.sh new file mode 100755 index 0000000..8b390a6 --- /dev/null +++ b/_scripts/build-diagrams.sh @@ -0,0 +1,35 @@ +#!/usr/bin/env bash +# Renders the PlantUML figures into input/images/, where both consumers find +# them: the IG Publisher copies that directory into the site, and pandoc reads +# it from the source tree for the PDF and DOCX. +# +# PlantUML ships inside the IG Publisher jar, so there is nothing else to +# install. Block diagrams set `!pragma layout smetana` because Graphviz is not +# a dependency of this repo. +# +# .drawio sources are not rendered here: draw.io has no headless exporter on +# this machine. Export them from the editor straight into input/images/, with +# the labels set to plain text ("Formatted Text" off), so the SVG carries +# ordinary elements that every renderer draws. +set -euo pipefail + +cd "$(dirname "$0")/.." + +if [ ! -f .work/tools/publisher.jar ]; then + echo "The publisher is missing. Run 'make tools' first." >&2 + exit 1 +fi + +mkdir -p input/images + +java -cp .work/tools/publisher.jar net.sourceforge.plantuml.Run \ + -tsvg -o "$(pwd)/input/images" _diagrams/*.plantuml + +# Recent JDKs serialise PlantUML's DOM with xmlns="" on every child element +# (the "not created as namespace-aware" warning). That drops the elements out +# of the SVG namespace and browsers render a blank image. Strip it. +for src in _diagrams/*.plantuml; do + sed -i 's/ xmlns=""//g' "input/images/$(basename "${src%.plantuml}").svg" +done + +ls input/images/*.svg diff --git a/_scripts/pageorder.py b/_scripts/pageorder.py index f73ae16..30be024 100644 --- a/_scripts/pageorder.py +++ b/_scripts/pageorder.py @@ -26,6 +26,19 @@ def folded(key, cfg=None): return " ".join(line.strip() for line in m.group(1).split("\n") if line.strip()) +def dependencies(cfg=None): + """(package, version, reason) for each entry under `dependencies:`.""" + cfg = cfg if cfg is not None else config() + m = re.search(r"^dependencies:\n(.*?)(?=^\S)", cfg, re.S | re.M) + + out = [] + for name, body in re.findall(r"^ ([\w.-]+):\n((?: .*\n)+)", m.group(1) if m else "", re.M): + fields = dict(re.findall(r"^ (\w+):\s*(.+?)\s*$", body, re.M)) + out.append((name, fields.get("version", ""), fields.get("reason", "").strip("\"'"))) + + return out + + def pages(cfg=None): """(filename, title, depth) in declaration order; depth 1 = top level.""" cfg = cfg if cfg is not None else config() diff --git a/_scripts/preview.py b/_scripts/preview.py index e64e06f..cffbc1d 100755 --- a/_scripts/preview.py +++ b/_scripts/preview.py @@ -26,7 +26,8 @@ ROOT = Path(__file__).resolve().parent.parent PAGES = ROOT / "input" / "pagecontent" CONFIG = ROOT / "sushi-config.yaml" -# The publisher writes the real stylesheets here; the preview borrows them. +IMAGES = ROOT / "input" / "images" +# The publisher writes the real stylesheets and scripts here; the preview borrows them. ASSETS = ROOT / "dist" / "site" PORT = 4000 @@ -48,6 +49,8 @@ def render(name, title, prefix, pages, numbers): src = (PAGES / name).read_text() src = re.sub(r"^\{:.*\}$", "", src, flags=re.M) + # kramdown abbreviations (`*[PMIR]: ...`) become tooltips on the site; pandoc has no equivalent + src = re.sub(r"^\*\[[^\]]+\]: .*$", "", src, flags=re.M) offset = ",".join(prefix.split(".")) body = subprocess.run( ["pandoc", "--from=gfm", "--to=html", "--no-highlight", @@ -86,13 +89,15 @@ def render(name, title, prefix, pages, numbers):

{prefix} {title}

{body} -{RELOAD_JS}""" + + +{RELOAD_JS}""" def fingerprint(): - return json.dumps(sorted( - (str(p), p.stat().st_mtime_ns) - for p in list(PAGES.glob("*.md")) + [CONFIG])) + # a re-rendered diagram (make diagrams) reloads the page too + watched = list(PAGES.glob("*.md")) + list(IMAGES.glob("*.svg")) + [CONFIG] + return json.dumps(sorted((str(p), p.stat().st_mtime_ns) for p in watched)) class Handler(http.server.SimpleHTTPRequestHandler): @@ -102,9 +107,22 @@ def do_GET(self): if self.path.startswith("/assets/") or self.path == "/fhir.css": target = ASSETS / self.path.lstrip("/") if not target.exists(): - return self.send_error(404, "Run 'make site' once to produce the stylesheets") + return self.send_error(404, "Run 'make site' once to produce the stylesheets and scripts") self.send_response(200) - self.send_header("Content-Type", "text/css") + ctype = {".js": "text/javascript", ".map": "application/json"}.get(target.suffix, "text/css") + self.send_header("Content-Type", ctype) + # `make site` and `make diagrams` rewrite these under the same URL + self.send_header("Cache-Control", "no-store") + self.end_headers() + return self.wfile.write(target.read_bytes()) + + if self.path.endswith(".svg"): + target = IMAGES / self.path.lstrip("/") + if not target.exists(): + return self.send_error(404, f"{target.name} is not in input/images") + self.send_response(200) + self.send_header("Content-Type", "image/svg+xml") + self.send_header("Cache-Control", "no-store") self.end_headers() return self.wfile.write(target.read_bytes()) diff --git a/input/ignoreWarnings.txt b/input/ignoreWarnings.txt index 11767ef..2c038ac 100644 --- a/input/ignoreWarnings.txt +++ b/input/ignoreWarnings.txt @@ -1,10 +1,19 @@ == Suppressed Messages == -# These fragments are produced by the template for guides that declare package -# dependencies and IP statements. This guide is narrative-only and includes -# neither, and the pages stay portable Markdown so pandoc can render the same -# sources to PDF and Word -- which rules out Jekyll {% include %} tags. +# These fragments are produced by the template for guides that carry IP +# statements, global profiles and cross-version analysis. This guide is +# narrative-only and includes none of them. The pages stay portable Markdown so +# pandoc can render the same sources to PDF and Word; the one Jekyll +# {% include %} in use, the dependency table on the index page, is replaced by +# _scripts/assemble.py. The HTML fragment 'ip-statements.xhtml' is not included anywhere in the produced implementation guide -An HTML fragment from the set [dependency-table.xhtml, dependency-table-short.xhtml, dependency-table-nontech.xhtml] is not included anywhere in the produced implementation guide The HTML fragment 'globals-table.xhtml' is not included anywhere in the produced implementation guide An HTML fragment from the set [cross-version-analysis.xhtml, cross-version-analysis-inline.xhtml] is not included anywhere in the produced implementation guide + +# Kramdown abbreviations (`*[PMIR]: ...` at the foot of a page) render as , +# which the publisher's HTML whitelist does not include. Browsers render it as a plain tooltip. +# The publisher reports only the first occurrence per page, naming that abbreviation. +Illegal HTML: illegal html element: abbr (MHDS) +Illegal HTML: illegal html element: abbr (PDQm) +Illegal HTML: illegal html element: abbr (PMIR) +Illegal HTML: illegal html element: abbr (IUA) diff --git a/input/images/central-architecture-diagram.svg b/input/images/central-architecture-diagram.svg new file mode 100644 index 0000000..9a19869 --- /dev/null +++ b/input/images/central-architecture-diagram.svg @@ -0,0 +1 @@ +
[ITI-93] Feed
[ITI-93] Feed
Shared HIE Services
Shared HIE Services
PMIR Patient Identity Registry
PMIR Patient Identity Registry
mCSD Care Services Selective Supplier
mCSD Care Services SelectiveSupplier
ATNA Audit Record Repos
ATNA Audit Record Repos
Record locator Service
(Mediador)
Record locator Service(Mediador)
MHD Document Consumer (delegated)
MHD Document Consumer (delegated)
PDQm / PIXm Consumer (delegated)
PDQm / PIXm Consumer (delegated)
IUA Authorization Client
IUA Authorization Client
mCSD Care Services Selective Consumer
mCSD Care Services SelectiveConsumer
IUA Resource Server
IUA Resource Server
ATNA Secure Node
ATNA Secure Node
[ITI-90]
[ITI-90]
[ITI-66] o [ITI-67] o [ITI-68]
[ITI-66] o [ITI-67] o [ITI-68]
[ITI-72]
[ITI-72]
[ITI-71] Get Access Token
[RFC 8693] Token Exchange
[ITI-103] Metadata
[ITI-71] Get Access Token[RFC 8693] Token Exchange[ITI-103] Metadata
MHDS Document Registry
MHDS DocumentRegistry
MHD Document Responder
MHD Document Responder
MHD Document Recipient
MHD Document Recipient
IUA Resource Server
IUA Resource Server
mCSD Care Services Selective Consumer
mCSD Care Services SelectiveConsumer
[ITI-78] o [ITI-83]
[ITI-78] o [ITI-83]
ATNA Secure Node
ATNA Secure Node
[ITI-90]
[ITI-90]
[ITI-83] Central PMIR...
[ITI-83] Central PMIR...
e.g EDUS
e.g EDUS
[ITI-20] Record Audit Event
[ITI-20] Record AuditEvent
[ITI-20] Audit...
[ITI-20] Audit...
Authoritative Patient Identity Source
Authoritative PatientIdentity Source
PMIR Patient Identity Source
PMIR Patient Identity Source
[ITI-20] Record Audit Event
[ITI-20] Record Audit Event
Authorization Server (STS)
AuthorizationServer (STS)
IUA Authorization Server
IUA Authorization Server
OpenID Provider
OpenID Provider
PIXm Consumer
PIXm Consumer
ATNA Secure Node
ATNA Secure Node
Text is not SVG - cannot display
\ No newline at end of file diff --git a/input/images/hix-actores-hospital.svg b/input/images/hix-actores-hospital.svg new file mode 100644 index 0000000..5e6a235 --- /dev/null +++ b/input/images/hix-actores-hospital.svg @@ -0,0 +1 @@ +Hospital (consumidor)Authorization Server (STS)Record Locator Service (Mediador)CustodioIUA Authorization ClientMHD Document ConsumerPIXm / PDQm ConsumerIUA Authorization ServerOpenID ProviderPIXm ConsumerIUA Resource ServerIUA Authorization ClientMHD Document ResponderMHD Document Consumer (delegated)PIXm / PDQm Consumer (delegated)IUA Resource ServerMHD Document Responder[ITI-71] Get Access Tokenatención: purpose_of_use = TREATemergencia: purpose_of_use = ETREATatención: [ITI-83] resuelve su identificador localemergencia: [ITI-78] busca por datos demográficos[ITI-67] Find Document References[ITI-68] Retrieve Document[HIX-1] Custodian Token Exchange[ITI-68] Retrieve Documenttoken derivado, aud = custodio \ No newline at end of file diff --git a/input/images/hix-actores-laboratorio.svg b/input/images/hix-actores-laboratorio.svg new file mode 100644 index 0000000..0d9d42c --- /dev/null +++ b/input/images/hix-actores-laboratorio.svg @@ -0,0 +1 @@ +Laboratorio (custodio)Authorization Server (STS)Record Locator Service (Mediador)IUA Authorization ClientPIXm Patient Identity SourceMHD Document SourceMHD Document ResponderIUA Resource ServerIUA Authorization ServerOpenID ProviderPIXm ConsumerIUA Authorization ClientIUA Resource ServerMHD Document Consumer (delegated)[ITI-71] Get Access Tokenpurpose_of_use = TREAT[ITI-104] Patient Identity Feedidentidad local + identificador nacional[ITI-65] Provide Document Bundlepuntero con custodio y securityLabel[HIX-1] Custodian Token Exchange[ITI-68] Retrieve Documenttoken derivado, aud = laboratoriocuando otro miembro recupera \ No newline at end of file diff --git a/input/images/hix-actores-paciente.svg b/input/images/hix-actores-paciente.svg new file mode 100644 index 0000000..cae898d --- /dev/null +++ b/input/images/hix-actores-paciente.svg @@ -0,0 +1 @@ +Aplicación del pacienteAuthorization Server (STS)Record Locator Service (Mediador)CustodioIUA Authorization ClientMHD Document ConsumerIUA Authorization ServerOpenID ProviderPIXm ConsumerIUA Resource ServerIUA Authorization ClientMHD Document ResponderMHD Document Consumer (delegated)PIXm / PDQm Consumer (delegated)IUA Resource ServerMHD Document Responder[HIX-2] Patient Application Launchpurpose_of_use = PATRQT, FAMRQT o PWATRNYpaciente = identidad maestra[ITI-67] Find Document References[ITI-68] Retrieve Documenttoken aud = RLS, confinado al paciente[HIX-1] Custodian Token Exchange[ITI-68] Retrieve Documenttoken derivado, aud = custodio \ No newline at end of file diff --git a/input/images/hix-delegacion.svg b/input/images/hix-delegacion.svg new file mode 100644 index 0000000..843c4e6 --- /dev/null +++ b/input/images/hix-delegacion.svg @@ -0,0 +1 @@ +MiembrosInfraestructura centralCustodiosCada destino valida el token por sí mismo,con las claves públicas del Authorization Server,sin llamar a nadie.MiembrosolicitanteAuthorizationServerRecord LocatorService (PEP)DocumentRegistryCustodio ACustodio Btoken del miembroaud = RLSintercambio [HIX-1]resource = custodio Xtoken derivadoaud = custodio Xsub = miembroact = RLStokenaud = Document Registrytokenaud = Custodio Atokenaud = Custodio B \ No newline at end of file diff --git a/input/images/hix-flujo-identidad.svg b/input/images/hix-flujo-identidad.svg new file mode 100644 index 0000000..1762e83 --- /dev/null +++ b/input/images/hix-flujo-identidad.svg @@ -0,0 +1 @@ +Fuente autoritativaRegistro deRecord LocatorCustodioConsumidorFuente autoritativa(p. ej. EDUS)Fuente autoritativa(p. ej. EDUS)Registro deidentidad maestraRegistro deidentidad maestraRecord LocatorServiceRecord LocatorServiceCustodioCustodioConsumidorConsumidorIdentidad maestra[ITI-93] Mobile Patient Identity Feed(identidad verificada)crea o actualizala identidad maestra200Identidad local de un miembro[ITI-104] Patient Identity Feed(Patient local + identificador comunitario)dominio = organización del token[ITI-104] (delegado)vincula la identidad localcon la identidad maestra200, o 422 si la personano existe en la comunidadresultadoResolución[ITI-83] Cross-reference Query(identificador local o comunitario)[ITI-83] (delegado)identificadores de la personaidentificadores permitidospor la política \ No newline at end of file diff --git a/input/images/hix-flujo-localizacion.svg b/input/images/hix-flujo-localizacion.svg new file mode 100644 index 0000000..dedd14a --- /dev/null +++ b/input/images/hix-flujo-localizacion.svg @@ -0,0 +1 @@ +ConsumidorAuthorizationRecord LocatorRegistro deDocumentDirectorioCustodioConsumidorConsumidorAuthorizationServerAuthorizationServerRecord LocatorServiceRecord LocatorServiceRegistro deidentidad maestraRegistro deidentidad maestraDocumentRegistryDocumentRegistryDirectorioDirectorioCustodioCustodioLocalización[ITI-71] Get Access Tokentoken (audiencia: RLS)[ITI-67] Find Document References(patient) [ITI-72][ITI-102] Introspect Tokenactivo, organización, propósito[ITI-83] identidad maestraidentidad maestra[HIX-1] intercambio(resource = Document Registry)JWT (aud = registro, sub = consumidor,act = RLS, vida ≤ 120 s)[ITI-67] [ITI-72]punterosdecisión de divulgación por punteroURL de contenido → RLSBundle de punteros divulgadosRecuperación[ITI-68] Retrieve Document(URL del RLS) [ITI-72][ITI-102] Introspect Tokenrelee el punterorecomprueba la divulgación[ITI-90] custodio → endpointendpoint activo del custodio[HIX-1] Custodian Token Exchange(resource = custodio)JWT (aud = custodio, sub = consumidor,act = RLS, vida ≤ 120 s)[ITI-68] Retrieve Document [ITI-72]validación local del JWTalt[el custodio responde]documentodocumento[el custodio no responde]OperationOutcome (transitorio)Cada llamada del RLS a un servicio central o a un custodio va precedida de un intercambio [HIX-1] a nombre del solicitante; se muestra solo donde importa.Cada actor registra sus eventos [ITI-20] bajo el identificador de correlación de la operación. \ No newline at end of file diff --git a/input/images/hix-flujo-paciente.svg b/input/images/hix-flujo-paciente.svg new file mode 100644 index 0000000..93208ab --- /dev/null +++ b/input/images/hix-flujo-paciente.svg @@ -0,0 +1 @@ +PersonaAplicaci.nAuthorizationFuente autoritativaRegistro deRecord LocatorPersonaPersonaAplicacióndel pacienteAplicacióndel pacienteAuthorizationServerAuthorizationServerFuente autoritativa(p. ej. EDUS)Fuente autoritativa(p. ej. EDUS)Registro deidentidad maestraRegistro deidentidad maestraRecord LocatorServiceRecord LocatorServiceEnrolamiento (una vez)crea su cuentaverificación de identidadidentidad verificadacuenta enlazada a laidentidad verificadaLanzamiento [HIX-2]authorization code + PKCE,contexto de lanzamiento de pacienteautenticación y consentimientoautoriza[ITI-83] identidad verificada → identidad maestraidentidad maestratoken (audiencia: RLS,contexto de paciente = identidad maestra)Acceso[ITI-67] / [ITI-68] [ITI-72][ITI-102] Introspect Tokenactivo, contexto de pacienteconfina la operaciónal paciente del contextopunteros o documento \ No newline at end of file diff --git a/input/images/hix-flujo-publicacion.svg b/input/images/hix-flujo-publicacion.svg new file mode 100644 index 0000000..ec85902 --- /dev/null +++ b/input/images/hix-flujo-publicacion.svg @@ -0,0 +1 @@ +CustodioAuthorizationRecord LocatorRegistro deDocumentCustodioCustodioAuthorizationServerAuthorizationServerRecord LocatorServiceRecord LocatorServiceRegistro deidentidad maestraRegistro deidentidad maestraDocumentRegistryDocumentRegistryalmacena el documentoen su repositorio[ITI-71] Get Access Tokentoken (audiencia: RLS)[ITI-65] Provide Document Bundle(metadatos, URL relativa) [ITI-72][ITI-102] Introspect Tokenactivo, organización, propósitocustodio = organización del tokenURL relativaetiqueta de confidencialidad presente[ITI-83] paciente local → identidad maestraidentidad maestra[HIX-1] Token Exchange(resource = Document Registry)JWT (aud = registro, sub = custodio,act = RLS, vida ≤ 120 s)[ITI-65] puntero consubject = identidad maestra [ITI-72]200200alt[la comunidad rechaza la publicación]4xx con OperationOutcomerevierte el documento localCada llamada del RLS a un servicio central o a un custodio va precedida de un intercambio [HIX-1] a nombre del solicitante.Cada actor registra sus eventos [ITI-20] bajo el identificador de correlación de la operación. \ No newline at end of file diff --git a/input/images/hix-master-patient-index.svg b/input/images/hix-master-patient-index.svg new file mode 100644 index 0000000..be58c83 --- /dev/null +++ b/input/images/hix-master-patient-index.svg @@ -0,0 +1 @@ +Registro de identidad maestraHospital AFuente autoritativa de identidad(p. ej. EDUS)Clínica BIdentidad local Dominio del Hospital APatient/349832Identidad maestrauna por persona Dominio verificado cédula 1-0234-0567Identidad local Dominio de la Clínica BPatient/123e4567ITI-104Patient/349832 + cédulaITI-93creaITI-104Patient/123e4567 + cédulaenlaceenlace \ No newline at end of file diff --git a/input/pagecontent/appendix-glossary.md b/input/pagecontent/appendix-glossary.md new file mode 100644 index 0000000..8b8181f --- /dev/null +++ b/input/pagecontent/appendix-glossary.md @@ -0,0 +1,136 @@ +Este glosario reúne, en una línea cada uno, los actores y términos que usa esta guía. Los actores propios de HIX se definen en la [sección 2.2](volume-1-actors.html). Los actores IHE enlazan a la página del perfil que los define. + +### Actores de HIX + +**Record Locator Service.** El mediador de la comunidad. Localiza y recupera documentos en nombre de los miembros y aplica la decisión de divulgación sobre los punteros. Es un nombre propio de esta guía, no vocabulario IHE. +{: #record-locator-service} + +**Document Registry.** El registro de documentos de la comunidad. Conserva los punteros a los documentos publicados y, bajo la Opción de Almacenamiento Central, el contenido que los custodios le entregan. Toma su nombre y su función del [Document Registry de MHDS](https://profiles.ihe.net/ITI/MHDS/volume-1.html#150111-document-registry), pero es un actor de HIX, definido por los actores que agrupa. +{: #document-registry} + +**[Authorization Server](https://profiles.ihe.net/ITI/IUA/index.html).** El Authorization Server de IUA. Emite, comprueba e intercambia los tokens que circulan por la comunidad. +{: #authorization-server} + +**Directorio de la comunidad.** Publica las organizaciones participantes, su pertenencia a la comunidad y los endpoints en los que responden. Es el Directory de mCSD. +{: #directorio-de-la-comunidad} + +**Registro de identidad maestra.** Conserva una identidad maestra por persona y sus enlaces con las identidades locales. Agrupa al Patient Identity Registry de PMIR, al Patient Identifier Cross-reference Manager de PIXm y al Patient Demographics Supplier de PDQm. +{: #registro-de-identidad-maestra} + +**[Audit Record Repository](https://profiles.ihe.net/ITI/TF/Volume1/ch-9.html).** El actor de ATNA que recibe los eventos de auditoría de los actores centrales. +{: #audit-record-repository} + +**Fuente autoritativa de identidad.** Sistema externo a la comunidad que verifica la identidad de las personas y crea las identidades maestras. Es el Patient Identity Source de PMIR. HIX propone que sea el EDUS. +{: #fuente-autoritativa-de-identidad} + +**Custodio.** El sistema que publica y custodia documentos. Miembro que produce documentos, los conserva, declara las identidades locales de sus pacientes y publica los punteros. +{: #custodio} + +**Consumidor.** El sistema que consume documentos. Miembro que localiza y recupera documentos de un paciente a través del Record Locator Service. +{: #consumidor} + +**Aplicación del paciente.** Aplicación con la que una persona, o quien ella autoriza, accede a su propio expediente con el contexto de paciente que fija el Authorization Server. +{: #aplicacion-del-paciente} + +### Actores IHE que HIX agrupa + +**[Document Source](https://profiles.ihe.net/ITI/MHD/5.0.0/1331_actors_and_transactions.html).** Actor de MHD que publica documentos y sus punteros con ITI-65. +{: #document-source} + +**[Document Consumer](https://profiles.ihe.net/ITI/MHD/5.0.0/1331_actors_and_transactions.html).** Actor de MHD que localiza listas y documentos con ITI-66 e ITI-67 y recupera documentos con ITI-68. +{: #document-consumer} + +**[Document Responder](https://profiles.ihe.net/ITI/MHD/5.0.0/1331_actors_and_transactions.html).** Actor de MHD que responde la localización y la recuperación de documentos. +{: #document-responder} + +**[Document Recipient](https://profiles.ihe.net/ITI/MHD/5.0.0/1331_actors_and_transactions.html).** Actor de MHD que recibe las publicaciones ITI-65. +{: #document-recipient} + +**[Patient Identity Source](https://profiles.ihe.net/ITI/PMIR/volume-1.html).** Actor de PMIR y de PIXm que alimenta identidades de paciente, con ITI-93 o ITI-104. +{: #patient-identity-source} + +**[Patient Identity Registry](https://profiles.ihe.net/ITI/PMIR/volume-1.html).** Actor de PMIR que conserva las identidades maestras que recibe por ITI-93. +{: #patient-identity-registry} + +**[Patient Identity Consumer](https://profiles.ihe.net/ITI/PMIR/volume-1.html).** Actor de PMIR que recibe por ITI-93 los cambios de las identidades maestras, en particular las fusiones, y los aplica a sus propios datos. +{: #patient-identity-consumer} + +**[Patient Identifier Cross-reference Manager](https://profiles.ihe.net/ITI/PIXm/volume-1.html).** Actor de PIXm que recibe identidades locales por ITI-104, las enlaza con la identidad maestra y responde ITI-83. +{: #patient-identifier-cross-reference-manager} + +**[Patient Identifier Cross-reference Consumer](https://profiles.ihe.net/ITI/PIXm/volume-1.html).** Actor de PIXm que resuelve un identificador con ITI-83. +{: #patient-identifier-cross-reference-consumer} + +**[Patient Demographics Supplier](https://profiles.ihe.net/ITI/PDQm/volume-1.html).** Actor de PDQm que responde búsquedas por datos demográficos con ITI-78 y coincidencias probabilísticas con ITI-119. +{: #patient-demographics-supplier} + +**[Patient Demographics Consumer](https://profiles.ihe.net/ITI/PDQm/volume-1.html).** Actor de PDQm que busca pacientes por datos demográficos con ITI-78 o con ITI-119. +{: #patient-demographics-consumer} + +**[Directory](https://profiles.ihe.net/ITI/mCSD/volume-1.html#146111-directory).** Actor de mCSD que publica el directorio y responde ITI-90. Hasta mCSD 3 se llamaba Care Services Selective Supplier, y así lo nombra todavía MHDS. +{: #directory} + +**[Query Client](https://profiles.ihe.net/ITI/mCSD/volume-1.html#146112-query-client).** Actor de mCSD que consulta el directorio con ITI-90. Hasta mCSD 3 se llamaba Care Services Selective Consumer, y así lo nombra todavía MHDS. +{: #query-client} + +**[Authorization Client](https://profiles.ihe.net/ITI/IUA/index.html).** Actor de IUA que obtiene tokens con ITI-71 y los presenta con ITI-72. +{: #authorization-client} + +**[Resource Server](https://profiles.ihe.net/ITI/IUA/index.html).** Actor de IUA que recibe un token con ITI-72, comprueba que está destinado a él y lo valida, en su caso con ITI-102. +{: #resource-server} + +**[Secure Node y Secure Application](https://profiles.ihe.net/ITI/TF/Volume1/ch-9.html).** Actores de ATNA. Un sistema que se declara uno u otro autentica sus conexiones, las cifra y registra sus eventos de auditoría con ITI-20. El Secure Node aplica esos servicios de seguridad a todo el sistema. La Secure Application los aplica solo a la aplicación y a los actores que agrupa. +{: #secure-node} + +**[Time Client](https://profiles.ihe.net/ITI/TF/Volume1/ch-7.html).** Actor de CT que sincroniza el reloj de su sistema mediante ITI-1 con el Time Server que la comunidad designa, propio o una fuente de tiempo externa. +{: #time-client} + +### Términos de esta guía + +**Identidad maestra.** La identidad verificada de una persona, única en la comunidad, creada por la fuente autoritativa de identidad. Lleva el identificador nacional y los enlaces a las identidades locales. +{: #identidad-maestra} + +**Identidad local.** El paciente tal como lo conoce un miembro, con el identificador de su propio dominio. Cada miembro la declara y la enlaza con la identidad maestra. +{: #identidad-local} + +**Puntero.** El `DocumentReference` que describe un documento sin contenerlo. Sobre él se toma toda decisión de la comunidad antes de mover contenido. +{: #puntero} + +**SubmissionSet.** Recurso `List` de MHD que agrupa los punteros de una misma publicación y dice quién los publicó y cuándo. Toda publicación ITI-65 lleva uno, e ITI-66 los devuelve. +{: #submissionset} + +**Decisión de divulgación.** La evaluación que hace la infraestructura central, en el mediador o en el Document Registry, puntero por puntero y antes de recuperar, de si un documento puede entregarse a quien lo pide. +{: #decision-de-divulgacion} + +**Propósito de uso.** Código del conjunto PurposeOfUse de HL7 que dice para qué se accede. Viaja en el token y lo evalúa la decisión de divulgación. +{: #proposito-de-uso} + +**Scope.** El alcance de un token en OAuth 2.0. Fija qué transacciones puede pedir su portador. +{: #scope} + +**[OpenID Provider](https://openid.net/specs/openid-connect-core-1_0.html#Terminology).** Authorization Server de OAuth 2.0 que además autentica a la persona y acredita esa autenticación con un `id_token`, según OpenID Connect. En HIX lo es el Authorization Server de la comunidad. +{: #openid-provider} + +**Token del solicitante.** El token que un miembro obtiene con ITI-71, o la aplicación del paciente con [HIX-2](volume-1-actors.html#hix-2), destinado al Record Locator Service. Lleva el sujeto, la organización, el propósito de uso, el alcance y, en el caso de la aplicación del paciente, el contexto de paciente. +{: #token-del-solicitante} + +**Token intercambiado.** El token que el mediador obtiene con [HIX-1](volume-1-actors.html#hix-1) para un único destino y una sola transacción, con el solicitante original como sujeto y el mediador como actor. +{: #token-intercambiado} + +**PEP.** Punto de aplicación de política. El lugar donde se comprueba que una petición cumple las reglas de la comunidad. En HIX, el primero es el mediador. +{: #pep} + +**PDP.** Punto de decisión de política. El lugar donde se toma la decisión que el PEP aplica. En HIX, la decisión de divulgación se toma en la infraestructura central, en el mediador o en el Document Registry. +{: #pdp} + +*[PMIR]: Patient Master Identity Registry, perfil IHE que gestiona la identidad maestra del paciente +*[PIXm]: Patient Identifier Cross-referencing for mobile, perfil IHE que enlaza los identificadores locales de un paciente con su identidad maestra +*[PDQm]: Patient Demographics Query for Mobile, perfil IHE de búsqueda de pacientes por datos demográficos +*[MHD]: Mobile access to Health Documents, perfil IHE para publicar, localizar y recuperar documentos sobre FHIR +*[MHDS]: Mobile Health Document Sharing, perfil IHE que compone MHD, PMIR, mCSD, IUA y ATNA en una comunidad de intercambio de documentos +*[mCSD]: Mobile Care Services Discovery, perfil IHE de directorio de organizaciones, servicios y endpoints +*[IUA]: Internet User Authorization, perfil IHE que aplica OAuth 2.0 a las transacciones sobre FHIR +*[ATNA]: Audit Trail and Node Authentication, perfil IHE de auditoría y seguridad de los nodos +*[BALP]: Basic Audit Log Patterns, perfil IHE con los patrones de AuditEvent de FHIR +*[CT]: Consistent Time, perfil IHE que sincroniza los relojes de los sistemas +*[PCF]: Privacy Consent on FHIR, perfil IHE de consentimiento del paciente diff --git a/input/pagecontent/appendix.md b/input/pagecontent/appendix.md new file mode 100644 index 0000000..d66845c --- /dev/null +++ b/input/pagecontent/appendix.md @@ -0,0 +1 @@ +Los apéndices reúnen material de apoyo que no forma parte normativa de los volúmenes. Por ahora contienen el glosario de actores y términos. diff --git a/input/pagecontent/index.md b/input/pagecontent/index.md index 112df82..04916a0 100644 --- a/input/pagecontent/index.md +++ b/input/pagecontent/index.md @@ -1,31 +1,26 @@ -HIX define una arquitectura de referencia para comunidades que comparten documentos clínicos. No propone un estándar nuevo sino que toma como fundamento el perfil [Mobile Health Document Sharing (MHDS)](https://profiles.ihe.net/ITI/MHDS/volume-1.html) de IHE y articula los perfiles, estándares y especificaciones necesarios para operarlo sobre FHIR. +HIX define una arquitectura de referencia para comunidades que comparten documentos clínicos. No propone un estándar nuevo. Articula los perfiles de IHE, los estándares y las especificaciones necesarios para operar una comunidad así sobre FHIR, y sigue el modelo de comunidad de **[Mobile Health Document Sharing (MHDS)](https://profiles.ihe.net/ITI/MHDS/volume-1.html)**, que toma como referencia sin declarar conformidad con él. ### Propósito y alcance -Esta guía describe los roles de la comunidad, sus límites de confianza y la relación entre sus componentes. Explica, entre otras decisiones, por qué la localización y la recuperación se median de forma centralizada; por qué la custodia documental se mantiene distribuida por defecto; y cómo **[IUA](https://profiles.ihe.net/ITI/IUA/index.html)** y **[OAuth 2.0](https://www.rfc-editor.org/info/rfc6749/)** establecen la base de autorización y delegación entre los participantes, incorporando **[SMART on FHIR](https://build.fhir.org/ig/HL7/smart-app-launch/)** en los flujos interactivos en los que la autorización requiere la participación de un usuario, a través de un **User Agent** y el *front-channel* de autorización. +Esta guía describe los roles de la comunidad, sus límites de confianza y la relación entre sus componentes. Explica, entre otras decisiones, por qué la localización y la recuperación se median de forma centralizada, por qué la custodia documental se mantiene distribuida por defecto y cómo **[IUA](https://profiles.ihe.net/ITI/IUA/index.html)** y **[OAuth 2.0](https://www.rfc-editor.org/info/rfc6749/)** establecen la base de autorización y delegación entre los participantes. Cuando la autorización requiere la participación de una persona, incorpora **[SMART App Launch](https://hl7.org/fhir/smart-app-launch/)** en el flujo interactivo que esa persona completa desde su navegador. Esta arquitectura abarca las siguientes capacidades dentro de la comunidad: -- publicación, indexación, localización y recuperación de documentos clínicos; -- custodia distribuida de documentos y colocación central cuando corresponda; -- transporte seguro entre la infraestructura central y los custodios, mediante - HTTPS directo o X-Road, sin alterar la topología mediada de la comunidad; -- identidad maestra de pacientes y vinculación con las identidades locales; -- directorio de organizaciones participantes, servicios y endpoints; -- autorización y divulgación controlada de documentos; +- Publicación, indexación, localización y recuperación de documentos clínicos. +- Custodia distribuida de documentos y almacenamiento central cuando corresponda. +- Transporte seguro hacia los custodios, HTTPS directo o **[X-Road](https://x-road.global/)** según declare el directorio, sin alterar la topología de la comunidad. +- Identidad maestra de pacientes y vinculación con las identidades locales. +- Directorio de organizaciones participantes, servicios y endpoints. +- Autorización y divulgación controlada de documentos. #### Capacidades en desarrollo Las siguientes capacidades forman parte de la arquitectura HIX, pero su especificación detallada se definirá en una versión posterior de esta guía. La arquitectura ya establece los límites, los puntos de integración y los flujos que permiten incorporarlas sin alterar la topología mediada de la comunidad. -- **Consentimiento anticipado del paciente.** HIX define dónde se aplica la - decisión de divulgación y qué información necesita; el modelo de - consentimiento, su ciclo de vida y sus políticas se especificarán a partir - de los perfiles IHE aplicables. -- **Auditoría de operaciones y divulgaciones.** HIX define la necesidad de - registrar las operaciones en ambos extremos de la interacción; el - repositorio central, el modelo de consulta y el comportamiento ante fallos - se especificarán posteriormente. +- **Consentimiento anticipado del paciente.** HIX define dónde se aplica la decisión de divulgación y qué información necesita. El modelo de consentimiento, su ciclo de vida y sus políticas se especificarán a partir de los perfiles IHE aplicables. +- **Auditoría de operaciones y divulgaciones.** HIX define la necesidad de registrar las operaciones en ambos extremos de la interacción. El modelo de consulta y el comportamiento ante fallos se especificarán posteriormente. + +Los casos de uso que dependen de estas capacidades se listan al final de la [sección 2.5](volume-1-usecases.html) del Volumen 1. ### Convenciones de la especificación @@ -47,12 +42,18 @@ desempeña dentro de dicho perfil. | Término | Significado | | --- | --- | -| **[MHDS](https://profiles.ihe.net/ITI/MHDS/volume-1.html)** — *Mobile Health Document Sharing* | Perfil IHE que define una comunidad de intercambio de documentos clínicos basada en FHIR y la composición de perfiles necesaria para operarla. | -| **[MHD](https://profiles.ihe.net/ITI/MHD/index.html)** — *Mobile access to Health Documents* | Perfil IHE para publicar, localizar y recuperar documentos clínicos mediante FHIR. HIX utiliza principalmente los actores **Document Recipient** y **Document Responder**. | +| **[MHDS](https://profiles.ihe.net/ITI/MHDS/volume-1.html)** — *Mobile Health Document Sharing* | Perfil IHE que define una comunidad de intercambio de documentos clínicos basada en FHIR y la composición de perfiles necesaria para operarla. HIX lo toma como arquitectura de referencia. | +| **[MHD](https://profiles.ihe.net/ITI/MHD/5.0.0/index.html)** — *Mobile access to Health Documents* | Perfil IHE para publicar, localizar y recuperar documentos clínicos mediante FHIR. HIX usa sus actores **Document Source**, **Document Consumer**, **Document Recipient** y **Document Responder**. | | **[PMIR](https://profiles.ihe.net/ITI/PMIR/index.html)** — *Patient Master Identity Registry* | Perfil IHE para gestionar y sincronizar identidades maestras de pacientes. | -| **[mCSD](https://profiles.ihe.net/ITI/mCSD/index.html)** — *Mobile Care Services Discovery* | Perfil IHE utilizado para consultar organizaciones participantes, servicios y endpoints. | +| **[PIXm](https://profiles.ihe.net/ITI/PIXm/index.html)** — *Patient Identifier Cross-referencing for mobile* | Perfil IHE con el que cada miembro declara sus identidades locales de paciente y resuelve un identificador a la identidad maestra. | +| **[PDQm](https://profiles.ihe.net/ITI/PDQm/index.html)** — *Patient Demographics Query for Mobile* | Perfil IHE para localizar a un paciente por sus datos demográficos cuando no se dispone de un identificador conocido por la comunidad. | +| **[mCSD](https://profiles.ihe.net/ITI/mCSD/index.html)** — *Mobile Care Services Discovery* | Perfil IHE utilizado para consultar organizaciones participantes, servicios y endpoints. En HIX, el endpoint de cada custodio declara además el canal de transporte por el que se lo alcanza. | +| **[ATNA](https://profiles.ihe.net/ITI/TF/Volume1/ch-9.html)** — *Audit Trail and Node Authentication* | Perfil IHE que aporta la autenticación de nodos, la confidencialidad en tránsito y el registro de eventos de auditoría. | +| **[CT](https://profiles.ihe.net/ITI/TF/Volume1/ch-7.html)** — *Consistent Time* | Perfil IHE que mantiene sincronizados los relojes de todos los sistemas de la comunidad, para que los eventos de auditoría y la vigencia de los tokens signifiquen lo mismo en cada extremo. | +| **[BALP](https://profiles.ihe.net/ITI/BALP/index.html)** — *Basic Audit Log Patterns* | Perfil IHE de contenido que define patrones reutilizables de `AuditEvent`. De ellos derivan los eventos de auditoría que cada perfil especifica para sus transacciones. | | **[IUA](https://profiles.ihe.net/ITI/IUA/index.html)** — *Internet User Authorization* | Perfil IHE utilizado por HIX como base de autorización para las interacciones protegidas entre sus participantes. Sus requisitos aplican a todos los flujos de autorización de HIX. | -| **[SMART on FHIR](https://build.fhir.org/ig/HL7/smart-app-launch/app-launch.html)** | Especificación de HL7 utilizada adicionalmente en los flujos interactivos en los que la autorización requiere la participación de un usuario a través de un `User Agent`. | +| **[SMART App Launch](https://hl7.org/fhir/smart-app-launch/app-launch.html)** | Especificación de HL7 que HIX usa en los flujos interactivos en los que la autorización requiere la participación de una persona desde su navegador. | +| **[X-Road](https://x-road.global/)** | Capa de intercambio de datos entre organizaciones sobre transporte mTLS entre servidores de seguridad. HIX la admite como canal hacia un custodio, declarado en el directorio; no aporta semántica documental. | | **RLS** — *Record Locator Service* | Componente central de HIX responsable de localizar los documentos clínicos disponibles para un paciente y mediar su recuperación desde los custodios correspondientes. | {: .table .table-bordered} @@ -61,13 +62,25 @@ Los siguientes términos relacionados con OAuth 2.0 y la arquitectura de autoriz | Término | Significado | | --- | --- | | **Client** | Aplicación que solicita acceso a un recurso protegido. | -| **AS / STS** — *Authorization Server / Security Token Service* | Función responsable de la autorización y de la emisión o intercambio de tokens utilizados entre los participantes de HIX. | +| **AS** — *Authorization Server* | Actor responsable de la autorización y de la emisión, comprobación e intercambio de los tokens que circulan entre los participantes de HIX. | | **RS** — *Resource Server* | Servicio que protege recursos y evalúa los tokens presentados para autorizar el acceso. | | **Access token** | Credencial presentada por un `Client` ante un `Resource Server` para solicitar acceso. | | **Audience** | Identificador del `Resource Server` al que está destinado un token. | | **Scope** | Alcance del acceso solicitado o concedido al `Client`. | +| **PEP** — *Policy Enforcement Point* | Punto donde se aplica una decisión de política sobre una solicitud, sea permitir, denegar o filtrar. En HIX el Record Locator Service es el primer PEP de la comunidad, y cada custodio es además PEP de su propio endpoint. | +| **PDP** — *Policy Decision Point* | Punto donde se toma la decisión que el PEP aplica. En HIX la decisión de divulgación se toma en la infraestructura central, en el Record Locator Service o en el Document Registry. El Authorization Server decide sobre la autorización, nunca sobre la divulgación. | {: .table .table-bordered} ### Cómo leer esta guía HIX organiza sus requisitos en diferentes niveles de abstracción. Los volúmenes de esta guía deben leerse de forma complementaria y no como especificaciones independientes. + +- El **Volumen 1** describe la arquitectura, es decir, qué hace cada actor y por qué. +- El **Volumen 2** especifica cada transacción, incluidas las propias de HIX. +- Los **apéndices** reúnen el material de apoyo, por ahora el glosario. + +### Dependencias + +HIX es una comunidad FHIR R5. De los perfiles IHE que compone, MHD está publicado sobre R5 y los demás solo sobre R4, y en esa versión se declaran. IUA, ATNA y CT no se distribuyen como paquetes FHIR, y por eso no figuran aquí aunque HIX los use. MHDS tampoco figura, porque HIX lo toma como referencia y no depende de su paquete. + +{% include dependency-table.xhtml %} diff --git a/input/pagecontent/volume-1-actors.md b/input/pagecontent/volume-1-actors.md new file mode 100644 index 0000000..67e0cf3 --- /dev/null +++ b/input/pagecontent/volume-1-actors.md @@ -0,0 +1,251 @@ +Esta sección define los actores de HIX y las transacciones que los vinculan. Los actores y transacciones tomados de un perfil IHE conservan el significado que les da su especificación de origen. Las transacciones identificadas como `HIX-n` son propias de esta guía y se especifican en el Volumen 2. + +HIX distingue tres clases de actor. Los **actores centrales** los opera la comunidad. Los **actores de miembro** los opera cada organización participante. La **fuente autoritativa de identidad** es externa a la comunidad. Un miembro solo trata con la infraestructura central, nunca con otro miembro. Obtiene sus tokens del Authorization Server, localiza y recupera a través del Record Locator Service, y publica y declara identidades ante la infraestructura central, que valida esas transacciones como describe la [sección 2.1](volume-1-concepts.html). + +Las tres pestañas siguientes muestran a los actores de miembro en su escenario típico. La aplicación del paciente es la de una persona que entra a su propio expediente. El hospital es un sistema que consume documentos, en atención normal y en una emergencia, donde por ejemplo busca al paciente por sus datos demográficos con PDQm. El laboratorio es un sistema que publica y custodia documentos. +{: #figuras-2-2} + +> **TODO.** Estos 3 diagramas son un MOCK en pantUML y se DEBEN pasar los tres diagramas de estas pestañas a draw.io, como la [Figura 2-1](volume-1.html#figura-2-1). + + + +
+ +
+ +![Aplicación del paciente ante la comunidad](hix-actores-paciente.svg) + +**Figura 2.2-1:** Aplicación del paciente ante la comunidad +{: #figura-2-2-1} + +
+ +
+ +![Hospital que consulta, en atención normal y en emergencia](hix-actores-hospital.svg) + +**Figura 2.2-2:** Hospital que consulta, en atención normal y en emergencia (ETREAT con PDQm) +{: #figura-2-2-2} + +
+ +
+ +![Laboratorio que publica documentos](hix-actores-laboratorio.svg) + +**Figura 2.2-3:** Laboratorio que publica documentos +{: #figura-2-2-3} + +
+ +
+ +Las dos tablas siguientes listan las transacciones que definen a cada actor. R significa que la transacción es requerida para declararse conforme con el actor, y O que es opcional. La columna Referencia indica el perfil IHE que define la transacción, o el Volumen 2 de esta guía para las propias de HIX. Los miembros, y los actores centrales ante los que presentan tokens, se agrupan además con IUA, y todos los actores salvo la aplicación del paciente con ATNA y CT. Esas agrupaciones, y las transacciones que traen consigo, se describen en la [sección 2.4](volume-1-groupings.html). + +**Tabla 2.2-1:** Actores de miembro +{: #tabla-2-2-1} + +| Actor | Transacción | Opcionalidad | Referencia | +| --- | --- | --- | --- | +| Sistema que publica y custodia documentos | Patient Identity Feed FHIR [ITI-104] | R | PIXm | +| | Provide Document Bundle [ITI-65] | R | MHD | +| | Retrieve Document [ITI-68] | R (nota 1) | MHD | +| Sistema que consume documentos | Find Document Lists [ITI-66] | R | MHD | +| | Find Document References [ITI-67] | R | MHD | +| | Retrieve Document [ITI-68] | R | MHD | +| | Mobile Patient Identifier Cross-reference Query [ITI-83] | O | PIXm | +| | Mobile Patient Demographics Query [ITI-78] | O (nota 2) | PDQm | +| | Patient Demographics Match [ITI-119] | O (nota 4) | PDQm | +| Aplicación del paciente | Patient Application Launch \[[HIX-2](volume-1-actors.html#hix-2)\] | R | Vol. 2 | +| | Find Document Lists [ITI-66] | R | MHD | +| | Find Document References [ITI-67] | R | MHD | +| | Retrieve Document [ITI-68] | R | MHD | +{: .table .table-bordered} + +**Tabla 2.2-2:** Actores centrales y fuente de identidad +{: #tabla-2-2-2} + +| Actor | Transacción | Opcionalidad | Referencia | +| --- | --- | --- | --- | +| Record Locator Service | Find Document Lists [ITI-66] | R | MHD | +| | Find Document References [ITI-67] | R | MHD | +| | Retrieve Document [ITI-68] | R | MHD | +| | Mobile Patient Identifier Cross-reference Query [ITI-83] | R | PIXm | +| | Find Matching Care Services [ITI-90] | R | mCSD | +| | Custodian Token Exchange \[[HIX-1](volume-1-actors.html#hix-1)\] | R | Vol. 2 | +| Document Registry | Provide Document Bundle [ITI-65] | R | MHD | +| | Find Document Lists [ITI-66] | R | MHD | +| | Find Document References [ITI-67] | R | MHD | +| | Retrieve Document [ITI-68] | R (nota 3) | MHD | +| | Mobile Patient Identifier Cross-reference Query [ITI-83] | R | PIXm | +| | Find Matching Care Services [ITI-90] | R | mCSD | +| | Mobile Patient Identity Feed [ITI-93] | R | PMIR | +| Authorization Server | Get Access Token [ITI-71] | R | IUA | +| | Introspect Token [ITI-102] | R | IUA | +| | Get Authorization Server Metadata [ITI-103] | R | IUA | +| | Custodian Token Exchange \[[HIX-1](volume-1-actors.html#hix-1)\] | R | Vol. 2 | +| | Patient Application Launch \[[HIX-2](volume-1-actors.html#hix-2)\] | R | Vol. 2 | +| | Mobile Patient Identifier Cross-reference Query [ITI-83] | R | PIXm | +| Directorio de la comunidad | Find Matching Care Services [ITI-90] | R | mCSD | +| Registro de identidad maestra | Mobile Patient Identity Feed [ITI-93] | R | PMIR | +| | Patient Identity Feed FHIR [ITI-104] | R | PIXm | +| | Mobile Patient Identifier Cross-reference Query [ITI-83] | R | PIXm | +| | Mobile Patient Demographics Query [ITI-78] | R | PDQm | +| | Patient Demographics Match [ITI-119] | R | PDQm | +| Audit Record Repository | Record Audit Event [ITI-20] | R | ATNA | +| Fuente autoritativa de identidad (externa) | Mobile Patient Identity Feed [ITI-93] | R | PMIR | +{: .table .table-bordered} + +Notas: + +1. No requerido si el custodio declara la Opción de Almacenamiento Central. +2. Requerido si el actor declara la Opción de Demografía. +3. La exige el Document Responder de MHD. El Document Registry solo tiene contenido que servir cuando declara la Opción de Almacenamiento Central. +4. Requerido si el actor declara la Opción de Coincidencia Demográfica. + +El propósito de uso no depende del actor sino del caso de uso. Es un código del conjunto [PurposeOfUse](https://terminology.hl7.org/ValueSet-v3-PurposeOfUse.html) de HL7, tomado del sistema [v3-ActReason](https://terminology.hl7.org/CodeSystem-v3-ActReason.html), que el Authorization Server incluye en el token de cada solicitante y que la decisión de divulgación evalúa. No decide qué transacciones puede pedir un solicitante. Eso lo fija el scope de su token. Un mismo hospital consulta con `TREAT` en la atención habitual y con `ETREAT` en una urgencia. HIX usa el conjunto completo de HL7 y no lo restringe. Qué propósitos acepta una comunidad, y con qué condiciones, es política de implementación. La [Tabla 2.2-3](volume-1-actors.html#tabla-2-2-3) solo orienta al lector con los más frecuentes y el caso en el que aparece cada uno[^pou]. + +**Tabla 2.2-3:** Propósitos de uso más frecuentes en HIX +{: #tabla-2-2-3} + +| Código | Nombre en HL7 | Caso en el que aparece | +| --- | --- | --- | +| [`TREAT`](https://terminology.hl7.org/CodeSystem-v3-ActReason.html#v3-ActReason-TREAT) | treatment | Atención habitual de un paciente. Con él consulta un hospital y publica un laboratorio | +| [`ETREAT`](https://terminology.hl7.org/CodeSystem-v3-ActReason.html#v3-ActReason-ETREAT) | Emergency Treatment | Atención inmediata de una urgencia. Qué permite frente a `TREAT` lo fija la política de la comunidad. Por ejemplo, divulgar documentos que en atención habitual exigirían un consentimiento, aunque el paciente esté plenamente identificado | +| [`BTG`](https://terminology.hl7.org/CodeSystem-v3-ActReason.html#v3-ActReason-BTG) | break the glass | Urgencia atendida por quien no está autorizado para ese acceso, con anulación de la política. Cómo se admite y se audita lo fija cada comunidad | +| [`COC`](https://terminology.hl7.org/CodeSystem-v3-ActReason.html#v3-ActReason-COC) | coordination of care | Coordinación de la atención de una persona entre varias organizaciones | +| [`PATRQT`](https://terminology.hl7.org/CodeSystem-v3-ActReason.html#v3-ActReason-PATRQT) | patient requested | Acceso de una persona a su propio expediente | +| [`FAMRQT`](https://terminology.hl7.org/CodeSystem-v3-ActReason.html#v3-ActReason-FAMRQT) | family requested | Acceso de un familiar autorizado por el paciente | +| [`PWATRNY`](https://terminology.hl7.org/CodeSystem-v3-ActReason.html#v3-ActReason-PWATRNY) | power of attorney | Acceso del representante legal del paciente, como el padre o la madre de un menor | +| [`HOPERAT`](https://terminology.hl7.org/CodeSystem-v3-ActReason.html#v3-ActReason-HOPERAT) | healthcare operations | Actividades administrativas y contractuales de la organización | +| [`HPAYMT`](https://terminology.hl7.org/CodeSystem-v3-ActReason.html#v3-ActReason-HPAYMT) | healthcare payment | Actividades financieras relacionadas con el pago de la atención | +| [`HRESCH`](https://terminology.hl7.org/CodeSystem-v3-ActReason.html#v3-ActReason-HRESCH) | healthcare research | Investigación en salud | +| [`PUBHLTH`](https://terminology.hl7.org/CodeSystem-v3-ActReason.html#v3-ActReason-PUBHLTH) | public health | Actividades de salud pública, como la notificación de enfermedades de declaración obligatoria | +{: .table .table-bordered} + +### Descripción de actores y requisitos + +Las descripciones siguen el orden de las tablas. Dos reglas valen para todos los actores y no se repiten en cada uno. Todo actor que recibe un token **SHALL** comprobar que está destinado a él y **SHALL** rechazar la solicitud si no lo está, como recomienda RFC 9700 para todo [Resource Server](appendix-glossary.html#resource-server) ([RFC 9700, §4.10.2](https://www.rfc-editor.org/rfc/rfc9700.html#section-4.10.2))[^rfc9700-aud]. Que el Authorization Server de la comunidad haya emitido un token no lo hace válido ante cualquier actor. Cada token nombra en su audiencia, el claim `aud`, a los actores ante los que vale, y ante cualquier otro no sirve, aunque lo haya emitido el mismo Authorization Server. Y todo sistema de un miembro y todo actor central registra sus propios eventos de auditoría, como exige la agrupación con ATNA de la [sección 2.4](volume-1-groupings.html). + +#### Sistema que publica y custodia documentos + +El custodio es el miembro que produce documentos. Los conserva, declara las identidades locales de sus pacientes y publica los punteros a sus documentos con el propósito de uso del caso, normalmente `TREAT`. Agrupa a un [Document Source](appendix-glossary.html#document-source) y un [Document Responder](appendix-glossary.html#document-responder) de MHD, y a un [Patient Identity Source](appendix-glossary.html#patient-identity-source) de PIXm. Responde las recuperaciones que le llegan desde la infraestructura central, y solo desde ella. + +El custodio **SHALL** declarar mediante [ITI-104](https://profiles.ihe.net/ITI/PIXm/ITI-104.html) la identidad local de todo paciente sobre el que publique, en su propio dominio de identificadores y con el identificador nacional de la persona. **SHALL** publicar mediante [ITI-65](https://profiles.ihe.net/ITI/MHD/5.0.0/ITI-65.html) punteros que lo nombren a él como custodio y lleven etiqueta de confidencialidad, con URL de contenido relativa cuando el contenido queda en él. + +El custodio **SHALL** conservar el contenido y responder [ITI-68](https://profiles.ihe.net/ITI/MHD/5.0.0/ITI-68.html), salvo que declare la Opción de Almacenamiento Central. **SHALL** validar localmente el token de cada solicitud con las claves que publica el Authorization Server, conforme a la [sección 2.6](volume-1-security.html). **SHALL** rechazar toda solicitud cuyo token no haya sido intercambiado por el Record Locator Service y **SHALL NOT** atender recuperaciones originadas directamente en otro miembro. + +#### Sistema que consume documentos + +El consumidor es el miembro que consulta el expediente de un paciente. Localiza y recupera documentos a través del Record Locator Service y agrupa a un [Document Consumer](appendix-glossary.html#document-consumer) de MHD. Desde su punto de vista la comunidad es un único servidor FHIR. Actúa con el propósito de uso `TREAT` en la atención habitual y con `ETREAT` cuando atiende una urgencia. + +El consumidor **SHALL** obtener un token del Authorization Server destinado al Record Locator Service y **SHALL** presentarlo en toda solicitud. **SHALL** recuperar los documentos únicamente a través de las URL que el Record Locator Service le entrega. Puede resolver la identidad de un paciente con [ITI-83](https://profiles.ihe.net/ITI/PIXm/ITI-83.html) y, si declara la Opción de Demografía, buscarlo por sus datos demográficos con [ITI-78](https://profiles.ihe.net/ITI/PDQm/ITI-78.html). Si declara la Opción de Coincidencia Demográfica, puede pedir además con [ITI-119](https://profiles.ihe.net/ITI/PDQm/ITI-119.html) las identidades que más se parecen a unos datos incompletos. Ambas sirven, por ejemplo, en una urgencia en la que no tiene un identificador fiable, como en la [Figura 2.2-2](volume-1-actors.html#figuras-2-2). + +#### Aplicación del paciente + +La aplicación del paciente accede al expediente de la persona que la usa, con el contexto de paciente que el Authorization Server fija durante el lanzamiento y el propósito de uso que corresponde a quien actúa, según la [Tabla 2.2-3](volume-1-actors.html#tabla-2-2-3). Agrupa a un Document Consumer de MHD. A partir del lanzamiento, sus consultas y recuperaciones son las de cualquier otro consumidor, confinadas a ese único paciente. + +Este actor **SHALL** obtener su token mediante [HIX-2](volume-1-actors.html#hix-2) y **SHALL NOT** solicitar ni asumir un contexto de paciente distinto del que el token declara. + +#### Record Locator Service + +El Record Locator Service es el mediador de la comunidad. Localiza y recupera documentos en nombre de los miembros y aplica la decisión de divulgación sobre los punteros, antes de mover contenido alguno. Ante los miembros se comporta como un Resource Server de IUA y un Document Responder de MHD. Ante los custodios y los demás actores centrales actúa como Document Consumer de MHD y cliente delegado, en nombre del solicitante original. + +El Record Locator Service **SHALL** aceptar únicamente tokens emitidos por el Authorization Server de la comunidad. **SHALL** comprobarlos mediante [ITI-102](https://profiles.ihe.net/ITI/IUA/index.html#3102-introspect-token-iti-102) una vez por operación y **SHALL** tomar de esa respuesta, y no de la solicitud, la organización, el propósito de uso y el contexto de paciente del solicitante. + +El Record Locator Service **SHALL** evaluar la decisión de divulgación sobre los punteros antes de originar cualquier recuperación, **SHALL** omitir de la respuesta los punteros cuya divulgación no esté permitida y **SHALL** volver a evaluarla al atender un [ITI-68](https://profiles.ihe.net/ITI/MHD/5.0.0/ITI-68.html). La omisión **SHALL NOT** ser distinguible, para el solicitante, de la ausencia del documento, y **SHALL** quedar registrada en la auditoría. **SHALL** aplicar la misma decisión a las listas que devuelve por [ITI-66](https://profiles.ihe.net/ITI/MHD/5.0.0/ITI-66.html), porque una lista revela qué documentos existen. Un puntero cuya divulgación se niega **SHALL NOT** originar consulta al directorio, intercambio de token ni llamada al custodio. + +El Record Locator Service **SHALL** entregar a los solicitantes URL de contenido que apunten a sí mismo. **SHALL** resolver el endpoint del custodio en el directorio de la comunidad en cada recuperación y **SHALL NOT** revelar ese endpoint al solicitante. + +El Record Locator Service **SHALL** obtener mediante [HIX-1](volume-1-actors.html#hix-1) un token distinto para cada destino que alcance, sea un custodio o un actor central, **SHALL** pedir en cada intercambio únicamente el alcance de la transacción que va a realizar, y **SHALL NOT** reenviar a ninguno el token del solicitante. **SHALL NOT** conservar copias de los documentos que transitan por él ni registrar su contenido. No tiene acceso propio al Document Registry ni al registro de identidad maestra. + +Cuando un custodio no responde, el Record Locator Service **SHALL** degradar la respuesta señalando el fallo y **SHALL NOT** hacer fallar la operación completa por ese motivo. + +> **Nota.** *Record Locator Service* es el nombre que esta guía da al actor. No es vocabulario IHE. Corresponde al localizador central del modelo Centralized Discovery and Retrieve de IHE, el que permite descubrir dónde están los documentos y recuperarlos del custodio que registró su existencia ([IHE HIE Whitepaper, §2.8](https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#28-document-sharing-models))[^hie-cdr]. En HIX media además la recuperación, y se implementa agrupando un Document Consumer y un Document Responder de MHD. + +#### Document Registry + +El [Document Registry](appendix-glossary.html#document-registry) es el registro de documentos de la comunidad. Toma su nombre y su función del Document Registry de MHDS, pero es un actor de HIX, definido por los actores que agrupa en la [sección 2.4](volume-1-groupings.html). Conserva los punteros a los documentos publicados y, bajo la Opción de Almacenamiento Central, el contenido que los custodios le entregan. Recibe por [ITI-93](https://profiles.ihe.net/ITI/PMIR/ITI-93.html) los cambios de las identidades maestras. + +El Document Registry **SHALL** registrar cada puntero a nombre de la organización que declara el token, **SHALL** rechazar la publicación cuyo custodio no coincida con ella y **SHALL** validar mediante [ITI-90](https://profiles.ihe.net/ITI/mCSD/ITI-90.html) que esa organización es un miembro activo de la comunidad. **SHALL** aplicar a los punteros y a las listas que conserva las fusiones de identidades maestras que recibe por ITI-93, de modo que ningún puntero quede asociado a una identidad que dejó de existir. + +El Document Registry **SHALL** registrar únicamente punteros cuyo `subject` sea la identidad maestra del paciente y que conserven en `sourcepatient` la identidad local con la que el custodio lo nombró. Cuando la publicación nombra al paciente solo con su identidad local, la infraestructura central **SHALL** resolverla mediante [ITI-83](https://profiles.ihe.net/ITI/PIXm/ITI-83.html) y escribir el resultado en `subject` al indexar. Así el miembro publica con sus propios identificadores y la comunidad traduce y valida por él. + +Esa consulta comprueba a la vez que la persona existe y está activa en la comunidad, porque PIXm no resuelve una identidad desactivada o eliminada ([PIXm, §2:3.83.4.2.2.5](https://profiles.ihe.net/ITI/PIXm/ITI-83.html#23834225-post-mergedelete))[^pixm-deprecated]. Es la misma comprobación que MHDS pide a su Document Registry antes de indexar, y que admite resolver preguntando al registro de identidad ([MHDS Vol. 1, §1:50.1.1.1.1](https://profiles.ihe.net/ITI/MHDS/volume-1.html#1501111-when-the-grouped-mhd-document-recipient--is-triggered))[^mhds-subject]. + +El Document Registry **SHALL** rechazar la publicación que carezca de etiqueta de confidencialidad o cuyo paciente no pueda resolverse a una identidad maestra. Cuando el contenido queda en el custodio, **SHALL** rechazar además la publicación cuya URL de contenido no sea relativa. + +#### Authorization Server + +El Authorization Server emite, comprueba e intercambia los tokens que circulan por la comunidad. Es el Authorization Server de IUA. Es el único actor que decide sobre la autorización y el único que conoce a la vez al solicitante, su organización y el alcance que se le concede. No decide sobre consentimiento, relación terapéutica ni identidad de paciente. + +El Authorization Server **SHALL** restringir la audiencia de todo token que emite a destinatarios identificados explícitamente, como recomienda RFC 9700 ([RFC 9700, §2.3](https://www.rfc-editor.org/rfc/rfc9700.html#section-2.3))[^rfc9700-aud]. El token del solicitante nombra a los actores centrales que el miembro alcanza directamente y el token intercambiado a un único destino, como fija la [sección 2.6](volume-1-security.html#modelo-de-confianza). + +El Authorization Server **SHALL** atender [HIX-1](volume-1-actors.html#hix-1) únicamente para el Record Locator Service. El token intercambiado **SHALL** llevar como audiencia el único destino indicado en la petición de intercambio, el mismo sujeto, las mismas extensiones de IUA y, si lo hay, el mismo contexto de paciente que el token presentado, y como actor al Record Locator Service, en el claim `act` con el que OAuth 2.0 Token Exchange expresa la delegación ([RFC 8693, §4.1](https://www.rfc-editor.org/rfc/rfc8693.html#section-4.1))[^rfc8693-act]. + +El alcance del token intercambiado **SHALL** ser el pedido en el intercambio y **SHALL NOT** exceder el del token del solicitante ni el de la delegación registrada, y su vida **SHALL NOT** superar los dos minutos ni la vida restante del token del solicitante. El Authorization Server **SHALL NOT** emitir por ningún otro camino un token cuya audiencia sea un custodio. + +El Authorization Server **SHALL** fijar la organización y el propósito de uso del solicitante desde su propio registro y **SHALL NOT** aceptarlos de la solicitud. Cuando una persona se autentica, **SHALL** resolver su identidad verificada a la identidad maestra mediante [ITI-83](https://profiles.ihe.net/ITI/PIXm/ITI-83.html) y **SHALL** fijar ese resultado como contexto de paciente del token, conforme a [HIX-2](volume-1-actors.html#hix-2). **SHALL NOT** emitir un token con contexto de paciente cuando esa identidad no resuelva a una identidad maestra. + +#### Directorio de la comunidad + +El directorio publica las organizaciones participantes, su pertenencia a la comunidad y los endpoints en los que responden. Es el [Directory](appendix-glossary.html#directory) de mCSD de la comunidad y la única fuente de la que la infraestructura central aprende a quién dirigir una recuperación. + +El directorio **SHALL** responder [ITI-90](https://profiles.ihe.net/ITI/mCSD/ITI-90.html) y **SHALL** ser el único origen de los endpoints que usa la infraestructura central. **SHALL** identificar a cada organización con el mismo identificador que el Authorization Server incluye en sus tokens. Los miembros no consultan el directorio. Su contenido se mantiene administrativamente, al incorporar un miembro. + +#### Registro de identidad maestra + +El registro de identidad maestra agrupa al [Patient Identity Registry](appendix-glossary.html#patient-identity-registry) de PMIR, al [Patient Identifier Cross-reference Manager](appendix-glossary.html#patient-identifier-cross-reference-manager) de PIXm y al [Patient Demographics Supplier](appendix-glossary.html#patient-demographics-supplier) de PDQm. Conserva una identidad maestra por persona, creada por la fuente autoritativa de identidad, y los enlaces con las identidades locales que los miembros declaran. + +El registro de identidad maestra **SHALL** crear identidades maestras únicamente a partir de [ITI-93](https://profiles.ihe.net/ITI/PMIR/ITI-93.html) recibido de la fuente autoritativa de identidad. **SHALL** aceptar [ITI-104](https://profiles.ihe.net/ITI/PIXm/ITI-104.html) únicamente en el dominio de identificadores del miembro que lo origina y **SHALL** rechazar la declaración que no pueda vincularse a una identidad maestra existente. Dentro de su propio dominio el miembro gestiona sus identidades locales con libertad, incluida la resolución de sus propios duplicados que define ITI-104. + +Una declaración de un miembro **SHALL NOT** crear, fusionar ni eliminar una identidad maestra. El registro **SHALL NOT** modificar la demografía de la identidad maestra a partir de lo que un miembro declara. **SHALL** responder [ITI-83](https://profiles.ihe.net/ITI/PIXm/ITI-83.html) únicamente con la identidad maestra, nunca con las identidades locales que otros miembros declararon. PIXm admite esa restricción, porque deja que la respuesta sea un subconjunto determinado por política ([PIXm, §2:3.83.4.1.3](https://profiles.ihe.net/ITI/PIXm/ITI-83.html#2383413-expected-actions))[^pixm-subset]. + +#### Audit Record Repository + +El Audit Record Repository es el actor de ATNA que recibe mediante [ITI-20](https://profiles.ihe.net/ITI/TF/Volume2/ITI-20.html) los eventos que registran los actores centrales. Existe para que una divulgación pueda reconstruirse completa desde el lado de la comunidad, con la solicitud del miembro y la recuperación ante el custodio bajo un mismo identificador de correlación. Cada miembro registra su propio lado en su propio registro, como ATNA exige a todo Secure Node o Secure Application. + +#### Fuente autoritativa de identidad + +La fuente autoritativa de identidad es el sistema, externo a la comunidad, contra el que se verifica la identidad de una persona y del que la comunidad obtiene sus identidades maestras. Es el Patient Identity Source de PMIR. HIX no designa cuál es. La propuesta para Costa Rica es que sea el EDUS, porque ya tiene resuelta la identificación de las personas. + +La fuente autoritativa **SHALL** alimentar el registro de identidad maestra mediante [ITI-93](https://profiles.ihe.net/ITI/PMIR/ITI-93.html), con un token emitido por el Authorization Server de la comunidad. Es la única que crea, actualiza, fusiona o desactiva identidades maestras. + +### Transacciones propias de HIX + +**Custodian Token Exchange [HIX-1].** El Record Locator Service presenta al Authorization Server el token del solicitante, un único destino y el alcance de la transacción que va a realizar, y recibe a cambio el [token intercambiado](appendix-glossary.html#token-intercambiado) para ese destino, sea un custodio o un actor central. Lo que ese token lleva lo fijan los requisitos del [Authorization Server](volume-1-actors.html#authorization-server) y lo resume la [Tabla 2.6-1](volume-1-security.html#tabla-2-6-1). Es un intercambio OAuth 2.0 Token Exchange ([RFC 8693](https://www.rfc-editor.org/rfc/rfc8693)) con resource indicator ([RFC 8707](https://www.rfc-editor.org/rfc/rfc8707)), restringido al mediador. No es una transacción IUA. IUA limita [ITI-71](https://profiles.ihe.net/ITI/IUA/index.html#371-get-access-token-iti-71) a los grants Authorization Code y Client Credentials ([IUA, §34.1.1.1](https://profiles.ihe.net/ITI/IUA/index.html#34111-authorization-client))[^iua-grants] y toma de RFC 8693 solo el parámetro con el que se pide el tipo de token. +{: #hix-1} + +**Patient Application Launch [HIX-2].** Una aplicación elegida por una persona obtiene del Authorization Server un token destinado al Record Locator Service cuyo contexto de paciente es la identidad maestra de esa persona. El Authorization Server resuelve esa identidad en el momento del consentimiento. Es la transacción [Get Access Token \[ITI-71\]](https://profiles.ihe.net/ITI/IUA/index.html#371-get-access-token-iti-71) de IUA con el grant Authorization Code, perfilada por [SMART App Launch](https://hl7.org/fhir/smart-app-launch/). HIX le da identificador propio por lo que añade, que es el contexto de paciente que fija el Authorization Server, y no porque sea ajena a IUA. Se especifica en el Volumen 2. +{: #hix-2} + +> **Nota.** La incorporación de un miembro, por la que una organización queda descrita en el directorio y reconocida por el Authorization Server, es un procedimiento administrativo y no una transacción. + +### Referencias + +Las citas reproducen el texto publicado por su fuente. Los recortes se marcan con "[...]" y la negrita es de esta guía. + +[^rfc9700-aud]: [RFC 9700, §2.3 Access Token Privilege Restriction](https://www.rfc-editor.org/rfc/rfc9700.html#section-2.3): "In particular, **access tokens SHOULD be audience-restricted to a specific resource server** or, if that is not feasible, to a small set of resource servers." [§4.10.2 Audience-Restricted Access Tokens](https://www.rfc-editor.org/rfc/rfc9700.html#section-4.10.2): "The authorization server associates the access token with the particular resource server, and **the resource server is then supposed to verify the intended audience**. If the access token fails the intended audience validation, **the resource server refuses to serve the respective request**." +[^pou]: [v3-ActReason, TREAT](https://terminology.hl7.org/CodeSystem-v3-ActReason.html#v3-ActReason-TREAT): "treatment. **To perform one or more operations on information for provision of health care.**" [ETREAT](https://terminology.hl7.org/CodeSystem-v3-ActReason.html#v3-ActReason-ETREAT): "Emergency Treatment. To perform one or more operations on information for provision of **immediately needed health care for an emergent condition**." [PATRQT](https://terminology.hl7.org/CodeSystem-v3-ActReason.html#v3-ActReason-PATRQT): "patient requested. To perform one or more operations on information **in response to a patient's request**." [FAMRQT](https://terminology.hl7.org/CodeSystem-v3-ActReason.html#v3-ActReason-FAMRQT): "family requested. To perform one or more operations on information in response to a request by **a family member authorized by the patient**." [PWATRNY](https://terminology.hl7.org/CodeSystem-v3-ActReason.html#v3-ActReason-PWATRNY): "power of attorney. To perform one or more operations on information in response to a request by **a person appointed as the patient's legal representative**." +[^rfc8693-act]: [RFC 8693, §1.1 Delegation vs. Impersonation Semantics](https://www.rfc-editor.org/rfc/rfc8693.html#section-1.1): "With delegation semantics, principal A still has its own identity separate from B, and it is explicitly understood that while B may have delegated some of its rights to A, **any actions taken are being taken by A representing B**." [§2.1 Request](https://www.rfc-editor.org/rfc/rfc8693.html#section-2.1): "resource. OPTIONAL. **A URI that indicates the target service or resource where the client intends to use the requested security token.**" [§4.1 "act" (Actor) Claim](https://www.rfc-editor.org/rfc/rfc8693.html#section-4.1): "The act (actor) claim provides a means within a JWT to express that **delegation has occurred and identify the acting party to whom authority has been delegated**." +[^mhds-subject]: [MHDS Vol. 1, §1:50.1.1.1.1 When the grouped MHD Document Recipient is triggered](https://profiles.ihe.net/ITI/MHDS/volume-1.html#1501111-when-the-grouped-mhd-document-recipient--is-triggered): "The Document Registry SHALL validate that the subject of the DocumentReference, and List Resources is the same Patient, and that **Patient is a recognized and active Patient within the Community**. The Patient identity must be recognized and active by the PMIR Patient Identity Registry in the document sharing community. **This may be accomplished by a query of the PMIR Patient Identity Registry**, by way of a cached internal patient database, or other means." +[^iua-grants]: [IUA, §34.1.1.1 Authorization Client](https://profiles.ihe.net/ITI/IUA/index.html#34111-authorization-client): "The Get Access Token [ITI-71] transaction **is scoped to the Authorization Code and Client Credential grant types** (see ITI TF-1: 34.4.1.1 Authorization Grant Types)." [§3.71.4.1.2.1 Client Credential grant type](https://profiles.ihe.net/ITI/IUA/index.html#3714121-client-credential-grant-type): "requested_token_type (optional): The requested token format shall be urn:ietf:params:oauth:token-type:jwt, urn:ietf:params:oauth:token-type:saml2 or urn:ietf:params:oauth:token-type:access-token [**RFC 8693 OAuth 2.0 Token Exchange**, Section 3]." +[^pixm-subset]: [PIXm, §2:3.83.4.1.3 Expected Actions](https://profiles.ihe.net/ITI/PIXm/ITI-83.html#2383413-expected-actions): "**The Patient Identifiers returned may be a subset based on policies that might restrict access to some Patient Identifiers.** For guidance on handling Access Denied, see ITI TF-2: Appendix Z.7." +[^pixm-deprecated]: [PIXm, §2:3.83.4.2.2.5 Post Merge/Delete](https://profiles.ihe.net/ITI/PIXm/ITI-83.html#23834225-post-mergedelete): "Based upon policy, **when the Patient is deprecated or deleted, the response message shall return: 200 OK, and return a Bundle with no patient resource, or 404 Not Found**" +[^hie-cdr]: [IHE HIE Whitepaper, §2.8 Document Sharing Models](https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#28-document-sharing-models): "**Centralized Discovery and Retrieve** – in this model, a centralized locator is used to discover the location of documents which enables a retrieval of the document from a custodian who has registered existence of the document with the centralized locator". + +*[PMIR]: Patient Master Identity Registry, perfil IHE que gestiona la identidad maestra del paciente +*[PIXm]: Patient Identifier Cross-referencing for mobile, perfil IHE que enlaza los identificadores locales de un paciente con su identidad maestra +*[PDQm]: Patient Demographics Query for Mobile, perfil IHE de búsqueda de pacientes por datos demográficos +*[MHD]: Mobile access to Health Documents, perfil IHE para publicar, localizar y recuperar documentos sobre FHIR +*[MHDS]: Mobile Health Document Sharing, perfil IHE que compone MHD, PMIR, mCSD, IUA y ATNA en una comunidad de intercambio de documentos +*[mCSD]: Mobile Care Services Discovery, perfil IHE de directorio de organizaciones, servicios y endpoints +*[IUA]: Internet User Authorization, perfil IHE que aplica OAuth 2.0 a las transacciones sobre FHIR +*[ATNA]: Audit Trail and Node Authentication, perfil IHE de auditoría y seguridad de los nodos +*[BALP]: Basic Audit Log Patterns, perfil IHE con los patrones de AuditEvent de FHIR +*[CT]: Consistent Time, perfil IHE que sincroniza los relojes de los sistemas +*[PCF]: Privacy Consent on FHIR, perfil IHE de consentimiento del paciente diff --git a/input/pagecontent/volume-1-concepts.md b/input/pagecontent/volume-1-concepts.md new file mode 100644 index 0000000..eb96dc9 --- /dev/null +++ b/input/pagecontent/volume-1-concepts.md @@ -0,0 +1,226 @@ +Esta sección explica las decisiones que dan forma a esta comunidad. Cada una se presenta con lo que decide, por qué lo decide y lo que cuesta. Son decisiones de arquitectura, no de implementación. Una comunidad puede desplegarlas de muchas maneras sin que cambie nada de lo que aquí se describe. La [Tabla 2.1-2](volume-1-concepts.html#tabla-2-1-2) resume los compromisos asumidos, y la última subsección explica la relación de HIX con MHDS. + +### Comunidad y límite de confianza +{: #limite-de-confianza} + +Una comunidad HIX es un conjunto de organizaciones que acuerdan compartir documentos clínicos bajo una política común y a través de una infraestructura común. La pertenencia es explícita. Una organización es miembro cuando figura en el directorio de la comunidad y el Authorization Server reconoce a sus sistemas. + +**En una malla de pares, las garantías de la comunidad valen lo que valga su miembro más débil.** Ese es el argumento que decide la topología. Si cada miembro descubre y consulta a los demás, cada uno tiene que implementar el descubrimiento y mantener tantas relaciones de confianza como miembros haya. Cada uno tiene que poner además un punto de aplicación de política, el PEP, delante de sus propios datos, y auditar por su cuenta. La política de la comunidad se aplica entonces en tantos lugares como miembros, con la calidad que cada uno pueda pagar, y basta un miembro mal implementado para que la garantía deje de existir para todos. IHE describe ambas topologías en su whitepaper sobre intercambio de información de salud ([HIE Whitepaper, §2.8](https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#28-document-sharing-models) y [§3.2](https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#32-centralized-discovery-and-retrieve))[^hie-wp]. HIX elige la centralizada y absorbe esa complejidad una sola vez, en el centro, donde se puede operar, verificar y auditar. + +Por esta razón, la relación de confianza no se establece de forma directa entre los miembros, sino entre cada miembro y la infraestructura central. Un miembro no confía en los demás ni necesita conocerlos. Confía en que la comunidad autoriza, media y registra cada interacción. Integrarse a HIX es integrarse una sola vez, con la comunidad. No hay que integrarse con cada uno de los demás miembros, ni volver a hacerlo cuando entra uno nuevo. + +### Mediación central de la localización y la recuperación + +Toda localización y toda recuperación pasan por el [Record Locator Service](appendix-glossary.html#record-locator-service), el mediador de la comunidad. Un solicitante obtiene del mediador los punteros que la política le permite ver, y las URL de contenido que recibe apuntan al propio mediador, nunca al custodio. Al recuperar, el mediador alcanza al custodio en nombre del solicitante y le entrega el documento. + +MHDS admite que un consumidor alcance directamente al servicio que aloja un documento fuera del Document Registry ([MHDS Vol. 1, §1:50.1.1.2](https://profiles.ihe.net/ITI/MHDS/volume-1.html#150112-storage-of-binary))[^mhds-storage], y reconoce que en ese caso su opción de consentimiento **no protege el contenido** y que cada Document Source carga solo con la protección de sus documentos ([MHDS Vol. 1, §1:50.2.2](https://profiles.ihe.net/ITI/MHDS/volume-1.html#15022-consent-manager-option))[^mhds-consent]. Con custodia distribuida, eso obligaría a cada custodio a evaluar la política de la comunidad frente a cada consumidor. La mediación cierra ese hueco. La política se aplica en un solo lugar, con una única superficie auditable y un único contrato de integración. + +El precio es que la infraestructura central se vuelve indispensable para operar, y se dimensiona y protege como tal. Todo byte clínico atraviesa el mediador. La [sección 2.6](volume-1-security.html) especifica lo que eso exige. + +Mediar no es lo mismo que enrutar. El mediador es imprescindible donde hay que alcanzar a un custodio en nombre de un miembro, es decir, al recuperar, porque es quien obtiene el [token intercambiado](appendix-glossary.html#token-intercambiado) para ese custodio y recorre el canal que el directorio declara. + +La decisión de divulgación sobre los punteros es otra cosa. La toma la infraestructura central antes de mover contenido alguno, y puede tomarla el mediador o un Document Registry que conozca la política de la comunidad, como admite la Opción de Consentimiento de la [sección 2.3](volume-1-options.html). + +En las transacciones entre un miembro y un solo componente central, como declarar una identidad, el trabajo es otro. Consiste en comprobar que la petición cumple las reglas de la comunidad para esa transacción, por ejemplo que el miembro solo escribe en su propio dominio de identificadores, y en registrarla. Esa comprobación la puede hacer el mediador o el propio componente, siempre que el componente conozca esas reglas y registre en el mismo repositorio de auditoría. El miembro ejecuta siempre las mismas transacciones, con los mismos mensajes y las mismas reglas. Lo único que cambia es el punto que las valida, el mediador o el componente central. + +> **Nota.** El mediador es desacoplable. En esencia no añade nada al modelo de MHDS. Solo concentra el PEP y las transacciones que MHDS reparte entre los miembros. Sin él, la comunidad operaría en esencia como describe MHDS, con el mismo flujo, porque cada miembro puede hacer por su cuenta lo que hace el mediador, es decir, aplicar la política, resolver endpoints, obtener credenciales y auditar. Que pueda no quiere decir que convenga, y ese es [el argumento con el que abre esta sección](volume-1-concepts.html#limite-de-confianza). Quitar el mediador no cambia la arquitectura, solo mueve el PEP a cada miembro. + +### Custodia distribuida y almacenamiento central + +El documento permanece donde se produjo. El miembro que lo creó lo conserva, responde por su contenido y participa en cada recuperación que lo alcanza. La infraestructura central mantiene el índice, no una copia del expediente. + +MHDS admite dos ubicaciones válidas para el contenido, dentro del Document Registry o en cualquier otro lugar de la comunidad, incluido el sistema del propio Document Source ([MHDS Vol. 1, §1:50.1.1.2](https://profiles.ihe.net/ITI/MHDS/volume-1.html#150112-storage-of-binary))[^mhds-storage]. HIX adopta la segunda como **política por defecto** y ofrece la primera como opción. Un custodio que no puede alojar un endpoint ejerce la Opción de Almacenamiento Central y entrega el contenido a la infraestructura central sin dejar de figurar como custodio. + +Las dos ubicaciones tienen ejemplos nacionales. Estonia recupera cada documento del proveedor que lo produjo, como se ve en la sección de transporte. Suiza hace lo contrario. Cada comunidad de su expediente electrónico almacena los binarios en su propio Document Repository y las instituciones le entregan el documento al publicarlo ([eHealth Suisse, EPR architecture, §3.3.4](https://www.e-health-suisse.ch/payload/api/documents/file/EPD-Architektur_EN.pdf))[^ch-epr-arch]. Su acceso móvil se especifica sobre MHD en [CH EPR FHIR](https://fhir.ch/ig/ch-epr-fhir/index.html). Como la API que ve el solicitante es idéntica bajo ambas ubicaciones, un custodio puede pasar de una a otra sin que ningún miembro lo note. Por eso "el contenido nunca sale del custodio" es una política por defecto y no un principio absoluto. La arquitectura admite las dos y la comunidad decide por custodio. + +### Identidad del paciente + +Cada miembro **solo conoce y solo usa sus propios identificadores de paciente**. No conoce los de los demás miembros ni necesita conocerlos. Para la comunidad, cada miembro es un **dominio de identificadores** distinto, y un mismo identificador local solo tiene sentido dentro del dominio del miembro que lo asignó. La comunidad no reemplaza esos identificadores. Mantiene una **identidad maestra** por persona y enlaza con ella las identidades locales que los miembros declaran, de modo que cualquier identificador local, de cualquier miembro, resuelve a la misma persona. + +La identidad maestra es un recurso `Patient` en un dominio reservado a la identidad verificada, en el que solo escribe la fuente autoritativa. Lleva el identificador nacional de la persona, la cédula en el caso de la figura, que la ancla a alguien real, la demografía verificada que aporta la fuente autoritativa y los enlaces a sus identidades locales, uno por cada miembro que la haya declarado. Contra esa demografía buscan ITI-78 e ITI-119. No lleva demografía de los miembros. Los nombres y las fechas que cada miembro registra se quedan en él. + +![Identidad maestra e identidades locales](hix-master-patient-index.svg) + +**Figura 2.1-1:** Identidad maestra e identidades locales +{: #figura-2-1-1} + +La [Figura 2.1-1](volume-1-concepts.html#figura-2-1-1) muestra cómo se construye. + +- La **fuente autoritativa de identidad** es quien crea la identidad maestra. Lo hace con el feed **[PMIR](https://profiles.ihe.net/ITI/PMIR/index.html)** ([ITI-93](https://profiles.ihe.net/ITI/PMIR/ITI-93.html)), una vez que comprobó quién es la persona con su identificador nacional. Nadie más puede crear una identidad maestra. HIX no define cuál debe ser esa fuente, pero propone que sea el EDUS, como indica la introducción del volumen. +- Cada **miembro que publica** declara los pacientes de su dominio con el feed **[PIXm](https://profiles.ihe.net/ITI/PIXm/index.html)** ([ITI-104](https://profiles.ihe.net/ITI/PIXm/ITI-104.html)). Envía su identificador local junto con el identificador nacional de la persona, y el registro de identidad enlaza ese identificador local con la identidad maestra que ya existe para esa persona. Si la persona todavía no tiene identidad maestra, la declaración se rechaza. *Un miembro **vincula**, nunca crea.* +Tres consultas responden quién es un paciente, y todas buscan solo entre identidades maestras. La [Tabla 2.1-1](volume-1-concepts.html#tabla-2-1-1) las compara. La tercera ordena sus resultados y da a cada uno un grado de coincidencia, como fija PDQm ([PDQm, §2:3.119.4.2.2.4](https://profiles.ihe.net/ITI/PDQm/ITI-119.html#231194224-quality-of-match))[^pdqm-match]. + +**Tabla 2.1-1:** Consultas de identidad +{: #tabla-2-1-1} + +| Consulta | Transacción | Qué recibe | Qué devuelve | Cuándo se usa | +| --- | --- | --- | --- | --- | +| Por identificador | [ITI-83](https://profiles.ihe.net/ITI/PIXm/ITI-83.html) de PIXm | Un identificador, local o nacional | La identidad maestra enlazada a él | Es la vía normal. La usan también el Record Locator Service al localizar, el Document Registry al indexar y el Authorization Server al fijar el contexto de paciente | +| Por datos demográficos | [ITI-78](https://profiles.ihe.net/ITI/PDQm/ITI-78.html) de PDQm | Criterios como el nombre o la fecha de nacimiento | Las identidades maestras que coinciden con ellos | Cuando no hay un identificador fiable | +| Por coincidencia probabilística | [ITI-119](https://profiles.ihe.net/ITI/PDQm/ITI-119.html) de PDQm | Los datos de un candidato | Las identidades maestras que más se le parecen, de más a menos probable | Cuando los datos están incompletos o pueden traer errores, como un apellido mal escrito | +{: .table .table-bordered} + +> **Nota.** Un miembro no puede crear una persona, fusionar dos personas ni escribir en el dominio de otro. Sobre las identidades locales de su propio dominio decide él. Y ninguna de las tres consultas prueba una identidad. Eso solo lo hace la fuente autoritativa. + +### El puntero + +La unidad del índice es el puntero, un [`DocumentReference`](https://hl7.org/fhir/R5/documentreference.html) de FHIR R5 que describe un documento sin contenerlo. Toda decisión de la comunidad se toma sobre el puntero, antes de mover un byte del documento, así que lo que el puntero lleva es una decisión de arquitectura. Estos son sus elementos. + +- **`subject`** apunta a la identidad maestra del paciente en todo puntero que la comunidad registra, nunca a una identidad local. El miembro no necesita conocer la identidad maestra para publicar. Nombra al paciente con la identidad local que declaró, y la infraestructura central la resuelve con la consulta por identificador y escribe el resultado en `subject` al indexar. Así ningún miembro tiene que resolver identidades antes de publicar. Un miembro que ya conoce la identidad maestra puede publicarla directamente, y la infraestructura central la comprueba igual. +- **`sourcepatient`** es una extensión que apunta a la identidad local, es decir, al paciente tal como lo declaró el miembro, con su identificador en su propio dominio. Es la extensión estándar [`documentreference-sourcepatient`](https://hl7.org/fhir/extensions/StructureDefinition-documentreference-sourcepatient.html), que en R5 reemplaza a `context.sourcePatientInfo`. Conserva la traza de qué miembro declaró a quién y permite volver a resolver `subject` si un enlace de identidad cambia. Todo puntero registrado lleva los dos, `sourcepatient` hacia la identidad local y `subject` hacia la identidad maestra. +- **`custodian.identifier`** nombra a la organización responsable con el mismo identificador que lleva su token y que publica el directorio. Nunca es una referencia a un recurso. +- **`content.attachment.url`** es una ruta relativa al endpoint del custodio cuando el contenido queda en él. Bajo la Opción de Almacenamiento Central apunta al contenido que conserva el Document Registry. Un puntero nunca contiene una dirección física ni nada que identifique un transporte. La dirección se resuelve en el directorio en cada recuperación. +- **`securityLabel`** lleva la [etiqueta de confidencialidad](https://hl7.org/fhir/R5/security-labels.html) del documento, un código del sistema [v3-Confidentiality](https://terminology.hl7.org/CodeSystem-v3-Confidentiality.html) de HL7, como `N` para normal, `R` para restringido o `V` para muy restringido. Es obligatorio desde la primera publicación. Sin la etiqueta en el índice, decidir si un documento se puede divulgar exigiría leerlo primero, y añadirla después obligaría a releer todos los documentos en los custodios. +- **`identifier`** es el identificador de negocio del documento. Identifica una versión concreta, de modo que publicar dos veces la misma versión no duplica el puntero. Una versión nueva no sobrescribe el puntero anterior. Se publica como un puntero nuevo que declara en `relatesTo` que reemplaza al anterior, y el anterior pasa a estado `superseded`, como fija MHD ([MHD, §2:3.65.4.1.2.3](https://profiles.ihe.net/ITI/MHD/5.0.0/ITI-65.html#23654123-replace-transform-signs-and-append-associations))[^mhd-replace]. Así el índice conserva la historia de cada documento. + +El resto de elementos, como `status`, `type` o `date`, son los metadatos habituales de MHD y se especificarán más adelante en esta guía. + +Un puntero nunca se publica suelto. Cada publicación es un ITI-65 con un SubmissionSet, un recurso `List` que agrupa los punteros publicados juntos y dice quién los publicó y cuándo, y puede llevar además carpetas, que también son recursos `List` ([MHD, §2:3.65.4.1.2](https://profiles.ihe.net/ITI/MHD/5.0.0/ITI-65.html#2365412-message-semantics))[^mhd-bundle]. El Document Registry conserva esas listas junto a los punteros, y son lo que devuelve ITI-66. Por eso la decisión de divulgación se aplica también a ellas, y las fusiones de identidad alcanzan a su `subject` igual que al de los punteros. + +### Directorio de la comunidad + +El directorio describe las organizaciones participantes, su pertenencia a la comunidad y los endpoints en los que responden. Es la fuente de la que la infraestructura central aprende a quién dirigir una recuperación, por qué canal y qué opciones ejerce cada custodio. + +Los miembros no consultan el directorio, porque nunca se comunican entre sí. Lo consulta el mediador, en cada operación, para saber a qué custodio dirigirse y en qué endpoint. Por eso incorporar un miembro no exige reconfigurar nada. Basta con darlo de alta en el directorio para que el mediador pueda alcanzarlo. Un custodio puede tener más de un endpoint, porque mCSD lo admite ([mCSD, §1:46.8.2](https://profiles.ihe.net/ITI/mCSD/volume-1.html#14682-endpoint-content))[^mcsd-endpoints]. Con qué criterio elige el mediador entre ellos es política de la comunidad. Si el directorio no devuelve ninguno activo, el mediador trata al custodio como no disponible. + +El directorio fija dos valores que se usan tal cual en toda la comunidad. El **identificador de la organización** es el mismo que el Authorization Server incluye en los tokens del miembro para decir en nombre de qué organización actúa, y el mismo que sus punteros llevan en `custodian.identifier`. La **dirección del endpoint** es la URL a la que el mediador llama, la audiencia del token que obtiene para ese custodio y la base contra la que se resuelven las rutas relativas de sus punteros. Como token, puntero y directorio parten del mismo valor, no pueden desincronizarse. + +### Autorización y delegación + +HIX usa OAuth 2.0 ([RFC 6749](https://www.rfc-editor.org/rfc/rfc6749)) según lo perfila [IUA](https://profiles.ihe.net/ITI/IUA/index.html). La idea de fondo es sencilla. Para hablar con la comunidad, un sistema necesita un token, y todos los tokens los emite un único Authorization Server. + +Un miembro obtiene un token para hablar con el Record Locator Service, y solo con él. Ese token no sirve ante ningún custodio, y el miembro nunca recibe uno que sirva. El mediador comprueba cada token que recibe preguntando al Authorization Server si sigue siendo válido. Esa consulta es la introspección de [RFC 7662](https://www.rfc-editor.org/rfc/rfc7662), que IUA recoge como la transacción Introspect Token ([ITI-102](https://profiles.ihe.net/ITI/IUA/index.html#3102-introspect-token-iti-102)). + +Cuando una operación exige llegar a un custodio, el mediador no reutiliza el [token del solicitante](appendix-glossary.html#token-del-solicitante). Lo **intercambia** por otro, siguiendo OAuth 2.0 Token Exchange ([RFC 8693](https://www.rfc-editor.org/rfc/rfc8693)) con un resource indicator ([RFC 8707](https://www.rfc-editor.org/rfc/rfc8707)). Presenta al Authorization Server el token del solicitante y pide a cambio uno nuevo, hecho a la medida de esa llamada. Vale para un solo custodio y una sola transacción, dura como mucho dos minutos y dice dentro quién pidió y quién actúa en su nombre. La [Tabla 2.6-1](volume-1-security.html#tabla-2-6-1) detalla lo que lleva. + +El custodio valida ese token por su cuenta, con las claves públicas del Authorization Server, sin tener que preguntarle. Así sabe quién pregunta, en nombre de quién actúa la comunidad y para qué. + +Lo mismo vale hacia los componentes centrales. El mediador no tiene acceso propio al Document Registry ni al registro de identidad maestra. Actúa ante ellos con tokens intercambiados de la misma forma, a nombre del miembro que lo pidió. Un puntero queda registrado a nombre de su custodio, no del mediador. El mediador es el primer punto de aplicación de la política de la comunidad, no un participante con autoridad propia. + +La [Figura 2.1-2](volume-1-concepts.html#figura-2-1-2) resume el recorrido de los tokens. Un solo token entra por la izquierda, el del miembro, y de él derivan tantos tokens de un solo destino como custodios y componentes centrales haga falta alcanzar. + +![Delegación de tokens en HIX](hix-delegacion.svg) + +**Figura 2.1-2:** Delegación de tokens en HIX +{: #figura-2-1-2} + +Tres reglas hacen que el mínimo privilegio sea estructural, en lugar de depender de la buena conducta de cada parte. + +- **Un token, el destino mínimo.** Cada token vale solo ante quien tiene que recibirlo. El intercambiado vale ante un único destino, porque uno que valiera en dos custodios permitiría a uno de ellos usarlo contra el otro. +- **Solo el mediador puede intercambiar.** Ningún otro participante puede pedir un token a nombre de un tercero, y los custodios no aceptan tokens llegados por otro camino. +- **La autoridad nunca crece.** El token intercambiado solo permite lo que el miembro ya podía, lo que la comunidad delega al mediador y lo que el custodio ofrece. Poder localizar un documento nunca da poder para recuperarlo. + +Un token dice quién pide, qué puede pedir, ante quién y hasta cuándo. El token de un miembro **no nombra a ningún paciente**. Solo lo hace el de una persona que entra a su propio expediente con [SMART App Launch](https://hl7.org/fhir/smart-app-launch/scopes-and-launch-context.html), y ahí el paciente en contexto sirve para confinar el token a ese expediente. La cuenta con la que esa persona entra no es un identificador de paciente. El Authorization Server resuelve el paciente en contexto contra la identidad maestra con la consulta por identificador. En ambos casos, **tener un token da derecho a preguntar, no a ver**. Qué documentos se entregan lo decide la infraestructura central, puntero por puntero. Esa separación es la idea más importante de este volumen. + +### Divulgación + +La decisión de divulgación se toma en la infraestructura central, **sobre los punteros y antes de recuperar contenido alguno**. La toma el mediador o, cuando la comunidad la sitúa allí, el Document Registry. Quien la toma combina dos fuentes. Del token toma lo que el Authorization Server avaló del solicitante, es decir, su organización, su propósito de uso y, cuando existe, el paciente en contexto. Del puntero toma el paciente, la etiqueta de confidencialidad, el tipo de documento y el custodio. Nada de lo que el solicitante afirme de sí mismo en la petición cuenta. + +Ese orden es lo que hace que centralizar valga su costo. Un puntero cuya divulgación se niega no genera ninguna recuperación, ninguna consulta al directorio y ningún token. La decisión se toma una vez por consulta, y un documento atraviesa dos, porque revelar que existe ya es una divulgación. Al localizar, se filtran los punteros de la respuesta. Al recuperar, el mediador vuelve a evaluar el puntero pedido antes de alcanzar al custodio. Un puntero negado no aparece en la respuesta ni se anuncia como negado. + +El punto de partida es un entorno de consentimiento implícito, con una política única para toda la comunidad. MHDS lo describe en su Consent Manager Option como el entorno en el que se permite divulgar mientras el paciente no haya registrado un consentimiento ([MHDS Vol. 1, §1:50.2.2](https://profiles.ihe.net/ITI/MHDS/volume-1.html#15022-consent-manager-option))[^mhds-implied]. El destino es [PCF](https://profiles.ihe.net/ITI/PCF/volume-1.html#1534-pcf-overview), donde las directivas de consentimiento de cada paciente se evalúan en cada petición ([PCF Vol. 1, §1:53.4](https://profiles.ihe.net/ITI/PCF/volume-1.html#1534-pcf-overview))[^pcf]. La Opción de Consentimiento declara dónde se aplica esa decisión y qué información necesita. **El modelo de consentimiento se especificará en una versión posterior de esta guía a partir de PCF.** + +### Auditoría en ambos extremos + +Cada participante registra lo que hace. Es lo que [ATNA](https://profiles.ihe.net/ITI/TF/Volume1/ch-9.html) exige a todo sistema que se declara [Secure Node o Secure Application](appendix-glossary.html#secure-node) ([ITI TF-1, §9.1.1.1](https://profiles.ihe.net/ITI/TF/Volume1/ch-9.html#9.1.1.1))[^atna-node] y lo que MHDS exige a su Document Registry ([MHDS Vol. 1, §1:50.1.1.1](https://profiles.ihe.net/ITI/MHDS/volume-1.html#150111-document-registry))[^mhds-audit]. Los registros siguen los patrones de [BALP](https://profiles.ihe.net/ITI/BALP/index.html), que definen cómo se escribe un `AuditEvent` de FHIR para cada tipo de evento. La infraestructura central registra la solicitud que recibe del miembro y la recuperación que ella misma inicia hacia el custodio. El custodio registra la entrega. + +Los registros de una misma divulgación comparten un identificador de correlación. El mediador lo genera al recibir la solicitud y lo transmite al custodio en cada llamada. BALP prevé este uso y reserva un elemento del `AuditEvent` para guardar el identificador de la petición y correlacionar los registros de cliente y servidor ([BALP, §3:5.7.3.1](https://profiles.ihe.net/ITI/BALP/content.html#35731-x-request-id-header))[^balp-corr]. Así una divulgación se puede reconstruir completa desde sus dos lados. + +El token intercambiado nombra al solicitante original y al mediador como actor. Por eso el custodio registra quién pidió el documento y en nombre de quién actuó la comunidad, y no solo que lo pidió la comunidad. + +Ningún registro contiene un token completo ni contenido clínico. Basta un identificador del token, como su `jti`, para atar el evento a él. Todos los componentes centrales registran en el mismo [Audit Record Repository](appendix-glossary.html#audit-record-repository) de ATNA, el repositorio de auditoría de la comunidad. Como además toda divulgación pasa por el mediador, la pregunta "quién accedió al expediente de esta persona" se responde desde un solo lugar, ese repositorio. Cómo se consulta se especificará más adelante, como señala la [descripción general](index.html). Eso no exime a ningún custodio de registrar su lado. + +### Transporte y redes de intercambio + +La dirección física de un custodio vive únicamente en el directorio. El puntero lleva una organización y una ruta relativa. El mediador resuelve la dirección en cada recuperación y llega al custodio por el canal que el directorio declara para él. Ese canal puede ser una conexión directa o una red de intercambio ya establecida, como [X-Road](https://x-road.global/). En ambos casos el puntero, la API que ven los miembros y el modelo de tokens son los mismos. Cambiar de canal es cambiar un dato del directorio. + +Una red de intercambio resuelve cómo se conectan las organizaciones y cómo se identifican entre sí. No dice nada de documentos, punteros ni consentimiento. Por eso HIX la usa solo por debajo del mediador. Si los miembros la usaran para hablar entre sí, volverían a la malla de pares que HIX descarta. Estonia sigue este mismo patrón. Su registro nacional de salud recupera los datos de cada proveedor cuando se necesitan y los presenta en un formato común ([e-Estonia](https://e-estonia.com/solutions/healthcare/e-health-records/))[^estonia], y los sistemas de información del país se conectan entre sí sobre X-Road ([e-Estonia](https://e-estonia.com/solutions/interoperability-services/x-road/))[^estonia-xroad]. El token intercambiado sigue viajando por ese canal y el custodio sigue validándolo. La identidad que la red asigna a cada organización no lo sustituye. + +### Comunidades vecinas + +Una comunidad HIX puede conectarse con comunidades que operen sobre [XDS](https://profiles.ihe.net/ITI/TF/Volume1/ch-10.html) o [XCA](https://profiles.ihe.net/ITI/TF/Volume1/ch-18.html) mediante una pasarela. Ante HIX la pasarela es un miembro más, custodio de los documentos que trae de la otra comunidad o consumidor de los que le pide. Ante la otra comunidad es un Initiating Gateway o un Responding Gateway de XCA. Así la mediación se conserva, porque el Record Locator Service alcanza a la pasarela como a cualquier custodio y ningún miembro habla con la otra comunidad. + +MHD prevé un puente así hacia XDS con su [XDS on FHIR Option](https://profiles.ihe.net/ITI/MHD/5.0.0/1332_actor_options.html#13322-xds-on-fhir-option)[^mhd-xds-on-fhir], y advierte que no convive en un mismo despliegue con la UnContained Reference Option que declaran los actores de HIX. Por eso la pasarela es siempre un sistema aparte. Esta guía no la especifica. + +### Compromisos asumidos + +IHE deja la gobernanza fuera de su alcance. Declara que no define políticas de privacidad ni de seguridad, y que el marco de políticas de una comunidad debe definirse antes de construirla ([MHDS Vol. 1, §1:50.5](https://profiles.ihe.net/ITI/MHDS/volume-1.html#1505-mhds-security-considerations) y [§1:50.5.1](https://profiles.ihe.net/ITI/MHDS/volume-1.html#15051-policies-and-risk-management))[^mhds-policy]. Por eso, de los compromisos de la tabla, la apuesta por la operación del centro es el que más pesa. + +**Tabla 2.1-2:** Compromisos de la arquitectura +{: #tabla-2-1-2} + +| Compromiso | Qué se acepta | Cómo se mitiga | +| --- | --- | --- | +| Acoplamiento de disponibilidad | Una recuperación mediada necesita al mediador, al Authorization Server y al custodio a la vez | Un custodio caído degrada la respuesta, no la hace fallar. Cualquier custodio puede pasar a almacenamiento central sin que nadie lo note | +| Contenido en tránsito por el centro | Todo byte clínico atraviesa el mediador, que lo ve en claro | El mediador no guarda ni registra contenido. El canal entre organizaciones va cifrado. El índice se gobierna como dato sensible | +| Authorization Server en el camino crítico | Cada localización exige una introspección y cada recuperación, además, un intercambio de tokens | Se dimensiona con la misma disponibilidad que el mediador. Un token intercambiado vale para un solo destino y dura como mucho dos minutos, así que un token filtrado tiene una ventana de uso corta y conocida | +| Apuesta por la operación del centro | La garantía de la comunidad vale lo que valga la operación de su infraestructura central. Un centro bien operado supera a una federación operada a medias, y un centro mal operado es peor que esa federación | Quién certifica miembros, quién responde al paciente y quién financia el centro se fija en la gobernanza de la comunidad, antes de construirla. Es su riesgo principal a largo plazo | +{: .table .table-bordered} + +### Relación con MHDS +{: #relacion-con-mhds} + +HIX sigue la forma de comunidad que describe [MHDS](https://profiles.ihe.net/ITI/MHDS/volume-1.html), con una infraestructura central de servicios compartidos y miembros que publican y consumen a través de ella, y toma de él buena parte de su vocabulario. No declara conformidad con MHDS. La declara con los perfiles que MHDS compone, que son los que se mantienen, se prueban y se distribuyen como paquetes versionados. + +Hay dos razones. La primera es que la última publicación de MHDS es de agosto de 2023 y está hecha sobre FHIR R4[^mhds-version], y los perfiles que compone siguieron cambiando después. [MHD se publicó sobre FHIR R5](https://profiles.ihe.net/ITI/MHD/5.0.0/index.html) y mCSD rehízo y renombró todos sus actores ([mCSD, Significant Changes](https://profiles.ihe.net/ITI/mCSD/issues.html#significant-changes))[^mcsd-rename], de modo que MHDS nombra hoy actores que mCSD ya no define. + +La segunda es que algunas de sus decisiones chocan con los perfiles que compone. MHDS agrupa el Document Registry con el Authorization Server ([MHDS Vol. 1, §1:50.2.1](https://profiles.ihe.net/ITI/MHDS/volume-1.html#15021-authorization-option))[^mhds-as-grouping] y deja en este la gestión del consentimiento ([MHDS Vol. 1, §1:50.2.2](https://profiles.ihe.net/ITI/MHDS/volume-1.html#15022-consent-manager-option))[^mhds-consent-as]. IUA, en cambio, se distingue precisamente por no atar el Authorization Server a los Resource Servers ([IUA, Relation to SMART-on-FHIR](https://profiles.ihe.net/ITI/IUA/index.html#relation-to-smart-on-fhir))[^iua-loose]. + +De ahí salen dos reglas. Cuando MHDS y un perfil vigente dicen cosas distintas, prevalece el perfil vigente. Cuando MHDS y una decisión de HIX dicen cosas distintas, esta guía declara en qué se aparta y por qué. La [Tabla 2.1-3](volume-1-concepts.html#tabla-2-1-3) reúne lo que HIX toma de MHDS y lo que no. + +**Tabla 2.1-3:** Lo que HIX toma de MHDS y lo que no +{: #tabla-2-1-3} + +| Asunto | En MHDS | En HIX | +| --- | --- | --- | +| Forma de la comunidad | Infraestructura central de servicios compartidos, con miembros que publican y consumen | La misma | +| Document Registry | Actor propio de MHDS, con sus opciones | Actor de HIX con el mismo nombre y la misma función, definido por los actores que agrupa en la [sección 2.4](volume-1-groupings.html) | +| Acceso de quien consulta | Directo al Document Registry y, si el contenido está fuera de él, al servicio que lo aloja | Siempre a través del Record Locator Service | +| Identidad que aporta un miembro | El miembro crea y actualiza identidades en el registro de la comunidad, como Patient Identity Source de PMIR | El miembro declara sus identidades locales con ITI-104 de PIXm y nunca crea una persona | +| Authorization Server | Agrupado con el Document Registry bajo la Authorization Option | Servicio central independiente y único emisor de la comunidad | +| Consentimiento | Lo gestiona y decide el Authorization Server agrupado | La decisión de divulgación se toma en la infraestructura central, separada de la autorización | +| Versiones | FHIR R4 y las versiones de los perfiles vigentes en 2023 | FHIR R5 y la versión vigente de cada perfil | +{: .table .table-bordered} + +El apartamiento de más peso es el de la identidad. MHDS deja que los participantes creen y actualicen identidades en el registro de la comunidad ([MHDS Vol. 1, §1:50.1](https://profiles.ihe.net/ITI/MHDS/volume-1.html#1501-mhds-actors-transactions-and-content-modules))[^mhds-identity]. HIX reserva esa facultad a la fuente autoritativa, como explica el apartado sobre la [identidad del paciente](volume-1-concepts.html#identidad-del-paciente), para que ningún miembro pueda crear una persona. + +### Referencias + +Las citas reproducen el texto publicado por su fuente. Los recortes se marcan con "[...]" y la negrita es de esta guía. + +[^mhds-consent]: [MHDS Vol. 1, §1:50.2.2 Consent Manager Option](https://profiles.ihe.net/ITI/MHDS/volume-1.html#15022-consent-manager-option): "Note that this option **does not protect Binary content stored outside of the Document Registry** [...]. When documents are stored outside of the Document Registry, **the Document Source system takes on the burden of protecting the document**." +[^mhds-storage]: [MHDS Vol. 1, §1:50.1.1.2 Storage of Binary](https://profiles.ihe.net/ITI/MHDS/volume-1.html#150112-storage-of-binary): "(1) The Document Source includes the Binary Resource in the [ITI-65] transaction, and the Document Registry is required to store it. (2) **The Community allows the Binary to be stored elsewhere in the Community.** [...] This might be other centralized infrastructure, distributed infrastructure, or **within the system implementing the Document Source**. [...] the service hosting the Binary shall: [...] **provide access to the community members**". +[^hie-wp]: [IHE HIE Whitepaper, §2.8 Document Sharing Models](https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#28-document-sharing-models): "the centralized model **requires knowledge only of the centralized locator** [...]. For Push and Federated approaches **a detailed directory of participating entitles** [sic] is typically used". [§3.2 Centralized Discovery and Retrieve](https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#32-centralized-discovery-and-retrieve): "a centralized locator is used to discover the location of documents which enables **a retrieval of the document from a custodian** who has registered existence of the document with the centralized locator". +[^mhds-implied]: [MHDS Vol. 1, §1:50.2.2 Consent Manager Option](https://profiles.ihe.net/ITI/MHDS/volume-1.html#15022-consent-manager-option): "The grouped IUA Authorization Server SHALL support consent configuration to enable Implied Consent and Explicit Consent environments. **Implied Consent environments allow disclosure when no Consent has been recorded for that patient**, Explicit Consent environments Deny disclosure when no Consent has been recorded for that patient." +[^pcf]: [PCF Vol. 1, §1:53.4 PCF Overview](https://profiles.ihe.net/ITI/PCF/volume-1.html#1534-pcf-overview): "The PCF Profile enables authorized access to data according to terms agreed by the Patient and the Organization protecting the data." [§1:53.1.1.3 Consent Authorization Server](https://profiles.ihe.net/ITI/PCF/volume-1.html#153113-consent-authorization-server): "The Consent Authorization Server **makes authorization decisions based on a given access requested context** (e.g., oAuth, query/operation parameters), organizational policies, and **current active Consent resources**." +[^atna-node]: [ITI TF-1, §9.1.1.1 Secure Node](https://profiles.ihe.net/ITI/TF/Volume1/ch-9.html#9.1.1.1): "Detect and report a Record Audit Event as specified in ITI TF-2: 3.20 for: **all of the activity-related events for the Secure Node** [...] **all transaction-related events for the Secure Node**". +[^mhds-audit]: [MHDS Vol. 1, §1:50.1.1.1 Document Registry](https://profiles.ihe.net/ITI/MHDS/volume-1.html#150111-document-registry): "The Document Registry **SHALL record all security relevant events** to ATNA Audit Record Repository with the “ATX: FHIR Feed” Option." +[^mhds-policy]: [MHDS Vol. 1, §1:50.5 MHDS Security Considerations](https://profiles.ihe.net/ITI/MHDS/volume-1.html#1505-mhds-security-considerations): "**The policy landscape that the community is built on needs to be defined well before the community is built.**" [§1:50.5.1 Policies and Risk Management](https://profiles.ihe.net/ITI/MHDS/volume-1.html#15051-policies-and-risk-management): "IHE solves interoperability problems via the implementation of technology standards. **It does not define Privacy or Security Policies**, Risk Management, Healthcare Application Functionality, Operating System Functionality, Physical Controls, or even general Network Controls." +[^balp-corr]: [BALP, §3:5.7.3.1 X-Request-Id header](https://profiles.ihe.net/ITI/BALP/content.html#35731-x-request-id-header): "Where it is known that an http RESTful transaction included an X-Request-Id, that value should be recorded in an .entity dedicated to X-Request-Id. **This ID can be used to correlated AuditEvents from client and server**, and may aid with correlation on further activities recorded caused by the transaction." +[^ch-epr-arch]: [eHealth Suisse, EPR architecture. A detailed description, §3.3.4 XDS Document Repositories](https://www.e-health-suisse.ch/payload/api/documents/file/EPD-Architektur_EN.pdf): "The Document Repository Service implements interfaces to **store and query the binary objects** of the XDS documents. **The data are captured by the connected systems of the (core) communities when documents are saved** and are registered via interfaces." +[^estonia]: [e-Estonia, e-Health Record](https://e-estonia.com/solutions/healthcare/e-health-records/): "the e-Health Record actually **retrieves data as necessary from various providers**, who may be using different systems" and "presents it in a standard format". +[^estonia-xroad]: [e-Estonia, X-Road](https://e-estonia.com/solutions/interoperability-services/x-road/): "X-Road®, an open-source software and ecosystem solution that provides unified and secure data exchange between private and public sector organisations, **is the backbone of e-Estonia**. Invisible yet crucial, it allows the nation’s various public and private sector e-service information systems to link up and function in harmony." +[^mhds-version]: [MHDS, pie de la publicación vigente](https://profiles.ihe.net/ITI/MHDS/index.html): "Package ihe.iti.mhds#2.3.1 based on FHIR 4.0.1. Generated 2023-08-04" +[^mcsd-rename]: [mCSD, Significant Changes](https://profiles.ihe.net/ITI/mCSD/issues.html#significant-changes): "**Reworked all Actors to improve clarity**", con la tabla de equivalencias "New Actor (with Option) | Old Actor", que incluye "Directory | Care Services Selective Supplier" y "Query Client | Care Services Selective Consumer". +[^mhds-as-grouping]: [MHDS Vol. 1, §1:50.2.1 Authorization Option](https://profiles.ihe.net/ITI/MHDS/volume-1.html#15021-authorization-option): "**The Document Registry SHALL be grouped with an IUA Resource Server and the IUA Authorization Server Actors.** The IUA Authorization Server Metadata Option shall be supported." +[^mhds-consent-as]: [MHDS Vol. 1, §1:50.2.2 Consent Manager Option](https://profiles.ihe.net/ITI/MHDS/volume-1.html#15022-consent-manager-option): "**The grouped IUA Authorization Server would be used to manage the consent status and make authorization decisions based on the consent status.** [...] The IUA Resource Server that is grouped with the MHDS Document Registry would enforce these decisions." +[^iua-loose]: [IUA, Relation to SMART-on-FHIR](https://profiles.ihe.net/ITI/IUA/index.html#relation-to-smart-on-fhir): "**IUA promotes a loose coupling of Resource Server and Authorization Servers.** This allows for deployments with multiple Resource Servers per Authorization Server as well as deployments with several or even no Authorization Servers." +[^mhds-identity]: [MHDS Vol. 1, §1:50.1 MHDS Actors, Transactions, and Content Modules](https://profiles.ihe.net/ITI/MHDS/volume-1.html#1501-mhds-actors-transactions-and-content-modules): "PMIR – Patient Identity Source and Patient Identity Registry – to provide patient identity lookup by demographics or identity, and **to receive create and update of patient identity from participants**" +[^mhd-replace]: [MHD, §2:3.65.4.1.2.3 Replace, Transform, Signs, and Append Associations](https://profiles.ihe.net/ITI/MHD/5.0.0/ITI-65.html#23654123-replace-transform-signs-and-append-associations): "The relatesTo.target element in the provided DocumentReference points at the pre-existing DocumentReference that is being replaced, transformed, signed, or appended. [...] **If a DocumentReference is being replaced, that DocumentReference needs to have the status element updated to superseded within the transaction bundle** with the UpdateDocumentsRef slice". +[^mcsd-endpoints]: [mCSD, §1:46.8.2 Endpoint Content](https://profiles.ihe.net/ITI/mCSD/volume-1.html#14682-endpoint-content): "The Endpoint.connectionType and specificType extension indicate the type of connectivity enabled by the Endpoint. As such, **Organization and OrganizationAffiliation Resources MAY have many Endpoints** for the various types of connectivity they support." +[^pdqm-match]: [PDQm, §2:3.119.4.1.3 Expected Actions](https://profiles.ihe.net/ITI/PDQm/ITI-119.html#23119413-expected-actions): "The results are ordered from most likely to least likely." [§2:3.119.4.2.2.4 Quality of Match](https://profiles.ihe.net/ITI/PDQm/ITI-119.html#231194224-quality-of-match): "**The Patient Demographics Supplier SHALL convey the quality of each match** based on strength of the particular result to the supplied Patient Resource. [...] it SHALL represent the confidence of a particular match within the bundle as a score attribute." +[^mhd-bundle]: [MHD, §2:3.65.4.1.2 Message Semantics](https://profiles.ihe.net/ITI/MHD/5.0.0/ITI-65.html#2365412-message-semantics): "The Document Source shall initiate a FHIR “transaction” using a “create” action by sending an HTTP POST request method composed of a FHIR Bundle Resource containing: **one SubmissionSet type List Resource; one or more DocumentReference Resources; zero or more Folder type List Resources; and zero or more Binary Resources** to the Document Recipient." +[^mhd-xds-on-fhir]: [MHD, §1:33.2.2 XDS on FHIR Option](https://profiles.ihe.net/ITI/MHD/5.0.0/1332_actor_options.html#13322-xds-on-fhir-option): "**The Document Responder that supports this option shall be able to be grouped with an XDS Document Consumer** so that any query or retrieve requests can be passed on to, and responded to, by an XDS environment." [§1:33.2.3 UnContained Reference Option](https://profiles.ihe.net/ITI/MHD/5.0.0/1332_actor_options.html#13323-uncontained-reference-option): "The UnContained Reference Option is not compatible with the XDS on FHIR Option. A system may be able to support both options, but **only one will be able to be used at a given deployment**." + +*[PMIR]: Patient Master Identity Registry, perfil IHE que gestiona la identidad maestra del paciente +*[PIXm]: Patient Identifier Cross-referencing for mobile, perfil IHE que enlaza los identificadores locales de un paciente con su identidad maestra +*[PDQm]: Patient Demographics Query for Mobile, perfil IHE de búsqueda de pacientes por datos demográficos +*[MHD]: Mobile access to Health Documents, perfil IHE para publicar, localizar y recuperar documentos sobre FHIR +*[MHDS]: Mobile Health Document Sharing, perfil IHE que compone MHD, PMIR, mCSD, IUA y ATNA en una comunidad de intercambio de documentos +*[mCSD]: Mobile Care Services Discovery, perfil IHE de directorio de organizaciones, servicios y endpoints +*[IUA]: Internet User Authorization, perfil IHE que aplica OAuth 2.0 a las transacciones sobre FHIR +*[ATNA]: Audit Trail and Node Authentication, perfil IHE de auditoría y seguridad de los nodos +*[BALP]: Basic Audit Log Patterns, perfil IHE con los patrones de AuditEvent de FHIR +*[PCF]: Privacy Consent on FHIR, perfil IHE de consentimiento del paciente +*[XDS]: Cross-Enterprise Document Sharing, perfil IHE de intercambio de documentos sobre SOAP +*[XCA]: Cross-Community Access, perfil IHE de acceso a documentos entre comunidades diff --git a/input/pagecontent/volume-1-groupings.md b/input/pagecontent/volume-1-groupings.md new file mode 100644 index 0000000..06eccc8 --- /dev/null +++ b/input/pagecontent/volume-1-groupings.md @@ -0,0 +1,121 @@ +Un actor de HIX no se implementa desde cero. Se implementa agrupando actores de los perfiles IHE que HIX compone, y cada uno de ellos trae consigo sus transacciones, sus opciones y sus requisitos. La [sección 2.2](volume-1-actors.html) dice qué transacciones ejecuta cada actor. Esta sección dice de qué está hecho, es decir, qué actores IHE agrupa y bajo qué opciones. Para quien implementa, es la lista de perfiles que debe leer y de agrupaciones que debe declarar al afirmar su conformidad. Para quien solo quiere entender la arquitectura, basta con la [sección 2.2](volume-1-actors.html) y esta queda como referencia. + +Las agrupaciones se describen primero en prosa, actor por actor, y se resumen al final en la [Tabla 2.4-2](volume-1-groupings.html#tabla-2-4-2). + +### Lo que casi todos agrupan + +Tres perfiles acompañan a casi todos los actores de HIX. Se describen aquí una sola vez y no se repiten en cada actor. + +**IUA pone el token en cada transacción.** Todo miembro es un [Authorization Client](appendix-glossary.html#authorization-client) de IUA. Obtiene el token del Authorization Server con [ITI-71](https://profiles.ihe.net/ITI/IUA/index.html#371-get-access-token-iti-71), que en la aplicación del paciente toma la forma de [HIX-2](volume-1-actors.html#hix-2), y lo presenta en cada solicitud con [ITI-72](https://profiles.ihe.net/ITI/IUA/index.html#372-incorporate-access-token-iti-72). Todo actor ante el que un miembro presenta un token, directamente o a través del Record Locator Service, es un [Resource Server](appendix-glossary.html#resource-server) de IUA, que recibe el token con ITI-72 y lo comprueba. Ambos pueden descubrir los endpoints del Authorization Server mediante [ITI-103](https://profiles.ihe.net/ITI/IUA/index.html#3103-get-authorization-server-metadata-iti-103)[^iua-actors]. + +IUA exige a todo Resource Server declarar con qué opción comprueba el token ([IUA, Tabla 34.2-1](https://profiles.ihe.net/ITI/IUA/index.html#342-iua-actor-options))[^iua-options]. Las opciones son la [Token Introspection Option](https://profiles.ihe.net/ITI/IUA/index.html#3424-token-introspection-option), la [JWT Token Option](https://profiles.ihe.net/ITI/IUA/index.html#3422-jwt-token-option) y la [Authorization Server Metadata Option](https://profiles.ihe.net/ITI/IUA/index.html#3421-authorization-server-metadata-option), y la [Tabla 2.4-1](volume-1-groupings.html#tabla-2-4-1) dice cuáles declara cada actor de HIX. + +**Tabla 2.4-1:** Cómo comprueba el token cada actor +{: #tabla-2-4-1} + +| Actor | Opciones de IUA | Cómo comprueba el token | +| --- | --- | --- | +| Record Locator Service | Token Introspection | Pregunta al Authorization Server con [ITI-102](https://profiles.ihe.net/ITI/IUA/index.html#3102-introspect-token-iti-102) | +| Custodio, Document Registry y registro de identidad maestra | JWT Token, Authorization Server Metadata | Por sí mismo, con las claves que el Authorization Server publica | +| Authorization Server | JWT Token, Authorization Server Metadata, Token Introspection | Emite los tokens como JWT, publica sus endpoints y sus claves con ITI-103 y responde ITI-102 | +{: .table .table-bordered} + +Un mismo sistema puede ser las dos cosas. El Record Locator Service es Resource Server ante los miembros y Authorization Client ante los custodios y los actores centrales, y un custodio presenta tokens al publicar y los valida al servir documentos. Cómo se autentican entre sí los demás actores centrales queda a criterio de la implementación, porque pueden compartir un mismo sistema, como dice el apartado sobre los despliegues. + +**ATNA protege el canal y deja rastro.** Todo sistema que participa en HIX, salvo la aplicación del paciente, es un [Secure Node o Secure Application](appendix-glossary.html#secure-node) de ATNA. Autentica al nodo con el que habla y cifra el canal con [ITI-19](https://profiles.ihe.net/ITI/TF/Volume2/ITI-19.html), bajo la opción [STX: TLS 1.2 Floor using BCP195](https://profiles.ihe.net/ITI/TF/Volume1/ch-9.html#9.2.6.4), y registra sus eventos de auditoría con [ITI-20](https://profiles.ihe.net/ITI/TF/Volume2/ITI-20.html), como recursos AuditEvent bajo la opción ATX: FHIR Feed[^atna-fhir-feed] y con el contenido que cada perfil define a partir de los patrones de BALP. Esa opción pide a quien registra al menos una de las dos interacciones de ITI-20, y al Audit Record Repository las dos. Quien escribe esos registros es, en términos de BALP, un Audit Creator, que BALP agrupa precisamente con ese Secure Node o Secure Application ([BALP, §1:52.1.1.1](https://profiles.ihe.net/ITI/BALP/volume-1.html#152111-audit-creator))[^balp-creator]. Los actores centrales envían sus eventos al Audit Record Repository de la comunidad. Cada miembro conserva los suyos en su propio repositorio. + +**CT mantiene los relojes de acuerdo.** Todo sistema que participa en HIX, salvo la aplicación del paciente, es un [Time Client](appendix-glossary.html#time-client) de CT y sincroniza su reloj con [ITI-1](https://profiles.ihe.net/ITI/TF/Volume2/ITI-1.html) contra el Time Server que la comunidad designa, propio o una fuente de tiempo externa. Sin relojes de acuerdo, los eventos de una misma divulgación no podrían ordenarse entre sistemas y la vigencia de dos minutos del token intercambiado no significaría lo mismo en cada extremo. + +Esta guía deja por ahora a la aplicación del paciente fuera de ATNA y de CT. Su actividad queda registrada por los dos actores centrales ante los que actúa, el Authorization Server al lanzarse y el Record Locator Service en cada consulta. + +> **TODO.** Alinear el tratamiento de la aplicación del paciente. Figura como cliente en el Authorization Server, puede ser un cliente confidencial cuando tiene backend propio, y de eso depende si se la considera miembro y qué le exigen ATNA, CT y la auditoría. + +### Miembros + +**Custodio.** Es un [Document Source](appendix-glossary.html#document-source) de MHD con la Comprehensive Metadata Option, porque el Document Registry exige metadatos completos al publicar, como hace el de MHDS[^mhds-source-comprehensive]. Declara también la [UnContained Reference Option](https://profiles.ihe.net/ITI/MHD/5.0.0/1332_actor_options.html#13323-uncontained-reference-option), porque `sourcepatient` referencia al paciente que el custodio declaró en el registro de identidad, en lugar de llevar una copia contenida[^mhd-uncontained]. Es un [Document Responder](appendix-glossary.html#document-responder) de MHD, que sirve el contenido de sus documentos con ITI-68 cuando el Record Locator Service se lo pide, y por eso también un Resource Server de IUA, que valida localmente el token intercambiado. Es un [Patient Identity Source](appendix-glossary.html#patient-identity-source) de PIXm, que declara sus identidades locales con ITI-104. Y es un Authorization Client de IUA, que obtiene el token con el que publica y declara. Bajo la Opción de Almacenamiento Central deja de ser Document Responder y Resource Server, porque entrega el contenido al publicar y ya no responde recuperaciones. + +**Consumidor.** Es un [Document Consumer](appendix-glossary.html#document-consumer) de MHD, que localiza con ITI-66 e ITI-67 y recupera con ITI-68 a través del Record Locator Service, y un Authorization Client de IUA. Puede agrupar además un [Patient Identifier Cross-reference Consumer](appendix-glossary.html#patient-identifier-cross-reference-consumer) de PIXm, para resolver con ITI-83 un identificador que ya conoce, y, bajo la Opción de Demografía, un [Patient Demographics Consumer](appendix-glossary.html#patient-demographics-consumer) de PDQm con la [Patient Search Option](https://profiles.ihe.net/ITI/PDQm/volume-1.html#13821-patient-search-option), para buscar con ITI-78 a un paciente del que solo conoce sus datos. Bajo la Opción de Coincidencia Demográfica ese mismo actor declara la [Match Operation Option](https://profiles.ihe.net/ITI/PDQm/volume-1.html#13822-match-operation-option), para buscarlo con ITI-119. No es Resource Server, porque no responde transacciones de nadie. + +**Aplicación del paciente.** Es un Document Consumer de MHD y un Authorization Client de IUA, y nada más. Obtiene su token con [HIX-2](volume-1-actors.html#hix-2) y desde ahí localiza y recupera como cualquier consumidor, confinada al paciente que la usa. + +### Actores centrales + +**Record Locator Service.** Hacia los miembros es un [Document Responder](appendix-glossary.html#document-responder) de MHD, que recibe sus localizaciones y recuperaciones, y un Resource Server de IUA con la Token Introspection Option, porque comprueba cada token con ITI-102. Hacia el Document Registry y los custodios es un [Document Consumer](appendix-glossary.html#document-consumer) de MHD, que ejecuta esas mismas transacciones a nombre del solicitante, y un Authorization Client de IUA, que obtiene para cada destino el token intercambiado con [HIX-1](volume-1-actors.html#hix-1). Agrupa además un [Patient Identifier Cross-reference Consumer](appendix-glossary.html#patient-identifier-cross-reference-consumer) de PIXm, con el que resuelve la identidad del paciente con ITI-83, y un [Query Client](appendix-glossary.html#query-client) de mCSD, con el que obtiene el endpoint de cada custodio con ITI-90. + +**Document Registry.** Es un actor de HIX que toma su nombre y su función del Document Registry de MHDS. HIX lo define por los actores que agrupa, que son los que MHDS fija para el suyo[^mhds-groupings] más uno, porque el miembro publica con su identidad local y la comunidad la traduce por él. + +- Un [Document Recipient](appendix-glossary.html#document-recipient) de MHD con la [Comprehensive Metadata Option](https://profiles.ihe.net/ITI/MHD/5.0.0/1332_actor_options.html#13321-comprehensive-metadata-option) y la [UnContained Reference Option](https://profiles.ihe.net/ITI/MHD/5.0.0/1332_actor_options.html#13323-uncontained-reference-option), que recibe las publicaciones y admite que `sourcepatient` referencie a un paciente del registro de identidad. +- Un [Document Responder](appendix-glossary.html#document-responder) de MHD, que responde las localizaciones y, bajo la Opción de Almacenamiento Central, también las recuperaciones. +- Un [Patient Identity Consumer](appendix-glossary.html#patient-identity-consumer) de PMIR, que recibe por ITI-93 las altas, los cambios y las fusiones de las identidades maestras y las aplica a los punteros y a las listas que conserva[^mhds-pic]. +- Un [Query Client](appendix-glossary.html#query-client) de mCSD, con el que comprueba que quien publica es un miembro activo de la comunidad. +- Un [Patient Identifier Cross-reference Consumer](appendix-glossary.html#patient-identifier-cross-reference-consumer) de PIXm, que HIX añade, con el que comprueba al indexar que la persona existe y está activa en la comunidad, la misma comprobación que MHDS pide a su Document Registry al validar una publicación[^mhds-subject], y con el que resuelve la identidad local de un puntero a su identidad maestra cuando la publicación le llega sin resolver. +- Un Resource Server de IUA, que valida por sí mismo cada token que recibe. + +HIX no declara las opciones que MHDS define para su Document Registry. La decisión de divulgación puede aplicarla el Record Locator Service o el propio Document Registry cuando conoce las reglas de la comunidad, como explica la [sección 2.1](volume-1-concepts.html), y validar la terminología de los metadatos queda a criterio de cada implementación. + +**Authorization Server.** Es el [Authorization Server de IUA](https://profiles.ihe.net/ITI/IUA/index.html#34112-authorization-server), con las tres opciones de la [Tabla 2.4-1](volume-1-groupings.html#tabla-2-4-1). Es también un [OpenID Provider](appendix-glossary.html#openid-provider), es decir, un servidor de autorización que además autentica a la persona y acredita esa autenticación con un `id_token`[^oidc-op]. Lo es porque [HIX-2](volume-1-actors.html#hix-2) se apoya en SMART App Launch, y SMART entrega ese `id_token` junto con el token de acceso cuando la aplicación pide el scope `openid`[^smart-openid]. Y agrupa un [Patient Identifier Cross-reference Consumer](appendix-glossary.html#patient-identifier-cross-reference-consumer) de PIXm, con el que resuelve a la identidad maestra la identidad de la persona autenticada para fijar el contexto de paciente. + +**Directorio de la comunidad.** Es el [Directory](appendix-glossary.html#directory) de mCSD. Lo consultan el Record Locator Service, para dirigir cada recuperación, y el Document Registry, para validar a quien publica. No agrupa ningún otro actor. + +**Registro de identidad maestra.** Agrupa tres actores que trabajan sobre los mismos datos, y es Resource Server de IUA ante todos ellos. + +- El [Patient Identity Registry](appendix-glossary.html#patient-identity-registry) de PMIR, que recibe por ITI-93 las identidades maestras de la fuente autoritativa y las reenvía a quien las consume, como el Document Registry. +- El [Patient Identifier Cross-reference Manager](appendix-glossary.html#patient-identifier-cross-reference-manager) de PIXm, que recibe por ITI-104 las identidades locales que los miembros declaran, las enlaza con la identidad maestra y responde ITI-83. +- El [Patient Demographics Supplier](appendix-glossary.html#patient-demographics-supplier) de PDQm con la [Match Operation Option](https://profiles.ihe.net/ITI/PDQm/volume-1.html#13822-match-operation-option), que responde por ITI-78 las búsquedas por datos demográficos y por ITI-119 las de coincidencia probabilística. + +**Audit Record Repository.** Es el [Audit Record Repository](https://profiles.ihe.net/ITI/TF/Volume1/ch-9.html) de ATNA con la opción ATX: FHIR Feed, que recibe por ITI-20 los eventos de los actores centrales como recursos AuditEvent. No agrupa ningún otro actor. + +**Fuente autoritativa de identidad.** Es el [Patient Identity Source](appendix-glossary.html#patient-identity-source) de PMIR, que crea, actualiza, fusiona y desactiva las identidades maestras con ITI-93, y un Authorization Client de IUA, porque lo hace con un token del Authorization Server de la comunidad. Es externa a la comunidad, y HIX no le pide nada que PMIR, IUA, ATNA y CT no pidan a cualquier sistema que participa. + +### Resumen + +La [Tabla 2.4-2](volume-1-groupings.html#tabla-2-4-2) reúne lo anterior en una sola vista. Las opciones van entre corchetes. ATNA Secure Node o Secure Application, BALP Audit Creator y CT Time Client acompañan a todos los actores salvo a la aplicación del paciente y no se repiten en cada fila. + +**Tabla 2.4-2:** Actores que agrupa cada actor de HIX +{: #tabla-2-4-2} + +| Actor de HIX | Actores agrupados | +| --- | --- | +| Custodio | MHD Document Source [Comprehensive Metadata, UnContained Reference], PIXm Patient Identity Source, IUA Authorization Client. Salvo bajo la Opción de Almacenamiento Central, también MHD Document Responder e IUA Resource Server [JWT Token, Authorization Server Metadata] | +| Consumidor | MHD Document Consumer, IUA Authorization Client. Opcionalmente PIXm Patient Identifier Cross-reference Consumer y, bajo las opciones de Demografía y de Coincidencia Demográfica, PDQm Patient Demographics Consumer [Patient Search, Match Operation] | +| Aplicación del paciente | MHD Document Consumer, IUA Authorization Client | +| Record Locator Service | MHD Document Responder, MHD Document Consumer, PIXm Patient Identifier Cross-reference Consumer, mCSD Query Client, IUA Resource Server [Token Introspection], IUA Authorization Client | +| Document Registry | MHD Document Recipient [Comprehensive Metadata, UnContained Reference], MHD Document Responder, PMIR Patient Identity Consumer, mCSD Query Client, PIXm Patient Identifier Cross-reference Consumer, IUA Resource Server [JWT Token, Authorization Server Metadata] | +| Authorization Server | IUA Authorization Server [JWT Token, Authorization Server Metadata, Token Introspection], OpenID Provider de OpenID Connect, PIXm Patient Identifier Cross-reference Consumer | +| Directorio de la comunidad | mCSD Directory | +| Registro de identidad maestra | PMIR Patient Identity Registry, PIXm Patient Identifier Cross-reference Manager, PDQm Patient Demographics Supplier [Match Operation], IUA Resource Server [JWT Token, Authorization Server Metadata] | +| Audit Record Repository | ATNA Audit Record Repository [ATX: FHIR Feed] | +| Fuente autoritativa de identidad | PMIR Patient Identity Source, IUA Authorization Client | +{: .table .table-bordered} + +### Sobre los despliegues + +Las agrupaciones anteriores son lógicas. Un despliegue puede repartir los actores agrupados entre varios sistemas o concentrarlos en uno solo, siempre que el comportamiento observable desde fuera sea el especificado. El Document Registry, el registro de identidad maestra y el directorio pueden vivir en un mismo servidor FHIR central sin que nada de esta sección cambie. + +### Referencias + +Las citas reproducen el texto publicado por su fuente. Los recortes se marcan con "[...]" y la negrita es de esta guía. + +[^iua-actors]: [IUA, Table 34.1-1 IUA Profile - Actors and Transactions](https://profiles.ihe.net/ITI/IUA/index.html#341-iua-actors-transactions-and-content-modules): "Authorization Client \| Get Access Token \| R [...] Incorporate Access Token \| R [...] Get Authorization Server Metadata \| O [...] Resource Server \| Incorporate Access Token \| R [...] Introspect Token \| O (Note 1) [...] Get Authorization Server Metadata \| O [...] Note 1: **Optionality of this transaction is "R" for an actor that supports the Token Introspection Option.**" +[^iua-options]: [IUA, Table 34.2-1 IUA - Actors and Options, Note 1](https://profiles.ihe.net/ITI/IUA/index.html#342-iua-actor-options): "**Authorization Server or Resource Server Actors shall support at least one of the following options: JWT Token, SAML, or Token Introspection.** The Authorization Client is not and does not need to be aware of the token processing options." +[^atna-fhir-feed]: [RESTful ATNA (Query and Feed), Rev. 3.6, §9.2.7.1 ATX: FHIR Feed Option](https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_RESTful-ATNA.pdf): "The ATX: FHIR Feed Option enables **sending ATNA audit records using RESTful capabilities and FHIR resources**. An Audit Record Repository that supports this option shall implement the two RESTful interactions defined in the Record Audit Event [ITI-20] transaction. **A Secure Node, Secure Application or Audit Record Forwarder that supports this option shall at least support one of the two RESTful interactions** defined in the Record Audit Event [ITI-20] transaction." +[^mhds-groupings]: [MHDS, Table 1:50.3-1 Required Actor Groupings](https://profiles.ihe.net/ITI/MHDS/volume-1.html#1503-mhds-required-actor-groupings): "Document Registry \| Required \| **CT / Time Client** [...] Required \| **ATNA / Secure Node or Secure Application with the STX: TLS 1.2 with the BCP195 Option and the ATX: FHIR Feed Option** [...] Required \| **MHD / Document Responder** [...] Required \| **MHD / Document Recipient with the Comprehensive Metadata Option** [...] Required \| **PMIR / Patient Identity Consumer** [...] if the Authorization Option \| **IUA / Resource Server with the The IUA Authorization Server Metadata Option** [...] if the UnContained References Option \| **mCSD / Care Services Selective Consumer** [...] if the SVCM Validation Option \| SVCM / Terminology Consumer". +[^mhds-pic]: [MHDS Vol. 1, §1:50.1 MHDS Actors, Transactions, and Content Modules](https://profiles.ihe.net/ITI/MHDS/volume-1.html#1501-mhds-actors-transactions-and-content-modules): "PMIR - Patient Identity Consumer provides **patient identity synchronization and specifically the merge function** to be applied to any data managed in the Document Registry." +[^mhds-subject]: [MHDS Vol. 1, §1:50.1.1.1.1 When the grouped MHD Document Recipient is triggered](https://profiles.ihe.net/ITI/MHDS/volume-1.html#1501111-when-the-grouped-mhd-document-recipient--is-triggered): "The Document Registry SHALL validate that the subject of the DocumentReference, and List Resources is the same Patient, and that **Patient is a recognized and active Patient within the Community**. The Patient identity must be recognized and active by the PMIR Patient Identity Registry in the document sharing community. **This may be accomplished by a query of the PMIR Patient Identity Registry**, by way of a cached internal patient database, or other means." +[^mhds-source-comprehensive]: [MHDS, §1:50.4.2.1 Use Case #1: Publication of a new document with persistence](https://profiles.ihe.net/ITI/MHDS/volume-1.html#150421-use-case-1-publication-of-a-new-document-with-persistence): "**The MHD Comprehensive Metadata Option is required of the MHD Document Source** as the MHD Document Recipient within the MHDS Document Registry will implement the Comprehensive Metadata Option." +[^oidc-op]: [OpenID Connect Core 1.0, §1.2 Terminology](https://openid.net/specs/openid-connect-core-1_0.html#Terminology): "OpenID Provider (OP): **OAuth 2.0 Authorization Server that is capable of Authenticating the End-User** and providing Claims to a Relying Party about the Authentication event and the End-User." +[^smart-openid]: [SMART App Launch, Scopes for requesting identity data](https://hl7.org/fhir/smart-app-launch/scopes-and-launch-context.html#scopes-for-requesting-identity-data): "Some apps need to authenticate the end-user. This can be accomplished by **requesting the scope openid**. [...] When these scopes are requested (and the request is granted), **the app will receive an id_token that comes alongside the access token**. This token must be validated according to the OIDC specification." +[^mhd-uncontained]: [MHD, §1:33.2.3 UnContained Reference Option](https://profiles.ihe.net/ITI/MHD/5.0.0/1332_actor_options.html#13323-uncontained-reference-option): "When this longitudinal consistency is managed, then the author, authenticator, sourcePatientInfo, and author entries **do not need to be a contained copy of the information known at the time of publication** ITI-65 since a Reference to the information in these directories will be valid over the full lifecycle of the entries." +[^balp-creator]: [BALP, §1:52.1.1.1 Audit Creator](https://profiles.ihe.net/ITI/BALP/volume-1.html#152111-audit-creator): "The Audit Creator shall detect the defined auditable events and record a complaint AuditEvent as defined. **The Audit Creator shall be grouped with an ATNA Secure Application or ATNA Secure Node with support for ATNA ATX:FHIR Feed Option** defined in the RESTful ATNA Supplement for the recording of the compliant AuditEvent to the Audit Record Repository." + +*[PMIR]: Patient Master Identity Registry, perfil IHE que gestiona la identidad maestra del paciente +*[PIXm]: Patient Identifier Cross-referencing for mobile, perfil IHE que enlaza los identificadores locales de un paciente con su identidad maestra +*[PDQm]: Patient Demographics Query for Mobile, perfil IHE de búsqueda de pacientes por datos demográficos +*[MHD]: Mobile access to Health Documents, perfil IHE para publicar, localizar y recuperar documentos sobre FHIR +*[MHDS]: Mobile Health Document Sharing, perfil IHE que compone MHD, PMIR, mCSD, IUA y ATNA en una comunidad de intercambio de documentos +*[mCSD]: Mobile Care Services Discovery, perfil IHE de directorio de organizaciones, servicios y endpoints +*[IUA]: Internet User Authorization, perfil IHE que aplica OAuth 2.0 a las transacciones sobre FHIR +*[ATNA]: Audit Trail and Node Authentication, perfil IHE de auditoría y seguridad de los nodos +*[BALP]: Basic Audit Log Patterns, perfil IHE con los patrones de AuditEvent de FHIR +*[CT]: Consistent Time, perfil IHE que sincroniza los relojes de los sistemas +*[SVCM]: Sharing Valuesets, Codes, and Maps, perfil IHE de terminología diff --git a/input/pagecontent/volume-1-options.md b/input/pagecontent/volume-1-options.md new file mode 100644 index 0000000..55e5fa2 --- /dev/null +++ b/input/pagecontent/volume-1-options.md @@ -0,0 +1,78 @@ +Las opciones definen capacidades que un actor puede implementar sin dejar de ser conforme. La [Tabla 2.3-1](volume-1-options.html#tabla-2-3-1) lista las que cada actor puede declarar. Un actor que declara una opción **SHALL** cumplir todos los requisitos de esa opción. + +**Tabla 2.3-1:** Actores y opciones de HIX +{: #tabla-2-3-1} + +| Actor | Opción | +| --- | --- | +| Record Locator Service | Opción de Consentimiento | +| Document Registry | Opción de Almacenamiento Central | +| | Opción de Consentimiento | +| Sistema que publica y custodia documentos | Opción de Almacenamiento Central | +| | Opción de Transporte Mediado | +| Sistema que consume documentos | Opción de Demografía | +| | Opción de Coincidencia Demográfica | +{: .table .table-bordered} + +### Opción de Almacenamiento Central + +Un [custodio](appendix-glossary.html#custodio) que no puede conservar sus documentos delega el almacenamiento del contenido en la infraestructura central. El documento sigue siendo suyo. Figura como custodio en los metadatos y conserva la responsabilidad sobre su contenido, pero deja de participar en la recuperación. + +El custodio que declara esta opción **SHALL** enviar el contenido dentro del [ITI-65](https://profiles.ihe.net/ITI/MHD/5.0.0/ITI-65.html) en lugar de una referencia, y **SHALL NOT** exponer un endpoint de recuperación. El Document Registry que declara esta opción **SHALL** conservar el contenido durante el ciclo de vida que la comunidad establezca y **SHALL** responder [ITI-68](https://profiles.ihe.net/ITI/MHD/5.0.0/ITI-68.html) con el contenido que conserva. El Record Locator Service **SHALL** atender la recuperación sin el salto hacia el custodio. + +Esta opción corresponde a la primera de las dos ubicaciones del contenido que describe MHDS ([MHDS Vol. 1, §1:50.1.1.2](https://profiles.ihe.net/ITI/MHDS/volume-1.html#150112-storage-of-binary))[^mhds-storage]. Ambas coexisten en una misma comunidad. El solicitante no distingue cuál se aplica a cada documento y no necesita hacerlo. Qué custodios pueden ejercerla, y quién lo decide, es política de la comunidad. + +Suiza opera todas sus comunidades con esta ubicación, como cuenta la [sección 2.1](volume-1-concepts.html#custodia-distribuida-y-almacenamiento-central). Lo que en HIX es una opción por custodio es allí la regla. + +### Opción de Transporte Mediado + +El tramo entre la infraestructura central y el custodio puede recorrer un canal de interconexión distinto de HTTPS directo, cuando la comunidad opera sobre una red de intercambio ya establecida, como X-Road. + +El custodio que declara esta opción **SHALL** publicar en el directorio el endpoint que describe ese canal, y **SHALL** aceptar la transacción [ITI-68](https://profiles.ihe.net/ITI/MHD/5.0.0/ITI-68.html) a través de él con el mismo contenido y los mismos requisitos de autorización. El token intercambiado sigue viajando en la solicitud y el custodio sigue validándolo. La identidad que el canal aporta **SHALL NOT** sustituir la validación del token. + +El canal y la arquitectura son capas separadas que no se afectan entre sí. El canal resuelve cómo se conectan las organizaciones, cómo se identifican y cómo se cifra el tramo entre ellas. La arquitectura resuelve qué se intercambia y bajo qué reglas, es decir, las transacciones, los punteros, los tokens, la decisión de divulgación y la auditoría. Cambiar de canal no cambia nada de la segunda capa, y nada de la segunda capa exige un canal concreto. Por eso la recuperación sigue siendo mediada, el solicitante sigue sin alcanzar al custodio y ningún puntero cambia. La representación del canal en el directorio se especificará más adelante en esta guía. + +Una red como X-Road autentica y cifra el tramo entre los servidores de seguridad de las dos organizaciones ([X-Road, Arquitectura §3.3](https://docs.x-road.global/Architecture/arc-g_x-road_arhitecture.html#33-message-transport-protocol))[^xroad-transport]. El tramo entre el sistema del custodio y su propio servidor de seguridad queda dentro de su organización, y protegerlo es responsabilidad del custodio. Esta guía no lo especifica. + +> **TODO.** Comprobar con pruebas sobre X-Road qué guarda su registro de mensajes, para ver si guarda los mensajes completos, y cómo se configura. Reflejar el resultado en esta opción y en las decisiones de política de la [sección 2.6](volume-1-security.html). + +### Opción de Consentimiento + +Habilita la evaluación de una decisión de divulgación por paciente antes de responder una localización o una recuperación. + +El actor que declara esta opción, sea el Record Locator Service o el Document Registry, **SHALL** consultar la decisión aplicable al paciente, al solicitante, a su organización, al propósito de uso que lleva su token y a la etiqueta de confidencialidad de cada puntero. **SHALL** omitir de la respuesta los documentos cuya divulgación no esté permitida, con las garantías que la [sección 2.2](volume-1-actors.html#record-locator-service) exige a toda omisión. Son que no se distinga de la ausencia del documento y que quede registrada en la auditoría. + +El modelo de consentimiento, su ciclo de vida, su representación y sus políticas se especificarán en una versión posterior de esta guía a partir de [PCF](https://profiles.ihe.net/ITI/PCF/index.html). Esta opción declara el punto en el que esa decisión se aplica y la información que necesita. Hasta entonces, la comunidad opera bajo la política de divulgación única que haya acordado, aplicada en el mismo punto. + +En qué punto se aplica, en el Record Locator Service o en el Document Registry, es decisión de la implementación, como explica la [sección 2.1](volume-1-concepts.html). MHDS resuelve este mismo problema de otro modo, con un Authorization Server agrupado con su Document Registry que gestiona el consentimiento. HIX no sigue ese camino, por las razones que da la [misma sección](volume-1-concepts.html#relacion-con-mhds). + +### Opción de Demografía + +Permite a un [consumidor](appendix-glossary.html#consumidor) localizar a un paciente por sus datos demográficos cuando no dispone de un identificador conocido por la comunidad. Corresponde a la [Patient Search Option](https://profiles.ihe.net/ITI/PDQm/volume-1.html#13821-patient-search-option) de PDQm. + +El consumidor que declara esta opción **SHALL** presentar al menos un criterio demográfico en cada consulta [ITI-78](https://profiles.ihe.net/ITI/PDQm/ITI-78.html). La infraestructura central **SHALL** responder sobre las identidades maestras, nunca sobre las identidades locales de los miembros, **SHALL** limitar la respuesta a los pacientes que la política de la comunidad permita revelar por esta vía y **SHALL** rechazar una consulta sin criterio. Es una búsqueda determinista. Cada criterio filtra, y ningún resultado lleva grado de coincidencia. + +### Opción de Coincidencia Demográfica + +Permite a un [consumidor](appendix-glossary.html#consumidor) encontrar a un paciente a partir de datos demográficos incompletos o inexactos, con la coincidencia probabilística del registro de identidad maestra. Corresponde a la [Match Operation Option](https://profiles.ihe.net/ITI/PDQm/volume-1.html#13822-match-operation-option) de PDQm. + +El consumidor que declara esta opción **SHALL** presentar en cada [ITI-119](https://profiles.ihe.net/ITI/PDQm/ITI-119.html) los datos del paciente que busca. La infraestructura central **SHALL** responder sobre las identidades maestras, nunca sobre las identidades locales de los miembros, **SHALL** limitar la respuesta a los pacientes que la política de la comunidad permita revelar por esta vía, **SHALL** ordenar los resultados de más a menos probable y **SHALL** indicar el grado de coincidencia de cada uno, como fija PDQm ([PDQm, §2:3.119.4.2.2.4](https://profiles.ihe.net/ITI/PDQm/ITI-119.html#231194224-quality-of-match))[^pdqm-match]. Un resultado de esta búsqueda es un candidato, no una identidad confirmada. + +### Referencias + +Las citas reproducen el texto publicado por su fuente. Los recortes se marcan con "[...]" y la negrita es de esta guía. + +[^mhds-storage]: [MHDS Vol. 1, §1:50.1.1.2 Storage of Binary](https://profiles.ihe.net/ITI/MHDS/volume-1.html#150112-storage-of-binary): "(1) The Document Source includes the Binary Resource in the [ITI-65] transaction, and the Document Registry is required to store it. (2) **The Community allows the Binary to be stored elsewhere in the Community.** [...] This might be other centralized infrastructure, distributed infrastructure, or **within the system implementing the Document Source**." +[^pdqm-match]: [PDQm, §2:3.119.4.1.3 Expected Actions](https://profiles.ihe.net/ITI/PDQm/ITI-119.html#23119413-expected-actions): "The results are ordered from most likely to least likely." [§2:3.119.4.2.2.4 Quality of Match](https://profiles.ihe.net/ITI/PDQm/ITI-119.html#231194224-quality-of-match): "**The Patient Demographics Supplier SHALL convey the quality of each match** based on strength of the particular result to the supplied Patient Resource. [...] it SHALL represent the confidence of a particular match within the bundle as a score attribute." +[^xroad-transport]: [X-Road, Arquitectura §3.3 Message Transport Protocol](https://docs.x-road.global/Architecture/arc-g_x-road_arhitecture.html#33-message-transport-protocol): "The X-Road Message Transport Protocol is used by security server to exchange service requests and service responses. [...] The protocol is based on HTTPS and **uses mutual certificate-based TLS authentication**." + +*[PMIR]: Patient Master Identity Registry, perfil IHE que gestiona la identidad maestra del paciente +*[PIXm]: Patient Identifier Cross-referencing for mobile, perfil IHE que enlaza los identificadores locales de un paciente con su identidad maestra +*[PDQm]: Patient Demographics Query for Mobile, perfil IHE de búsqueda de pacientes por datos demográficos +*[MHD]: Mobile access to Health Documents, perfil IHE para publicar, localizar y recuperar documentos sobre FHIR +*[MHDS]: Mobile Health Document Sharing, perfil IHE que compone MHD, PMIR, mCSD, IUA y ATNA en una comunidad de intercambio de documentos +*[mCSD]: Mobile Care Services Discovery, perfil IHE de directorio de organizaciones, servicios y endpoints +*[IUA]: Internet User Authorization, perfil IHE que aplica OAuth 2.0 a las transacciones sobre FHIR +*[ATNA]: Audit Trail and Node Authentication, perfil IHE de auditoría y seguridad de los nodos +*[BALP]: Basic Audit Log Patterns, perfil IHE con los patrones de AuditEvent de FHIR +*[PCF]: Privacy Consent on FHIR, perfil IHE de consentimiento del paciente diff --git a/input/pagecontent/volume-1-security.md b/input/pagecontent/volume-1-security.md new file mode 100644 index 0000000..d283236 --- /dev/null +++ b/input/pagecontent/volume-1-security.md @@ -0,0 +1,198 @@ +Esta sección describe el modelo de confianza de HIX, los controles que la arquitectura especifica y las decisiones que cada comunidad debe tomar por política. Sigue el orden de las consideraciones de seguridad de MHDS, es decir, políticas y gestión de riesgo, controles técnicos y aplicación al intercambio de documentos ([MHDS Vol. 1, §1:50.5](https://profiles.ihe.net/ITI/MHDS/volume-1.html#1505-mhds-security-considerations))[^mhds-security]. Como IHE, esta guía resuelve problemas de interoperabilidad mediante estándares. No define políticas de privacidad ni de seguridad, gestión de riesgo, funcionalidad clínica, controles físicos ni controles generales de red ([MHDS Vol. 1, §1:50.5.1](https://profiles.ihe.net/ITI/MHDS/volume-1.html#15051-policies-and-risk-management))[^mhds-policy]. Lo que sigue separa lo que queda en manos de la comunidad de lo que fija la arquitectura. + +### Políticas y gestión de riesgo + +MHDS advierte que el marco de políticas de una comunidad debe definirse antes de construirla[^mhds-security]. Las secciones anteriores dejan a la política de la comunidad una serie de decisiones que aquí se reúnen. + +- Qué organizaciones pueden ser miembros, quién lo certifica, bajo qué condiciones dejan de serlo y quién financia la infraestructura central. La [Tabla 2.1-2](volume-1-concepts.html#tabla-2-1-2) de compromisos de la arquitectura lo señala como el riesgo principal de la comunidad a largo plazo. +- Qué propósitos de uso se admiten, con qué condiciones y qué documentos alcanza cada uno, en particular qué permite `ETREAT` frente a `TREAT`, como indica la [Tabla 2.2-3](volume-1-actors.html#tabla-2-2-3). +- Qué política de divulgación aplica mientras el modelo de consentimiento no esté especificado, como señala la [sección 2.3](volume-1-options.html). +- Qué custodios pueden ejercer la Opción de Almacenamiento Central y quién lo decide. +- Cómo se verifica que los custodios etiquetan correctamente la confidencialidad de sus documentos. +- Cómo obtiene una persona la identidad verificada con la que se autentica ante el Authorization Server, como señala la [sección 2.5](volume-1-usecases.html). +- Qué solicitantes pueden buscar pacientes por datos demográficos y qué identidades maestras se les revelan por esa vía, como exigen la Opción de Demografía y la Opción de Coincidencia Demográfica. +- Cuánto tiempo se conservan los registros de auditoría, quién puede consultarlos y qué ocurre con una operación cuando el Audit Record Repository no está disponible. +- Qué constituye un acceso de emergencia, cómo se admite y qué consecuencias tiene invocarlo. +- Si el acceso de red a los custodios se cierra de modo que la vía mediada sea la única alcanzable, o si esa restricción es solo defensa en profundidad. +- Si se admite la introspección en el custodio, con la dependencia del Authorization Server en cada recuperación que conlleva, como señala la [sección 2.6.2](volume-1-security.html#modelo-de-confianza). + +### Modelo de confianza {#modelo-de-confianza} + +El límite de confianza pasa entre cada miembro y la infraestructura central, como establece la [sección 2.1](volume-1-concepts.html). Una recuperación cruza ese límite dos veces, del solicitante a la comunidad y de la comunidad al custodio, y cada cruce lleva un token de un régimen distinto. El primero es el token que el solicitante obtiene del Authorization Server, destinado al Record Locator Service y comprobado por introspección. El segundo es el [token intercambiado](appendix-glossary.html#token-intercambiado) que el Record Locator Service obtiene con [HIX-1](volume-1-actors.html#hix-1) para cada destino que alcanza, sea un custodio o un actor central, y que el destino valida por sí mismo. La [Tabla 2.6-1](volume-1-security.html#tabla-2-6-1) los compara. + +**Tabla 2.6-1:** Los dos regímenes de token +{: #tabla-2-6-1} + +| | Token del solicitante | Token intercambiado | +| --- | --- | --- | +| Quién lo obtiene | El miembro con ITI-71, o la aplicación del paciente con [HIX-2](volume-1-actors.html#hix-2) | El Record Locator Service con [HIX-1](volume-1-actors.html#hix-1) | +| Audiencia | El Record Locator Service | Un único destino, custodio o actor central | +| Vida | La que fije el Authorization Server | Dos minutos como máximo, y nunca más que la vida restante del token del solicitante | +| Cómo se valida | Por introspección en el Authorization Server con ITI-102, una vez por operación | En el destino, con las claves que publica el Authorization Server ([JWKs](https://www.rfc-editor.org/info/rfc7517/)), sin necesidad de introspección | +| Sujeto | El sistema del miembro, o la persona que lanzó la aplicación | El mismo | +| Extensiones de IUA | La organización y el propósito de uso | Las mismas | +| Alcance | El concedido al solicitante | Solo el de la transacción que motivó el intercambio | +| Contexto de paciente | Solo si lo obtuvo una aplicación del paciente | El mismo, si lo hay | +| Actor | Ninguno | El Record Locator Service, en el claim `act` | +{: .table .table-bordered} + +El sujeto del token del solicitante es el sistema del miembro, porque el Authorization Server autentica a ese cliente y no a una persona, y en ese caso IUA pone como sujeto al cliente. La organización, el profesional y el propósito de uso van en las extensiones que IUA define para el token ([IUA, §3.71.4.2.2.1](https://profiles.ihe.net/ITI/IUA/index.html#3714221-json-web-token-option))[^iua-sub]. Cuando el token lo obtiene una aplicación del paciente, el sujeto es la persona que la lanzó. + +De la tabla se siguen cuatro reglas. De cada una conviene decir qué fija HIX, de qué depende y qué queda en manos de la comunidad. + +**Un token intercambiado vale ante un solo destino.** El formato no lo impone. El claim `aud` de un JWT admite una lista de audiencias ([RFC 7519, §4.1.3](https://www.rfc-editor.org/rfc/rfc7519.html#section-4.1.3))[^rfc7519-aud], y el Authorization Server lo rellena con el recurso que el cliente indicó al pedir el token ([RFC 9068, §3](https://www.rfc-editor.org/rfc/rfc9068.html#section-3))[^rfc9068-aud]. HIX lo restringe para el token intercambiado, porque de eso depende que un custodio no pueda reutilizarlo ante otro. El token del solicitante nombra a los actores centrales que el miembro alcanza directamente, que en este volumen es solo el Record Locator Service. Si la arquitectura cambiara y alcanzara otro, su token nombraría a ambos en `aud` sin que cambie nada más de este capítulo. + +**El token del solicitante no sale de la infraestructura central.** El Record Locator Service no lo reenvía a ningún custodio ni actor central. Ante cada destino presenta un token intercambiado para ese destino, como fija la [sección 2.2](volume-1-actors.html). Así el solicitante nunca tiene una credencial que valga ante un custodio, y un custodio nunca recibe una que valga ante otro. + +**El custodio puede validar el token sin preguntar al Authorization Server.** Todo lo que necesita está en el token y en las claves que el Authorization Server publica. Esa publicación es su única dependencia, y la resuelve por adelantado, conservando las claves y renovándolas cuando aparece un identificador de clave que no conoce. La subsección siguiente detalla la validación y dice cuándo una comunidad puede añadirle la introspección. + +**El Record Locator Service no actúa por cuenta propia ante los actores centrales.** No tiene credenciales permanentes hacia el Document Registry ni hacia el registro de identidad maestra. Cada acceso lo hace a nombre de un solicitante, con el token intercambiado para ese destino, y así queda auditado. De esta forma se evita el acceso arbitrario entre los componentes centrales. Ninguno puede consultar a otro sin una petición de un solicitante que lo justifique, y una credencial del mediador comprometida no da acceso a nada por sí sola, porque no existe ninguna que valga sin ese intercambio. + +#### Validación en el custodio + +El custodio recibe el token intercambiado y lo valida como RFC 9068 pide a todo Resource Server que recibe un token de acceso en forma de JWT ([RFC 9068, §4](https://www.rfc-editor.org/rfc/rfc9068.html#section-4))[^rfc9068-validate], más las comprobaciones que HIX añade sobre la delegación. El custodio **SHALL** comprobar, como mínimo, lo siguiente. + +1. La firma, con las claves que publica el Authorization Server, y que el algoritmo es uno de los que la comunidad admite. +2. Que el emisor es exactamente el Authorization Server de la comunidad. +3. Que el tipo de token es el de un token de acceso. +4. Que la audiencia es exactamente él. +5. Que el token no ha expirado y que su momento de emisión es coherente con su vida máxima. +6. Que lleva un sujeto y un identificador de token. +7. Que el cliente al que se emitió es el Record Locator Service. +8. Que el actor declarado en el claim `act` es el Record Locator Service. +9. Que el alcance cubre la transacción que recibe. + +Las tres comprobaciones que más pesan son la audiencia, el cliente y el actor. La audiencia sola no basta, porque un token emitido directamente a otro cliente para esa misma audiencia la pasaría. El cliente y el actor son lo que vuelve estructural que solo el Record Locator Service pueda alcanzar a un custodio en nombre de alguien, porque el claim `act` es la forma en que OAuth 2.0 Token Exchange declara que hubo delegación y quién actúa ([RFC 8693, §4.1](https://www.rfc-editor.org/rfc/rfc8693.html#section-4.1))[^rfc8693-act]. + +El custodio **SHALL** validar el token intercambiado con las claves que publica el Authorization Server, y esa validación basta para aceptarlo. HIX no exige introspección en el custodio. El custodio **MAY** comprobarlo además por introspección, con la [Token Introspection Option](https://profiles.ihe.net/ITI/IUA/index.html#3424-token-introspection-option) de IUA y [ITI-102](https://profiles.ihe.net/ITI/IUA/index.html#3102-introspect-token-iti-102), si la comunidad lo admite. Entonces cada recuperación depende del Authorization Server en el momento de atenderla, y esa dependencia se asume a sabiendas. + +#### Lo que un token prueba y lo que no + +Un custodio que recibe un token intercambiado puede comprobar por sí mismo cinco cosas. + +- Que lo emitió el Authorization Server de la comunidad. +- Que el Record Locator Service lo pidió en nombre de un solicitante concreto. +- Que vale ante él y ante nadie más. +- Que autoriza solo la transacción para la que se intercambió. El token del solicitante puede llevar varios scopes, pero el Record Locator Service pide en el intercambio únicamente el de la transacción que va a realizar, por ejemplo el de ITI-68 al recuperar. El alcance se expresa siempre con el identificador de la transacción IHE, también en el token de la aplicación del paciente. De SMART esa aplicación toma solo los scopes que piden contexto e identidad, como `launch/patient` y `openid`, que no autorizan nada ante un Resource Server. HIX no usa los scopes de recurso de SMART, como `patient/DocumentReference.rs`, porque dirían lo mismo en un segundo vocabulario. +- Que expira en dos minutos como máximo. + +El token no nombra ningún documento. Mientras dura, autoriza esa transacción ante ese custodio, sea cual sea el documento. Tampoco nombra al paciente, porque el token de un miembro no lleva ninguno, como explica la [sección 2.1](volume-1-concepts.html). La excepción es la aplicación del paciente. Su contexto de paciente, fijado con [HIX-2](volume-1-actors.html#hix-2), se conserva en el intercambio y limita al custodio a ese expediente. + +Lo que el token sí aporta es el contexto con el que se decide, en las extensiones de IUA. Quién pide, para qué organización, con qué propósito de uso y, si lo hay, sobre qué paciente. Ese contexto acota lo que puede alcanzarse con el token, y con él se decide qué documento se entrega, en tres capas y en este orden. + +1. La [decisión de divulgación](appendix-glossary.html#decision-de-divulgacion), que la infraestructura central aplica sobre los punteros antes de mover contenido. +2. La política local del custodio sobre su propio endpoint. +3. La auditoría, que no previene pero acota y detecta. + +#### Contención de una credencial comprometida + +Deshabilitar un cliente en el Authorization Server **SHALL** revocar sus tokens vigentes, de modo que la siguiente introspección los declare inactivos, que es el estado que RFC 7662 prevé para un token revocado ([RFC 7662, §2.2](https://www.rfc-editor.org/rfc/rfc7662.html#section-2.2))[^rfc7662-active], y ningún intercambio pueda partir de ellos. Un token ya intercambiado no tiene ciclo de vida propio. El Record Locator Service lo usa una sola vez, en la recuperación que lo motivó, y expira en dos minutos como máximo, así que una recuperación ya en curso termina. + +Lo que contiene una credencial comprometida es que los tokens obtenidos con ella dejen de valer, no que cambie la credencial. Si el Authorization Server los revoca también al rotar el secreto o la clave de un cliente es decisión de su implementación. Si no lo hace, hay que revocarlos aparte. + +### Controles técnicos de seguridad y privacidad + +HIX especifica los siguientes controles. Cada uno remite a la sección que lo fija. + +- **Autenticación de sistemas.** Toda conexión entre dos participantes se autentica en ambos extremos con ATNA, como fija la [sección 2.4](volume-1-groupings.html). Ningún participante acepta tráfico anónimo. Bajo la Opción de Transporte Mediado, la autenticación mutua del tramo entre organizaciones la aporta la red de intercambio. +- **Autorización.** Toda transacción presenta un token emitido por el Authorization Server de la comunidad y destinado a quien la recibe, como fija la [sección 2.2](volume-1-actors.html). +- **Delegación acotada.** El token con el que la comunidad alcanza a un custodio se emite para esa recuperación, a nombre del solicitante original y con el Record Locator Service como actor, como fija la [sección 2.2](volume-1-actors.html#authorization-server). +- **Mínimo privilegio.** El alcance de un token intercambiado se limita a la transacción que motivó el intercambio, como fija la [sección 2.2](volume-1-actors.html#authorization-server). Poder localizar un documento nunca da poder para recuperarlo. +- **Confidencialidad en tránsito.** Todo tramo entre participantes viaja cifrado, incluido el que atraviesa un canal de interconexión bajo la Opción de Transporte Mediado. El tramo entre un custodio y su propio servidor de seguridad es responsabilidad del custodio, como fija la [sección 2.3](volume-1-options.html). +- **Divulgación decidida sobre los punteros.** La política se evalúa en la infraestructura central, una vez por consulta, sobre los metadatos del índice y antes de que se mueva contenido, como fija la [sección 2.1](volume-1-concepts.html). +- **Auditoría en ambos extremos.** El miembro que solicita y la infraestructura central registran la localización. Infraestructura central y custodio registran la recuperación. Ningún tramo queda sin testigo. +- **Trazabilidad entre tramos.** Los registros de una misma divulgación comparten un identificador de correlación, de modo que la interacción completa pueda reconstruirse. +- **Identidad del paciente.** Solo la fuente autoritativa crea identidades maestras. Lo que un miembro declara vincula su identidad local con una de ellas, en su propio dominio, y queda registrado como una afirmación suya. + +### Aplicación al intercambio de documentos + +#### Seguridad básica + +Todo actor de HIX, salvo la aplicación del paciente, es un Secure Node o Secure Application de ATNA y un Time Client de CT, como fija la [sección 2.4](volume-1-groupings.html). Los actores centrales registran sus eventos en el Audit Record Repository de la comunidad y cada miembro en el suyo, con el contenido que cada perfil define para su transacción a partir de los patrones de BALP. + +El Record Locator Service **SHALL** registrar tanto la solicitud que recibe como cada recuperación que origina hacia un custodio, bajo un identificador de correlación que él mismo acuña y transmite al custodio, y **SHALL NOT** transmitir hacia el custodio ninguno que el solicitante proponga. Ningún registro de auditoría **SHALL** contener un token completo ni contenido clínico. Lo que ata un evento a su token es un identificador suyo, como el `jti`, que es la evidencia que BALP pide registrar en lugar del token ([BALP, §3:5.7.5](https://profiles.ihe.net/ITI/BALP/content.html#3575-oauth-security-token))[^balp-token]. + +#### Protección según el tipo de documento + +La política de la comunidad determina qué solicitante alcanza qué documentos. MHDS lo plantea con una tabla de ejemplo que cruza el código de confidencialidad de cada documento con el rol del solicitante, y señala que ese rol y el propósito de uso llegan en el token de IUA ([MHDS Vol. 1, §1:50.5.3.2](https://profiles.ihe.net/ITI/MHDS/volume-1.html#150532-protecting-different-types-of-documents))[^mhds-doctypes]. La arquitectura ofrece el punto donde aplicarla y los datos con los que evaluarla, es decir, quién solicita, en nombre de qué organización, con qué propósito, sobre qué paciente y con qué etiqueta de confidencialidad. La [Tabla 2.6-2](volume-1-security.html#tabla-2-6-2) es la versión de HIX de ese ejemplo, con el propósito de uso en lugar del rol porque es lo que el token de HIX lleva siempre. Es un ejemplo, no un requisito. + +**Tabla 2.6-2:** Ejemplo de política de acceso por etiqueta de confidencialidad +{: #tabla-2-6-2} + +| Etiqueta del documento | Solicitante | Resultado | +| --- | --- | --- | +| `N`, normal | Profesional de un miembro con propósito `TREAT` | Permitido | +| `N`, normal | La propia persona con propósito `PATRQT` | Permitido | +| `R`, restringido | Profesional de un miembro con propósito `TREAT` | Permitido con registro reforzado | +| `R`, restringido | La propia persona con propósito `PATRQT` | Según política de la comunidad | +| `V`, muy restringido | Cualquiera salvo el custodio | Denegado, salvo acceso de emergencia | +{: .table .table-bordered} + +Cada comunidad define su equivalente y lo aplica en el punto donde toma la decisión de divulgación. Lo que sí es requisito es que la política falle cerrada. Un puntero sin etiqueta se rechaza al publicar, como fija la [sección 2.2](volume-1-actors.html), y una etiqueta que la política no reconoce se trata como la más restrictiva. FHIR pide a toda guía de implementación decir qué hacer con una etiqueta que no se reconoce, sin prescribir la respuesta ([FHIR R5, Security Labels](https://hl7.org/fhir/R5/security-labels.html))[^fhir-seclabels]. + +#### Consentimiento del paciente + +La decisión de divulgación se aplica en el punto y con la información que describe la Opción de Consentimiento de la [sección 2.3](volume-1-options.html), y su destino es PCF, como explica la [sección 2.1](volume-1-concepts.html). Mientras el modelo de consentimiento no esté especificado, la comunidad opera bajo la política de divulgación que haya acordado, que debe estar documentada y ser la misma para todos los miembros. + +#### Superficies de identidad + +Las transacciones de identidad también divulgan. ITI-83 revela que un identificador corresponde a una persona que la comunidad conoce, e ITI-78 e ITI-119 revelan qué identidades maestras coinciden con unos datos demográficos, o se les parecen. Ninguna revela las identidades locales de otros miembros, como fijan la [sección 2.2](volume-1-actors.html) para ITI-83 y las opciones de Demografía y de Coincidencia Demográfica de la [sección 2.3](volume-1-options.html) para ITI-78 e ITI-119. Estas superficies las habilita el scope del token, no el propósito de uso, y la comunidad decide qué solicitantes pueden ejercerlas y qué identidades maestras se revelan por datos demográficos. + +#### Acceso de emergencia + +MHDS pide reconocer los modos de emergencia desde el diseño, y advierte que anular una restricción del paciente por peligro inminente no es romper la política sino una condición explícita dentro de ella ([MHDS Vol. 1, §1:50.5.1](https://profiles.ihe.net/ITI/MHDS/volume-1.html#15051-policies-and-risk-management))[^mhds-emergency]. HIX distingue dos casos con los propósitos de uso de la [Tabla 2.2-3](volume-1-actors.html#tabla-2-2-3). Con `ETREAT`, un profesional autorizado atiende una urgencia y la política de la comunidad decide qué le permite frente a `TREAT`. Con `BTG`, accede quien no está autorizado para ese acceso, con anulación de la política, que es lo que HL7 define para ese código[^btg]. + +HIX no define cuándo procede ninguno de los dos. Sí exige que sean declarados y no inferidos. El solicitante **SHALL** pedir el propósito de emergencia al obtener el token, el Authorization Server **SHALL** emitirlo como propósito de uso del token solo cuando su registro lo admita para ese solicitante, y el evento **SHALL** registrarse con auditoría reforzada que permita revisarlo después. + +### Perfiles y controles + +MHDS cierra sus consideraciones de seguridad con la relación entre sus controles y los perfiles IHE que los aportan ([MHDS Vol. 1, §1:50.5.4](https://profiles.ihe.net/ITI/MHDS/volume-1.html#15054-ihe-security-and-privacy-controls)). La [Tabla 2.6-3](volume-1-security.html#tabla-2-6-3) hace lo mismo para HIX. + +**Tabla 2.6-3:** Relación entre controles y perfiles o especificaciones +{: #tabla-2-6-3} + +| Control | Perfil o especificación que lo aporta | +| --- | --- | +| Autenticación de sistemas | ATNA | +| Autorización y alcance | IUA, OAuth 2.0 | +| Delegación acotada y mínimo privilegio | RFC 8693, RFC 8707 | +| Validación local del token intercambiado | RFC 9068 | +| Introspección de tokens | IUA, RFC 7662 | +| Autorización con participación de la persona | SMART App Launch, OpenID Connect | +| Confidencialidad en tránsito | ATNA | +| Relojes sincronizados | CT | +| Auditoría | ATNA, BALP | +| Identidad del paciente | PMIR, PIXm, PDQm | +| Localización de endpoints | mCSD | +| Divulgación controlada | Opción de Consentimiento, y PCF cuando se especifique | +{: .table .table-bordered} + +### Referencias + +Las citas reproducen el texto publicado por su fuente. Los recortes se marcan con "[...]" y la negrita es de esta guía. + +[^mhds-security]: [MHDS Vol. 1, §1:50.5 MHDS Security Considerations](https://profiles.ihe.net/ITI/MHDS/volume-1.html#1505-mhds-security-considerations): "It is especially important for the reader to understand that **the scope of an IHE profile is only the technical details necessary to ensure interoperability**. It is up to any organization building a community to understand and carefully implement the policies of that community and to perform the appropriate risk analysis. [...] **The policy landscape that the community is built on needs to be defined well before the community is built.**" +[^mhds-policy]: [MHDS Vol. 1, §1:50.5.1 Policies and Risk Management](https://profiles.ihe.net/ITI/MHDS/volume-1.html#15051-policies-and-risk-management): "IHE solves interoperability problems via the implementation of technology standards. **It does not define Privacy or Security Policies**, Risk Management, Healthcare Application Functionality, Operating System Functionality, Physical Controls, or even general Network Controls." +[^mhds-emergency]: [MHDS Vol. 1, §1:50.5.1 Policies and Risk Management](https://profiles.ihe.net/ITI/MHDS/volume-1.html#15051-policies-and-risk-management): "An important set of policies are those around emergency modes. [...] **When these use cases are factored in up-front, the mitigations are reasonable.** [...] Need to override a patient specified privacy block due to eminent danger to that patient – **this override is not a breaking of the policy but would need to be an explicit condition within the policy.**" +[^mhds-doctypes]: [MHDS Vol. 1, §1:50.5.3.2 Protecting different types of documents](https://profiles.ihe.net/ITI/MHDS/volume-1.html#150532-protecting-different-types-of-documents): "This differentiation of the types of data can be represented using a diagram like found in Table 50.5.3.2-1: Sample Access Control Policies, showing an ‘X’ where the defined Role (rows) would have permitted access to data tagged with the given (columns) ConfidentialityCode (U-Unrestricted, L-Low, M-Moderate, N-Normal, R-Restricted, V-Very Restricted). [...] **These roles would be conveyed from the requesting organization through the use of the Internet User Authorization (IUA) Profile.** [...] Additional information can be carried such as the PurposeOfUse, what the user intends to use the data for. Note that **Privacy Policies and Access Control rules can leverage any of the user context, patient identity, or document metadata** discussed above." +[^fhir-seclabels]: [FHIR R5, Security Labels](https://hl7.org/fhir/R5/security-labels.html): "Local agreements and implementation profiles for the use security labels should describe how the security labels connect to the relevant consent and policy statements, and in particular: [...] **What to do if a resource has an unrecognized security label on it** [...]" +[^rfc7519-aud]: [RFC 7519, §4.1.3 "aud" (Audience) Claim](https://www.rfc-editor.org/rfc/rfc7519.html#section-4.1.3): "**In the general case, the "aud" value is an array of case-sensitive strings**, each containing a StringOrURI value. In the special case when the JWT has one audience, the "aud" value MAY be a single case-sensitive string containing a StringOrURI value." +[^rfc9068-aud]: [RFC 9068, §3 Requesting a JWT Access Token](https://www.rfc-editor.org/rfc/rfc9068.html#section-3): "If the request includes a "resource" parameter (as defined in [RFC8707]), **the resulting JWT access token "aud" claim SHOULD have the same value as the "resource" parameter in the request.**" +[^rfc9068-validate]: [RFC 9068, §4 Validating JWT Access Tokens](https://www.rfc-editor.org/rfc/rfc9068.html#section-4): "Resource servers receiving a JWT access token MUST validate it in the following manner. The resource server MUST verify that the "typ" header value is "at+jwt" or "application/at+jwt" and reject tokens carrying any other value. [...] The issuer identifier for the authorization server [...] MUST exactly match the value of the "iss" claim. The resource server MUST validate that **the "aud" claim contains a resource indicator value corresponding to an identifier the resource server expects for itself**. [...] The resource server MUST validate the signature of all incoming JWT access tokens according to [RFC7515] using the algorithm specified in the JWT "alg" Header Parameter. **The resource server MUST reject any JWT in which the value of "alg" is "none".** The resource server MUST use the keys provided by the authorization server. The current time MUST be before the time represented by the "exp" claim." +[^rfc8693-act]: [RFC 8693, §4.1 "act" (Actor) Claim](https://www.rfc-editor.org/rfc/rfc8693.html#section-4.1): "The act (actor) claim provides a means within a JWT to express that **delegation has occurred and identify the acting party to whom authority has been delegated**." +[^rfc7662-active]: [RFC 7662, §2.2 Introspection Response](https://www.rfc-editor.org/rfc/rfc7662.html#section-2.2): "active. REQUIRED. **Boolean indicator of whether or not the presented token is currently active.** [...] a "true" value return for the "active" property will generally indicate that a given token has been issued by this authorization server, **has not been revoked by the resource owner**, and is within its given time window of validity". +[^btg]: [v3-ActReason, BTG](https://terminology.hl7.org/CodeSystem-v3-ActReason.html#v3-ActReason-BTG): "break the glass. **To perform policy override operations on information for provision of immediately needed health care for an emergent condition** affecting potential harm, death or patient safety **by end users who are not provisioned for this purpose of use**. Includes override of organizational provisioning policies and may include override of subject of care consent directive restricting access." [ETREAT](https://terminology.hl7.org/CodeSystem-v3-ActReason.html#v3-ActReason-ETREAT): "Emergency Treatment. To perform one or more operations on information for provision of **immediately needed health care for an emergent condition**." +[^balp-token]: [BALP, §3:5.7.5 OAuth Security Token](https://profiles.ihe.net/ITI/BALP/content.html#3575-oauth-security-token): "There is still a need to include some evidence in the AuditEvent to tie this audit log entry with a specific token, but **the whole token should not be recorded for security reasons**." +[^iua-sub]: [IUA, §3.71.4.2.2.1 JSON Web Token Option](https://profiles.ihe.net/ITI/IUA/index.html#3714221-json-web-token-option): "sub (required): **If known, unique identifier of the user; the client_id otherwise** [JWT, Section 4.1]. client_id (required): identifier of the client for which the token is issued." Y en §3.71.4.2.2.1.1 JWT IUA extension: "The Authorization Server and Resource Server shall support the following extensions to the JWT access token: **subject_name** (optional): The user's name as String. **subject_organization_id** (optional): Unique identifier of the user's organization. [...] **subject_role** (optional): Coded values indicating the user's roles. [...] **purpose_of_use** (optional): Purpose of use for the request. [...] The above claims shall be wrapped in an "extensions" object with key 'ihe_iua'". + +*[PMIR]: Patient Master Identity Registry, perfil IHE que gestiona la identidad maestra del paciente +*[PIXm]: Patient Identifier Cross-referencing for mobile, perfil IHE que enlaza los identificadores locales de un paciente con su identidad maestra +*[PDQm]: Patient Demographics Query for Mobile, perfil IHE de búsqueda de pacientes por datos demográficos +*[MHD]: Mobile access to Health Documents, perfil IHE para publicar, localizar y recuperar documentos sobre FHIR +*[MHDS]: Mobile Health Document Sharing, perfil IHE que compone MHD, PMIR, mCSD, IUA y ATNA en una comunidad de intercambio de documentos +*[mCSD]: Mobile Care Services Discovery, perfil IHE de directorio de organizaciones, servicios y endpoints +*[IUA]: Internet User Authorization, perfil IHE que aplica OAuth 2.0 a las transacciones sobre FHIR +*[ATNA]: Audit Trail and Node Authentication, perfil IHE de auditoría y seguridad de los nodos +*[BALP]: Basic Audit Log Patterns, perfil IHE con los patrones de AuditEvent de FHIR +*[CT]: Consistent Time, perfil IHE que sincroniza los relojes de los sistemas +*[PCF]: Privacy Consent on FHIR, perfil IHE de consentimiento del paciente diff --git a/input/pagecontent/volume-1-usecases.md b/input/pagecontent/volume-1-usecases.md new file mode 100644 index 0000000..eca2a94 --- /dev/null +++ b/input/pagecontent/volume-1-usecases.md @@ -0,0 +1,113 @@ +Esta sección recorre los casos de uso que la arquitectura soporta. Cada uno se cuenta desde el punto de vista de quien lo vive y se acompaña del flujo entre actores, con las transacciones y el orden en que ocurren. El detalle de cada transacción está en el Volumen 2. + +Los casos siguen las tres historias de las figuras de la [sección 2.2](volume-1-actors.html), el laboratorio que publica, el hospital que consulta y la persona que accede a lo suyo, precedidas por la identidad del paciente, que es condición de todas. La publicación, la consulta y el acceso del paciente son independientes entre sí y ocurren en cualquier orden y con cualquier frecuencia. La incorporación de un miembro, que precede a todo, es un procedimiento administrativo y no un caso de uso de esta guía. + +### Identidad del paciente + +#### Descripción del caso de uso + +Una persona existe en la comunidad desde que la fuente autoritativa de identidad la alimenta al registro de identidad maestra. El custodio que la atiende declara a la comunidad qué [identidad local](appendix-glossary.html#identidad-local) le corresponde. El registro vincula esa identidad con la [identidad maestra](appendix-glossary.html#identidad-maestra) y, desde entonces, los documentos que ese custodio publique con su identificador local quedan asociados a la misma persona que los publicados por los demás miembros. + +Un miembro que declaró sus identidades locales pregunta con su propio identificador de la persona y obtiene la identidad maestra enlazada, que es como la comunidad la nombra. Un miembro que solo consume no declara ninguna, y pregunta con el identificador nacional de la persona, cuyo dominio la comunidad siempre reconoce. Ninguno de los dos obtiene los identificadores de los demás miembros. Un miembro que no dispone de ningún identificador conocido por la comunidad puede, si declara la Opción de Demografía, buscar por datos demográficos entre las identidades maestras y, si declara la Opción de Coincidencia Demográfica, pedir las que más se parecen a unos datos incompletos. + +Lo que un miembro declara vincula. Nunca crea una persona, nunca fusiona dos y nunca modifica lo que la identidad maestra dice de ella. + +#### Flujo del proceso + +![Alimentación y resolución de la identidad del paciente](hix-flujo-identidad.svg) + +**Figura 2.5-1:** Alimentación y resolución de la identidad del paciente +{: #figura-2-5-1} + +1. La fuente autoritativa de identidad alimenta la identidad maestra de la persona mediante [ITI-93](https://profiles.ihe.net/ITI/PMIR/ITI-93.html). +2. El custodio declara su identidad local mediante [ITI-104](https://profiles.ihe.net/ITI/PIXm/ITI-104.html) ante la infraestructura central, en su propio dominio de identificadores y con el identificador nacional de la persona. La infraestructura central comprueba que el dominio corresponde a la organización del token, y el registro de identidad maestra vincula la identidad local con la maestra. Si la persona no existe en la comunidad, rechaza la declaración e indica el motivo. +3. Un consumidor resuelve su identificador a la identidad maestra mediante [ITI-83](https://profiles.ihe.net/ITI/PIXm/ITI-83.html) ante la infraestructura central y, si declara la Opción de Demografía, busca por datos demográficos mediante [ITI-78](https://profiles.ihe.net/ITI/PDQm/ITI-78.html) o, con la Opción de Coincidencia Demográfica, mediante [ITI-119](https://profiles.ihe.net/ITI/PDQm/ITI-119.html). + +### Publicación de un documento + +#### Descripción del caso de uso + +Un laboratorio termina un resultado y lo publica en la comunidad. Envía los metadatos y conserva el documento. Desde ese momento el resultado es localizable por cualquier miembro autorizado, sin que el laboratorio deba anticipar quién lo buscará ni conocer a nadie más que a la comunidad. Lo publica con el [propósito de uso](appendix-glossary.html#proposito-de-uso) de la atención, `TREAT`. + +El laboratorio nombra al paciente con su identificador local, se nombra a sí mismo como [custodio](appendix-glossary.html#custodio), indica dónde está el documento con una ruta relativa a su propio endpoint y etiqueta su confidencialidad. La comunidad comprueba que el laboratorio publica solo por sí mismo y solo sobre pacientes que él mismo declaró, resuelve la identidad maestra y registra el [puntero](appendix-glossary.html#puntero). Si rechaza la publicación, dice por qué. Conviene que el laboratorio no dé por publicado un documento hasta recibir la confirmación. + +#### Flujo del proceso + +![Publicación de un documento](hix-flujo-publicacion.svg) + +**Figura 2.5-2:** Publicación de un documento +{: #figura-2-5-2} + +1. El custodio conserva el documento en su repositorio y obtiene del Authorization Server un token para publicar. +2. El custodio publica los metadatos, agrupados en un SubmissionSet, mediante [ITI-65](https://profiles.ihe.net/ITI/MHD/5.0.0/ITI-65.html) ante la infraestructura central. Bajo la Opción de Almacenamiento Central, incluye el contenido. +3. El Document Registry comprueba que el custodio del puntero es la organización que el token declara y que esa organización es un miembro activo según el directorio, que la URL de contenido es relativa y que el puntero lleva etiqueta de confidencialidad. Rechaza la publicación que no cumpla alguna de esas condiciones e indica el motivo. +4. La infraestructura central resuelve a la identidad maestra, mediante [ITI-83](https://profiles.ihe.net/ITI/PIXm/ITI-83.html), la identidad local con la que el custodio nombró al paciente, y la escribe como sujeto del puntero, que conserva también la identidad local. El Document Registry lo registra a nombre del custodio y responde. Si el paciente no resuelve a una identidad maestra, la publicación se rechaza. + +### Consulta del expediente por un profesional + +#### Descripción del caso de uso + +Un profesional de un hospital atiende a la misma persona y necesita su historial. Consulta la comunidad con el identificador que su propio sistema conoce de la persona, o con su identificador nacional, y con el propósito de uso de la atención habitual, `TREAT`. Obtiene la lista de documentos que la política le permite ver y recupera el que le interesa. No sabe, ni necesita saber, qué organización lo custodia. + +La recuperación atraviesa dos tramos autorizados. El profesional llega a la comunidad con un [token del solicitante](appendix-glossary.html#token-del-solicitante), y la comunidad llega al custodio con un [token intercambiado](appendix-glossary.html#token-intercambiado) para ese único custodio, que el custodio valida por sí mismo. La [sección 2.6](volume-1-security.html#modelo-de-confianza) compara los dos tokens y dice qué lleva cada uno. + +Si un custodio no responde, el profesional recibe un resultado que lo dice, junto con todo lo demás que pidió. Un custodio caído degrada la respuesta y nunca la hace fallar. + +En una urgencia la historia cambia en dos puntos. El profesional consulta con el propósito de uso `ETREAT`, y qué permite frente a `TREAT` lo fija la política de la comunidad, por ejemplo divulgar documentos que en atención habitual exigirían un consentimiento. Y si la persona llega sin un identificador fiable, el hospital puede buscarla por sus datos demográficos bajo la Opción de Demografía o la Opción de Coincidencia Demográfica, como en la [Figura 2.2-2](volume-1-actors.html#figuras-2-2). La búsqueda la habilita el scope del token, no el propósito. El propósito se evalúa después, en la [decisión de divulgación](appendix-glossary.html#decision-de-divulgacion). + +#### Flujo del proceso + +![Localización y recuperación mediada](hix-flujo-localizacion.svg) + +**Figura 2.5-3:** Localización y recuperación mediada +{: #figura-2-5-3} + +1. El [consumidor](appendix-glossary.html#consumidor) obtiene del Authorization Server un token destinado al Record Locator Service y localiza mediante [ITI-67](https://profiles.ihe.net/ITI/MHD/5.0.0/ITI-67.html). En una urgencia sin identificador conocido, busca antes a la persona por datos demográficos mediante ITI-78 o ITI-119 ante la infraestructura central. +2. El Record Locator Service comprueba el token mediante [ITI-102](https://profiles.ihe.net/ITI/IUA/index.html#3102-introspect-token-iti-102), resuelve la identidad maestra mediante ITI-83, consulta el Document Registry mediante ITI-67, evalúa la decisión de divulgación sobre cada puntero y devuelve los divulgados, con URL de contenido que apuntan a sí mismo. +3. El consumidor recupera mediante [ITI-68](https://profiles.ihe.net/ITI/MHD/5.0.0/ITI-68.html) sobre una de esas URL. +4. El Record Locator Service relee el puntero, vuelve a evaluar la divulgación, resuelve el endpoint del custodio en el directorio mediante [ITI-90](https://profiles.ihe.net/ITI/mCSD/ITI-90.html) y obtiene mediante [HIX-1](volume-1-actors.html#hix-1) un token para ese custodio. +5. El Record Locator Service recupera el documento del custodio mediante ITI-68. El custodio valida el token con las claves públicas del Authorization Server y entrega el documento, que el Record Locator Service entrega al consumidor. Bajo la Opción de Almacenamiento Central, lo recupera del Document Registry en lugar del custodio, con un token intercambiado para él. + +### Acceso del paciente a su expediente + +#### Descripción del caso de uso + +Una persona abre una aplicación de su elección y accede a sus propios documentos. La aplicación no la opera la comunidad y no tiene autoridad permanente sobre nada, solo lo que esta persona le concedió y mientras dure. + +La persona tiene una identidad verificada ante el Authorization Server. Cómo la obtiene es política de la comunidad. Al lanzar la aplicación, el Authorization Server la autentica, resuelve esa identidad a la identidad maestra y emite un token cuyo contexto de paciente es ella misma. La aplicación no elige a qué paciente accede. El contexto viene fijado en el token y el Record Locator Service confina cada consulta a ese paciente. El propósito de uso dice quién actúa, la propia persona, un familiar que ella autorizó o su representante legal, con los códigos de la [Tabla 2.2-3](volume-1-actors.html#tabla-2-2-3). A partir de ahí, sus consultas y recuperaciones son las de cualquier otro solicitante. + +Este caso es el que permite a HIX servir a la persona lo que es suyo, y no solo lo que la política de la comunidad permite entre organizaciones. + +#### Flujo del proceso + +![Acceso del paciente a su expediente](hix-flujo-paciente.svg) + +**Figura 2.5-4:** Acceso del paciente a su expediente +{: #figura-2-5-4} + +1. La [aplicación del paciente](appendix-glossary.html#aplicacion-del-paciente) inicia [HIX-2](volume-1-actors.html#hix-2). El Authorization Server autentica a la persona, obtiene su autorización para la aplicación, resuelve su identidad verificada a la identidad maestra mediante ITI-83 y emite el token con ese contexto de paciente y el propósito de uso que corresponde a quien actúa. +2. La aplicación localiza y recupera mediante ITI-67 e ITI-68 a través del Record Locator Service, que confina cada operación al paciente del contexto. + +### Casos previstos + +Los siguientes casos forman parte de la arquitectura y se especificarán en versiones posteriores de esta guía. La arquitectura ya fija dónde se aplican y qué información necesitan. + +- **Consentimiento anticipado del paciente.** La persona registra una directiva que permite o restringe la divulgación de sus documentos por clase de solicitante, propósito de uso, categoría de documento y ventana de validez. Se evalúa en cada operación bajo la Opción de Consentimiento. +- **Administración del consentimiento desde una aplicación.** La persona concede a una aplicación de su elección permiso para leer y escribir sus directivas. +- **Acceso solicitado por un miembro cuando no hay directiva.** Un miembro dirige a la persona al Authorization Server, que autoriza ese acceso específico. El token resultante lleva el contexto de paciente y la divulgación avanza bajo una autoridad que un momento antes no existía. +- **Acceso con anulación de la política.** Un profesional accede a documentos que la política ordinaria no le permitiría, declarando el propósito de uso `BTG`. Cómo se admite y cómo se audita lo fija cada comunidad, como indica la [Tabla 2.2-3](volume-1-actors.html#tabla-2-2-3). +- **Identidad del personal sanitario.** El Authorization Server federa hacia el proveedor de identidad de cada institución en lugar de alojar cuentas de profesionales. + +Las citas reproducen el texto publicado por su fuente. Los recortes se marcan con "[...]" y la negrita es de esta guía. + + +*[PMIR]: Patient Master Identity Registry, perfil IHE que gestiona la identidad maestra del paciente +*[PIXm]: Patient Identifier Cross-referencing for mobile, perfil IHE que enlaza los identificadores locales de un paciente con su identidad maestra +*[PDQm]: Patient Demographics Query for Mobile, perfil IHE de búsqueda de pacientes por datos demográficos +*[MHD]: Mobile access to Health Documents, perfil IHE para publicar, localizar y recuperar documentos sobre FHIR +*[MHDS]: Mobile Health Document Sharing, perfil IHE que compone MHD, PMIR, mCSD, IUA y ATNA en una comunidad de intercambio de documentos +*[mCSD]: Mobile Care Services Discovery, perfil IHE de directorio de organizaciones, servicios y endpoints +*[IUA]: Internet User Authorization, perfil IHE que aplica OAuth 2.0 a las transacciones sobre FHIR +*[ATNA]: Audit Trail and Node Authentication, perfil IHE de auditoría y seguridad de los nodos +*[BALP]: Basic Audit Log Patterns, perfil IHE con los patrones de AuditEvent de FHIR +*[CT]: Consistent Time, perfil IHE que sincroniza los relojes de los sistemas diff --git a/input/pagecontent/volume-1.md b/input/pagecontent/volume-1.md new file mode 100644 index 0000000..b466eb7 --- /dev/null +++ b/input/pagecontent/volume-1.md @@ -0,0 +1,52 @@ +HIX es una comunidad de intercambio de documentos clínicos sobre FHIR. Sigue el modelo que IHE llama **Centralized Discovery and Retrieve**, en el que un localizador central permite descubrir dónde están los documentos y recuperarlos del custodio que registró su existencia ([IHE HIE Whitepaper, §2.8](https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#28-document-sharing-models))[^hie-cdr]. HIX lo aplica con una precisión. También la recuperación pasa por ese localizador, de modo que **la localización y la recuperación se median de forma centralizada, mientras la custodia de los documentos permanece distribuida** entre los miembros que los producen. + +IHE realiza ese modelo sobre FHIR con **[MHDS](https://profiles.ihe.net/ITI/MHDS/volume-1.html)**. HIX lo toma como arquitectura de referencia, sin declarar conformidad con él, y compone directamente los perfiles que resuelven cada pieza, por las razones que da la [sección 2.1](volume-1-concepts.html#relacion-con-mhds). + +Cada perfil que HIX compone aporta una pieza de esa arquitectura. + +- **[MHD](https://profiles.ihe.net/ITI/MHD/5.0.0/index.html)** pone las transacciones con las que se publica, localiza y recupera un documento. +- **[PMIR](https://profiles.ihe.net/ITI/PMIR/index.html)**, **[PIXm](https://profiles.ihe.net/ITI/PIXm/index.html)** y **[PDQm](https://profiles.ihe.net/ITI/PDQm/index.html)** ponen la identidad maestra del paciente y su vínculo con las identidades locales. +- **[mCSD](https://profiles.ihe.net/ITI/mCSD/index.html)** pone el directorio del que la infraestructura central aprende dónde responde cada custodio. +- **[IUA](https://profiles.ihe.net/ITI/IUA/index.html)** y OAuth 2.0 ponen los tokens que cruzan cada límite de confianza, con **[SMART App Launch](https://hl7.org/fhir/smart-app-launch/)** cuando quien autoriza es una persona. +- **[ATNA](https://profiles.ihe.net/ITI/TF/Volume1/ch-9.html)** con **[BALP](https://profiles.ihe.net/ITI/BALP/index.html)** pone el registro que hace reconstruible cada divulgación. + +Lo que ningún perfil cubre, como el intercambio de tokens hacia un custodio o el lanzamiento de la aplicación del paciente, HIX lo especifica como transacción propia, identificada como `HIX-n`, en el Volumen 2. + +### Infraestructura Central + +![Infraestructura central de HIX](central-architecture-diagram.svg) + +**Figura 2-1:** Infraestructura central de HIX +{: #figura-2-1} + +La [Figura 2-1](volume-1.html#figura-2-1) muestra la infraestructura central de la comunidad, es decir, los servicios que HIX opera y las transacciones que los conectan. Es una vista de arquitectura, no de despliegue. Omite las agrupaciones transversales que casi todo actor lleva, como el Time Client de CT, y no dibuja los sistemas de los miembros, que solo tratan con la infraestructura central y nunca entre sí. + +- El **Record Locator Service** es el mediador de la comunidad. Localiza y recupera documentos en nombre de los miembros y aplica la decisión de divulgación. +- El **Authorization Server** es el único emisor de tokens de la comunidad. Emite el token con el que un miembro llega al mediador y lo intercambia por otro, acotado a un destino, cada vez que el mediador tiene que alcanzar a un custodio o a un componente central. +- El **Document Registry** conserva los punteros a los documentos publicados, cada uno con la identidad maestra del paciente como sujeto. +- Los **Shared HIE Services** de la figura completan la infraestructura. El directorio de la comunidad describe a los miembros y sus endpoints, el registro de identidad maestra mantiene una identidad por persona y el Audit Record Repository concentra los eventos de los componentes centrales. +- La **fuente autoritativa de identidad** es externa a la comunidad y la única que puede crear identidades maestras. HIX no la designa. Propone que en Costa Rica sea el EDUS, el expediente digital único de la CCSS, que ya tiene resuelta la identificación de las personas. + +Dicho en seis afirmaciones. + +1. La comunidad es **la única contraparte** de sus miembros. **Ningún miembro interactúa con otro.** +2. El **índice es central y el contenido es del custodio**. Un documento se queda donde se produjo, y la comunidad sabe que existe, de quién es y quién lo conserva. +3. La **divulgación se decide una vez por cada consulta**, en la infraestructura central, sobre los metadatos del índice y antes de mover contenido alguno. Localizar y recuperar son dos consultas. +4. Cada recuperación alcanza al custodio con una **credencial derivada de la petición viva del solicitante**, el [token intercambiado](appendix-glossary.html#token-intercambiado), que vale para ese único custodio, dura dos minutos como máximo y el custodio verifica por sí mismo. Ningún participante tiene credenciales permanentes hacia otro, ni siquiera el mediador. +5. La **identidad maestra del paciente está anclada en la identidad nacional verificada**. Los miembros declaran sus identidades locales, la comunidad las vincula y ningún miembro crea una persona. +6. El **transporte hacia cada custodio se declara en el directorio**, no en los punteros ni en la API. Una red de intercambio como [X-Road](https://x-road.global/) puede llevar ese tramo sin que cambie un puntero, un token ni una transacción. + +### Cómo leer este volumen + +- **Conceptos y decisiones de arquitectura** explica el porqué de cada decisión, la alternativa que descarta y lo que cuesta. +- **Actores y transacciones** define los actores de HIX, las transacciones que los vinculan y los requisitos normativos de cada uno. +- **Capacidades opcionales de los actores** describe lo que un actor puede declarar además de lo requerido, sin dejar de ser conforme. +- **Agrupaciones de actores requeridas** enumera los actores de otros perfiles que cada actor de HIX agrupa. +- **Casos de uso y flujos** recorre los escenarios que la arquitectura soporta, con el flujo de cada uno. +- **Consideraciones de seguridad** especifica el modelo de confianza, los dos regímenes de token y los controles de seguridad y privacidad. + +El Volumen 2 especifica cada transacción. Este volumen describe qué hace cada actor y por qué, y el siguiente, cómo. + +### Referencias + +[^hie-cdr]: [IHE HIE Whitepaper, §2.8 Document Sharing Models](https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#28-document-sharing-models): "**Centralized Discovery and Retrieve** – in this model, a centralized locator is used to discover the location of documents which enables a retrieval of the document from a custodian who has registered existence of the document with the centralized locator". [§3 Document Sharing Profiles](https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#3-document-sharing-profiles) asocia ese modelo a "Mobile access to Health Documents (MHD), Mobile Health Document Sharing (MHDS), and Cross-Enterprise Document Sharing (XDS)". diff --git a/sushi-config.yaml b/sushi-config.yaml index b3da90b..4e02d5f 100644 --- a/sushi-config.yaml +++ b/sushi-config.yaml @@ -13,8 +13,8 @@ name: HixHealthInformationExchange title: Health Information Exchange description: >- Specification of the hix health information exchange: a Document Sharing - community built on the IHE MHDS profile, together with the authorization, - identity, directory and audit mechanisms that surround it. + community composed from the IHE MHD, PMIR, PIXm, PDQm, mCSD, IUA, ATNA and + BALP profiles, with IHE MHDS as its reference architecture. status: draft version: 0.1.0 fhirVersion: 5.0.0 @@ -26,32 +26,46 @@ publisher: name: Meddyg url: https://meddyg.com +# dependencies: +# ihe.iti.mhd: +# version: 5.0.0 +# reason: "Publicación, localización y recuperación de documentos (FHIR R5)" +# ihe.iti.pmir: +# version: 1.6.0 +# reason: "Identidad maestra del paciente (FHIR R4)" +# ihe.iti.pixm: +# version: 3.1.0 +# reason: "Declaración de identidades locales y resolución a la identidad maestra (FHIR R4)" +# ihe.iti.pdqm: +# version: 3.2.0 +# reason: "Búsqueda de pacientes por datos demográficos (FHIR R4)" +# ihe.iti.mcsd: +# version: 4.0.0 +# reason: "Directorio de organizaciones, servicios y endpoints (FHIR R4)" +# ihe.iti.balp: +# version: 1.1.4 +# reason: "Patrones de los eventos de auditoría (FHIR R4)" + # Page order drives the automatic section numbering shown in the rendered site. pages: index.md: title: Descripción general - # volume-1.md: - # title: Volume 1 — Architecture - # volume-1-overview.md: - # title: Overview - # volume-1-actors.md: - # title: Actors and Systems - # volume-1-transactions.md: - # title: Transactions and Workflows - # volume-1-options.md: - # title: Actor Options - # volume-1-groupings.md: - # title: Required Actor Groupings - # volume-1-information.md: - # title: Information Architecture - # volume-1-usecases.md: - # title: Use Cases - # volume-1-security.md: - # title: Security and Trust Model - # volume-1-deployment.md: - # title: Deployment and Runtime Views - # volume-1-cross-profile.md: - # title: Cross-profile Integration + volume-1.md: + title: Volumen 1. Arquitectura + volume-1-concepts.md: + title: Conceptos y decisiones de arquitectura + volume-1-actors.md: + title: Actores y transacciones + volume-1-options.md: + title: Capacidades opcionales de los actores + volume-1-groupings.md: + title: Agrupaciones de actores requeridas + volume-1-usecases.md: + title: Casos de uso y flujos + volume-1-security.md: + title: Consideraciones de seguridad + # volume-1-cross-profile.md: + # title: Consideraciones entre perfiles y despliegue # volume-2.md: # title: Volume 2 — Transactions # volume-2-index.md: @@ -102,10 +116,10 @@ pages: # title: hix Extensions # conformance-artifacts.md: # title: Conformance Artifacts - # appendix.md: - # title: Appendices - # appendix-glossary.md: - # title: Glossary + appendix.md: + title: Apéndices + appendix-glossary.md: + title: Glosario # appendix-rationale.md: # title: Design Rationale # appendix-references.md: @@ -117,18 +131,15 @@ pages: menu: Descripción general: index.html - # Volume 1: - # Volume 1 — Architecture: volume-1.html - # Overview: volume-1-overview.html - # Actors and Systems: volume-1-actors.html - # Transactions and Workflows: volume-1-transactions.html - # Actor Options: volume-1-options.html - # Required Actor Groupings: volume-1-groupings.html - # Information Architecture: volume-1-information.html - # Use Cases: volume-1-usecases.html - # Security and Trust Model: volume-1-security.html - # Deployment and Runtime Views: volume-1-deployment.html - # Cross-profile Integration: volume-1-cross-profile.html + Volumen 1: + Arquitectura: volume-1.html + Conceptos y decisiones: volume-1-concepts.html + Actores y transacciones: volume-1-actors.html + Capacidades opcionales: volume-1-options.html + Agrupaciones requeridas: volume-1-groupings.html + Casos de uso y flujos: volume-1-usecases.html + Consideraciones de seguridad: volume-1-security.html + # Entre perfiles y despliegue: volume-1-cross-profile.html # Volume 2: # Volume 2 — Transactions: volume-2.html # Transaction Index: volume-2-index.html @@ -157,9 +168,9 @@ menu: # IHE Departures: conformance-departures.html # hix Extensions: conformance-extensions.html # Conformance Artifacts: conformance-artifacts.html - # Appendices: - # Appendices: appendix.html - # Glossary: appendix-glossary.html + Apéndices: + Apéndices: appendix.html + Glosario: appendix-glossary.html # Design Rationale: appendix-rationale.html # References: appendix-references.html # Change History: appendix-changes.html diff --git a/template-local/content/assets/css/hix.css b/template-local/content/assets/css/hix.css index 79e7df0..4b0b729 100644 --- a/template-local/content/assets/css/hix.css +++ b/template-local/content/assets/css/hix.css @@ -13,3 +13,42 @@ --btn-hover-color: #34799a; /* 6. Menu button hover color */ --ig-status-text-color: #0e3a4f; /* 1. IG title and status text color */ } + +/* + * The one layout override. project.css floats `p > img` left, and Markdown + * renders a figure as exactly that, so the caption and the next paragraph wrap + * in the sliver of space beside the diagram. + */ +p > img { + float: none; +} + +/* + * Show the reader where an in-page link landed. The browser marks the element + * whose id is in the URL fragment as :target, so a jump to a footnote, a table, + * a figure or a section tints it for a moment. A table caption carries the + * table's id, so the table beneath it is tinted too. The tint fades; nothing + * is left behind once the reader has found their place. + * + * The way back from a footnote lands on the reference mark, a superscript + * digit too small for a tint to be noticed, so the block that holds it is + * tinted instead. :has() keeps its own rule: a browser without it drops the + * rule, not the ones above. + */ +:target { + scroll-margin-top: 1.25rem; +} + +:target, +:target + table { + animation: hix-target 2.5s ease-out; +} + +:has(> sup:target) { + animation: hix-target 2.5s ease-out; +} + +@keyframes hix-target { + from { background-color: rgba(52, 121, 154, 0.35); } + to { background-color: transparent; } +}