Integración de datos ISO/IEEE11073 provenientes de dispositivos

Transcripción

Universidad de Zaragoza Centro Politécnico Superior
Integración de datos ISO/IEEE11073 provenientes de dispositivos médicos en un servidor de Historia Clínica Electrónica (HCE) según la norma UNE‐EN/ISO 13606 Programa de Postgrado en Ingenierías Transversales Ingeniería Biomédica Tesis Fin de Máster Autora Mª Pilar Muñoz Gargallo Directores
Dr. Ignacio Martínez Ruiz
Dr. Adolfo Muñoz Carrero
Septiembre 2010
‐
Curso 2009/2010
"La motivación más importante para trabajar tanto en la escuela
como en la vida, es el placer en su resultado y el valor de dicho
resultado para la comunidad."
Albert Einstein
ÍNDICE
Índice de tablas .......................................................................................................... 4
Índice de figuras ........................................................................................................ 5
Lista de acrónimos ..................................................................................................... 9
Abstract .................................................................................................................... 15
Bloque 0 ....................................................................................................................... 17
Introducción
i.
Antecedentes y contexto. .................................................................................. 19
ii.
Hipótesis y objetivos ......................................................................................... 20
iii.
Estructura de la memoria ............................................................................ 21
Bloque 1 ....................................................................................................................... 23
Historia Clínica Electrónica y normalización. Estado del Arte
1.1.
De la Historia Clínica a la Historia Clínica Electrónica ............................ 27
1.2.
Situación europea, nacional y líneas de futuro ........................................... 39
1.2.1.
Situación en Europa .............................................................................. 39
1.2.2.
Situación en España .............................................................................. 42
1.2.3.
Futuro de los sistemas de Salud ........................................................... 48
Conclusiones… ......................................................................................................... 51
Bloque 2 ....................................................................................................................... 53
Implementación de la arquitectura cliente/servidor para interoperabilidad de HCE
2.1.
Servidor de HCE. Primera Implementación ............................................... 56
2.1.1.
Estudio de los estándares UNE-EN/ISO 13606 e ISO/IEEE 11073 ... 56
2.1.2.
Consideraciones en la toma de datos telemáticos ................................ 58
2.1.3.
Diseño de arquetipos primarios ............................................................ 58
2.1.4.
Arquitectura inicial del servidor de HCE ............................................. 59
2.1.5.
Pruebas. ................................................................................................. 61
2.2.
Arquitectura cliente/servidor HCE. Segunda Implementación .................. 62
2.2.1.
Estudio del nuevo formato de datos...................................................... 62
2.2.2.
Arquitectura Multicapa. Modificaciones. ............................................. 64
1
2.3.
Diseño e implementación del “standard approach” CE2EHR .................... 65
Bloque 3 ....................................................................................................................... 69
Conclusiones y líneas futuras. Próximos retos de I+D+i
3.1
Conclusiones.................................................................................................. 71
3.2
Líneas futuras. .............................................................................................. 72
3.3
Próximos retos de I+D+i. .............................................................................. 74
3.3.1. Integridad semántica de datos clínicos en soluciones de
telemonitorización. ............................................................................................... 75
3.3.2.
3.4
Situaciones médicas de interés para integración de estándares......... 76
Hitos académicos y de investigación. Agradecimientos. ............................. 79
Referencias ............................................................................................................... 83
Anexos
Anexo A . Historia Clínica Electrónica y normalización. ................................... 101
A.1 Instituciones, normas y estándares. ........................................................... 101
A.2 Terminología médica y codificación. ........................................................... 109
Anexo B . openEHR .............................................................................................. 115
Anexo C . Estándares HL7 ................................................................................... 121
C.1 Mensajería HL7 v2 ..................................................................................... 121
C.2 Mensajeria HL7 v3 ..................................................................................... 123
C.3 Clinical Document Arquitecture ................................................................. 125
C.4 Otros estándares. ........................................................................................ 127
Anexo D Norma UNE-EN/ISO 13606 .................................................................. 129
Anexo E . Estándar ISO/IEEE 11073 .................................................................. 139
Domain Information Model ............................................................................... 142
Service Model ..................................................................................................... 152
Comms Model ..................................................................................................... 156
Anexo F . Envejecimiento de la población y cronicidad de las enfermedades. .. 165
Anexo G . Comparativa entre UNE-EN/ISO 13606 e ISO/IEEE 11073 ............ 169
Anexo H . Archetype Description Language y arquetipos. ................................. 177
Archetype Description Language ...................................................................... 177
Arquetipos .......................................................................................................... 180
Peso ................................................................................................................. 180
Pulso ................................................................................................................ 182
2
Tensión arterial ............................................................................................. 185
Glucomería ...................................................................................................... 190
Oximetria ........................................................................................................ 193
Temperatura ................................................................................................... 196
ECG ................................................................................................................. 199
Anexo I . Diseño del cliente. Pruebas. ................................................................. 203
Anexo J . Nuevos dispositivos médicos de uso domiciliario................................ 211
Anexo K . Informes definidos por el MSPS ......................................................... 217
Informe de Alta de Hospitalización ................................................................... 217
Informe clínico de Consulta Externa de Especialidades .................................. 219
Informe Clínico de Urgencias ............................................................................ 221
Informe de Historia Clínica Resumida ............................................................. 224
Informe Cínico de Atención Primaria ............................................................... 226
Informe de Resultados de Pruebas de Laboratorio .......................................... 228
Informes de Resultados de Pruebas de Imagen ............................................... 231
Informe de Resultados de Cuidados de Enfermería ......................................... 233
Anexo L . Consideraciones acerca de la toma de medidas en servicios de
telemonitorización. ................................................................................................ 237
a.
Glucemia ..................................................................................................... 238
b.
Temperatura corporal ................................................................................. 239
c.
Tensión Arterial .......................................................................................... 240
d.
Pulso ............................................................................................................ 243
e.
Peso .............................................................................................................. 245
f.
Pulsioximetria ............................................................................................. 247
g.
Espirometría ............................................................................................... 249
h.
Electrocardiografía ..................................................................................... 252
i.
Perfil lipídico ............................................................................................... 253
Anexo M . Situaciones médicas de interés para integración de los estándares
ISO/IEEE 11073 y UNE-EN/ISO 13606 ............................................................... 257
a.
Diabetes ....................................................................................................... 258
b.
Hipertensión................................................................................................ 262
c.
Sobrepeso..................................................................................................... 267
d.
Problemas Respiratorios............................................................................. 271
Enfermedad Pulmonar Obstructiva Crónica (EPOC)................................... 271
3
Asma ............................................................................................................... 274
e.
Sistema Inmune deprimido ........................................................................ 276
f.
Personas con movilidad reducida. .............................................................. 278
Índice de tablas
Tabla 1.1-1. Principales organismos de normalización en para la HCE .................. 35
Tabla 1.1-2. Organismos que desarrollan terminologías médicas. ........................... 36
Tabla 1.1-3. Terminologías médicas. .......................................................................... 37
Tabla 1.2-1. Proyectos de e-Salud en Europa. ........................................................... 39
Tabla 1.2-2. Proyectos europeos concluidos relacionados con HCE. ........................ 40
Tabla 1.2-3. Relación de Servicios autonómicos de salud. ........................................ 42
Tabla 2.1-1. Atributos de obligatorios o relevantes en Telemedicina. ...................... 57
Tabla 2.1-2. Principales tipos de datos según TS14796 . ....................................... 57
Tabla 2.3-1. Tabla de conversión entre unidades a Unidades UCUM. .................... 68
Tabla A-1. Estándares sobre requerimientos y análisis de sistemas de HCE. ..... 102
Tabla A-2. Estándares sobre arquitectura en sistemas de HCE. .......................... 103
Tabla A-3. Estándares sobre modelado y metodología en sistemas de HCE. ....... 103
Tabla A-4. Estándares sobre comunicación en sistemas de HCE. .......................... 105
Tabla A-5. Estándares sobre infraestructuras en sistemas de HCE. ..................... 105
Tabla A-6. Estándares sobre privacidad en sistemas de HCE. .............................. 106
Tabla A-7. Estándares sobre seguridad en sistemas de HCE................................. 106
Tabla A-8. Estándares sobre token en sistemas de HCE. ....................................... 106
Tabla A-9. Estándares sobre calidad en sistemas de HCE ..................................... 107
Tabla A-10. Estándares sobre políticas en sistemas de HCE ................................. 107
Tabla A-11. Estándares sobre seguridad en la gestión de identidades en sistemas
de HCE. ...................................................................................................................... 107
Tabla A-12. Estándares sobre terminologías y ontologías en sistemas de HCE. .. 108
Tabla C-1. Composición de un mensaje HL7 V2 a nivel de segmento. ................... 122
Tabla C-2. Caracteres de codificación en HL7 V2 ................................................... 123
Tabla D-1.Campos relevantes en el RM de ISO/EN 13606. .................................... 137
Tabla E-1. Especializaciones en desarrollo para X73.............................................. 141
Tabla E-2. Nomenclatura.......................................................................................... 143
Tabla E-3. Tabla de conversión según Fig E-3 ........................................................ 146
Tabla G-1. Atributos de EHR_EXTRACT. ............................................................... 169
Tabla G-2 Atributos por asociación de EHR_EXTRACT......................................... 169
Tabla G-3. Atributos de FOLDER. ........................................................................... 170
Tabla G-4. Atributos por Asociación de FOLDER. .................................................. 170
Tabla G-5. Atributos de COMPOSITION. ............................................................... 171
Tabla G-6. Atributos por asociación de COMPOSITION. ....................................... 171
Tabla G-7. Atributos de SECTION........................................................................... 171
Tabla G-8. Atributos por asociación de SECTION. ................................................. 172
4
Tabla G-9. Atributos de ENTRY............................................................................... 172
Tabla G-10. Atributos por asociación de ENTRY. ................................................... 173
Tabla G-11. Atributos de CLUSTER ........................................................................ 173
Tabla G-12. Atributos por asociación de CLUSTER ............................................... 173
Tabla G-13. Atributos de ELEMENT. ...................................................................... 174
Tabla G-14. Atributos por asociación de ELEMENT. ............................................. 174
Tabla G-15. Atributos de AUDIT_INFO. ................................................................. 174
Tabla G-16. Atributos de ATTESTATION_INFO. .................................................. 175
Tabla G-17. Atributos por asociación de ATTESTATION_INFO. .......................... 175
Tabla G-18. Atributos de FUNCTIONAL_ROLE. ................................................... 175
Tabla G-19. Atributos de RELATED_PARTY. ........................................................ 175
Tabla G-20. Atributos de LINK. ............................................................................... 176
Tabla G-21. Atributos por asociación de LINK........................................................ 176
Tabla H-1. Equivalente matemático de palabras reservadas. ................................ 179
Tabla J-1. Dispositivos médicos................................................................................ 216
Tabla L-1. Valores de Tensión arterial en función de edad y sexo ........................ 242
Tabla L-2. Presión sistólica normal en función de ubicación de la toma. .............. 242
Tabla L-3. Umbrales de patologías de la tensión arterial ....................................... 243
Tabla L-4. Estratificación del riesgo ........................................................................ 243
Tabla L-5. Frecuencia cardiaca en función de la edad ............................................ 244
Tabla L-6. IMC: definición y rangos. ........................................................................ 246
Tabla L-7. Patrones espirometricos de distintas funciones ventilatorias. ............. 250
Tabla M-1. Clasificación de la diabetes.................................................................... 258
Tabla M-2. Complicaciones asociadas a la diabetes. ............................................... 260
Tabla M-3. Variables a monitorizar en la diabetes. ................................................ 261
Tabla M-4. Clasificación primaria de la hipertensión. ........................................... 263
Tabla M-5. Clasificación secundaria de la hipertensión ......................................... 263
Tabla M-6. Complicaciones asociadas a la hipertensión. ........................................ 265
Tabla M-7. Variables a monitorizar en hipertensión .............................................. 265
Tabla M-8. Clasificación de los desordenes del peso. .............................................. 267
Tabla M-9. Valores de riesgo en función de la distribución de la grasa corporal .. 267
Tabla M-10. Complicaciones asociadas a un exceso de peso. .................................. 269
Tabla M-11. Variables a monitorizar en caso de sobrepeso. ................................... 269
Tabla M-12. Variables a monitorizar en la EPOC................................................... 273
Tabla M-13. Variables a monitorizar en casos de movilidad reducida. .................. 279
Índice de figuras
Fig. 1.1-1. Relaciones existentes entre diferentes organismos de normalización. ... 36
Fig. 1.1-2. Terminologías asociadas por ámbito de aplicación .................................. 38
Fig. 1.1-3. Relaciones entre las diferentes terminologías. ........................................ 38
Fig. 1.2-1. Principales inciativas y proyectos de HCE............................................... 41
Fig. 1.2-2. Descentralización del SNS. ....................................................................... 43
Fig. 1.2-3. Inversión y Madurez en las TICs sanitarias por comunidades. .............. 43
5
Fig. 1.2-4. Posición relativa de las CCAA en desarrollo de sus sistemas de e-Salud.
...................................................................................................................................... 44
Fig. 1.2-5. Evolución de la implantación de la receta electrónica en España. ......... 44
Fig. 1.2-6. Evolución de la implantación de la HCE de AP en España. ................... 45
Fig. 1.2-7. Evolución de la implantación de la cita on-line en España. .................... 45
Fig. 1.2-8. Pirámide de Riesgo de Kaiser Permanente. ............................................. 49
Fig. 1.2-9. Modelo de cuidados de enfermedades crónicas. ....................................... 49
Fig. 1.2-10. Paradigma de interoperabilidad. ............................................................ 50
Fig. 2.1-1. Representación conceptual de un extracto de HCE. ................................ 56
Fig. 2.1-2. Aplicación cliente. Pruebas. ...................................................................... 61
Fig. 2.2-1. Comparativa TS14796 vs. ISO/DIS 21090 ............................................... 63
Fig. 2.2-2. Descripción de la arquitectura multicapa. ............................................... 65
Fig. 2.3-1. Esquema del modelo estructural de una medida. .................................... 66
Fig. 2.3-2. Diagrama funcional de la transmisión de datos médicos remotos a un
servidor de HCE. ......................................................................................................... 67
Fig. 3.2-1. Diagrama ER de los diferentes informes definidos desde el MSPS. ....... 73
Fig. 3.2-2. Ejemplo de reutilización de conceptos en los informes de HCDSNS. ..... 74
Fig. 3.3-1. Interpretación semánticamente correcta de la medida. .......................... 76
Fig. 3.3-2. Diagrama ER Enfermedades-Síntomas-Signos. ...................................... 77
Fig. 3.3-3. Ejemplo de diagrama conceptual realizado: paciente hipertenso. .......... 77
Fig. A-1. Niveles superiores en la organización de SNOMED-CT. ......................... 111
Fig. A-2. Relaciones y granularidad en SNOMED-CT. ........................................... 112
Fig. A-3. Estructura de datos de SNOMED-CT. ...................................................... 113
Fig. B-1. Información vs. Conocimiento. .................................................................. 116
Fig. B-2. Estructura de jerárquica del EHR de openEHR. ..................................... 116
Fig. B-3. Estructura de una COMPOSITION de openEHR. ................................... 117
Fig. B-4. Clases ENTRY de openEHR. ..................................................................... 117
Fig. C-1. Modelo Básico de transacciones HL7 V2. ................................................. 121
Fig. C-2. Estructura de un mensaje HL7 v2 ............................................................ 122
Fig. C-3. Nucleo y RIM completo de HL7 V3 ........................................................... 124
Fig. C-4. Metodología de definición de mensajes en HL7 V3. ................................. 124
Fig. C-5. Estructura de un archivo CDA. ................................................................. 125
Fig. C-6. Niveles en un documento CDA. ................................................................. 126
Fig. C-7. Relación de CDA con los mensajes de HL7............................................... 126
Fig. D-1 ISO/EN13606 Reference Model (simplified scheme from ISO/EN13606-1)
.................................................................................................................................... 131
Fig. D-2. Component Relationships of the ISO/EN 13606 Reference Model ......... 132
Fig. D-3. Relation between Information (Reference Model) and Knowledge
(Archetype Model) ..................................................................................................... 132
Fig. D-4. Top- level structure forn an Archetype Description language (extracted
from ISO/EN 13606-2) .............................................................................................. 132
Fig. D-5. Archetype Model (simplified scheme from ISO/EN 13606-2) .................. 133
Fig. E-1. Tipos de Uso para X73- PHD..................................................................... 140
Fig. E-2. Diagrama de clases del X73- PHD. ........................................................... 143
Fig. E-3. Ejemplo de calculo de M y B ...................................................................... 146
6
Fig. E-4. Estructura de un objeto PM-Store. ........................................................... 147
Fig. E-5. Estructura de la clase CfgScanner. ........................................................... 149
Fig. E-6. Gestión de la ventana de transmisión en la clase CfgScanner. ............... 150
Fig. E-7. Ejemplo de recepción de tramas ................................................................ 151
Fig. E-8. Tipos de mensaje asociados a Association Service. .................................. 152
Fig. E-9. Mensaje varible, fijo y agrupado. .............................................................. 154
Fig. E-10. Máquina de estados en el agente ............................................................ 157
Fig. E-11. Máquina de estados en el manager. ........................................................ 157
Fig. E-12. Trama Association Request...................................................................... 158
Fig. E-13. Trama Association response. ................................................................... 159
Fig. E-14. Trama Release Request ............................................................................ 160
Fig. E-15. Trama Release Response. ......................................................................... 160
Fig. E-16. Trama Abort. ............................................................................................ 161
Fig. E-17. Trama Data Request Action..................................................................... 161
Fig. E-18. Trama Data Request Action Response. ................................................... 162
Fig. E-19. Trama Data Reporting. ............................................................................ 162
Fig. E-20. Trama Data Request Action..................................................................... 163
Fig. F-1 Evolución de la pirámide poblacional a nivel mundial ............................. 165
Fig. F-2. Previsión de la situación en España ......................................................... 166
Fig. F-3. Distribución Mundial de las Muertes según Causa por Grupos de Países
.................................................................................................................................... 167
Fig. F-4. Distribución Mundial de Muertes por Causa y Región del Mundo ......... 167
Fig. H-1. Esquema de un arquetipo. ........................................................................ 177
Fig. I-1. Pantalla de Log-in cliente. .......................................................................... 203
Fig. I-2. Pantalla de bienvenida del cliente. ............................................................ 203
Fig. I-3. Sub-Interfaces adaptadas al tipo de dato. ................................................. 204
Fig. I-4. SubInterfaces que admiten parámetros multiples. ................................... 204
Fig. I-5.Mensajes de ayuda en la interfaz ................................................................ 205
Fig. I-6. Introducción de campos obligatoria. .......................................................... 205
Fig. I-7. Validador de patrón de entrada ................................................................. 205
Fig. I-8. Extracto recivido. ........................................................................................ 206
Fig. I-9. Ejemplo de entrada. .................................................................................... 207
Fig. I-10. Rutina de decodificación ........................................................................... 207
Fig. I-11. Pantalla de petición de arquetipos. .......................................................... 208
Fig. I-12. Depliegue de parámetros .......................................................................... 208
Fig. I-13. Restricciones en la petición ...................................................................... 208
Fig. I-14. Descarga de información........................................................................... 209
Fig. L-1. Localización de los pulsos sanguineos ....................................................... 244
Fig. L-2. Relación entre SO2 y PO2 ........................................................................... 247
Fig. L-3. Derivaciones frontales. .............................................................................. 252
Fig. L-4. Derivaciones precordiales .......................................................................... 252
Fig. M-1. Pautas de control en la diabetes ............................................................... 259
Fig. M-2. Diagrama conceptual de la diabetes ........................................................ 261
Fig. M-3. Diagrama conceptual de la hipertensión. ................................................ 266
Fig. M-4 Distribución de la grasa corporal. ............................................................. 267
7
Fig. M-5. Diagrama conceptual asociado al sobrepeso ............................................ 270
Fig. M-6. Complicaciones asociadas a la EPOC....................................................... 272
Fig. M-7. Diagrama conceptual asociado a la EPOC ............................................... 274
Fig. M-8. Diagrama conceptual de sistema deprimido. ........................................... 277
Fig. M-9. Diagrama conceptual para la movilidad reducida................................... 279
8
Lista de acrónimos
ACR
ADA
ADL
AEMPS
AENOR
AIM
AMA
ANA
ANSI
AOM
AORN
AP
APA
API
ASTM
ATC
AVS
cADL
CALLIOPE
CAP
CCOW
CCR
CCAA
CCOW
CDA
CDT
CE
CELENEC
CEN
CENISSS
CENTC251
CIAP
CIP
CLEF
CORBA
CPME
CPT
CS
CT
CTCAE
CV
dADL
American Collage of Radiology
American Dental Association
Archetype Definition Language
Agencia Española de Medicamentos y Productos Sanitarios
Asociación Española de Normalización
Association Insurance Management
American Medical Asociation
American Nursing Asociation
American National Standards Institute
Archetype Object Model
Association of periOperative Registered Nurses
Atención Primaria
American Psychiatric Association
Application Programming Interface
American Society for Testing and Materials
Anatomical Therapeutic Chemical classification system
Agència Valenciana de Salud
Constraint form of ADL
Call for Interoperability
College of American Pathologists.
Clinical Context Object WorkGroup
Continuity of Care Records
Comunidades Autónomas
Clinical Context Object WorkGroup
Clinical Document Architecture de HL7
Current Dental Terminology
Compute Engine
European Committee for Electrotechnical Standardisation
Comité Europeo de Normalización
CEN Information Society Standardisation System
Comité Técnico 251 del Comité Europeo de Normalización
Clasificación Internacional de Atención Primaria
Competitiveness and Innovation Framework Programme
Clinical E-Science Framework
Common Object Request Broker Architecture
Comite Permanent Des Medecins Europeens
Current Procedentural Terminology
Code Simple Value
Clinical Terms
Common Terminology Criteria for Adverse Events
Coded Value
Data definition form of ADL
9
DDD
DICOM
DIM
DIS
D-MIM
DSM
E2ESHP
EAHP
ECG
ED
EFN
EHMA
EHR
EHR-QTN
EHTEL
EN
epSOS
ER
ESI
ESQH
ETSI
EUROREC
FDA
FDB
FLOP
FSM
FSN
GTC
HC
HCD
HCDSNS
HCE
HGNC
HI
HIS
HISA
HL7
HMD
HOPE
HUGO
HUPH
I3A
IBIME
IB-SALUT
ICD
10
Dosis Diaría Definida
Digital Imaging and Communication in Medicine
Domain Information Model
Draft International Standard
Domain Messsage Information Model
Diagnostic and Statistical Manual of Mental Disorders
End-to-End Standard Harmonization Protocol
European Association of Hospital Pharmacists
Electrocardiograma
Encapasulated Data
European Federation of Nurses
European Hospital and Healthcare Federation
Electronic Health Record
Thematic Network on Quality Labelling And Certification of EHR
European Health Telematics Association
European
European Patients Smart Open Services
Entidad - Relación
Electronic Signatures and Infrastructures
European Society for Quality Healthcare
European Telecommunications Standards Institute
European Health Records Institute
Food and Drug Administration (United States)
First DataBank
First-Order Predicate Logic
Finite State Machine
Fully Specified Name
Grupo de Tecnologías de las Comunicaciones
Historia Clínica
Historia Clínica Digital
Historia Clínica Digital del Sistema Nacional de Salud
Historia Clínica Electrónica
HUGO Gene Nomenclature Committee
Health Informatics
Hospital Information System
Health Informatics Service Architecture
Health Level 7
Hierachical Message Description
European Hospital and Healthcare Federation
Human Genome Organisation database
Hospital Universitario Puerta de Hierro
Instituto de Investigación en Ingeniería de Aragón
Grupo de Informática Biomédica
Servei de Salut de les Illes Balears
International statistical Classification of Diseases and Related
ICF
ICH
ICHI
ICPC
ICS
ICSR
ICSS
IDCR
IDH
IDMP
IEC
IEEE
IHC
IHE
IHTSDO
II
IIS
INE
INGESA
ISCIII
ISMS
ISO
ISOTC215
IVL_TS
IT
ITACA
ITU
ITU-T
IU
JAX-RPC-1
LIS
LOINC
LOPD
MD
MDER
MEDRA
MIB
MS
MSPS
NANDA
NCI
NEMA
Health Problems
International Classification of Functioning, Disability and Health
International Conference on Harmonisation
International Classification of Health Interventions
International Classification of Primary Care ≈ CIAP
Institut Català de la Salut
Individual Case Safety Reports
Institute of Communication and Computer Systems
International Development Research Centre
Índice de Desarollo Humano
IDentification of Medicinal Products
International Electrotechnical Commission
Institute of Electrical and Electronic Engineers, Inc.
OASIS International Health Consortium
Integrating the Healthcare Enterprise
International Health Terminology Standars Development
Organisation
Instance Identifier
Internet Information Server
Instituto Nacional de Estadística
Instituto Nacional de Gestión Sanitaria
Instituto de Salud Carlos III
Information Security Management Systems
International Organization for Standardization
ISO - Technical Committee 215
Time Stamp Interval
Information Technologies
Instituto de Aplicaciones de las Tecnologías de la Información y
de las Comunicaciones Avanzadas
International Telecommunication Union
ITU Telecommunication Standardizarion Sector
Iowa University
Java API for XML Remote Procedure Call
Laboratory Information System
Laboratory Observation Identifier names and Codes
Ley Orgánica de Protección de Datos
Medical Device
Medical Data Encoding Rules
Medical Dictionary for Regulatory Activities
Medical Information Bus
Monitoring Server
Ministerio de Sanidad y Política Social
North American Nursing Diagnosis Association
National Cancer Institute
National Electrical Manufacturers Association
11
NHS
NIC
NLM
NOC
OASIS
OMG
OMS
ONIM
OPCS
SAKIDETZA
OSASUNBID
EA
OSI
PACS
PAR
PDF
PDQ
PGEU
PHD
PHR
PIB
PNDS
PNUD
PoC MDC
PQ
PROREC
Q-REC
RELMA
RIDE
RIM
RIS
RM
R-MIM
SACYL
SAGE
SALUD
SAS
SCS
SCS
SEEDO
SERGAS
12
National Health Service
Nursing Interventions Classification
National Library of Medicine
Nursing Outcomes Classification
Organization for the Advancement of Structured Information
Standards
Object Management Group
Organización Mundial de la Salud ≈ WHO
Online Mendelian Inheritance in Man
Office of Population, Censuses and Surveys Classification of
Surgical Operations and Procedures
Servicio Vasco de Salud
Servicio Navarro de Salud
Open System Interconnection
Picture Archiving and Comunication Systems
Project Approval Request
Portable Document Format
Physician Data Query
Pharmaceutical Group of the European Union
Personal Health Device
Personal Health Record
Producto Interior Bruto
Perioperative Nursing Data Set
Programa de Naciones Unidas para el Desarrollo
Point-of-Care Medical Device Communication
Physical Quantity
PROmotion strategy for European electronic health RECord
Quality Labelling and Certification of Electronic Health Record
systems in Europe
Regenstrief LOINC Mapping Assistant
A Roadmap for Interoperability of eHealth Systems with Special
Emphasis on Semantic Interoperability
HL7 Reference Information Model
Radiology Information System
Reference Model
Refined Message Information Model
Sanidad de Castilla y Leon
Security Algorithms Group of Experts
Servicio Aragonés de Salud
Servicio Andaluz de Salud
Servicio Canario de Salud
Servicio Cántabro de Salud
Sociedad Española para el Estudio de la Obesidad
Servizo Galego de Saúde
SERIS
SERMAS
SES
SESCAM
SESPA
SNOMED
SDO
SMS
SNS
SOAP
TAC
TCSA
TFM
TIC
TrEHRT
TS
TS
UCUM
UMLS
UN/CEFACT
URI
UZ
UEMS
UML
UNE
UPV
VNA
W3C
WHO
WIDENET
WONCA
WS
WSDL
XDS
XML
Servicio Riojano de Salud
Servicio Madrileño de Salud
Servicio Extremeño de Salud
Servicio de Salud de Castilla La Mancha
Servicio de Salud del Principado de Asturias
Systematized Nomenclature of Medicine
Standards Development Organisation
Servicio Murciano de Salud
Sistema Nacional de Salud
Simple Object Access Protocol
Tomografía Axial Computerizada
Técnicas Competitivas S.A.
Tesis Fin de Máster
Tecnología de la Inforamción y la Comunicación
Travelers EHR Template
TimeStamp or Time Point
Technical Specification
Unified Code for Units of Measure
Unified Medical Language System
United Nations Centre for Trade Facilitation and Electronic
Business
Uniform Resource Identifier
Universdad de Zaragoza
Union Européenne des Médecins Spécialistes
Unified Modeling language
Unificación de Normativas Españolas
Universidad Politécnica de Valencia
Visiting Nursing Association
World Wide Web Consortium
World Health Organization ≈ OMS
OfferingWorld-Wide Services through an International Network of
Health Record centres
Word Organization of Family Doctors
Web Service
Web Services Description Language
Cross Enterprise Document Sharing
eXtensible Markup Language
13
14
Abstract
Esta Tesis Fin de Máster (TFM) se enmarca dentro del trabajo del grupo de
telemedicina del Grupo de Tecnologías de las Comunicaciones (GTC) dentro de la
División de Ingeniería Biomédica del Instituto de Investigación en Ingeniería de
Aragón (I3A) de la Universidad de Zaragoza (UZ) y pretende sentar las bases de un
sistema de adquisición de datos remotos para ser incorporados a la Historia Clínica
Electrónica (HCE) del paciente de manera no supervisada.
Para lograr este cometido, la TFM se soporta en dos ejes fundamentales: la
norma UNE-EN/ISO 13606 para el intercambio de la Historia Clínica Electrónica
(HCE) del paciente de manera interoperable (tema de maxima actualidad
respaldado por gran cantidad de proyectos existentes que avalan esta necesidad:
entre ellos el proyecto de Historia Clínica Digital del Sistema Nacional de Salud
(HCDSNS) del Ministerio de Sanidad y Política Social (MSPS) o el proyecto
european patient Smart Open Services (epSOS) enmarcado dentro del espacio
europeo) y el estándar ISO/IEEE 11073 para la adquisición de señales biológicas de
manera transparente al dispositivo utilizado (recientemente adoptado como
estándar internacional y con multitud de iniciativas asociadas a la integración de
dispositivos médicos en el contexto de la salud personal, como Continua Health
Alliance, Integrating the Healthcare Enterprise (IHE), Microsoft HealthVault,
Google Health, entre otras).
Las aportaciones de esta TFM se inician con estudio pormenorizado y exhaustivo
de la realidad actual de la HCE, sus normas y estándares relacionados, así como los
retos futuros en este campo. Este Estado del Arte ha permitido, en primer lugar, la
consecución de una serie de hitos relacionados con la norma UNE-EN/ISO 13606
como son: el diseño de una base de datos capaz de albergar la información
relevante a transmitir, el diseño e implementación de modelos clínicos conceptuales
de las medidas a tomar específicos para la toma de medidas telemáticas, el
desarrollo de una interfaz de comunicación mediante tecnologías middleware
siguiendo las especificaciones definidas por la norma y el consecuente proceso de
extracción de HCE conforme a esa interfaz.
En segundo lugar, se ha realizado un estudio del estándar ISO/IEEE 11073 que
ha permitido comprender su lógica interna de funcionamiento y analizar la
viabilidad de equiparación de datos adquiridos mediante ISO/IEEE 11073 a la
HCE del paciente. Dicho estudio ha desembocado en una propuesta de
homogeneización de ambas normas basada en tecnologías eXchange Markup
Language (XML) mediante la cual dispositivos médicos de telemonitorización son
capaces de remitir medidas remotas a un servidor de HCE en una métrica
determinada. En base a esa métrica, se ha diseñado e implementado la lógica de
extracción de los datos relevantes, así como su correcto almacenamiento en las
bases de datos adecuadas. Como evolución natural al trabajo realizado, se ha hecho
un estudio en profundidad de aquellos factores que pueden llegar a enmascarar la
validez de la medida realizada, y su relación con aquellas enfermedades de las que
son emblema (como puede ser una glucometría en la diabetes).
Finalmente, para la consecución de este TFM se han realizado prácticas médicas
en tres ámbitos diferentes:
 el académico, en colaboración con el Instituto de Salud Carlos III (ISCIII) y el
Hospital Universitario Puerta de Hierro de Madrid (HUPH), que han permitido
la validación de los extractos de HCE generados y arquetipos propuestos;
15
 el empresarial, en colaboración con Técnicas Competitivas S.A. (TCSA), una
empresa canaria que, entre otros productos, ofrece servicios de gestión de HCE
en el ámbito de la salud,
 y el sanitario, mediante entrevistas con profesionales médicos para determinar
los datos que, además de la propia medida, resultan fundamentales y deben ser
asociados a ésta como el dispositivo utilizado o la hora en la que se realizó la
medida.
16
Bloque 0
Introducción
i.
Antecedentes y contexto.
ii.
Hipótesis y objetivos.
iii. Estructura de la memoria.
En este primer bloque, se expondrá el marco en el que se sitúa esta Tesis Fin de Máster:
situación socio-tecnológica actual, contexto formal en el que se enmarca esta solución y
objetivos del trabajo, tanto principales como particulares. Para finalizar se detallará el
contenido del resto de bloques y apartados de este trabajo.
17
Bloque 0:
18
Introducción
El enorme desarrollo tecnológico que ha sufrido la sociedad en los últimos años
no ha permanecido ajeno al mundo de la medicina, afortunadamente. Han sido
muchos los avances tecnológicos que han permitido, y permiten, mejoras en la
calidad asistencial a todos los pacientes: el desarrollo de la imagen médica, la
capacidad de procesado y tratamiento de las señales fisiológicas, la creación de
protocolos médicos, etc. han constituido hitos en la historia de la medicina. La
eficiencia sanitaria se ha visto favorecida por todos estos factores y por la creciente
tendencia consistente en la compartición/intercambio de datos clínicos entre
diferentes procesos asistenciales y centros sanitarios.
Todo ello junto con un nivel de vida más elevado (mejor alimentación, mejores
condiciones laborales, mayor asistencia social, mayor nivel cultural, etc.) han
propiciado un aumento de varias décadas en la esperanza de vida en la población,
tanto española como de cualquier otro país desarrollado.
La situación social y sanitaria es, por tanto, completamente distinta a la que
podríamos encontrar hace un par de décadas en nuestro país: aquellas
enfermedades que antes eran sinónimo de “sentencia de muerte” hoy en día son
tratables (a nivel curativo o paliativo), la conciencia sanitaria es mucho más
sensible ante temas de higiene y salubridad, etc.
Sin embargo no todos los cambios han resultado positivos: el envejecimiento de
la población (lo que se demuestra en la inversión de la pirámide poblacional) y la
aparición de nuevas patologías de carácter crónico, son sólo algunas de
consecuencias de esta nueva situación social.
El desarrollo tecnológico no sólo ha beneficiado al ámbito clínico en el sentido
más estricto sino que ha propiciado el desarrollo del cuidado domiciliario: la
posibilidad de adquirir determinados dispositivos médicos a un coste razonable
permite en muchos casos el seguimiento, al menos parcial, de muchas patologías.
Dichos dispositivos, no solo poseen la capacidad de adquirir medidas fisiológicas
sino que muchas veces también implementan interfaces de comunicación que
permiten la transmisión del dato recién adquirido a una segunda entidad (software,
servidor centralizado, otro dispositivo, etc.).
i. Antecedentes y contexto.
Esta Tesis Fin de Máster (TFM) se integra en el contexto de diseño e
implementación de una plataforma de telemonitorización de pacientes basada en
estándares extremo a extremo (1) desarrollada por el grupo de telemedicina de
GTC/I3A. La arquitectura de la plataforma (ver Fig. i-1), está basada en una
pasarela (Compute Engine, CE) que concentra toda la información recogida por los
distintos dispositivos médicos (Medical Devices, MDs). Este CE se comunica a
través de la red externa de acceso y transporte, con un servidor de monitorización
que gestiona distintos CEs y reúne toda la información proveniente de cada
escenario para actualizar la HCE del paciente. Las características de cada
elemento que conforma la arquitectura del sistema son:
 Medical Devices (MDs). La adquisición de datos médicos sigue un formato
propietario. Estos adaptadores crean la especialización para el MD que genera
su modelo de información específico y establece la máquina de estados finitos
permitiendo así a los MDs no compatibles con ISO/IEEE 11073 actuar como
agentes nativos de una comunicación ISO/IEEE 11073.
19
Bloque 0:
 Compute Engine (CE). El dispositivo de pasarela está diseñado como un
manager nativo ISO/IEEE 11073 que recoge toda la información médica
proveniente de MDs. La información es almacenada en un fichero de datos que,
junto con el perfil de configuración específico (Config Profile), sirve como entrada
de datos para el proceso de creación de tramas para un protocolo de
armonización entre estándares extremo a extremo (End-to-End Standard
Harmonization Protocol,
E2ESHP). Este protocolo permite integrar la
información adquirida por los MDs en la HCE de forma transparente y
posibilita, a partir de una consulta en la base de datos o de modificaciones del
Config Profile del correspondiente caso de uso, administrar y gestionar
remotamente los CEs y las especificaciones de cada MD.
 Monitoring Server (MS). Está compuesto por dos entidades. La primera actúa
como servidor E2ESHP puesto que se encarga de recibir los datos de ISO/IEEE
11073, decodificando tramas E2ESHP y extrayendo los datos ISO/IEEE 11073
apropiados (clasificando información por usuario asociado) para almacenarlos en
la base de datos. El segundo implementa una doble función cliente/servidor
EN13606 aceptando peticiones UNE-EN/ISO 13606 de información almacenada
en la base de datos, y generando extractos UNE-EN/ISO 13606 siguiendo sus
arquetipos.
Fig. i-1. Plataforma de telemoritorización basada en estándares extremo-a-extremo
ii. Hipótesis y objetivos
En esta TFM se ha pretendido establecer un nexo de unión entre dos grandes
ámbitos de cuidado en la salud: el estrictamente sanitario y el de cuidado personal.
El ámbito estrictamente sanitario comprende aquel gestionado por profesionales
sanitarios en cualquiera de sus acepciones: Atención Primaria (AP), Atención
Especializada y Atención Hospitalaria. El ámbito de cuidado personal comprende
aquellas medidas adquiridas en entornos domiciliarios y que podrían incorporarse
a la HCE de ese paciente. A su vez, las tendencias tecnológicas marcan que los
nuevos modelos de comunicación en los dispositivos médicos como los sistemas de
integración de información médica sean adaptados y modificados para que
satisfagan requisitos de homogeneidad y de interoperabilidad, mediante un diseño
basado en estándares.
Así este TFM pretende como objetivo principal establecer las bases del diseño de
soluciones de salud electrónica (e-Salud) ubicuas, interoperables y basadas en los
estándares que actualmente se están consolidando en la Unión Europea:
 ISO/IEEE 11073 para la interoperabilidad de dispositivos médicos
proporcionando una definición completa y estandarizada de la nomenclatura de
cada dispositivo: básculas, tensiómetros, glucómetros, pulsioxímetros,
adquisición de electrocardiogramas (ECG), etc.
20
Introducción
 UNE-EN/ISO 13606 para la representación de cualquier información incluida en
la HCE, así como para su comunicación entre centros o servicios de salud. Esta
norma asegura la interoperabilidad semántica de la información transmitida y
facilita la creación de las estructuras de información que se desean utilizar, a las
que se les da el nombre de arquetipos.
Dentro de esta TFM se pretende diseñar e implementar un modelo de
comunicaciones basado en estos dos estándares. Así, los datos recopilados en
distintos entornos (domiciliarios, hospitalarios, móviles, etc.) e intercambiados a
través del estándar ISO/IEEE 11073 entre los dispositivos médicos y el CE, se
almacenan en un servidor de datos de acuerdo a una propuesta de armonización
entre ambos estándares para que, tras una petición de HCE, dicho servidor sea
capaz de elaborar un extracto conforme a UNE-EN/ISO 13606.
Los objetivos particulares de esta TFM son los siguientes:
 Un estudio en profundidad de la norma UNE-EN/ISO 13606 y el estándar
ISO/IEEE 11073, para identificar los valores que una vez obtenidos por los
dispositivos médicos remotos debieran ser incluidos en la HCE.
 El modelado de los diferentes conceptos del dominio que pueden ser obtenidos
gracias a ISO/IEEE 11073 mediante el uso de arquetipos para lograr
interoperabilidad semántica en la información transmitida.
 Establecer unas directrices en el diseño de las composiciones generadas a partir
de la adquisición de datos telemáticos.
Como resultado de esta TFM se contará con una arquitectura de red completa
basada en estándares que permitirá obtener una solución integrada de u-Salud.
Además, se avanzará en el diseño e implementación de un nuevo servicio
cliente/servidor que integre los modelos de datos provenientes de dispositivos
médicos de telemonitorización basados en ISO/IEEE 11073.
iii. Estructura de la memoria
La presente memoria se estructura mediante una separación en bloques de
contenido:
 En el Primer Bloque introducirá el concepto de historia clínica, y se ilustrarán
las motivaciones, ventajas e inconvenientes que ha supuesto el paso de la
historia clínica a HCE. Así mismo, se hará una revisión de las diferentes
herramientas utilizadas para intentar solventar dichos inconvenientes: sistemas
de gestión, codificaciones y métodos de transmisión de datos clínicos.
 En el Segundo Bloque se detallarán los pasos que se han seguido a la hora de
implementar una arquitectura cliente/servidor capaz de generar extractos de
HCE conforme a la norma UNE-EN/ISO 13606. Entre dichos pasos se puede
destacar:
o Un estudio en profundidad de la norma UNE-EN/ISO 13606 y el estándar
ISO/IEEE 11073, para identificar aquellos valores que una vez obtenidos por
los dispositivos médicos remotos debieran ser incluidos en la HCE.
o El modelado de los diferentes conceptos del dominio que pueden ser obtenidos
gracias a ISO/IEEE 11073 mediante el uso del Modelo de Arquetipos definido
en UNE-EN/ISO 13606-2.
o Establecimiento de las diferentes consideraciones realizadas a la hora de
diseñar las composiciones generadas de la adquisición de datos telemáticos.
21
Bloque 0:
 En el Tercer Bloque se propondrán las conclusiones y líneas futuras y próximos
retos de I+D+i. Entre esas líneas se ha apostado, y comenzado el análisis, por
dos líneas claras, cada una de ellas con diferentes temporalidades:
o De manera inmediata, el diseño de Templates, arquetipos complejos, para el
modelado de los actuales informes definidos por el MSPS en su proyecto de
HCDSNS.
o A largo plazo, el diseño de arquetipos completos que permitan conservar la
integridad semántica de datos clínicos, desde una perspectiva más amplia que
la simple adquisición de datos de forma unívoca. De esta forma, se pretende
adecuar estos datos, no solo a la continuidad de cuidado desde un mismo
centro sanitario, sino a otras facetas de la HCE como pueden ser la
investigación clínica o la generación de informes complejos orientados como
composición de arquetipos simples que permitan, entre otras cosas, el
modelado de situaciones médicas de interés.
De este momento en adelante se usarán algunos acrónimos para facilitar la lectura
de esta TFM:
 El estándar ISO/IEEE 11073 pasará a denominarse X73.
 La norma UNE-EN/ISO13606 pasará a denominarse EN13606.
22
Bloque 1
Historia Clínica Electrónica y
normalización. Estado del Arte
1.1 De la Historia Clínica a la Historia Clínica
Electrónica. ¿Por qué? ¿Qué supone? ¿Cómo y mediante
qué?
1.2 Situación europea, nacional y líneas de futuro.
Conclusiones…
1. D E LA H ISTORIA C LÍNICA A LA H ISTORIA C LÍNICA E LECTRÓNICA En este primer bloque, se revisará la evolución de la Historia Clínica, desde sus orígenes a
su concepción actual, analizando las razones del cambio y las consecuencias que este
produjo en la gestión y transmisión de la misma. Del mismo modo, se repasará la
panorámica general respecto al proceso de normalización que se está viviendo: organismos,
sistemas de codificación, políticas nacionales e internacionales, etc. Además se describirá la
respuesta comercial ante el actual marco social de envejecimiento y como esa respuesta
puede crear sinergias con los sistemas sanitarios. El bloque termina con las reflexiones
obtenidas de esta revisión general.
23
Bloque 1:
24
Historia Clínica Electrónica y normalización. Estado del Arte.
Ya lo dice la sabiduría popular: “Es gran parte de la salud el conocer la
enfermedad.” Y para adquirir ese conocimiento es necesario documentar los
episodios donde la ausencia de salud es manifiesta. Así es como surge el concepto
de Historia Clínica (HC) y como su concepción ha evolucionado a lo largo de la
historia (2; 3; 4). Ya los chamanes pretendían localizar las enfermedades para
extraer y expulsar el cuerpo extraño que las causaban, aunque deberemos esperar
hasta los Tratados Hipocráticos (libros I y III de las Epidemias) para tener un
ejemplo de HC. En estos documentos, considerados una guía patológica, se realiza
una profusa descripción de los síntomas y su evolución a lo largo del tiempo
intentando relacionarlos con el medio ambiente donde se originó la enfermedad.
Más adelante, en las “consillias” medievales, se puede analizar la doctrina galénica
de la que no se apartaban lo más mínimo. En estos documentos en donde se
establecían discusiones de las cuestiones relativas a la etiología, a la patogenia y al
tratamiento de la enfermedad. Su aplicación docente es clara. Durante la época
renacentista, surge la “observatio” como nuevo modelo de Historia clínica. Durante
este periodo surge un protocolo de autopsia vinculado a la HC, donde se distingue
entre órganos normales y alterados. En este nuevo modelo se recupera la
ordenación cronológica de los síntomas al hacer las descripciones y una
enumeración de las lesiones encontradas en los órganos. Durante el siglo XVII se
produce la ruptura definitiva con la doctrina galénica y aparece una nueva
nosología que originó que la HC comenzara a reconocerse como elemento básico de
la descripción de la enfermedad de un paciente y, por lo tanto, el documento
princeps de la praxis médica. Las aportaciones principales son el empirismo clínico
(sólo se describe aquellos hechos que se perciben por los sentidos) y la especificidad
(describir casos de enfermar individual pero correlacionándolo con los casos típicos
de una determinada especie morbosa1). Las HCs poseerán una determinada
selección de síntomas y se relacionará el tempo propio de la enfermedad con el de la
especie morbosa a la que pertenezca. Durante el siglo XVIII surge un modelo de
historia clínica que se considera canónico y que con algunas variaciones es el que se
utiliza en la actualidad. Establece que la exploración de los enfermos debía
consistir en 3 fases: inspección, anamnesis y exploración objetiva, que junto con el
desarrollo de la enfermedad y el análisis del cadáver constituyen el modelo de HC.
Durante el siglo XIX aparecen 3 mentalidades diferentes: la anatomo-clínica, la
fisiopatológica y la etiológica. La Historia anatomo-clínica se centró en clasificar las
enfermedades por las lesiones que éstas producen, la historia fisiopatológica
centrada en la alteración de las funciones del organismo que produce la
enfermedad, mientras que la historia etiológica se encargará de relacionar los
antecedentes (familiares o personales) con el estado de la enfermedad y el
transcurso de la misma. Todo ello dio una mayor coherencia interna a la historia
clínica, así como precisión y riqueza descriptiva.
modo de enfermar que se caracteriza por estar producido siempre por la misma causa,
tener unos signos y unos síntomas determinados, tener unas lesiones y alteraciones
funcionales constantes y una evolución determinada. 1
25
Bloque 1:
Calidad Asistencial
Asistencial
Investigación
Historia
Clínica
Legal
Docencia
Administrativa
Fig. iii-1. Aspectos de la Historia Clínica
Todos estos matices y perspectivas en la documentación clínica han ido
constituyendo el esquema de la HC actual de un paciente, la cual representa la
evolución de su estado de salud a lo largo del tiempo y como se ha definido en
varias publicaciones, bien sea en su versión en papel como digital, es el compendio
de documentos que surgen como consecuencia del contacto entre el propio paciente
y un equipo de salud. (5) (6) (7) (8) (9) Aunque no solo es el aspecto médico el
único objeto de la HC. Hay que considerar también otros aspectos como podemos
ver en (5) (9) (10). (ver Fig. iii-1):
 Asistencial y/o epidemiológica: El primer cometido de toda historia clínica es el
servir como soporte de una buena administración sanitaria, facilitando la
atención y el seguimiento del paciente en dos vertientes, tanto asistencial (o
curativa) como epidemiológica (o de prevención). No se puede obviar que la
historia de salud de cada paciente es personal y, entre otras cosas, puede desde
matizar determinados umbrales de enfermedad a identificar datos anómalos.
 Evaluación de la calidad asistencial: La calidad asistencial es el estudio de la
estructura, el proceso y el resultado de la asistencia prestada. La HC servirá
para evaluar la eficacia de la atención prestada al paciente.
 Investigación: no cabe duda de que la historia clínica es la base de cualquier
investigación médico-sanitaria o epidemiológica, tanto a nivel individual como
colectivamente;
 Docencia: también es importante este cometido de la historia clínica, el servir de
apoyo a la enseñanza teórico-práctica de la medicina tanto en el pregrado como
en el postgrado;
 Administrativa: pues hoy la historia clínica se utiliza como pieza fundamental
para las tareas de gestión del centro sanitario;
 Médico-jurídico-legal: pues es el único documento que revela la relación entre
médico y paciente: dictaminará la necesidad de la atención sanitaria, si se
reconoció el problema y se estableció el tratamiento adecuado, etc.
Todos estos aspectos hacen de la historia clínica y su correcta organización un
elemento clave en cualquier sistema sanitario.
26
1.1. De la Historia Clínica a la Historia Clínica
Electrónica
¿Por qué? Motivación
Todo sistema vivo tiende a cambiar y el sanitario no es una excepción. De hecho
el sistema sanitario, puede verse afectado por múltiples factores reflejo de la
sociedad a la que sirve. Entre algunos de los cambios más notables que han
propiciado modificaciones en la HC se pueden encontrar:
 Cambios en el espectro demográfico. (9) (11) (12) En los últimos años se ha
producido un aumento de la población en núcleos urbanos. A su vez se está
experimentando un aumento en la esperanza de vida en la población fruto de los
avances sanitarios, médicos y sociales lo que incrementa el porcentaje de la
población que llega a edades avanzadas. De este modo el sistema sanitario tiene
que soportar más usuarios potenciales y, considerando ese envejecimiento de la
población, es más probable que esa necesidad de atención sanitaria.
 Especialización de la medicina. (7) La especialización de la medicina ha
conllevado la descentralización de la atención sanitaria, generando una
distinción entre centros de atención primaria, especialidades, etc. por no
mencionar los registros hospitalarios. Todos esos datos, pertenecen a un mismo
historial clínico y todos ellos deberían tenerse en cuenta en la toma de decisiones
médicas.
 Cambios en la movilidad de los ciudadanos. (13) Hace unos años no era
inhabitual pertenecer a un único centro sanitario, pero hoy en día un cambio de
residencia debido a cuestiones laborales o de estudios es algo común. Ante esta
situación sólo queda la disyuntiva de trasladar tus registros sanitarios o generar
unos nuevos en el nuevo punto de destino.
 Mejoras médicas y tecnológicas. Al desarrollar nuevas pruebas diagnosticas
(resonancias, radiologías, Tomografías Axial Computerizadas o TACs, etc.) la
historia de salud de un paciente se convierte en una aglutinación de diferentes
formatos (papel, pruebas de video, placas, etc.) (9) (14) El acceso a la historia ya
no podrá realizarse de manera homogénea.
En resumen, la situación es cada vez más compleja a nivel organizativo: un
centro sanitario cada vez tiene que proporcionar asistencia a una mayor cantidad
de pacientes y, en consecuencia, el volumen de información soportada crece
exponencialmente. Con el desarrollo de las Tecnologías de la Información y
Comunicaciones, (TICs), se ofrecieron soluciones a este asunto como pueden ser los
programas de gestión documental lo que requiso trabajar con documentos cuyo
formato fuese electrónico.
La adecuada transformación de la HC a formato electrónico puede facilitar
enormemente el aprovechamiento pleno de todas las funciones que ésta presenta a
nivel de investigación o asistencial (identificar causas de la enfermedad y proponer
medidas orientadas a su erradicación o a la paliación de sus efectos, parametrizar
sus episodios, registrar incidentes, catalogar secuelas, etc.). El tener estos datos en
formato electrónico ayuda, gracias a técnicas de minería de datos (Data Mining), a
analizar una gran fuente de datos formada por la agregación de las HC de muchos
pacientes o a omitir los datos personales del paciente (anonimación de la
información), convirtiendo la HC en herramienta en la investigación clínica (15).
27
Bloque 1:
Sin embargo, ese paso a formato electrónico debe ser adecuado, pues no basta
con digitalizar. Hay que tomar en consideración todos los aspectos que este salto
conceptual representa.
¿Qué supone? Implicaciones
El paso de la HC a formato electrónico supone algo más que la digitalización de
la historia clínica aunque los términos suelen confundirse (16) (17). Sin embargo,
no puede ignorarse todo el volumen de información previamente a la implantación
de la HCE, información que no puede perderse y el coste de pasarla a formato
electrónico resultaría astronómico. Es por ello que en muchos sistemas sanitarios
se optó por escanear los documentos de la HC, reduciendo el historial del paciente a
una colección de imágenes o de Portable Document Format (PDF). (16) (17) (18).
De ahí surge la Historia Clínica Digital (HCD) Esto supone un paso intermedio en
la creación de una HCE, pues facilita la consulta de documentos, pero no permite
tener un acceso directo a los datos contenidos en ellos como ocurre en la HCE.
El paso de la HC a un formato electrónico presenta muchas ventajas, algunas ya
mencionadas, y grandes inconvenientes. A continuación se tratará de enunciar las
principales consecuencias, positivas y negativas, de este hecho trascendental. Ente
las ventajas, podemos encontrar varias (9) (14), algunas más relevantes que otras,
pero podemos citar:
 Ahorro de espacio. Al generar documentación de manera continua, y la
necesidad de conservarla durante una gran cantidad de tiempo, el espacio se
convierte en un problema. Tanto la HCE como la HCD, permiten condensar toda
esa montaña de documentación en una o varias unidades de disco. Ese ahorro de
espacio permite, bien seguir generando documentación (se puede atender a más
personas, generar documentación más exhaustiva, etc.) bien reutilizar ese
espacio en otros usos (laboratorios, almacenes, más consultas) (ver Fig. 1.1-1).
 Facilidad de acceso. Los datos de los pacientes residirán de forma
centralizada/distribuida en servidores dentro del centro sanitario. El acceder a
un determinado historial se limitará a consultar adecuadamente esos servidores
eliminando la necesidad de solicitar a priori al personal encargado que busque el
historial deseado. Además, optimiza recursos humanos.
 Ahorro en costes. Muchos son los conceptos que se pueden englobar dentro de
este apartado: Al suprimirse la necesidad de tener una copia en papel de la
historia se reducen costes de material dentro del centro sanitario, pues el
consumo de material fungible o de impresión se reduce. Obtenemos pues un
beneficio ecológico.
 Mayor seguridad para el paciente. Gracias a la facilidad en el acceso a los
datos clínicos también se favorece la no repetición de determinados
procedimientos clínicos, por placas de Rayos X ordenada con días de diferencia
por otro facultativo.
 Ausencia de formato físico. En la misma línea de las dos ventajas anteriores,
y gracias a no limitarnos a un formato físico de la información clínica esta
adquiere propiedades de ubicuidad, siendo posible acceder a ella desde varios
lugares a la vez. (Ver Fig. 1.1-2) Se eliminaría la necesidad de tener varias
copias impresas en distintas ubicaciones, con el consiguiente riesgo a que una de
ellas quedase desactualizada. Tampoco se degradaría el soporte que contiene la
información con el uso (el papel se puede arrugar, romper, perder, etc.)
28
Fig. 1.1-1. Ahorro de Espacio.
 Salvaguarda de los datos clínicos. Un centro sanitario es también un
Sistema de Información y debe protegerse ante una posible pérdida de los datos
que custodia. El tiempo y recursos invertidos en hacer copias de seguridad de
datos electrónicos es considerablemente menor que los necesarios para replicar
volúmenes de información en papel. Por lo tanto, con la correcta política de
seguridad, la posibilidad de poder recuperar esos datos clínicos ante una
eventual catástrofe es considerablemente mayor.
 Tratamiento de la información. Anteriormente se comentaba la importancia
de la historia clínica como instrumento en la docencia y en la investigación. El
hecho de disponer de esos datos en formato electrónico, permite manipularlos
más fácilmente para ese propósito (Data Mining, Sistemas de apoyo a la decisión
clínica, etc.) permitiendo conservar el anonimato de los pacientes.
Fig. 1.1-2. Ausencia de Formato Físico.
29
Bloque 1:
A pesar de esta cantidad de ventajas, también se tendrán que resolver algunos
problemas asociados del paso de la HC a formato entre los que podemos destacar
(9):
 Seguridad de los sistemas. Aunque se ha mencionado una mejora en la
seguridad en la transición de la HC a formato electrónico, también presenta
inconvenientes frente a la versión en papel respecto a intrusiones. La “facilidad
en el acceso” y la “intangibilidad de los datos” son propiedades que pueden ser
aprovechadas por cualquier persona, no solo el personal sanitario y por lo tanto
es necesario establecer un sistema de permisos que restrinja el acceso a ciertos
datos a determinados profesionales (por ejemplo, un facultativo del corazón no
necesita conocer datos relativos al historial traumatológico de un paciente) para
el control de acceso interno y establecer las suficientes medidas de seguridad
que impida que un agente externo (un hacker, por ejemplo) pueda acceder a
nuestro sistema y copiar, borrar o incluso modificar los datos clínicos.
 Codificación de la información. El paso a formato electrónico favoreció el
desarrollo de sistemas de codificación extensos (patologías, síntomas, pruebas
médicas, etc.). Localmente, en un mismo centro sanitario, este hecho resulta
beneficioso (Así, es mejor seleccionar una opción codificada de un menú que
tener que escribir “El paciente manifiesta dolor abdominal agudo intermitente”)
puesto que la conversión de esos códigos a información comprensible por
humanos (“human readable information”) es automática al conocer las
equivalencias. Sin embargo al intentar compartir esa información, y debido al
carácter local de esos códigos los cuales pueden poseer un significado especifico
en un sistema determinado, es necesario transmitir bien la codificación con las
equivalencias bien los códigos ya traducidos, ya que en el centro de destino esos
códigos pueden significar algo completamente diferente ó incluso no utilizarse.
Caso particular de la codificación es la identificación de pacientes y resto de
entidades implicadas en el proceso de atención. Así, el número de HC de un
paciente no es el mismo en todos los centros, o incluso en los servicios a los que
acude. (19)
 Transmisión de la información. La Historia Clínica de un paciente debería
seguirle allá donde este fuera, pues da fe de su interacción con el sistema
sanitario. La gran movilidad de los ciudadanos así como la especialización de la
medicina hacen que diferentes centros de salud necesiten compartir información
entre sí. Sin embargo, con el desarrollo de las TICs la HC deja de tener un
formato físico, lo cual añade complejidad: los centros sanitarios pueden haber
desarrollado su sistema de gestión basándose en diferentes arquitecturas,
diferentes sistemas de almacenamiento de la información, codificaciones
diferentes, diferentes lenguas y/o dialectos, etc.
Se analizará toda esta problemática en las siguientes secciones.
¿Cómo? Sistemas de Gestión.
La principal función de un sistema sanitario es proporcionar atención sanitaria
a una determinada cantidad de pacientes, cantidad que tiende en ir en aumento.
Sin embargo la atención sanitaria no puede verse como un hecho puntual sino que
necesita ser contextualizada para la situación particular de cada paciente: así, no
requerirá el mismo cuidado un paciente de 30 años con hipertensión que un
anciano que sufra la misma patología. Es por ello que son necesarias herramientas
que ayuden a esa contextualización.
30
Si por un momento se olvida que se está tratando con datos médicos, se puede
equiparar este tipo de sistemas a cualquier otro que necesite almacenar y/o tratar
una gran cantidad de información, la cual irá en aumento con el número de
entidades tratadas. Será necesario disponer de un sistema de gestión de
información que dé soporte al sistema para que pueda seguir realizando sus
actividades con total normalidad. Sin embargo, el ámbito médico presenta ciertas
peculiaridades que no se pueden ignorar, entre ellas la especialización de la
medicina donde cada rama o especialidad puede generar diferente tipología de
información: en algunos casos solo será necesaria la adquisición de ciertos datos
como en los análisis de laboratorio, mientras que en otros casos habrá que adquirir
imágenes o videos como en pruebas radiológicas o ecografías. Los sistemas de
información tenderán a diseñarse en función del tipo de información que traten.
Y aunque se ha hablado de centro sanitario, tal vez hubiera sido más preciso
hablar de servicios sanitarios recogidos dentro de un centro sanitario pues serán
los servicios los que generen información, aunque será el centro, como elemento
centralizador el encargado de custodiarla. Así en España por ejemplo, el real
decreto 1277/2003 (20) establece la diferencia entre centro sanitario y servicio
sanitario, y en él se lista las diferentes categorías de centros y se enumera los
diferentes servicios que un centro sanitario puede ofrecer. Los centros sanitarios
son, por tanto, sistemas heterogéneos de información cuya complejidad depende de
los servicios que soporte: La complejidad organizativa de un centro de atención
primaria es menor que la de un centro hospitalario, pues este último podría ser
capaz de soportar más servicios que el centro de Atención Primaria.
Algunos de esos servicios sanitarios, por sus características intrínsecas, han
adquirido entidad propia, como son los Sistemas de Información Radiológica
(Radiology Informations System,RIS) en los servicios radiológicos, los sistemas de
adquisición y transferencia de Imágenes (Picture Archiving and Comunication
Systems,PACS) como sistemas de gestión de Laboratorio (Laboratory Information
System, LIS) o incluso los sistemas de información hospitalaria (Hospital
Information System, HIS). Un análisis pormenorizado del flujo de información en
estos sistemas puede ayudarnos a establecer políticas de seguridad adecuadas. En
la Fig. 1.1-3, modificada a partir de (21), se puede ver un ejemplo de lo que se está
tratando de explicar. El PACs tiene que ser capaz de ser almacenar varios tipos de
pruebas (prueba tipo 1, prueba tipo 2), pero no todos los médicos tienen los mismos
privilegios, y roles: algunos profesionales sólo necesitan acceder al PACs para dejar
un archivo, otros sin embargo necesitan acceder a imágenes para ser capaz de
analizarlas e introducir modificaciones en los archivos y otros, sin embargo, sólo
necesitan acceder a imágenes ya analizadas.
31
Bloque 1:
Solicitud Prueba Analisis Prueba Prueba Tipo 1 Prueba Tipo 2 Análisis Imágenes Fig. 1.1-3. Flujo de Información en un PACs.
La construcción de este tipo de arquitecturas no es sencilla, y tradicionalmente
se ha optado por un “outsourcing” (22) o, lo que es lo mismo, comprar sistemas
comerciales por bloques. Mientras en la historia en papel se mantenía como única
problemática el obtener una “copia impresa” del resultado de la prueba (papel,
placas, radiologías, etc.) para adjuntarlo al historial del paciente, actualmente el
principal hándicap consiste en comunicar esa información a otros subsistemas del
centro de manera transparente para que pueda tenerse en cuenta a la hora de
emitir un diagnostico. En el “outsourcing” de soluciones nos encontramos con
diferentes proveedores y tecnologías que hacen que la integración de sistemas no
sea algo trivial, lo que puede terminar derivando en islas de información incapaces
de compartir información con otros sistemas.
Dentro de un sistema sanitario, conocida la arquitectura del mismo y los
dispositivos que la integran, esta problemática se simplifica, puesto que se pueden
definir interfaces de comunicación localmente válidos y adaptados a las
características del centro. Además, dado el uso generalizado de algunos de estos
subsistemas, los fabricantes de estos módulos suelen incorporar mecanismos que
posibilitan la transmisión de la información recibida: los RIS actuales, por ejemplo,
proporcionan interfaces para enviar sus imágenes a PACS, normalmente mediante
algún tipo de mensajería. Así, compartir información dentro de un mismo sistema
sanitario resulta factible.
El problema adquiere un matiz diferente cuando se trata de compartir
información con otros centros sanitarios. Dejando al margen aspectos legales y
tecnológicos, la transmisión de la información de una manera inequívoca se
convierte en un aspecto clave a estudiar puesto que una transmisión errónea o
incompleta de los datos médicos puede ocasionar un error en el diagnostico por una
mala interpretación de los datos o un retraso en la determinación debido a la
necesidad de repetir alguna prueba.
32
¿Quiénes y mediante qué? Organizaciones y Normalización.
Que la Historia Clínica es la herramienta más importante para la gestión de la
salud de un paciente es algo innegable. Es por ello que su promoción se encuentra
entre las iniciativas de diversas organizaciones como la Unión Europa, la cual
identifica la HCE como una de las áreas de desarrollo que pueden ayudar a
garantizar la continuidad asistencial y reducir el gasto sanitario. (23)
Sin embargo para conseguir la completa implantación de la HCE se necesitan
cumplir ciertos requisitos como son la interoperabilidad, tanto técnica como
semántica, la garantía de protección tanto de datos personales como sanitarios o la
evaluación continuada de los sistemas con objeto de mejorar su calidad. Estos
aspectos adquieren una especial relevancia si se considera el caso de la
interoperabilidad transfronteriza de la HCE, donde se encuentran diversidad de
idiomas o legislaciones. Llegados a este punto, la coordinación entre todas las
partes implicadas (gobiernos estatales, regionales, etc.) que marquen líneas
estratégicas y de acción con antelación suficiente a su puesta en marcha definitiva
es un factor clave (24).
La transmisión de la información clínica, de forma que esta no pierda
significación médica, es el actual caballo de batalla de la Informática Medica: la
necesidad de compartir información entre distintos centros sanitarios es primordial
a la hora de emitir un diagnóstico correcto y preciso. Sin embargo esa cierta
libertad en la organización propia de cada centro hace que la tarea no sea algo
fácilmente abordable.
Desde un punto de vista estricto de la comunicación, se debe garantizar la
seguridad en las comunicaciones y la integridad de la información transmitida. Los
datos que se están transmitiendo son relativos a la salud, y de la misma manera
que en el almacenaje de los datos en los centros sanitarios, éstos merecen
consideraciones especiales pues una alteración en los mismos puede propiciar un
diagnostico erróneo, una alteración del tratamiento, etc. Sin embargo, no solo no es
necesaria la integridad de los datos, sino que en la transmisión se conserve la
integridad semántica de dichos datos. Se han de proporcionar herramientas que
permitan al receptor interpretar correctamente la información recibida. Esta es
una de las principales razones que ha favorecido el desarrollo de las diferentes
terminologías y sistemas de codificación. Por todo ello, el problema de la
transmisión de datos clínicos no puede abordarse sólo desde una única
perspectiva.
Pero, ¿es realmente necesaria esa codificación mediante terminologías médicas?
El origen de las terminologías médicas surge de la aspiración de lograr una
normalización en la denominación de los conceptos: En todo lenguaje, incluido el
médico, surgen fenómenos de sinonimia y polisemia que representan un obstáculo
en la comunicación. El objeto de las terminologías es, por lo tanto, fijar un término
para cada concepto y un concepto para cada término. (25)
Pero el origen de las terminologías no es único: La especialización de la medicina
en determinadas áreas conduce a la compartimentación de responsabilidades y
atribuciones en el ámbito médico (ver Fig. 1.1-4, modificada de (26)). Fruto de ello
surgieron diferentes maneras de nombrar ó codificar enfermedades, síntomas, etc.
válidas en cada ámbito. Así no tiene la misma visión de un determinado síntoma,
en granularidad por ejemplo, una enfermera que un patólogo, los cuales pueden ver
diferentes matices de una misma enfermedad.
33
Bloque 1:
Fig. 1.1-4. Especialidades medicas, codificaciones y conceptos médicos.
Habitualmente, los términos se codifican mediante una codificación jerárquica o
aleatoria usando cadenas alfanuméricas. Pero no sólo se codifican terminologías
médicas, sino diferentes clasificaciones y agrupamientos que podamos establecer en
el ambiente médico (ver Fig. 1.1-5). Tampoco esa identificación de términos o
enfermedades es única. La descoordinación entre diferentes organizaciones
nacionales e internacionales de normalización puede hacer que aparezcan
nomenclaturas o terminologías en el mismo campo temático.
Valorando estas consideraciones, parece obvio que el camino para abarcar ambos
problemas pasa por la normalización en
Fig. 1.1-5 Nomenclaturas, clasificaciones y Agrupamientos.
34
Conservando todas estas consideraciones en mente, tal vez aparezca una última
pregunta a la que contestar, quizá la más esencial: “¿Cómo se construye un sistema
de HCE? Y la respuesta no puede ser otra que “Como mejor se ajuste a tus
intereses.” Sin embargo, si deseamos conseguir que sea un sistema interoperable,
nuestro sistema se tendrá que amoldar a una serie de requerimientos marcados por
organismos de normalización y/o estandarización (Standard Development
Organizations, SDOs) y deberá adoptar terminologías comúnmente aceptadas. Las
SDOs, y las normas que estas definen, pueden clasificarse atendiento a su ámbito
de aplicación: nacionales como la Asociación Española de Normalización (AENOR),
regionales como el Comité Europeo de Normalización (CEN) en Europa o
internacionales como International Developement Organization (ISO). En la Tabla
1.1-1 podemos ver una relación de los principales organismos de normalización que
hay que tener en cuenta en el desarrollo de la HCE (27) (28), todos ellos
independientes entre sí salvo los comités técnicos que dependen directamente de
organismos superiores.
Sin embargo, el hecho de trabajar en temas comunes ha causado la aparición de
sinergias entre los diferentes organismos de normalización como mediante el
Acuerdo de Viena (The Vienna Agreement, (29)), mediante el cual cualquier
documento elaborado por cualquiera de las partes es remitido al contrario para su
votación conjunta, o como el Memorandum of Understanding (30) entre HL7,
CENTC251 y la Joint Iniciative on SDO (31), en el que se establece una
colaboración entre las partes para la definición de un conjunto de datos común para
el intercambio de información sanitaria. En la Fig. 1.1-1 se puede ser una
representación de esas relaciones:
Institute of Electrical and Electronics Engineers
International Organization for Standardization
ISO - Technical Committee 215
Digital Imaging and Communications in Medicine
International Electrotechnical Commission
HL7 International
Internacional Integrating the Healthcare Enterprise
Organization for the Advancement of Structured Information Standards
OASIS International Health Consortium
Object Management Group
United Nations Centre for Trade Facilitation and Electronic Business
World Wide Web Consortium
International Telecommunication Union
ITU Telecommunication Standardizarion Sector
European Committee for Standardisation
Technical Committee of CEN for Health Informatics
Europeo
IEC
(32)
(33)
(34)
(35)
(36)
HL7
IHE
OASIS
IHC
OMG
UN/CEFACT
W3C
ITU
ITU-T
(37)
(38)
(39)
(40)
(41)
(42)
(43)
(44)
(45)
CEN
(46)
CENTC 251
(47)
CEN Information Society Standardisation System
CEN/ISSS
(48)
CEN / ISSS e-Health Standardization Focus Group
CEN/ISSS
e-Health
(49)
European Telecommunications Standards Institute
IHE Europe
European Committee for Electrotechnical Standardisation
Americano
IEEE
ISO
ISO TC215
DICOM
American National Standards Institute
American Society for Testing Materials
National Electrical Manufacturers Association
ETSI
(50)
IHE Europe
CELENEC
(51)
(52)
ANSI
ASTM
NEMA
(53)
(54)
(55)
Tabla 1.1-1. Principales organismos de normalización en para la HCE
35
Bloque 1:
ITU-T
ITU
IEC
CEN ISSS
(eHealth)
colaboran
Representante
oficial en los USA
ANSI
acredita
punto de entrada europeo
UN/CEFACT
CEN ISSS
CELENEC
CEN
desarrolla
estándares como
votan
IHE Europe
ISO
desarrollan
conjuntamente
NEMA
alianza
funda
IEEE
alianza
promociona
DICOM
colaboran
CEN TC251
IHE
OMG
ISO TC215
alianza
JIRA
Leyenda
Internacional
Europeo
W3C
Memorandum of
Understunding
trabajo
armonizado
HL7
ETSI
ASTM
use case
Otros
ESI
OASIS
IHC
Fig. 1.1-1. Relaciones existentes entre diferentes organismos de normalización.
En el Anexo A se puede encontrar una descripción más extensa de estas
organizaciones, así como una relación de aquellos estándares que habría que
considerar en el caso de la construcción de un sistema de HCE. En cuanto a las
tendencias en la transmisión de la información, se necita referenciar los estándares
definidos por HL7 (ver Anexo B), openEHR (ver Anexo C) y la norma EN13606
(ver Anexo D).
Las diferentes terminologías también son desarrolladas por organizaciones,
aunque su ámbito muchas veces excede el institucional, como pueden ser colegios
profesionales o instituciones particulares. (28)
Organismos
intermacionaes
Colegios y
asociaciones
profesionales
Instituciones
particulares
International Health Terminology SDO
International Conference on Harmonisation
World Health Organization
World Organisation of Family Doctors
American Dental Association
American Medical Association
Association of periOperative Registered Nurses
American Psychiatric Association
Food and Drug Administration (United States)
Visiting Nursing Association
Hearts Corporation
HUGO Gene Nomenclature Committee
Iowa University
National Cancer Institute
National Health Service
National Library of Medicine (United States)
The Regenstrief Institute
IHTSDO
ICH
WHO
WONCA
ADA
AMA
AORN
APA
FDA
NANDA
VNA
HeCo
HGNC
IU
NCI
NHS
NLM
RI
Tabla 1.1-2. Organismos que desarrollan terminologías médicas.
36
(56)
(57)
(58)
(59)
(60)
(61)
(62)
(63)
(64)
(65)
(66)
(67)
(68)
(69)
(70)
(71)
(72)
(73)
Anatomical, Therapeutic, Chemical classification
system
ATC
Farmacología
WHO
Common Terminology Criteria for Adverse Events
CTCAE
Reacciones
adversas
NCI
COSTART
Reacciones
adversas
FDA
CDT
Odontologia
ADA
Current Procedentural Terminology
CPT
Procedimientos
AMA
Diagnostic and Statistical Manual of Mental Disorders
DSM
Psiquiatria
APA
Coding Symbols for a Thesaurus of
Adverse Reaction Terms
Current Dental Termilology
First DataBank
FDB
Farmacología
HeCo
HUGO
Genética
HGNC
International Statistical Classification of Diseases and
Related Health Problems
ICD
Enfermedades
WHO
International Classification of Functioning,
Disability and Health
ICF
Salud y
problemas
WHO
International Classification of Health
Interventions
ICHI
Intervenciones
WHO
Human Genome Organisation database
International Classification of Primary Care
ICPC
A. primaria
WHO
Logical Observation Identifiers Names and Codes
LOINC
Laboratorio
RI
Medical Dictionary for Regulatory Activities
MedRa
Reacciones
Adversas
ICH
Oncología
NCI
NANDA
Enfermería
NANDA
NIC
Enfermería
IU
NOC
Enfermeria
IU
OMAHA
Enfermería
VNA
ONIM
Genética
NLM
OPCS-4
Procedimientos
NHS
PDQ
Oncología
NCI
NCI Thesaurus NCI thesaurus
Nursing Interventions Classification
Nursing Outcomes Classification
Omaha System
Online Mendelian Inheritance in Man
Office of Population, Censuses and Surveys
Classification of Surgical Operations and Procedures
Physician Data Query
Perioperative Nursing Data Set
RxNorm
Systematized Nomenclature of Medicine-Clinical
Terms
Unified Medical Language System
PNDS
Enfermería
AORN
RxNORM
Farmacología
NLM
SNOMED-CT
General
ITSHIDO
UMLS
thesaurus
General
NLM
Tabla 1.1-3. Terminologías médicas.
En la Fig. 1.1-2, se puede ver una representación de las terminologías
médicas más relevantes agrupadas por ámbito de aplicación, mientras que en la
Fig. 1.1-3 se puede ver un diagrama de las distintas relaciones que se establecen
entre ellas. Son consideración particular SNOMED-CT, que no se ciñe a ninguna
temática en concreto y UMLS Thesaurus compuesto por la agregación de varias
terminologías. (28) (74) (75) (76) (77)
En el ámbito de las terminologías también aparecen relaciones de
colaboración, como entre LOINC y SNOMED-CT, donde SNOMED-CT desiste en el
desarrollo codificación en el ámbito de laboratorio para adoptar la desarrollada en
LOINC. (78)
37
Bloque 1:
NIC
NANDA
Terminologías
Médicas
NOC
PNDS
OMAHA
Enfermería
RxNorm
Psiquiatria
FDB
Odontología
ATC
Farmacología
CDT
SNOMED - CT
Reacciones Adversas
General
DSM
Laboratorio
LOINC
UMLSThesaurus
CTCAE
COSTART
HUGO
MedRa
ONIM
PDQ
ICD
Clasificaciones
ICPC
Oncología
Gabrieli
Genética
NCI
Otras
MEDCIN
ICF
QML
Procedimientos
OPCS-4
ICHI
CPT
ICD-X-CM
ICCS
Fig. 1.1-2. Terminologías asociadas por ámbito de aplicación
Fig. 1.1-3. Relaciones entre las diferentes terminologías.
38
1.2. Situación europea, nacional y líneas de futuro
En los próximos apartados se va a referenciar las tendencias existentes a nivel
europeo y nacional en relación con la HCE, tras lo cual trataremos de relacionarlo
con la situación existente en nuestro país, pues debido a la situación de
descentralización en la sanidad española la analogía puede resultar interesante.
1.2.1. Situación en Europa
Los diferentes cambios económicos, demográficos y sociales están propiciando
cambios en el modelo de servicios orientados al ciudadano en el sector de la e-Salud
(79) (23). Algunos de los proyectos de e-Salud más relevantes según (80) se pueden
encontrar en la Tabla 1.2-1 clasificados según su objetivo principal. En concreto, el
interés por promover una HC interoperable y estandarizada para el beneficio del
paciente se ha visto impulsado por varias iniciativas como la estrategia e-Europe en
2005 (81), o su equivalente actualidad incluido dentro de la Digital Agenda for
Europe (82): Muchos han sido los proyectos que han sido apoyados y financiados
desde la Unión europea a través del programa Marco para el desarrollo, en un
principio y a través del Competitiveness and Innovation Framework Programme
(programas CIP) (83) desde su creación. En la tabla podemos ver un histórico de los
proyectos que han finalizado (84):
Proyecto Europeos
País
Descripción
REDES NACIONALES Y REGIONALES DE E-SALUD
E- HEALTH HUNGARY
NETLIT
E-PRESCRIPTION
FLOW
SLOVENIA HEALTH CARD
HEALTHNET
HYGEIANET
MEDCOM
THE NORTHERN NORWEGIAN
HEALTH NETWORK
UUMA
Hungría
Lituania y Suecia
Suecia
Bélgica
Eslovenia
Karelia del Norte (Finlandia)
Isla de Creta (Grecia)
Dinamarca
Historia Clínica por problemas
Docencia, investigación y asistencia
Prescripción electrónica
Accesible por pacientes y médicos
Tarjetas chips con datos de salud
Mejorar el flujo de información
Módulos específicos para servicios
Intercambio de datos clínicos
Noruega
Sistemas de telemedicina
Helsinki
Teleconsulta
SISTEMAS DE E-SALUD Y SERVICIOS PARA PROFESIONALES DE SALUD
COHERENCE
ELIAS-HIS
OXFORD CLINICAL INTRANET
TERIVAN ANTICO
TIP
Francia
Rumanía
Oxford (Reino Unido)
Finlandia
Hungría
Actividad Hospitalaria
Actividad Hospitalaria
AP, Hospitallario
Anticogulación
Transplantes
TELEMEDICINA Y APLICACIONES DE E-SALUD DE CUIDADO EN HOGAR
DITIS
HOSPITAL AT HOME
PHN MOBILE COMPUTING
REMSSY
BOARIO
Chipre
Atenas (Grecia)
Irlanda
Rumanía
Pavia (Italia)
Pacientes con Cancer
Cuidado domiciliario
Cuidado domiciliario (enfermeria)
Atención de emergencia
Telecardiología
SISTEMAS ORIENTADOS A CIUDADANOS PARA SALUD Y BIENESTAR
HEALTH BUDDY
Estrasburgo (Francia)
SUSTAINS III
Uppsala (Suecia)
Cuidado de Crónicos
Acceso a la HCE
WWW.HEALTHGATE.AT
Austria
Control de la diabetes
Tabla 1.2-1. Proyectos de e-Salud en Europa.
39
Bloque 1:
Proyecto
Duración
Resultados
PROmotion strategy
for European
electronic health
RECord (85)
1996-1998
Financiado por el 4º Programa Marco. El
resultado fue la instauración de varios
centros ProRec.
OfferingWorld-Wide
Services through an
International
Network of Health
Record centres (80)
2000-2002
Quality Labelling
and Certification of
Electronic Health
Record systems in
Europe (86)
2005-2008
A Roadmap for
Interoperability of
eHealth Systems
with Special
Emphasis on
Semantic
Interoperability (87)
EHR-Implement (88)
Financiado por el 5º programa Marco.
Tomando como base los centros ProRec,
disemina información y provee de servicios
de valor añadido para la HCE. Lanzó el
European Institute for Health Records
(EUROREC)
Financiado por el 6ª Programa Marco, es
un proyecto de EuroRec. Entre sus
objetivos
se
pueden
encontrar
la
certificación de calidad en sistemas de
HCE y proporcionar recursos para la
interoperabilidad.
2006-2007
Financiado por el 6ª Programa Marco, es
un proyecto de EuroRec. El objeto de este
proyecto era la definición de una serie de
recomendaciones para su aplicación a
nivel europeo y que proporcionaran
interoperabilidad en sistemas de e-Salud
2007-2010
Financiado por el 7º Programa Marco, es
un proyecto de EuroRec. Su objetivo era
recoger y comparar implementaciones de
sistemas de HCE en Europa y definir y
difundir políticas de buenas prácticas.
Tabla 1.2-2. Proyectos europeos concluidos relacionados con HCE.
Con el paso del tiempo los esfuerzos por lograr una HCE interoperable no han
menguado y en la actualidad existen varios proyectos y organizaciones consagradas
a tal fin. (Ver Fig. 1.2-1). Entre ellos se pueden destacar:
 European Institute for Health Records (EuroRec Institute) (89): Es una
institución sin ánimo de lucro que promueve el uso de sistemas HCE construidos
bajo criterios de calidad. Dado que es una entidad de certificación, su misión se
centra en dar soporte al etiquetado de sistemas de HCE con criterios de calidad
y en la definición de criterios funcionales.
 Thematic Network on Quality Labelling And Certification of EHR
Systems (EHR-QTN) (90): Es un proyecto de EuroRec y está financiado por el
programa CIP. En él se pretende preparar a la comunidad sanitaria europea
para poder realizar comparaciones sistemáticas de calidad y certificación en
sistemas de e-Salud, y en concreto en sistemas de HCE.
 E-Health-INTEROP (91): es un proyecto de la Unión europea que recoge las
directrices impuestas en el Mandato 403 (M/403) (92) para la estandarización de
la e-Salud en Europa, proporcionando un conjunto de estándares consistentes
que sean capaces de suplir las actuales y futuras necesidades de estos sistemas.
 Clinical E-Science Framework (CLEF) (83): Es un proyecto dedicado a
establecer una infraestructura técnica y metodológica para la investigación
clínica y bio-científica mediante el desarrollo de repositorios, seguros e
interoperables, de información obtenida de los registros sanitarios de pacientes.
40
Fig. 1.2-1. Principales inciativas y proyectos de HCE.
 European patient Smart Open Services (epSOS) Project (94): es un
proyecto financiado por el programa CIP, que involucra a 27 organizaciones
(Ministerios de Sanidad, Centros competentes, etc.) de 12 países. Su objetivo es
desarrollar herramientas que permitan el acceso seguro a la información de
salud del paciente, especialmente a resúmenes clínicos y a la prescripción
electrónica.
 Call for Interoperability (CALLIOPE) (95): Es una red temática que engloba
a 28 instituciones de 16 países, entre las que se pueden destacar algunas como
IHE Europe, Continua Health Alliance o Institute of Communication and
Computer Systems (ICCS). Su función es dar soporte a la co-ordinación y a la
implementación.
 European Health Telematics Association (EHTEL) (96): compuesta por 55
instituciones de varios países colabora activamente con asociaciones de
hospitales (European Hospital and Healthcare Federation (HOPE), European
Health Management Association (EHMA)), instituciones de seguros
(Association Insurance Management (AIM)), Doctores (Comite Permanent Des
Medecins Europeens (CPME), Union Européenne des Médecins Spécialistes
(UEMS)), Farmacia(Pharmaceutical Group of the European Union (PGEU), European Association of Hospital Pharmacists (EAHP)), enfermería (European
Federation of Nurses (EFN)), pacientes y ciudadanos (AGE Platform, European
Patients’ Forum), como instituciones dedicadas a la certificación. (European
Society for Quality Healthcare (ESQH), EuroRec) para ser una red que cree
confianza y coherencia entre todas las partes implicadas en la e-Salud.
Todas estas iniciativas son el ejemplo claro de la necesidad de coordinación a
nivel internacional para conseguir una HCE interoperable, y la apuesta clara por
un desarrollo basado en normas y estándares.
41
Bloque 1:
1.2.2. Situación en España
El sistema sanitario español actual tiene su origen en la ley de General de la
Sanidad (1983) mediante la cual fue instaurado, integrando diferentes subsistemas
públicos sanitarios. Su finalidad es, según el artículo 1, "la regulación general de
todas las acciones que permitan hacer efectivo el derecho a la protección de la salud
reconocido en el artículo 43 (97) y concordantes de la Constitución". El Servicio
Nacional de Salud (SNS) se basa en el principio de que toda persona tiene derecho
a la salud, independientemente de su situación económica y laboral. Para
favorecer la efectividad del SNS, este está basado en una serie de principios como
son:
 Universalización de la atención. Cubre al 100% de la población,
independientemente de su situación económica y de su afiliación a la seguridad
social.
 Accesibilidad y desconcentración. Para garantizar la equidad en el acceso a
los servicios se ha instrumentalizado la regionalización sanitaria, basada en
situar los diferentes servicios sanitarios lo más cerca posible de donde vive y
trabaja la población. Se trata así de reducir la concentración de centros
sanitarios en los núcleos urbanos.
 Descentralización. En la actualidad se tiende a descentralizar la gestión de los
recursos sanitarios; para ello se emprendieron unas reformas en la organización
del sistema sanitario, con el fin de asegurar una mayor capacidad de respuesta
por parte de los servicios y de los profesionales a las necesidades y aspiraciones
de los ciudadanos. Se tiende a implicar a la comunidad en la toma de decisiones
sobre la gestión del gasto y en el modo de utilización de los servicios. (ver Fig.
1.2-2;Tabla 1.2-3)
 Atención Primaria. En el servicio nacional de salud, la base de la atención
sanitaria es la atención primaria de salud y actualmente hay definido un marco
estratégico para su mejora, de 5 años de duración (84)
Comunidad
Andalucía
Aragón
Asturias
Baleares
Canarias
Cantabria
Castilla La Mancha
Castilla y León
Cataluña
Extremadura
Galicia
La Rioja
Madrid
Murcia
Navarra
País Vasco
Valencia
Ceuta y Melilla
Nombre del servicio
Servicio Andaluz de Salud
Servicio Aragonés de Salud
Servicio de Salud del Principado de Asturias
Servei de Salut de les Illes Balears
Servicio Canario de Salud
Servicio Cántabro de Salud
Servicio de Salud de Castilla La Mancha
Sanidad de Castilla y Leon
Institut Català de la Salut
Servicio Extremeño de Salud
Servizo Galego de Saúde
Servicio Riojano de Salud
Servicio Madrileño de Salud
Servicio Murciano de Salud
Servicio Navarro de Salud
Servicio Vasco de Salud
Agència Valenciana de Salud
Instituto Nacional de Gestión Sanitaria
SAS
SALUD
SESPA
IB-SALUT
SCS
SCS
SESCAM
SACYL
ICS
SES
SERGAS
SERIS
SERMAS
SMS
OSASUNBIDEA
OSAKIDETZA
AVS
INGESA
Tabla 1.2-3. Relación de Servicios autonómicos de salud.
42
(99)
(100)
(101)
(102)
(103)
(104)
(105)
(106)
(107)
(108)
(109)
(110)
(111)
(112)
(113)
(114)
(115)
(116)
Fig. 1.2-2. Descentralización del SNS.
Sin embargo, aunque la descentralización de la sanidad haya favorecido un
incremento de la efectividad y un mejor aprovechamiento de los recursos
dependiendo de las características de cada región (incrementando el número de
camas hospitalarias en regiones más envejecidas, por ejemplo) también se presenta
como un elemento des-normalizador a efectos de interoperalidad, puesto que cada
Comunidad Autónoma puede adoptar las políticas que considere más adecuadas.
Un reflejo de esta situación lo encontramos en la inversión en TICs realizada por
las diferentes CCAA (117), tal y como se muestra en la Fig. 1.2-3.
Fig. 1.2-3. Inversión y Madurez en las TICs sanitarias por comunidades.
43
Bloque 1:
Fig. 1.2-4. Posición relativa de las CCAA en desarrollo de sus sistemas de e-Salud.
Por lo tanto son los Servicios de Salud Autonómicos los encargados de proponer
y ejecutar las directrices generales en política de Salud, planificación y asistencia
sanitaria y de consumo en cada una de las comunidades, quedando el Ministerio de
Sanidad y Política Social como un elemento coordinador entre ellas. De este modo,
son comprensibles las diferentes velocidades encontradas en materia de e-Salud,
como se puede ver en la Fig. 1.2-4, entre los que podemos destacar algunos por la
relevancia que han adquirido, en el ámbito nacional como internacional: Diraya en
en el SAS, Jara en el SES, IANUS en el SERGAS, H3C en el ICS, etc.
A pesar de esta libertad en las apuestas por diferentes proyectos y políticas,
algunos proyectos (118) aparecen como comunes como son la receta electrónica (ver
Fig. 1.2-5), la HCE (ver Fig. 1.2-6) o la cita por internet (ver Fig. 1.2-7).
Fig. 1.2-5. Evolución de la implantación de la receta electrónica en España.
44
Fig. 1.2-6. Evolución de la implantación de la HCE de AP en España.
Fig. 1.2-7. Evolución de la implantación de la cita on-line en España.
Uno de los proyectos actuales del MSPS es la coordinación del proyecto de
HCDSNS, que ya se ha citado anteriormente: En un escenario donde la movilidad
de los ciudadanos va en aumento, cada vez es más probable que un usuario del SNS
necesite ser atendido fuera de su comunidad autónoma pero, gracias a este
proyecto se pretende garantizar el acceso a datos clínicos, los propios o de las
personas a las que represente, de manera telemática. Un ejemplo de esta
tendencia puede verse en el SCS, donde se ha desarrollado una herramienta
denominada Drago-AP (119) para la HCE de AP y a la cual pueden acceder los
pacientes mediante Drago-WEB (120). Para el acceso por parte de los profesionales
sanitarios se utilizará una política de certificados digitales y la clasificación en
roles funcionales dependiendo de la actividad que cada profesional desarrolle, lo
que se presenta como un claro reflejo de lo que la norma EN13606 en su parte de
seguridad establece, donde se define una tabla de verdad de doble entrada para el
acceso a datos. También se contempla que un paciente pueda comportarse como un
auditor externo y sea capaz de conocer quién ha accedido a sus datos médicos o a
los de las personas que representa.
45
Bloque 1:
El proyecto de HCDSNS establece una serie de documentos que conformarán la
Historia Clínica Digital (121) (ver Anexo como lo son Historia clínica Resumida,
Informe Clínico de Alta, Informe Clínico de Consulta Externa, Informe Clínico de
Urgencias, Informe Clínico de Atención Primaria, Informe de Cuidados de
Enfermería, Informe de Resultados de pruebas de imagen, Informe de Resultados
de pruebas de laboratorio y el Informe de Resultados de otras pruebas diagnósticas.
Todos ellos presentan una estructura similar entre sí salvo en los apartados de
sesión clínica donde el contenido se adapta al tipo de informe del que se esté
hablando. Para consensuar el contenido de estos informes se han establecido 7
grupos de trabajo en los que han participado 27 sociedades que representaban a las
principales especialidades médicas en España y 12 expertos con perfiles de tipo
institucional como gestores de centros y expertos en admisión y documentación
clínica.
Para conseguir interoperabilidad técnica se ha seguido una política de uso de
estándares y modelos normalizados, como la especificación del intercambio de datos
mediante XML, la adopción de HL7 CDA nivel 1 en la cabecera del documento, la
utilización del modelo de referencia del 13606 ó HL7 V3 RIM, la recomendación de
diversos formatos para la transmisión (DICOM para imagen, PDF para
documentos, etc.), la adopción de determinados sistemas de codificación como puede
ser el sistema de codificación del INE para ámbitos geográficos (CCAA, provincia,
etc..) o aquellos que nos permitan identificar de manera univoca a pacientes y a
profesionales sanitarios. (122)
Limitándonos exclusivamente a un plano más semántico de la solución, para
conseguir interoperabilidad semántica se ha decidido adoptar como terminología
clínica de referencia SNOMED-CT. Esto permitirá la representación del contenido
de documentos clínicos para su interpretación automática e inequívoca entre
sistemas distintos de forma precisa y entre diferentes idiomas. Así la información
clínica adquirida en un Centro Sanitario en el País Vasco en euskera podrá ser
decodificada fácilmente, traducida y podrá mostrarse en otro Centro Sanitario de
otra comunidad autónoma en otro idioma como por ejemplo, en un Centro Sanitario
en Cataluña en catalán. Sin embargo, para poder llevar a cabo esto se deberá
traducir el núcleo de SNOMED-CT, el cual solo se distribuye en inglés y españolargentino a las diferentes lenguas oficiales que concurren en el estado español.
Además no se utiliza sólo SNOMED- CT como terminología de referencia, sino que
en determinados informes se hace uso de NANDA, LOINC o CIE-9-MC.
El uso generalizado desde SNOMED-CT como terminología clínica de referencia
es posible gracias a la reciente inscripción de España como miembro de la IHTSDO,
organización que posee los derechos de SNOMED-CT y se encarga de su
explotación. (123) El uso de esta terminología no es inmediato, pues solo se
distribuye en inglés y una versión del español Argentina, por lo que habrá que
validar aquellos términos no comunes al español hablado en España.
La plataforma donde se desarrolla esta iniciativa es un piloto en el que
participan 10 CCAA, y dentro de cada comunidad autónoma, se designa al menos
un centro hospitalario de referencia, una selección de centros de salud y una serie
de profesionales sanitarios (facultativos y enfermería). (124)
46
Otro de los proyectos que se están llevando a cabo es el proyecto Nomenclator
Digitalis (125) cuyo objeto es identificar la composición para todos los productos
farmaceuticos e incluir, de forma generalizada, la información necesaria para
incorporar un parámetro adecuado de medida, como puede ser la Dosis Diaria
Definida (DDD), para mejorar las unidades de medición tradicionales como han
sido han sido el importe, las recetas y, en algunos casos, el número de envases
consumidos. Este proyecto tiene gran importancia, sobre todo en un sistema
reactivo como es el sanitario español que se basa fundamentamente en la
farmacología. Este nomenclátor, que toma como base su análogo para la
facturación, determina cada fármaco a través de los siguientes parámetros:







Principio activo, codificado de acuerdo a al ATC
Valor de la DDD
Dosis (nº de mg, UI, etc.)
Unidad en la que se expresa la Dosis (codificada)
Contenido o tamaño del envase (nº de comprimidos, etc.)
Forma farmacéutica (codificada)
Vía de administración (codificada)
Esta definición, establecida por el Agencia Española de Medicamentos y
Productos Sanitarios (AEMPS) se encuentra en la línea definida por el Individual
Case Safety Reports (ICSR) en el documento preENV 27953 de farmacovigilancia y
el (Identification of Medicinal Products) IDPM que posee 5 items de trabajo: el
ISO/CD 11238, ISO/CD 11239, ISO/CD 11240, ISO/CD 11595 y ISO/CD el 11616
(106).
Así, las líneas estratégicas tanto a nivel europeo como nacional presentan una
cierta concordancia: receta electrónica, medicación y transmisión interoperable de
información clínica. En cuanto a la legislación en la HC es difícil de tratar de una
manera general puesto que está supeditado a las disposiciones de cada país. En el
ámbito español encontramos varios puntos específicos que se deben cumplir:  Esquema nacional de interoperabilidad (127), cuyo objetivo es la creación
de las condiciones necesarias para garantizar el adecuado nivel de
interoperabilidad técnica, semántica y organizativa de los sistemas y
aplicaciones empleados por las Administraciones públicas, que permita el
ejercicio de derechos y el cumplimiento de deberes a través del acceso electrónico
a los servicios públicos, a la vez que redunda en beneficio de la eficacia y la
eficiencia.
 Esquema nacional de seguridad (128), el cual está constituido por los
principios básicos y requisitos mínimos requeridos para una protección adecuada
de la información. Será aplicado por las Administraciones públicas para
asegurar el acceso, integridad, disponibilidad, autenticidad, confidencialidad,
trazabilidad y conservación de los datos, informaciones y servicios utilizados.
 Ley Orgánica de Protección de Datos (LOPD) (129), tiene por objeto
garantizar y proteger, en lo que concierne al tratamiento de los datos personales,
las libertades públicas y los derechos fundamentales de las personas físicas, y
especialmente de su honor, intimidad y privacidad personal y familiar. Su
objetivo principal es regular el tratamiento de los datos y ficheros, de carácter
personal, independientemente del soporte en el cual sean tratados, los derechos
de los ciudadanos sobre ellos y las obligaciones de aquellos que los crean o
tratan.
47
Bloque 1:
1.2.3. Futuro de los sistemas de Salud
Durante muchísimo tiempo la esperanza de vida en un país o sociedad ha sido
uno de los factores clave para determinar su grado de desarrollo junto con otros
como el Producto Interior Bruto (PIB). Entre ellos podemos citar el Índice de
Desarrollo Humano (IDH) elaborado por el Programa de Naciones Unidas para el
Desarrollo (PNUD) o incluso los cinco puntos fijados como prioridades en el taller
de trabajo de Kelburn en Junio de 1996 por el International Development Research
Centre (IDCR).
Sin embargo en una lectura más exhaustiva se hace patente el factor salud en
esa catalogación con expresiones como “salud y bienestar físico” o “vida larga y
saludable”: La necesidad de una buena salud para disfrutar de esa mayor
esperanza de vida que los cambios sociales y avances sanitarios nos ofrecen es
innegable.
Recurriendo a la definición de la OMS de salud que la define como “Estado de
completo bienestar físico, mental y social y no solamente la ausencia de
enfermedad” se puede llegar a inferir en la gran variabilidad de factores que
afectan a nuestra salud tanto los meramente biológicos (factores genéticos,
envejecimiento, etc) como los ambientales (clima, culturales, etc.) o simplemente el
estilo de vida actual. El concepto de Salud no puede tomarse como algo estático o
general, sino que es algo particular de cada individuo y susceptible a múltiples
factores. El hecho de asociar solamente la salud a los sistemas de asistencia
sanitaria limita en gran medida la concepción de salud.
Muchos han sido los cambios que ha experimentado nuestra sociedad en las
últimas décadas o incluso en los últimos años: una mayor difusión del conocimiento
sanitario, avances tecnológicos de aplicación tanto en el ámbito sanitario (nuevas
técnicas diagnosticas, nuevo instrumental, nuevas técnicas de curación, etc.) como
al social (mejores medios de comunicación, nuevos electrodomésticos, etc.), cambios
en los hábitos alimentarios y sanitarios, etc. La principal consecuencia de todos
estos cambios ha sido un aumento en la esperanza de vida de la sociedad
actual. Muchas son las referencias donde se hace gala de la inversión o del
estrechamiento de la pirámide poblacional en España (130) (131)(ver Anexo F),
por ejemplo, o en el resto de países desarrollados.
De forma paralela, y en parte como consecuencia de ese envejecimiento, se ha
producido un aumento del número de pacientes crónicos que requieren una
continuidad en el cuidado. Debido a fenómenos como la homeostasis, la aparición
de una enfermedad crónica puede conllevar un agravamiento de otras
enfermedades o incluso la aparición de otra enfermedad crónica. De este modo, el
perfil de paciente clave que se perfila en la sociedad no es aquel que posee una
única enfermedad sino que puede llegar a poseer una cierta variedad de
enfermedades, todas ellas relacionadas entre sí. (132) Todo ello supone un gran
costo económico para el sistema sanitario como personal para el propio paciente y
sus familiares.
Otra tendencia actual es la creciente preocupación por la salud personal: es el
Wellness, la necesidad de sentirte bien. No se busca simplemente la ausencia de
enfermedad sino un óptimo estado físico que permita afrontar de una manera más
holgada el cómoda estilo de vida.
48
Como consecuencia de estas situaciones se pueden identificar dos líneas de
control, una de ellas originada por la administración y otra originada por el propio
autocontrol del sujeto:
El control generado por la administración se centra en el control del gasto
sanitario. Los 2 modelos más influyentes internacionalmente en los últimos años
son el de la “pirámide de riesgo” (estratificación de riesgo) desarrollado por Kaiser
Permanente y el “modelo de cuidados de enfermedades crónicas” desarrollado por el
Mc Coll Institute en Seattle (EE.UU) (133).
 El modelo de la pirámide de riesgo identifica 3 niveles de intervención según el
nivel de complejidad del paciente y organiza a los pacientes según su riesgo. (ver
Fig. 1.2-8). Esto a su vez permite utilizar mejor los recursos humanos
concentrándolos sobre los grupos más complejos evitando así ingresos
hospitalarios costosos e innecesarios
 El modelo de cuidados de enfermedades crónicas es un marco organizativo para
coordinar la atención a enfermos crónicos en atención primaria. El modelo
conlleva una lógica poblacional y propone una serie de intervenciones que
permiten obtener mejores resultados clínicos y funcionales. (ver Fig. 1.2-9).
Nivel 3: Gestión de casos complejos.
Alta comorbilidad y alto uso de recursos
Nivel 2: Gestión de patologías.
Morbilidad intermedia y alto uso de recursos
Nivel 1: Apoyo a la autogestión.
Pacientes enfermos crónicos con buen
control de su enfermedad.
Fig. 1.2-8. Pirámide de Riesgo de Kaiser Permanente.
Sistema de Salud
Organización de Atención Sanitaria
Comunidad
recursos y
políticas
Autogestión
Paciente
Informado
Activo
Apoyo a la
Decisión
Diseño
sistema
presentación
Sistema de
Información
clínica
Interacciones productivas
Equipo de salud
Proactivo
Resultado clínicos y funcionales
Fig. 1.2-9. Modelo de cuidados de enfermedades crónicas.
49
Bloque 1:
En esta línea anterior de sistemas de autocontrol por parte del paciente han
surgido varias plataformas, muchas de ellas un marcado perfil comercial, cuyo
objetivo es el de ayudar a gestionar datos médicos a los usuarios, tanto los propios
como los de sus familiares. Son los denominados Personal Health Records (PHR),
documentos o sistemas de gestión de registros donde una persona puede centralizar
datos médicos: toma habitual de algún signo vital, relación de alergias, almacenaje
de alguna prueba de imagen, etc. Entre los más conocidos se pueden encontrar
Microsoft Health Vault (134), Google Health™ (135) o Dossia (136), todos ellos con
múltiples funciones y capacidades similares.
En estas plataformas ofrecen la posibilidad de interactuar directamente con
ellas, mediante el uso de interfaces de programación (Application Programming
Interface, API) o mediante aplicaciones específicas como el Connection Center de
Microsoft (137). Estas soluciones de comunicación son propietarias, y por lo tanto
no interoperables, disyuntiva que también se puede solucionar mediante la
implementación de sistemas de comunicación basadas en el estándar X73, un
estándar para el intercambio interoperable de información de dispositivos médicos.
(Ver Anexo E)
Una variante de esta tendencia es el uso de Portable PHR, dispositivos llevables
en los que se pueden almacenar datos clínicos en diferentes aplicaciones como
MyLifeRecord (138) para iPhone, Mac o PC, HealthFrame™ (139) para iPod,
dispositivos con conectividad USB como Vital Key (140).
Entre estos elementos están empezando a aparecer sinergias como las que
podemos encontrar como el proyecto Travelers EHR Template (TrEHRT) (141)
mediante el cual podemos poseer un resumen de nuestros datos de salud. Este
programa permite exportar archivos que siguen la especificación ASTM E2369
para la continuidad de cuidado (Continuity of Care Records, CCR) (142). Esto
puede ser el inicio de un nuevo paradigma de interoperabilidad, en el que se
produzcan interacciones entre centros sanitarios, PHRs y portables PHR. (Ver Fig.
1.2-10)
Fig. 1.2-10. Paradigma de interoperabilidad.
50
Los PHRs constituyen, por lo tanto, una valiosa fuente de información para la
continuidad de cuidado, puesto que se elimina la necesidad de acudir al centro de
salud y se implica el propio paciente en su cuidado personal concediéndole una
mayor autonomía, con los beneficios psicológicos que ello conlleva. Esa información
debería poder ser re-aprovechada para el diagnostico clínico pero, una vez más,
encontramos el problema de la comunicación.
Conclusiones…
Los sistemas sanitarios son sistemas vivos, que deben adaptarse a la sociedad a
la que sirven, y cambios en esa sociedad deben provocar cambios en el sistema
sanitario. Nuestra sociedad está sufriendo un proceso de envejecimiento progresivo
y al igual que las patologías con mayor morbilidad. Las enfermedades con una
mayor prevalencia son las crónicas: lo común hoy en día no es morir de una
enfermedad, sino morir enfermo. Y así como la concepción de la medicina y la HC
ha ido variando con el paso del tiempo, ahora también deberá volver a cambiar
hacía un modelo mas proactivo, pues el continuar con un modelo reactivo
conllevará un coste inviable.
Estos son los principales motivos del cambio de paradigma de un modelo de
sistema sanitario centrado en el paciente a un modelo centrado en el ciudadano, en
el que se prioriza la telemedicina y el seguimiento del paciente crónico. Para el
seguimiento de un paciente crónico, solo es necesaria la monitorización de
determinados signos vitales, pues una alteración de esos signos vitales puede ser
indicio suficiente de un episodio de enfermedad.
La situación presente es, por lo tanto, paradójica puesto que esas medidas que
complementarían las realizadas en el centro sanitario ya existen, o al menos existe
la capacidad de adquirirlas remotamente desde dispositivos médicos. No es un
problema cultural, sino tecnológico de cómo comunicar esos resultados al centro
sanitario pertinente.
Sin embargo, la transmisión de información entre sistemas independientes no es
algo trivial y podría ser comparable a mantener una conversación con el que se
desconoce el interlocutor: es necesario fijar una serie de cuestiones para llegar a un
entendimiento pleno: un soporte a la comunicación entendible por ambas partes,
una estructura sintáctica común a ambas partes y un idioma o jerga en concreto.
Transmitiendo la información mediante tecnologías middleware (soporte de la
comunicación), solo resta establecer qué estructura se usará (reglas sintácticas) y
qué lenguaje en concreto (idioma). La única manera de lograrlo es mediante el uso
de estándares y normas para la integridad sintáctica y la codificación de la
información mediante terminología médica u otros sistemas de que permitirá
establecer un marco común para conseguir interoperabilidad semántica total,
temas en los que se está trabajando a nivel nacional, europeo e internacional.
51
Bloque 1:
52
Bloque 2
Implementación de la
arquitectura cliente/servidor
para interoperabilidad de HCE
2.1 Servidor de HCE. Primera Implementación
2.2 Arquitectura cliente/servidor de HCE. Segunda
implementación
2.3 Diseño e implementación del “standard approach”
CE2EHR
2. Servidor de HCE. Primera Implementación En este segundo bloque, con el apoyo opcional de varios anexos, se describirá el proceso
metodológico aplicado a la implementación de la solución: el estudio de los documentos
necesarios (norma, estándares, especificaciones técnicas, etc.), así como un estudio de
aplicación y armonización entre ellas, las consideraciones realizadas en el diseño de la
solución, el uso de arquetipos como herramienta para lograr la integridad semántica, la
definición de una lógica global de implementación mediante funciones modulares y su
posterior evolución a una arquitectura multicapa. Finalmente, se expone el diseño e
implementación de una propuesta de modelo de comunicación entre el CE y el MS
utilizando una metodología análoga a la utilizada en la implementación del servidor de
HCE.
53
Bloque 2:
54
Implementación de la arquitectura cliente/servidor para la
interoperabilidad de HCE
En este capítulo se va a describir, mediante el apoyo opcional a los diferentes
anexos, el proceso seguido en la implementación del servidor de monitorización, el
cual se presenta como clave en este proyecto pues ejercerá las funciones tanto de
adquisición de datos remotos (E2ESHP) como de envío a un sistema sanitario
(UNE-EN/ISO 13606). Una representación del flujo de información puede ver ese
en la Fig. 2-1
X73
MDs
UNE-EN/ISO 13606
E2ESHP
CEs
MS
Historial
Clínico
Electrónico
Sistema
Sanitario
Fig. 2-1 Esquema general del proyecto
En dicha figura se puede ver como la adquisición de datos biomédicos se realiza
mediante el estándar X73 en aquellos dispositivos médicos que así lo implementen.
Si un determinado dispositivo no lo implementase necesitaría un adaptador. Una
vez los datos han sido adquiridos en el CE, se construye una instancia de
documento XML y se envía al MS. Una vez llegados a ese punto, el servidor se
encargará de decodificarlos para incorporarlos a su arquitectura. Y del mismo modo
que se encarga de la recepción de datos por parte del CE, se encargará de la
respuesta a las peticiones de HCE conforme lo que la norma establece.
En este capítulo se presentan dos implementaciones distintas del servidor, cada
una de ellas válida en un instante temporal diferente. En la primera
implementación del servidor se siguió la norma al pie de la letra en el sentido más
riguroso y se utilizó como tipo de datos la especificación técnica (TS14796). En la
segunda implementación, y debido al avanzado estado en el que se encuentra el
draft de ISO ISO/DIS 21090, se opto por robustecer la implementación para que
pudiera hacer frente a este nuevo conjunto de datos.
55
Bloque 2:
2.1. Servidor de HCE. Primera Implementación
Para la consecución de esta primera implementación, fue necesario un gran esfuerzo en cuanto a la asimilación de conceptos pues la norma no específica guía o lenguaje de implementación y, en especial, no impone ningún sistema de almacenamiento de la información. La translación de los diferentes requisitos que la norma posee a especificaciones reales es interpretación del autor. 2.1.1. Estudio de los estándares UNE-EN/ISO 13606 e ISO/IEEE
11073
Como paso previo a la toma de ninguna decisión se realizó un estudio de las
instancias que componen el modelo de referencia, especialmente de aquellas que
poseen un carácter más clínico que de auditoría y seguridad. Una representación
conceptual de la estructura de un extracto de HCE puede verse en la Fig. 2.1-1,
donde se pueden identificar cada uno de los bloques lógicos encargados de
transmitir la información médica (Extract, Folder, Composition, Section, Entry,
Cluster y Element). Dado que la norma no establece restricción alguna en la forma
en que los datos se almacenan en un determinado sistema, y al poseer la libertad
de desarrollar un sistema desde cero se optó por un diseño de almacenamiento,
basado en bases de datos relacionales, que siguiera una organización similar.
Para la definición del número de tablas que compondrían la base de datos
relacional se realizó un estudio comparativo entre UNE-EN/ISO 13606 e ISO/IEEE
11073, el cual se puede observar en profundidad en el Anexo G, en el que se
identificaron aquellos campos de obligada transmisión en un extracto de HCE y
otros que, aunque carecen de esa obligatoriedad, ayudarán a la adecuada
comprensión del extracto. Una síntesis de ese estudio puede verse en la Tabla
2.1-1, en la cual se especifican por bloques (que se corresponden con las respectivas
clases del RM) nombre del atributo, clase a la que corresponde, obligatoriedad (en
su caso) y de donde extraer ese valor. Para su completa comprensión se puede
encontrar una relación de los principales tipos de datos definidos según TS14796, y
su función en la Tabla 2.1-2.
Fig. 2.1-1. Representación conceptual de un extracto de HCE.
56
EHR_EXTRACT
ehr_id
ehr_system
rm_id
subject_of_care
time_created
II
II
String
II
TS
Obligatorio
Obligatorio
Obligatorio
Obligatorio
Obligatorio
Se creará en el momento de la construcción
Valores constantes para ese sistema.
Valor constante
*
Se creará en el momento de la construcción
COMPOSITION name TEXT
rc_id
II
synthesised Boolean
II
committer
II
ehr_system
ehr_id
II
TS
time_committed
Obligatorio
Obligatorio
Obligatorio
Obligatorio
Obligatorio
Obligatorio
Obligatorio
Se creará en el momento de la recepción
Valor constante= FALSE
Identificación del dispositivos
Constante para un mismo sistema de salud
Coincide con ehr_system (principio cadena)
ENTRY archetype_id
II
meaning
CV
name TEXT
II
rc_id
synthesised Boolean
uncertain_expressed Bolean
Opcional
Opcional
Obligatorio
Obligatorio
Obligatorio
Obligatorio
Se determinará en la recepción
CLUSTER meaning
CV
name TEXT
obs_time IVL<TS>
II
rc_id
synthesised Boolean
CS
structure_type
Opcional
Obligatorio
Opcional
Obligatorio
Obligatorio
Obligatorio
Se obtendrá del dispositivo
Valor constante= STRC01
ELEMENT
meaning
CV
name TEXT
II
rc_id
synthesised Boolean
[Data
value
Value]
Opcional
Obligatorio
Obligatorio
Obligatorio
Obligatorio
Se creará en el momento de la recepción y se
obtendrá del dispositivo
Tabla 2.1-1. Atributos de obligatorios o relevantes en Telemedicina.
Tipo dato
Función
Code Simple Value
Coded Value
Encapsulated Data
Instance Identifier
CS
CV
ED
II
Codificación simple de un dato.
Codificación de un dato.
Soporte datos multimedia.
Identificación única de instancias.
Point Time
TS
Determinar un instante temporal.
IVL_TS
Determinar un intérvalo temporal.
Point Time Interval
Tabla 2.1-2. Principales tipos de datos según TS14796 .
57
Bloque 2:
Estas consideraciones han sido de gran utilidad a la hora, tanto de diseñar un
sistema de almacenamiento de información como de diseñar las rutinas propias
para la generación del extracto.
2.1.2. Consideraciones en la toma de datos telemáticos
El carácter remoto que adquiere la toma de las medidas que no se realizan en
presencia de ningún profesional sanitario conlleva ciertas decisiones de diseño que
habrá que definir a la hora de incluir estas en la historia clínica. El principio por el
que se regirán estas decisiones será el de máxima sencillez, por lo tanto se
descartará el uso de algunos componentes del Modelo de Referencia que no aportan
significación clínica, como con Folder y Section, cuya función es primordialmente
organizativa.
La primera pregunta que cabría preguntarse desde un punto de vista de diseño
es qué es lo que va a considerarse una composición. El criterio seguido para
determinar esa cuestión es el análogo al que se seguiría en caso que la toma de
medidas se realizara mediante dispositivos que no cumplieran el estándar X73: en
ese caso, la lógica nos dicta que dichas medidas se anotarían en un “papel” y cada
cierto tiempo se notificarían al médico de cabecera o a quién se considerara
pertinente. En nuestro caso, el papel es el CE y el momento de notificar las
medidas al médico sería el envío del XML al MS. Por lo tanto, se considerará una
composición toda la información recibida de un mismo paciente en una notificación.
Así mismo cabría plantearse otros factores ajenos al diseño de la solución pero
que podrían llegar a condicionar el funcionamiento del sistema, como puede ser
fallos tecnológicos que mermen la conectividad del dispositivo y que por tanto
provoquen que la toma de la medida no coincida en tiempo con la creación de una
nueva Composition. Por lo tanto se tomará como criterio de diseño la adquisición
del instante temporal en el que haya tomado cualquier medida.
2.1.3. Diseño de arquetipos primarios
Una de las principales características de la norma EN 13606 es la separación
entre información y conocimiento. Mientras que la información queda soportada
por el modelo de referencia, la vía para representar el conocimiento es mediante
arquetipos. Los arquetipos son modelos formales de los conceptos del dominio (p.ej.
informe de alta, medida de la presión arterial, orden de tratamiento, etc.) creados
mediante restricciones al modelo de referencia y que permiten compartir dichos
conceptos entre los interlocutores. Poseen un lenguaje de definición propio, el
Archetype Description Languge (ADL) que actualmente se encuentra en su versión
1.4. (Ver Anexo H)
Los arquetipos, entre otras atribuciones, permiten la definición de un mismo
concepto en varios idiomas, lo que permitiría superar las barreras del lenguaje, y
podría establecer asociaciones con determinadas codificaciones como lo son las
terminologías médicas (SNOMED-CT, LOINC, etc.)
Aunque la norma, en su flexibilidad, permite la transmisión de entidades que no
se correspondan a ningún arquetipo en concreto la omisión de la definición de una
manera tan específica de un concepto se consideró una forma de desaprovechar una
de las herramientas más robustas que la norma define para lograr integridad
semántica.
58
Por ello que se decidió arquetipar aquellos conceptos que iban a ser transmitidos
desde el CE. Las medidas para las que se han realizado arquetipos corresponden
con algunas para las que el dispositivo encargado de su captura posee
especificación en el estándar X73: peso, glucometría, temperatura, pulso, tensión
arterial y oximetría. Además, aunque no existe una especificación formal para ello
y como valor añadido, se diseño un arquetipo para la transmisión de ECGs cuyo
formato en video nos permitiría el uso de ED. Los arquetipos diseñados se pueden
ver en el Anexo H.
Para la edición de arquetipos se ha utilizado una herramienta específica
opensource desarrollada por el grupo de informática biomédica (IBIME)
perteneciente al Instituto de Aplicaciones de las Tecnologías de la Información y de
las Comunicaciones Avanzadas (ITACA) perteneciente a la Universidad Politécnica
de Valencia (UPV) denominada LINKEHR-Ed. (143)
2.1.4. Arquitectura inicial del servidor de HCE
EN13606 establece en su parte quinta las interfaces que rigen el modelo de
intercambio. En este proyecto, y a partir de la especificación de todos los
parámetros bajo los que se pide la información clínica, se ha implementado una
arquitectura Web Services (WS). WS podría definirse como un conjunto de
aplicaciones o tecnologías con capacidad para interoperar en la web,
intercambiando datos con la finalidad de ofrecer servicios. Los proveedores ofrecen
servicios como procedimientos remotos y los usuarios solicitan un servicio llamando
a estos procedimientos a través de la web. Las tecnologías que intervienen en esta
comunicación son: Simple Object Access Protocol (SOAP), basado en eXtensible
Markup Language (XML) que proporciona un mecanismo estándar de envío de
mensajes, y el lenguaje de descripción de servicios web (Web Services Description
Language, WSDL) que especifica sintaxis y mecanismos de intercambio de estos
mensajes.
La tecnología de desarrollo de WS ha sido C# de la plataforma dotNet, por lo que
será necesario un servidor Internet Information Server (IIS) de páginas web
dinámicas ASP.Net. Siguiendo la misma metodología de trabajo se podrían
desarrollar WS que cumpliesen la misma función en Java, aunque en este caso
sería necesario un entorno de desarrollo como Axis2 y un contenedor de servlets
como Apache Tomcat. La única diferencia entre estas dos posibles soluciones es la
clase de datos que WS admite como entrada: las entradas de WS en Java han de
cumplir la especificación Java API for XML Remote Procedure Call (JAX-RPC-1), y
dada la complejidad y el número variable en los parámetros de entrada, la
posibilidad de tener una herramienta que admita datos estructurados como
entrada puede resultar muy útil para dar servicio homogéneo a clientes que
soporten clases como parámetros de entrada. Es por ello que se ha tomado como
base una tecnología dotNet: a partir de una simple definición de clases en el cliente
del WS, la posibilidad de duplicar dicho servicio para que admita como entrada
datos estructurados facilitaría la decodificación de estos parámetros.
59
Bloque 2:
Fig. 2.2-1. Diagrama Funcional de la solución.
La implementación de la solución se ha dividido en dos partes:
 La lógica de acceso a datos, que contiene los mecanismos de comunicación con la
base de datos.
 El núcleo de funcionamiento, donde a partir de los datos proporcionados por la
primera capa es la encargada de construir el extracto a partir de técnicas
iterativas.
El esquema global de la implementación se muestra en la Fig. 2.2-1. A partir de
una petición EN13606 de HCE desde el cliente con una serie de parámetros
elegidos, el servidor obtiene dichos parámetros y, en función de ellos, identifica las
Compositions que cumplen los requisitos de la petición. Una vez determinadas, y
tras completar la cabecera (GenerateHeaderEHR), se añaden dichas Compositions
(GenerateComposition) para generar el extracto HCE (GenerateExtract) que será
devuelto al cliente. Las funciones que realizan este proceso son:
 ProcessAdditionalInputParameters. Encargado de procesar los posibles datos de
entrada que aumenten / limiten el numero de compositions solicitadas en la
petición (EN13606 request).
 IIFiller. Genera un Instance Identifier (tipo de datos perteneciente al conjunto de
datos propuesto por CEN (CEN data types) para el intercambio de Datos Clínicos
según la especificación TS14796 ).
 GenerateComposition. Crea una Composition.
 GenerateEntry. Crea un Entry.
 GenerateQuantityElement. Crea un elemento, en cuya propiedad value contiene
un dato del tipo Physical Quantity (PQ), de CEN data types.
 GenerateEncapsulatedElement. Crea un elemento, en cuya propiedad value
contiene un dato del tipo Encapsulated Data (ED), de CEN data types.
 GenerateCluster. Crea un Cluster.
 GenerateElementCluster. Crea un Element perteneciente a un Cluster.
 GenerateClinicMeaning. Obtiene un Coded Value (CV) que permite realizar una
asociación entre los términos que se transmiten con repositorios de terminología
clínica (SNOMED-CT, Thesaurus).
60
 GenerateMediaTypeCode. Obtiene un CV que permite determinar el tipo de datos
que contiene el dato encapsulado.
 GenerateCompressionCode. Obtiene un CV que permite saber bajo qué código de
compresión están los datos almacenados.
 GenerateIntegrityAlgorithmCode. Obtiene un CV que permite identificar el
algoritmo utilizado al generar la firma de dato encapsulado para comprobar la
integridad de este en la transmisión.
2.1.5. Pruebas.
En cualquier proyecto que contenga unaparte de implementación, la necesidad
de corrobar el correcto comportamiento se convierte en imperiosa. En nuestro caso,
tras la implementación se ha realizado un proceso de depuración realizando
pruebas tanto de “caja negra” como de “caja blanca” para asegurarnos del correcto
comportamiento de la aplicación implementada. Para ello se ha hecho uso de un
cliente web, implementado ex profeso y que posteriormente ha adquirido
atribuciones de demostrador. La Fig. 2.1-2 representa una composición de la
aplicación implementada, pero se puede encontrar una descripción más detallada
en el Anexo I.
Respuesta Petición de extracto Usabilidad Pantalla de Login Decodificación Ayudas Validación Arquetipos Documentación Fig. 2.1-2. Aplicación cliente. Pruebas.
61
Bloque 2:
2.2. Arquitectura cliente/servidor HCE. Segunda
Implementación
En esta segunda implementación se ha robustecido el servidor, optimizando su
rendimiento y re-implementando algunas de las funciones que conforman el núcleo
de la aplicación, de forma que estas han adquirido un carácter más abstracto y por
lo tanto más re-usable. Además, se ha adaptado el servidor para que sea capaz de
soportar el nuevo conjunto de datos para la transmisión de información médica, y
armonizado entre CEN y HL7. Esta segunda implementación ha sido la utilizada
como base para la realización de gran parte de las prácticas médicas.
2.2.1. Estudio del nuevo formato de datos
El primer paso realizado en el proceso de adaptación del servidor de HCE fue un
estudio comparativo entre las especificaciones TS14796 y ISO/DIS 21090. Como se
puede ver en la Fig. 2.2-1, independientemente de la herencia entre tipos de datos
(tanto para establecer una nueva rama de los mismos como para definir uno más
específico) el número de clases definidas ha aumentado considerablemente. De
hecho, se puede advertir un gran esfuerzo en la definición de las clases de datos
que dan soporte a texto estructurado. Esto representa sin duda un gran intento
para lograr dar soporte a la transmisión de los distintos documentos clínicos que se
almacenaban como texto en claro. Del mismo modo, se puede observar que los data
types ya no provienen de la clase abstracta DATA_VALUE sino de ANY, de la que
derivan el resto de clases que, a su vez, deriva de HXIT. Además, en ANY también
se puede encontrar el atributo null_flavour que sirve para determinar por qué un
determinado registro se encuentra vacío. Se detalla a continuación una
comparativa de los data types más utilizados:
 Instance Identifier (II), fundamental en la identificación univoca de registros,
dispositivos, personas, etc. El número de atributos se incrementa debido a la
herencia de atributos. Resaltar el hecho de que el periodo de tiempo para el que
ese identificador es válido <IVL_TS> en este nuevo documento se divide en 2
diferentes: validTimeLow y validTimeHigh.
 Coded Value (CV), para la representación de un concepto codificado. Los
atributos permanecen inalterados, pero ahora se denomina Coded
Description.Coded Value (CD.CV) y restringe CD en lugar de especializar Coded
Symple Value (CS).
 Time Interval (IVL<TS>), para establecer intervalos de tiempo. Sus atributos
aumentan por herencias, llegando a poder especificar, un periodo de validez para
ese periodo de tiempo.
Tomando como base estos cambios se realizaron una serie de modificaciones en
la base de datos utilizada en el servidor de HCE, así como diversas adaptaciones
en la lógica de acceso a datos que se explican a continuación. Este hecho, supuso la
primera parte de las prácticas médicas: Para corroborar la validez del extracto de
HCE generado se contó con la colaboración del Hospital Universitario Puerta de
Hierro (HUPH) y del Instituto de Salud Carlos III (ISCIII). Ambas instituciones
han desarrollado conjuntamente un servidor de HCE acorde a las normas UNEEN/ISO 13606 e ISO/DIS 21090 para validación y depuración de extractos accesible
remotamente a través de tecnologías WS (119) . Mediante el envío de extractos de
HCE al servidor de HUPH/ISCIII, se ha validado la completa interoperabilidad
semántica del servicio, garantizando el estricto cumplimiento de la norma y la
validez de los nuevos data types.
62
21090
14796
Primitives
Bit
BitString
Quantity
Basic
Basic
Quantity
Boolean
Integer
Time Point
Real
Date
PQ
QTY
ANY
INT
StrucDoc.Br
BL
INT.NONNEG
StrucDoc.Sup
BL.NONNULL
INT.POS
StrucDoc.Sub
CO
StrucDoc.LinkHtml
MO
Identifiers &
Locators
UID
URL
II
Character, String
Multimedia Types
Collection
Structured
Text
HXIT
RTO
OID
Quantity
Identification
Location
StrucDoc.Base
REAL
StrucDoc.RenderMultimedia
RTO
StrucDoc.FootnoteRef
PQV
StrucDoc.Footnote
PQ
StructDoc.TitleFootnote
TEL
PQR
strucDoc.Content
TEL.URL
PQ.TIME
StrucDoc.Caption
TEL.PERSON
MO
StrucDoc.Captioned
TEL.PHONE
TS
StrucDoc.Paragraph
TEL.EMAIL
TS.DATE
StructDoc.CMFootnotes
II
TS.DATE.FULL
StructDoc.CMInline
TS.DATETIME
StructDoc.CMContent
TS.DATETIME.FULL
StructDoc.CMGeneral
TS.BIRTH
StructDoc.CMTitle
Text &
Binary Data
StrucDoc.List
StrucDoc.Item
StrucDoc.TableItem
Character
ED
Encapsulated Data
ED.Image
Character String
ED.TEXT
Collection
StrucDoc.TCell
StrucDoc.TRow
StrucDoc.TRowPart
SET
ED.DOC.
COLL
LIST
StrucDoc.TRowGroup
ED.DOC.INLINE
DSET
GLIST
StrucDoc.ColItem
ED.DOC.REF
LIST
SLIST
StrucDoc.Col
ED.SIGNATURE
GLIST
BAG
StrucDoc.ColGroup
ED.STRUCTUREDTEXT
SLIST
INTERVAL
StrucDoc.Table
ED.STRUCTUREDTITTLE
HIST
INTERVAL OF PQ
StrucDoc.Text
ST
BAG
INTERVAL OF TIME
StrucDoc.Title
ST.NT
SC
SC.NT
Continuos
Set Data
QSET
Coded Datatypes
Coded Datatypes
QSU
QSI
QSD
CD
CD
CR
CD.CV
QSS
CE
CS
QSC
CV
IVL
CS
IVL.LOW
CO
Periodic Time
Interval
Periodic Interval of
time
Event Realated
Periodic Interval of
time
QSP
Name and
Address
IVL.HIGH
IVL.WIDTH
PIVL
EIVL
ADXP
AD part
GTS.BOUNDEDPIVL
AD
ENXP
EN
EN.TN
Uncertainty
EN.PN
EN.ON
UVP
NPPD
URG
URG.LOW
URG.HIGH
Fig. 2.2-1 Comparativa TS14796 vs. ISO/DIS 21090
63
Bloque 2:
Fruto de esta colaboración se ha confeccionado un framework completo de 681
clases definidas en C#, incluyendo clases enumeradas, que permitirán interactuar
con cualquier instancia posible definida según el modelo de referencia y el ISO/DIS
21090.
2.2.2. Arquitectura Multicapa. Modificaciones.
La norma EN13606 proporciona una arquitectura formal basada en la
transmisión de HCE bajo petición (arquitectura cliente/servidor) implementada
tradicionalmente mediante el uso de tecnologías middleware basadas en WS. En
esta segunda implementación del servidor se propone una arquitectura multicapa
con objeto de flexibilizar la forma en la que se puede realizar esta petición.Un
esquema detallado de la arquitectura multicapa se muestra en la Fig. 2.2-2.
La primera capa corresponde al nivel de acceso a datos (Data Access) que trabaja
en colaboración constante con el núcleo de la aplicación: una segunda capa basada
en la construcción de clases (Class Based Core). Así, el diagrama funcional se inicia
con una petición UNE-EN/ISO13606 de HCE (requestEHR) desde el cliente con una
serie de parámetros (subject_of_care, purpose, time_interval, etc.).
A partir de aquí, el servidor obtiene dichos parámetros (Obtaining Parameters) e
identifica las Compositions que cumplen los requisitos de la petición (Obtaining
Composition_id). Una vez determinadas, y tras completar la cabecera
(GenerateEHRheader), se añaden dichas Compositions (GenerateComposition) para
generar el extracto de HCE (GenerateExtract) mediante técnicas recursivas
aprovechando la jerarquía presente en la estructura de un extracto de HCE.
Finalmente, este extracto será devuelto al cliente mediante tecnologías WS.
Una tercera capa (XML Interface) permite ser invocada para la generación e
intercambio de ficheros eXchange Markup Language (XML Construction) usando el
núcleo de la aplicación gracias a la conversión XML de los tipos de datos
serializados ISO/DIS 21090 a clases (Class Convertion). Para poder invocar el
núcleo de la aplicación se realizan conversiones entre el fichero XML y las clases
que lo representan. Así, esta capa ofrece autentica interoperabilidad (mediante la
función requestEHRXML) dado que no presenta dependencia tecnológica.
Una cuarta capa (Customized Interface) ha sido implementada para facilitar la
llamada a esta aplicación por sistemas heredados que no implementen la norma.
Mediante funciones intermedias de wrapping se permite acomodar conforme a
UNE-EN/ISO13606 la sintaxis de la petición realizada por este tipo de sistemas
heterogéneos (requestEHRParams) mediante la adaptación de los parámetros
requeridos. Esta capa debería situarse formalmente en el lado cliente, aunque el
servidor puede dar esa funcionalidad adicional.
De hecho, esta cuarta capa ha consituido la segunda parte de las prácticas
médicas en colaboración con Técnicas Competitivas SA (TCSA), una empresa
canaria que ofrece servicios de consulta de HCE y es ajena al desarrollo propuesto
de la arquitectura multicapa. El desarrollo de esta capa personalizada, respetando
todos los argumentos especificados en la parte 5 de la norma, se ha realizado
eligiendo estructuras interoperables y escalables (string[], string[][], etc.) de forma
que la llamada pudiera realizarse a través de una librería genérica de llamada a
diferentes WS. Los resultados de esta integración han constituido una contribución
a un Invitational Workshop de desarrolladores de la norma, en la que se seleccionó
este trabajo entre aportaciones enviadas desde el continente europeo. (145)
64
Fig. 2.2-2. Descripción de la arquitectura multicapa.
El resto de las prácticas médicas realizadas con TCSA han consistido en tareas
de coordinación y asesoramiento en la adopción de la norma EN13606 pues desde el
SCS, pionero entre el resto de servicios autonómicos de salud, se ha decidido la
adopción esta norma como eje del modelo de HCE desarrollado en la comunidad.
Durante las reuniones mantenidas con TCSA se ha compartido el enfoque
metodológico utilizado en la implementación del servidor, así como se ha
participado en la definición de equivalencias entre el actual sistema de información
y estructuras que puedan interpretarse como instancias válidas del RM.
2.3. Diseño e implementación del “standard approach”
CE2EHR
El diseño de este standard approach, se justifica en la búsqueda de un modelo
de atención integral de salud al ciudadano y no sobre el paciente. Se pretende
favorecer la transición de un modelo sanitario más reactivo a un modelo más
proactivo. Es por ello que desde la Unión Europea sitúa la e-Salud dentro de las
áreas identificadas como de actuación y, en concreto, desarrolla e incentiva el
desarrollo de una HCE unificada y las soluciones de telemedicina en el seguimiento
de pacientes crónicos a través de dispositivos móviles para conseguir mayor
cobertura y asegurar la continuidad de cuidado. (23) (146)
Es por ello, que se ha diseñado un sistema de adquisición no supervisada de
medidas remotas para su incorporación en la HCE. Sin embargo, la adquisición no
supervisada de estas medidas no es algo trivial: las medidas a veces se presentan
compuestas por entidades más simples (por ejemplo, presión arterial compuesta
por sistólica y diastólica), la capacidades del dispositivo que puede obtener más de
una medida a la vez (por ejemplo, un pulsioxímetro capaz de obtener la frecuencia
cardiaca y la saturación de oxígeno en sangre), la obtención de datos redundantes
(por ejemplo, la presión del pulso que puede obtenerse directamente o mediante la
resta entre el valor de diastólica y sistólica), etc.
65
Bloque 2:
Fig. 2.3-1. Esquema del modelo estructural de una medida.
Estos hechos justifican la necesidad de modelos clínicos de las medidas
adquiridas para garantizar la transmisión interoperable de la información: Los
arquetipos permiten tanto la definición de estructuras comunes de organización de
la información como la identificación univoca de los conceptos mediante el enlace a
terminología médica. En nuestro caso, se han utilizado los arquetipos que se
habían definido en la primera implementación del servidor y que pueden
consultarse en el Anexo H.
La pretensión de abarcar la mayor cantidad posible de medidas ha reducido el
diseño de la estructura a la concatenación de medidas simples y la hora en la que
se realizó la medida (además de información adicional de contexto, como puede ser
el identificador del paciente). La Fig. 2.3-1muestra el esquema estructural de una
medida. Así, cada medida contendrá una serie de conceptos que poseerán
significación propia (como puede ser la medida simple del pulso, la tensión
diastólica o la temperatura corporal). Los datos corresponden con cantidades y esas
entidades, tanto en TS14796 como en ISO/DIS 21090, corresponden con una
instancia Physical Quantity (PQ). Esta instancia PQ puede simplificarse en el caso
de datos remotos de telemedicina a la especificación de un valor y unas unidades,
pues el resto de atributos carecen de sentido en la transmisión remota.
Sin embargo, la determinación de unidades no identifica unívocamente esos
conceptos, como ocurre con la tensión sistólica y diastólica que comparten unidades
(mmHg, pascales, etc.). Es necesario un código identificativo en un sistema de
referencia en concreto. Se necesitará pues, un elemento adaptador que posea
capacidades de procesado y que permita la construcción de este tipo de estructuras
y sea capaz de asignar un código a cada concepto. Según las especificaciones
TS14796 y ISO/DIS 21090, un código se puede identificar unívocamente mediante
un identificador único en un sistema determinado, y se representaría mediante un
Coded Value (CV en TS14796, CD.CV en ISO/DIS21090). En la implementación
particular de esta TFM, esto no presenta una dificultad adicional pues dentro de
modelo de funcionamiento del X73 se establece una codificación propia e interna
que asigna valores codificados únicos que referencian a los objetos y a sus
atributos.
66
Fig. 2.3-2. Diagrama funcional de la transmisión de datos médicos remotos a un servidor de
HCE.
De este modo, el esquema global de comunicaciones queda como se ve en la Fig.
2.3-2, en la que se define el flujo de estados por el que la información tendrá que
pasar:  Los datos médicos son recibidos por el elemento colector, que se encarga de la
fragmentación de la información recibida en elementos simples y, tras
codificarlos adecuadamente, genera una instancia de comunicación de datos al
servidor y envía dichos datos al módulo receptor.
 Una vez que éste recibe la información correspondiente del CE, el MS efectúa la
decodificación de cada uno de los elementos que componen los diferentes
conceptos transmitidos, tanto la información de contexto como los conceptos
médicos y para cada uno de ellos se selecciona aquél que identifique al concepto
clínico en sí (código) y realiza un mapeo entre ese código y su equivalente en el
sistema de codificación usado en el centro sanitario de referencia.
 A partir de aquí se consulta un repositorio de arquetipos simples que poseen
enlaces a la codificación usada en el HCIS, lo que permite conocer bajo qué
premisas debe guardarse la información. Así, el arquetipo elegido establece las
condiciones bajo las cuales esa medida debería haber sido adquirida (por
ejemplo, se puede disponer de un arquetipo que indique que la presión diastólica
posee un determinado código y sus unidades han de ser mmHg).
 Una vez conocidas estas premisas de recepción, se procede a una validación
secuencial:
o Comprobación de las unidades. El realizar este tipo de comprobación
responde a la diversidad de dispositivos médicos y a la posibilidad de recibir
las medidas en unidades distintas pero equivalentes (por ejemplo, la tensión
arterial que posee unidades de presión y puede ser expresada en milímetros
de mercurio (mmHg) o Kilopascales (kPa)). De hecho, y dado que el
conocimiento queda reflejado en la definición de arquetipo, este proceso
seguiría siendo válido si se descubriera, por ejemplo, que las unidades más
apropiadas para definir la tensión arterial son atmosferas de presión.
67
Bloque 2:
o Escalado del valor. En el caso que fuese pertinente, ocurriría si las unidades
con que se reciben los datos médicos no se corresponden con las que dicta el
modelo. Esto implicaría conocer las operaciones necesarias para transformar
el valor del concepto para hacerlo coherente a las nuevas unidades.
Se puede ver un ejemplo de esta situación en la Tabla 2.3-1, donde se enumeran
la diversidad de unidades que el estándar X73 permite para un mismo concepto,
así como la transformación para transformar ese valor adecuadamente a
unidades Unified Code for Units of Measure (UCUM), que son las utilizadas en
nuestros arquetipos.
 Una vez efectuado este proceso, se envían los datos decodificados a la lógica de
inserción de datos para que pasen a formar parte del conjunto de datos clínicos
según la estructura interna del HCIS. Finalmente, indicar que en el detalle de
todo este proceso sólo se ha analizado el procedimiento que se seguiría con un
único dato clínico. Para la decodificación de toda una trama con múltiples datos
habría que iterar el proceso N veces.
El modelo de comunicaciones se ha desarrollado mediante una arquitectura
multicapa cliente/servidor basada en tecnologías Web Services y se ha utilizado el
lenguaje de programación C# de la plataforma dotNet que permite un desarrollo
ágil de aplicaciones. Para la puesta en marcha de las pruebas reales se ha
instalado y configurado un Internet Information Server (IIS) que sirve de motor de
funcionamiento de la aplicación servidor.
Las pruebas realizadas, dentro de la plataforma previamente implementada,
han consistido en el envío de múltiples instancias de comunicación desde CEs
tanto fijos (PCs desktop y NetBooks) como móviles (SmartPhones y PDAs),
utilizando diversas tecnologías para el transporte de datos (USB y Bluetooth) y
desde diferentes sistemas operativos (Windows, Windows Mobile, Linux y Android).
Como resultado de las pruebas realizadas y tras utilizar varios tipos de medidas
donde algunas produjeron códigos relativos al mismo concepto clínico (como el caso
del pulso, que tiene codificaciones distintas si se obtiene de un tensiómetro o de un
pulsioxímetro), se ha observado la correcta inserción de todos los datos en el
sistema de almacenamiento.
Concepto
Posibles unidades X73
Conversión
Unidades UCUM
Kg
1
Peso
kg
Lb
0,455
ºC
1
Temperatura
ºC
ºF
1/1,8 – 32/1,8
mg/dL
1
Glucosa
mg/dL
mmol/L
18
mmHg
1
Presión
mmHg
kPa
7.50061683
Concentración de oxígeno
%
1
%
Pulso
Latidos por minuto
1
Latidos por minuto
Tabla 2.3-1. Tabla de conversión entre unidades a Unidades UCUM.
68
Bloque 3
Conclusiones y líneas futuras.
Próximos retos de I+D+i
3.1 Conclusiones.
3.2 Líneas futuras.
3.3 Próximos retos de I+D+i.
3.4 Hitos académicos y de investigación.
Agradecimientos. En este tercer bloque, se resumirán las conclusiones obtenidas en esta Tesis Fin de Máster,
tanto de origen académico como personal. Así mismo se introducirán las líneas futuras en
las que trabajar siguiendo la línea ya iniciada durante este año, así como se apuntarán
varias líneas de investigación en las que este trabajo profundizará más adelante. El Bloque
termina enumerando los frutos de este trabajo en forma de artículos en revistas científicas,
tanto nacionales como internacionales, así como todos los actos y congresos a los que se ha
asistido y que han ayudado a tomar una perspectiva más amplia del problema. 69
Bloque 3:
70
Conclusiones y líneas futuras. Próximos retos I+D+i
3.1
Conclusiones.
Las conclusiones de la realización de este TFM para el autor han sido
significativas desde varias ópticas (general e histórica, de actualidad del proceso,
de implementación, metodológica y práctica):
 En primer lugar, se ha logrado una visión global del problema de la
transmisión de la información a través del estudio y evolución de la
concepción de la HC y toda la problemática asociada del paso de esta a HCE:
o Diferentes organismos de normalización y las relaciones entre ellas.
o Diferentes terminologías dependiendo del área de cuidado de la que procedan
los datos médicos.
o Diferentes filosofías de transmisión de información generadas en ámbitos
distintos (más académicos, más comerciales, etc.)
Esta visión general confirma la hipótesis de que la transmisión de información
médica de manera interoperable no es una tarea sencilla y que debe ser
abordada conjuntamente por todas las partes implicadas.
 En segundo lugar, también se ha obtenido una panorámica actual del
problema, pues se ha tenido la oportunidad de conocer de primera mano la
situación real del proceso de normalización que el mundo sanitario está
experimentando y los mecanismos que se están siguiendo para derrumbar las
barreras que previamente se habían levantado:
o Los diferentes proyectos regionales, nacionales y europeos.
o Las tendencias de convergencia entre las distintas alternativas de
transmisión de la información.
o La respuesta comercial tanto en la propuesta de mecanismos que garanticen
la interoperabilidad (desarrollo de interfaces basadas en estándares) como en
el desarrollo de sistemas propietarios y análogos a sistemas de HCE para la
autogestión de la salud.
Dicha experiencia de primera mano ha proporcionado una visión privilegiada de
la situación actual, que una vez asimilada permitirá un avance rápido en la
consecución de futuros retos.
 La experiencia de la implementación del servidor de HCE ha permitido
trasladar todos esos conocimientos a la realidad tangible: tanto el esfuerzo
inicial realizado en la primera implementación como el esfuerzo extra requerido
para realizar una segunda implementación han hecho patente la sensibilidad de
la arquitectura, pues cambios en una de las piezas en las que se sustenta la
norma ha ocasionado una reestructuración en la lógica de acceso a datos.
 El diseño del modelo de comunicaciones, realizado sobre dos elementos que
proporcionan interoperabilidad en sus extremos, permite abstraer la
implementación y generalizar el proceso de adquisición no supervisada
de datos a otros sistemas de adquisición que sustenten la descripción de los
conceptos del dominio en modelos formales.
 La investigación realizada en torno a medidas y enfermedades, ha permitido un
mejor conocimiento del mundo sanitario: se han adquirido conocimientos
relativos a los factores que afectan a la toma de ciertas medidas, así como las
secuelas que pueden causar ciertas patologías y los puntos clave a controlar
para evitarlas. Este background permitirá interacciones fluidas con el mundo
sanitario, y será de gran utilidad para el modelado clínico tanto de medidas
como para establecer perfiles de pacientes y/o usuarios del sistema sanitario.
71
Bloque 3:
 La posibilidad de la realización de prácticas médicas en ámbitos tan
distintos, como lo son el comercial, el médico y el académico, ha permitido
comprender la visión tan dispar que se posee en estos 3 ámbitos de la misma
realidad, desde la defensa acérrima del modelo completo hasta la adecuación de
la norma a las necesidades específicas en cada ámbito. Además la asistencia a
múltiples congresos y conferencias ha resultado clarificadora e instructiva en
estos tres campos.
Por esto, y por muchas otras razones, las conclusiones al trabajo realizado
difícilmente pueden ser consideradas más positivas, al menos para el autor y
cubren las expectativas y objetivos planteados al comienzo del trabajo.
3.2
Líneas futuras.
Entre las líneas futuras planteadas dentro de este campo de investigación, se
abren varios caminos:
 La revisión continúa de las próximas versiones del ISO/DIS 21090, que establece
el tipo básico de datos a utilizar en la transmisión de la información.
 La implementación de una variante misma plataforma, utilizando el estándar
HL7 versión 3 como eslabón final de la cadena en lugar de la norma EN 13606,
etc.
Sin embargo, dada la importancia que se da desde instancias europeas a la
telemedicina, se intentó acomodar los informes generados en nuestro sistema a un
posible informe genérico que pudiera estar definido desde el MSPS.
Desgraciadamente, a fecha de realización de esta TFM, no hay definido ningún
informe de funcionalidad similar a los que son generados en el servidor aunque se
vislumbró un nuevo camino a seguir: el modelado de los informes definidos para el
intercambio de información sanitaria entre CCAA.
El estudio de los diferentes informes definidos desde MSPS hizo patentes una de
las mayores propiedades que posee la norma EN 13606: su modelo clínico. La
estructura de dichos informes (ver Anexo K) se corresponde casi completamente
con el contenido de los informes emitidos papel y divide la organización de los
informes en 3 grandes grupos funcionales (datos del centro, datos del paciente y
datos del proceso asistencial). Dentro de esos grupos funcionales se establecen
campos de obligada transmisión y otros opcionales, así como la recomendación de la
subdivisión de un determinado apartado debido a que esos datos puedan ser de
distinta índole ó tengan diferente origen (así, los antecedentes se pueden
subclasificar en familiares, enfermedades médicas, medicación que se está
tomando, etc.)
Los indicios de repetición de estructuras eran tan claros que se optó por modelar
la totalidad de los informes mediante un diagrama Entidad-Relación (diagrama
ER), cuyo resultado puede verse en la Fig. 3.2-1
Como puede verse, hay varias “piezas” que se repiten en este esquema, que si se
modelasen mediante conceptos del dominio (arquetipos) se podría, con un esfuerzo
razonable, establecer estructuras que ayuden a la decodificación de la información
(ver Fig. 3.2-2). Esto constituye un claro ejemplo de la potencia de la estrategia de
doble modelo (información y conocimiento) en la consecución de la interoperabilidad
semántica.
72
nombre
codigo
CIPCA
Comunidad Autónoma
(1,1)
(1,N)
(1,N)
Pertenecer
fechaNacimiento
Formada
sexo
(1N)
NASS
DNI
direccion
apellidos
(1,N)
Paciente
(1,1)
idComunidad
Asignado
(1,N)
(1,N)
Centro Sanitario
Coordina
(1,N)
Unidad Asistencial
Nombre
CIPSNS
nombre
idUnidad
Tiene
Unidad
idCentro
ultimaActualizacion
(1,N)
fechaCreacion
Servicio
idRes
dirección
Vacunaciones
Alergias
Unidad_Coordinacion
Recomendaciones
Resumen
Problemas resueltos
(1,N)
Trabaja
Resultados enfermeria
Farmacos
(1,N)
(0,N)
(1,1)
Alertas
Diagnostico enfermeros activos
Posee
(1,1)
(0,N)
Observaciones
Contribuye
Emitido
idInforme
rol
Intervenciones Enfermería
(0,N)
(1,N)
idProfesional
(0,N)
Atención Primaria
Centro Especialidades
(1,1)
Firma
Hospital
Profesional
Informes
tipo
(0,N)
Supervisa
(1,1)
Nombre
fechaCreación
Apellidos
rol
tipoDocumento
Antecedentes
Resumen Pruebas
Historia
Exploración
Otros Diagnosticos
Motivo de Alta
Diagnostico
Generales
Antecedentes
Evolucion
fecha Muestra
Causa
Recomendaciones
Grupo
Tratamiento
Hallazgos
Recomendaciones
Protocolo
Numero Muestra
Procedimientos
Exploración
Diagnostico
Diagnostico resueltos
Hospitalización
Especialidades
Urgencias
Enfermeria
Imagen
Laboratorio
Atencion Primaria
info Clinica
motivoAlta
Procedencia
Valoración
fechaExploracion
(1,1)
tipoIngreso
descripcionExploracion
(1,1)
Diagnostico activos
Contiene
Motivo Alta
MotivoConsulta
Contiene
motivoIngreso
Tipo Consulta
Episodios Atendidos
Resultados
(1,N)
(1,N)
Motivo Consulta
Cuidador
Intervenciones
ResultadoB
Info Complementaria
ResultadoA
idResA
Descripción
idResB
Nombre
Nombre
Resultado
Unidades
Rango
conclusion
Tecnica
comentarios
Fig. 3.2-1. Diagrama ER de los diferentes informes definidos desde el MSPS.
La consecución de este fin podría resultar una aportación interesante, aunque
con la actual definición de los campos no se poseen garantías de lograr
interoperabilidad semántica pues salvo algunos campos en algunos informes, que
se transmiten asociados a una terminología (NIC/NOC/NANDA, SNOMED-CT,
LOINC) el resto se transmite en forma de texto libre y esto no representa garantía
alguna de que un concepto no pueda malinterpretarse. Por ello, dentro de esta línea
se pueden definir 2 sub-líneas diferentes: el modelado estricto de los informes
definidos en el proyecto de HCDSNS y el modelado mejorado de estos informes,
complementándolos con enlaces a terminologías y/o sistemas de clasificación
médicos, e incluso definición de esos mismos arquetipos donde cada concepto
presente traducciones a las distintas lenguas oficiales del estado español.
73
Bloque 3:
Antecedentes:
Atención Primaria
Antecedentes familiares
Alergias
Alergias
Medicación
Alergias
Resumen de la HCE
Atención Especializada
Fig. 3.2-2. Ejemplo de reutilización de conceptos en los informes de HCDSNS.
En cualquiera de los dos casos, la definición de estos arquetipos no podrá
realizarse de forma automática, pues por motivos de seguridad no está permitida la
transmisión de datos identificativos del paciente y/o de cualquier persona vinculada
al proceso clínico. Por ello, se deberá utilizar como apoyo la Base de Datos de
Tarjetas Sanitarias Individuales del SNS (147), gracias a la cual se podrá
identificar unívocamente a cada ciudadano gracias al código único proporcionado
desde el ministerio, entre otros.
3.3
Próximos retos de I+D+i.
Como continuidad natural del trabajo que se viene realizando hasta el momento, se planteó la necesidad de dotar de contexto a las medidas adquiridas por el CE y más
tarde almacenadas en el MS, para poder ir más allá de la simple identificación de
la medida realizada. Este reto se plantea interesante desde la perspectiva de que la
autogestión de enfermedades crónicas va a ir creciendo en los próximos años. Esto
supondrá, al realizarse las medidas ajenas al entorno sanitario, que esas
constantes que ¿conformaban?¿contenían? algunos parámetros se convertirán en
variables que habrá que conocer para poder interpretar correctamente la medida.
En los próximos apartados se describen los procesos seguidos en un primer
intento de abordar este reto. Como conclusiones de esta primera incursión se
obtuvo otra posible línea de investigación: el modelado del paciente crónico.
74
3.3.1. Integridad semántica de datos clínicos en soluciones de
telemonitorización.
El objeto de dotar a los datos biomédicos adquiridos de contexto conservando así su integridad semántica estriba, como ya se ha comentado, en reajustar el modelo del concepto clínico ante un abanico más amplio de posibilidades que los fijados por el entorno del centro sanitario donde habitualmente se realizan las medidas que terminan en la HC del paciente. Es necesario definir un contexto completo de adquisición de la medida, que permita una interpretación correcta de la medida, y conserve de este modo su integridad sanitaria. Como primer paso en la consecución de este objetivo, se realizó una búsqueda
pormenorizada de información en diversos recursos como pueden ser diccionarios
médicos online como MedlinePlus (122) páginas de asociaciones de enfermos como
la Sociedad Española para el Estudio de la Obesidad (SEEDO) (123). El volumen
de información recopilado indujo a la construcción de un modelo de “ficha” que se
fue completando para cada una de las medidas (¿qué es?, ¿valores normales?,
¿patologías donde se presenta?, ¿pautas de medida?, ¿factores que influyen?,
¿necesita complementarse con otras medidas?)
En principio, y bajo la influencia del trabajo con el estándar X73, sólo se realizó
este estudio para aquellas medidas que se pueden obtener con un dispositivo para
el que el estándar X73 poseyera especialización. Posteriormente, se amplió este
estudio a otro tipo de medidas que se consideraron de interés y que podrían llegar
al centro sanitario por un camino alternativo a la plataforma descrita en esta TFM.
Puede verse la relación completa de medidas analizadas en el Anexo L.
Los primeros resultados a este trabajo proporcionaron para cada medida una
serie de condicionantes que se catalogaron como pseudo-estáticos o dinámicos. Los
condicionantes pseudo-estáticos son aquellos que permanecen inalterados
permanentemente o durante un gran espacio de tiempo (edad, la raza, etc.). Los
condicionantes dinámicos son aquellos que pueden variar de medida a medida
(hora en la que se realiza la medida, si se ha ingerido alimento o medicación
previamente, el lugar donde se toma la medida etc.). En función de esta
clasificación realizada se establece qué variables deben obtenerse junto a la medida
y qué factores deberán, bien almacenarse en el centro sanitario, bien establecer los
mecanismos necesarios para ser calculados en función de otros que sí lo estén, como
la edad a partir de la fecha de nacimiento. Si se es capaz de obtener toda esa
información se podrá realizar una interpretación semánticamente completa de la
medida. (Ver Fig. 3.3-1)
Una de las conclusiones obtenidas en esta primera recopilación fue la necesidad
de seguimiento de un gran número de signos vitales comunes a varias patologías en
concreto, así como que la presencia de alguna enfermedad (o caso de interés) puede
resultar explicativa de un valor anómalo de la medida. Llegados a este punto, se
decidió enfocar el problema desde una perspectiva diferente: el modelado del
paciente crónico.
75
Bloque 3:
Fig. 3.3-1. Interpretación semánticamente correcta de la medida.
3.3.2. Situaciones médicas de interés para integración de
estándares
La clasificación de pacientes en un sistema sanitario en función de la gravedad
de su estado de salud, su edad, etc. tiene como objeto adecuar la asistencia
sanitaria a las necesidades del individuo en particular en grupos funcionales. Al
tratar de profundizar en la categorización de paciente crónico responde, en cierta
medida, a la necesidad de establecer un mayor detalle en granularidad de ese gran
“cajón de sastre” que puede abarcar desde una diabetes a una insuficiencia
cardiaca.
En este apartado se ha seguido una metodología similar a la anterior al
principio: se ha recopilado información de varias fuentes y se han elaborado
diversas fichas descriptivas de cada enfermedad estudiada (¿En qué
consiste?¿clasificación por defecto?¿síntomas?¿grupos de riesgo? ¿complicaciones?
¿frecuencia de los controles?, ¿qué monitorizar y que se puede hacer de manera
telemática? ¿interacciones con otras enfermedades? y ¿recomendaciones?). Se puede
ver una descripción completa de las enfermedades estudiadas en el Anexo I.
El objeto principal de este estudio fue comprobar si sería posible mejorar la
calidad asistencial de un enfermo crónico, mediante el control domiciliario de
ciertos signos vitales, sin que ello supusiera un incremento en el gasto sanitario ni
una obligación para el paciente crónico de acudir con una periodicidad mayor al
centro sanitario. Entre las conclusiones que se extrajeron de las diversas fichas, se
encuentra la confirmación de dicha hipótesis pues muchas medidas de control sí
pueden tomarse de manera domiciliaria.
Además, gracias a la elaboración de diversos diagramas conceptuales, que tratan
de resumir gráficamente el contenido de la ficha, se puede encontrar un comienzo
de modelado de paciente multicrónico.
76
La situación que se trata de modelar es la definida en el diagrama ER
representado en la Fig. 3.3-2. A modo de ejemplo, se ha extraído el diagrama
conceptual del enfermo hipertenso. (Ver Fig. 3.3-3). En este diagrama podemos ver
la enfermedad origen del estudio y en el cuadro azul claro la clasificación existente
por defecto. En este diagrama, se muestran aquellos signos vitales que deberían
monitorizarse y los dispositivos que se necesitan para ello. Para añadir esta
columna se ha elaborado un “compendio-resumen” de algunos dispositivos médicos
que pueden adquirirse en el mercado, junto con sus funcionalidades y nivel de
conectividad (ver anexo Z). El objeto de esta tabla sería minimizar el gasto
sanitario: si solo se necesita medir tensión y pulso, puede resultar más económico
adquirir un tensiómetro que mida el pulso, que un tensiómetro sencillo y un
pulsímetro.
NombreApellidos
Nombre
edad
idPac
rangoValores
idCond
Paciente
condicion
(1,N)
SubClasif
(0,N)
Tiene
Efecto
Nombre
Grado
(0,N)
Relación
(0,N)
idEnf
relacionar
Precisión
(1,N)
(0,N)
Enfermedad
(1,N)
(1,N)
Controlar
(1,N)
(1,N)
Signos Vital
Miden
(1,N)
Dispositivo
MarcaModelo
idDispos
idSigno
Periodicidad
Presenta
Tipo
rangoNormalidad
Nombre
unidades
(0,N)
Sintomas
idSint
Frecuencia
Nombre
Fig. 3.3-2. Diagrama ER Enfermedades-Síntomas-Signos.
Fig. 3.3-3. Ejemplo de diagrama conceptual realizado: paciente hipertenso.
77
Bloque 3:
Estos diagramas fueron creciendo en complejidad a medida que se fueron
completando más fichas y determinadas relaciones adquirieron carácter
bidireccional. Sin embargo, por simplicidad, se decidió no analizar más que
aquellas relaciones
directas con la enfermedad sin llegar a cuestionarse
implicaciones de segundo orden. Con estos diagramas se pretendía establecer
pautas de cuidado preventivo en pacientes multicrónicos: así, un paciente diabético
que ya de por sí, se encuentra en predisposición de desarrollar hipertensión debería
controlarse más a menudo la tensión que un paciente hipertenso que presente una
gravedad mayor en términos de hipertensión y no tuviera el problema añadido de
la diabetes.
Ambos compendios de “fichas resumen”, tanto de signos vitales como de
enfermedades, han constituido la tercera parte de las prácticas médicas puesto que
se tuvo la oportunidad de concertar entrevistas con médicos que avalaron y/o
desestimaron algunas de las informaciones que se encontraron en la investigación
previa. Ocurrió la paradoja de que algunos de los factores que influían en las
medidas eran relevantes pero sólo en determinados casos, como por ejemplo la edad
en la investigación médica, donde no se deberían conocer los datos de la persona de
la que provienen los datos, pero ese factor puede resultar clave para interpretar
correctamente una medida.
En cuanto a la pretensión de establecer perfiles de cuidado preventivo en
pacientes crónicos, ésta no fue desestimada pero se remitió a guías clínicas para
completar con mayor precisión los protocolos médicos que siguen los pacientes
crónicos, entre ellas las guías NICE.
Así, como un primer paso se prevé el modelado completo de signos vitales,
mediante arquetipos de medidas sencillas. Además, gracias a la posibilidad de
especialización que poseen los arquetipos, se podría definir un arquetipo genérico
para un signo vital que no obligase a la transmisión de información de contexto,
pero que sus especializaciones para su uso, por ejemplo de investigación, si lo
hiciera.
78
3.4 Hitos académicos y de investigación.
Agradecimientos.
Como resultado de este trabajo se han llevado a consecución los siguientes hitos
académicos y de investigación:
Publicación de los siguientes artículos científicos en revistas:
o
Martínez I, Escayola J, Martinez-Espronceda M, Muñoz P, Trigo JD, Muñoz
A, Led S, Serrano L and García J. “Seamless Integration of ISO/IEEE11073 Personal Health Devices and ISO/EN13606 Electronic Health Records into an End‐to‐End Interoperable Solution”, Telemedicine and e-Health. Accepted
o
Muñoz P; Martinez I, Muñoz A, Trigo JD, Escayola J, García J. “The
ISO/EN13606 standard for the interoperable exchange of Electronic Health
Records ”. special issue on Electronic Health/Medical Record of the Journal
of Healthcare Engineering Editor: Chyu, M. Target publication Juanuary
2011
Publicación de los siguientes artículos en congresos, simposios y
reuniones científicas:
INTERNACIONALES
o
Martínez I, del Valle P, Muñoz P, Trigo JD, Escayola J, Muñoz A, Serrano L
and García J, “Interoperable and Standard E-Health Solution Over
Bluetooth”, 32nd Annual International IEEE EMBS Conference, Poster
Session, Buenos Aires 2010
o
Martínez I, Trigo JD, Martínez-Espronceda M, Escayola J, Muñoz P,
Serrano L and García J, “Integration Proposal through Standard-Based
Design of an End-to-End Platform for p-Health Environments” Proc. of the
31st Int. Conf. of the IEEE Eng. in Med. and Biol. Soc.. pp. 4639-4642,
Minneapolis 2009
o
Martínez I, Escayola J, Martínez-Espronceda M, Serrano L, Trigo JD,
Muñoz P. and García J, “Implementation Guidelines for an End-to-End
Standard-based Platform for Personal Health” Fourth International MultiConference on Computing in the Global Information Technology. pp. 123131, Cannes 2009
NACIONALES
o
P. Muñoz, I. Martínez, A. Muñoz, A. Aragües, J. Escayola y J. García, “Uso
de arquetipos en la adquisición no supervisada de medidas remotas para su
incorporación a un servidor de HCE” XXVIII Congreso anual de la Sociedad
Española de Ingeniería Biomédica (CASEIB). Submitted.
o
P. Muñoz, I. Martínez, A. Muñoz, F. Ramos, C. Hernández, R. Somolinos, P.
del Valle, J.D. Trigo y J. García, “Arquitectura Multicapa Cliente/Servidor para el intercambio de HCE basado en ISO/DIS 21090 y UNE‐EN/ISO13606” XXVIII
Congreso anual de la Sociedad Española de Ingeniería Biomédica (CASEIB).
Submitted.
79
Bloque 3:
o
P. del Valle, J.D. Trigo, P. Muñoz, I. Martínez y J. García, “Evaluación de
una propuesta de diseño de una solución de e-Salud e-accesible orientada a
personas ancianas y con diversidad funcional” XXVIII Congreso anual de la
Sociedad Española de Ingeniería Biomédica (CASEIB). Submitted.
o
A. Aragües, P. Funes, P. del Valle, J.D. Trigo, J. Escayola, P. Muñoz, M.
Martínez-Espronceda, I. Martínez y J. García, “Integración sobre una
plataforma Android de las normas de interoperabilidad ISO/IEEE11073 y
UNE-EN/ISO13606” XXVIII Congreso anual de la Sociedad Española de
Ingeniería Biomédica (CASEIB). Submitted.
o
P. Muñoz, I. Martínez, A. Muñoz, J.D. Trigo, M. Martínez-Espronceda y J.
García, “Integración de datos ISO/IEEE11073 provenientes de Dispositivos
Médicos en un Servidor de HCE según el estándar EN13606” XXVII
Congreso anual de la Sociedad Española de Ingeniería Biomédica (CASEIB).
pp. 701-704, Cádiz 2009
o
M. Gil, I. Martínez, J.D. Trigo, P. Muñoz, M. Martínez-Espronceda y J.
García, “Configuración remota de perfiles de usuario y casos de uso para
una solución ubicua de p-Salud” XXVII Congreso anual de la Sociedad
Española de Ingeniería Biomédica (CASEIB). pp. 689-692 Cádiz 2009.
o
I. Martínez, J. Escayola, J.D. Trigo, M. Martínez-Espronceda, L. Serrano, P.
Muñoz y J. García, “Plataforma Telemática de Integración de Estándares
End-to-End para Salud Personal” XXVI Jornadas Ingeniería Telemática
(JITEL). pp. 156-163, 2009
Participación en reuniones científicas, congresos, simposios, foros y
workshops:
o
Asistencia “DREAMING: The Role of Electronic Medical Records Adoption
in Home Care Web”, seminario web, Agosto de 2010
o
Ponencia “ISO/IEEE11073 Data Integration in a Real EHR System based
on EN13606” en el “CEN/ISO EN13606 Invitational Workshop”. Madrid,
Junio de 2010
o
Asistencia “VIII Foro de Normalización de las TICs en Salud”, La Granja
de San Ildefonso, Castilla y León, España, Abril 2010.
o
Asistencia “XIII Congreso Nacional de Informática
INFORSALUD 2010”.Madrid. Febrero de 2010.
o
Asistencia “Workshop Interoperabilidad semántica y certificación de sistemas de información clínica”, Madrid, España, Diciembre 2009.
o
Asistencia “VII Foro de Normalización de las TICs en Salud” La Granja de
San Ildefonso, Castilla y León, España, 2009.
de
la
Salud,
Al enumerar estos logros académicos no se ha podido evitar recordar todo lo que
estos supusieron, no solo a nivel académico sino también personal y las
circunstancias personales que imprimieron su sello. Por lo tanto, y aunque
bastante más difíciles de enumerar que los anteriormente citados logros, resulta
imprescindible recalcar la aportación que muchas personas han tenido en la
conclusión de esta TFM:
80
En primer lugar me gustaría agradecer la labor de mis dos directores, Nacho y
Adolfo, tanto por su guía en lo académico como por su paciencia, apoyo y
comprensión en lo personal, por saber encontrar ese frágil equilibrio, en especial
Nacho que me ha sufrido de manera más directa y continuada. Porque el poder
escribir esta memoria es, en sí, otro gran logro y os lo debo a vosotros.
En segundo lugar a mis compañeros de trabajo y laboratorio, que a su vez
considero amigos: Pilar, Toño, Javi y Chus, porque mi labor sin la suya hubiera
sido mucho más complicada, por todos sus consejos y sus ánimos.
En tercer lugar a todas esas personas implicadas en mis prácticas médicas: Fran
y Carol desde Canarias, por todas las facilidades en la coordinación y por su trato
amable que lograron que trabajar a tanta distancia no fuera ni mucho menos un
inconveniente; Rosa, que más allá de la validación de un trabajo se esforzó por
ampliar mi perspectiva con toques de realidad y, una vez más, Adolfo porque su
implicación en este proyecto sobrepasó sobradamente la tutoría de las prácticas,
dedicándome tiempo incluso en congresos, Workshops o en las reuniones del comité
técnico 139 de AENOR.
Tampoco puedo dejar sin mencionar a todos los compañeros del máster y todos
esos instantes dignos de recordar, por la comprensión tácita, el apoyo incondicional
o esas horas invertidas en los trabajos que terminaban en risas: las Evas, los
Jesús, Jose, Juan, Fernando, Vanesa… Sois muchos, como los recuerdos que
conservaré de este máster.
¿Y cómo no valorar a todas esas personas ajenas a este mundo? Mi familia y mis
amigos, que me creen capaz de cosas de las que yo me siento incapaz. ¿Cómo no dar
las gracias por la educación recibida? A mis padres por inculcarme unos valores y
enseñarme que un trabajo bien hecho requiere esfuerzo y que hay que esforzarse
aunque muchas veces nadie entienda el porqué. A mis abuelos, paradigma de
serenidad y a los que tantas veces he utilizado como analogía en mis explicaciones,
porque gracias a hacerme participe de sus vidas mi perspectiva del problema que se
abarca en esta tesis ha sido mucho más amplia y rica. A mis hermanos, que
siempre están ahí. ¿Y cómo no agradecer la amistad? Por ser ese oído destino de
mis quejas en momentos de debilidad, por saber disculpar mis múltiples fallos y
sobrevalorar mis escasas virtudes, por esforzaros en entenderme cuando empiezo a
hablar con “siglas”, por todos los ánimos y consejos recibidos aunque no me guste
oírlos, porque con ellos demostráis que os importo de verdad: Cielo y Cipri, Cris y
Miguel, Isa, Sara, Vane, Héctor, Noemí, Ana Bel, Pedro, Mª Jose… Aquí también
sois demasiados como para nombraros a todos, pero no para guardar recuerdos de
todos vosotros.
GRACIAS A CADA UNO DE VOSOTROS!
81
Bloque 3:
82
Referencias
1. Martinez, I, y otros. Integration Proposal throught Standard-Based Design of
an End-to-End Platform for p-Health Environments. Minneapolis : IEEE
Engenering in Medicine and Biology society, 2009.
2. Carballo, Carlos Manuel da Costa. Documentación de las ciencias de la
Información. . Madrid : Servicio de Publicaciones 19CM, 1997. 20. 41/63.
3. Costa Carballo, C. M. da. Introducción a la información y documentación
médica / Carlos Manuel da Costa Carballo. Madrid : Síntesis, D.L., 1993. pág. 367
p.
4. Da Costa Carballo, CM. revistas.ucm.es. [En línea]
http://revistas.ucm.es/inf/02104210/articulos/DCIN9797110041A.PDF.
5. Carnicero Giménez de Azcárate, J. De la Historia Clínica a la Historia de
Salud Electrónica (Resumen). [aut. libro] J Carnicero Giménez de Azcárate, y otros.
V Informe SEIS: De la Historía Clínica a la Historia de Salud Electrónica.
Pamplona : SEIS, 2003.
6. Healthcare Information and Management Systems (HIMSS). Electronic
Health Record (EHR) definition. [En línea]
http://www.himss.org/ASP/topics_ehr.asp.
7. Carnicero, J. Introducción. De la historia clínica a la historia de la salud
electrónica.La historia clínica en la era del conocimiento. [aut. libro] J Carnicero
Giménez de Azcárate, y otros. V Informe SEIS: De la Historía Clínica a la Historia
de Salud Electrónica. Pamplona : SEIS, 2003.
8. Cortes Generales. Ley básica reguladora de la autonomía del paciente y de
derechos y obligaciones en materia de inforderechos y obligaciones en materia de
información y documentación clínica. BOE. 2002. 274. LEY 41/2002.
9. Falagán, JA y Nogueira, J. La información clínica y de salud. [aut. libro] J
Carnicero Giménez de Azcárate, y otros. V Informe SEIS: De la Historía Clínica a
la Historia de Salud Electrónica. Pamplona : SEIS, 2003.
10. Consejo Hospitalario Universitario de Albacete. Manual de
Documentación clínica. Albacete : s.n., 2006.
11. SESPAS. Informe 1998 SESPAS: La salud pública y el futuro del estado del
Bienestas. Granada : SESPAS, 1998.
http://www.sespas.es/informe1998/capitulo1.pdf.
83
12. Gestal Otero, J.J, y otros. Nuevas Formas de Gestión Sanitaria. [aut. libro]
G. Piedróla Gil. Medicina preventiva y salud. Barcelona : Masson SA, 2002.
13. Comisión de las Comunidades Europeas. La salud electrónica – hacia una
mejor asistencia sanitaria para los ciudadanos europeos: Plan de acción a favor de
un Espacio Europeo de la Salud Electrónica. Bruselas : s.n., 2004.
14. Escolar Castellón, F, Iraburu Elizondo, M y Manso Montes, E. Modelos
de Salud Electrónica. [aut. libro] J Carnicero Giménez de Azcárate, y otros. V
Informe SEIS: De la historia clínica a la historia de la salud electrónica.
15. García Rojo, M y Martín Sanchez, F. El impacto de la historia clínica
electrónica en la investigación y la docencia. [aut. libro] J Carnicero Giménez de
Azcárate, y otros. V Informes SEIS: De la Historía Clínica a la Historia Clínica
Electrónica. Pampona : SEIS, 2003.
16. Archivo de historias clínicas Digitalizado, una solución previa a la Historia
Clínica Electrónica. Ramos-López, J.M, Cuchí Alfaro, M y Sánchez Molano,
M.A. 2, s.l. : Sociedad Española de Documentación Médica (SEDOM), 2009, Papeles
Médicos, Vol. 18, págs. 4-10. ISSN: 1133-7591.
17. Mandirola Brieux, H. Biocom. [En línea] Julio de 2008.
http://www.biocom.com/informatica_medica/Despapelizacion%20Standards%20Stru
ctured%20Product%20Label.pdf.
18. Redacción. El Hospital de Elda inicia el escaneado de su archivo de historias
clínicas en papel. Diario Medico.com. 2010, Número 4.147.
19. Carnicero, J y Vazquez, JM. La identificación, un requisito previo a la
historia de salud electrónica. [aut. libro] J Carnicero Giménez de Azcárate, y otros.
V Informe SEIS: De la Historía Clínica a la Historia de Salud Electrónica.
20. Ministerio de Sanidad y consumo. Real Decreto 1277/2003, Bases generales
sobre autorización de centros, servicios y establecimientos sanitarios. BOE. 2003.
BOE-A-2003-19572.
21. SECTRA. Sectra Breast Imaging PACS. [En línea]
http://www.sectra.com/medical/mammography/solutions/pacs/pacs_workflow.html.
22. García, R. Tecnología y herramientas. [aut. libro] L Barrios, y otros. El sistema
integrado de información clínica. Pamplona : SEIS, 2004.
23. Las TIC’s en el marco de la e-Salud. García, J. 19, s.l. : RevistaeSalud.com,
2009, Vol. 5. ISSN: 1698-7969.
24. Comisión de las Comunidades Europeas. RECOMENDACIÓN DE LA
COMISIÓN sobre la interoperabilidad transfronteriza de los sistemas de historiales
84
médicos electrónicos. Bruselas : Diario Oficial de la Unión Europea, 2008.
2008/594/CE.
25. La terminología médica: diversidad, norma y uso. Díaz Rojo, J.A. [ed.]
MedTrad. 4, Junio de 2001, Panace@, Vol. 2, págs. 40-46. SSN: 1537-1964.
26. Instituto Quimíco Biológico. MedCiclopedia. [En línea]
http://www.iqb.es/mapa.htm.
27. European Commission – DG Information Society. Inventory of Relevant
Standards for EHR Systems. Regensburg : ProRec Germany, eHealth Competence
Center, 2007.
28. Monteagudo, JL y Hernandez, C. Estándares para la HCE. [aut. libro] J
Carnicero Giménez de Azcárate, y otros. V Informe SEIS. Pamplona : SEIS, 2003.
29. ISO. The ISO history. The Vienna Agreement. [En línea]
http://www.iso.org/iso/about/the_iso_story/iso_story_vienna_agreement.htm.
30. HL7. Health Level 7. Document Center. [En línea] 2000.
http://www.hl7.org/documentcenter/public/mou/CEN-TC251.pdf.
31. Joint Iniciative on SDO. [En línea] http://www.global-e-healthstandards.org/.
32. IEEE. [En línea] http://www.ieee.org/index.html.
33. ISO . [En línea] http://www.iso.org/iso/home.html.
34. ISOTC215. [En línea]
http://isotc.iso.org/livelink/livelink/fetch/4230450/4230458/customview.html?func=ll
&objId=4230458&objAction=browse&sort=subtype.
35. DICOM Homepage. [En línea] http://medical.nema.org/.
36. IEC. [En línea] http://www.iec.ch/.
37. HL7 International. [En línea] http://www.hl7.org/index.cfm.
38. IHE. [En línea] http://www.ihe.net/.
39. OASIS. [En línea] http://www.oasis-open.org/home/index.php.
40. IHC. [En línea] http://www.oasis-open.org/committees/ihc/charter.php.
41. OMG. [En línea] http://www.omg.org/.
42. UN/CEFACT. [En línea] http://www.unece.org/cefact/.
43. W3C. [En línea] World Wide Web Consortium.
44. ITU. [En línea] http://www.itu.int/en/pages/default.aspx.
85
45. ITU-T. [En línea] http://www.itu.int/ITU-T/.
46. CEN. [En línea] http://www.cen.eu/cen/pages/default.aspx.
47. CENTC251. [En línea] http://cen.iso.org/.
48. CEN/ISSS. [En línea]
http://www.cen.eu/cen/sectors/sectors/isss/pages/default.aspx.
49. CEN/ISSS e-Health. [En línea] http://www.cen.eu/cen/sectors/sectors/isss
/pages/eHealth_FG.aspx.
50. ETSI. [En línea] http://www.etsi.org/WebSite/homepage.aspx.
51. IHE Europe. [En línea] http://www.ihe-europe.net/.
52. CELENEC. [En línea] http://www.cenelec.eu/Cenelec/Homepage.htm.
53. ANSI. [En línea] http://www.ansi.org/.
54. ASTM. [En línea] http://www.astm.org/.
55. NEMA. [En línea] http://www.nema.org/.
56. IHTSDO. [En línea] http://www.ihtsdo.org/.
57. ICH. [En línea] http://www.ich.org/cache/compo/276-254-1.html.
58. World Health Organization. [En línea] http://www.who.int/.
59. WONCA. [En línea] http://www.globalfamilydoctor.com/.
60. ADA. [En línea] http://www.ada.org/.
61. AMA. [En línea] http://www.ama-assn.org/.
62. AORN. [En línea] http://www.aorn.org/.
63. APA. [En línea] http://www.psych.org/.
64. FDA. [En línea] http://www.fda.gov/.
65. NANDA Internacional. [En línea] http://www.nanda.org/.
66. VNA. [En línea] http://www.omahasystem.org/index.html.
67. Hearts Corporation. [En línea] http://www.hearst.com/.
68. HGNC. [En línea] www.hugointernational.org/comm_genenomenclaturecommittee.php.
69. Iowa University. [En línea] http://www.uiowa.edu/.
86
70. NCI. [En línea] http://www.cancer.gov/.
71. NHS. [En línea] http://www.nhs.uk/Pages/HomePage.aspx.
72. NLM. [En línea] , es un proyecto de EuroRec..
73. The Regentrief Institute. [En línea] http://www.regenstrief.org/.
74. NML. UMLS- Thesaurus Release source vocabularies. [En línea]
http://www.nlm.nih.gov/research/umls/knowledge_sources/metathesaurus/release/s
ource_vocabularies.html.
75. SNOMED-CT. Eritreros, J. Madrid : MSPS- 3º Foro sobre el Sistema de
Información del Sistema Nacional de Salud, 2003.
76. The Unified Medical Language System. Bodenreider, O, y otros. s.l. :
MedInfo, 2004.
77. XX Congreso Nacional de la Sociedad Española de Anatomía Patológica
(Patología). Sociedad Española de Anatomía Patológica. Pamplona : s.n.,
2001. ISBN: 84-699-5285-4.
78. IHTSDO. SNOMED CT® User Guide. 2008.
79. Comisión de las Comunidades Europeas. La salud electrónica – hacia una
mejor asistencia sanitaria para los ciudadanos europeos: Plan de acción a favor de
un Espacio Europeo de la Salud Electrónica. COMUNICACIÓN DE LA COMISIÓN
AL CONSEJO, AL PARLAMENTO EUROPEO, AL COMITÉ ECONÓMICO Y
SOCIAL EUROPEO Y AL COMITÉ DE LAS REGIONES. Bruselas : s.n., 2004.
COM(2004) 356 final.
80. Reig, J, Monteagudo, JL y Speilberg, T. La Historia de Salud Electronica:
Perspectiva Internacional. [aut. libro] J Carnicero Giménez de Azcárate, y otros. V
Informe SEIS: De la Historía Clínica a la Historia de Salud Electrónica.
81. Comisión europea. [En línea]
http://ec.europa.eu/information_society/eeurope/2005/index_en.htm.
82. Comunidad europea. Digital Agenda . Europa Information Society. [En línea]
http://ec.europa.eu/information_society/eeurope/2005/index_en.htm.
83. Comisión europea. Competitiveness and Innovation Framework Programme
(CIP). [En línea] http://ec.europa.eu/cip/.
84. Engelbrecht, R. EHR-systems certification criteria for better e-Health
management. Munich : EuroRec, 2008.
85. ProRec Irelad. Introduction. [En línea] http://www.prorecireland.ie/.
87
86. EuroRec. Q-Rec. [En línea] http://www.eurorec.org/RD/pastProject_QREC.cfm.
87. —. RIDE. [En línea] http://www.eurorec.org/RD/pastProject_RIDE.cfm.
88. —. EHR-Implement. [En línea]
http://www.eurorec.org/RD/EHR_implement.cfm.
89. —. [En línea] http://www.eurorec.org/.
90. —. EHR-Q-TN. [En línea] http://www.eurorec.org/RD/index.cfm.
91. e-Health- INTEROP. [En línea] http://www.ehealth-interop.nen.nl/.
92. Comisión Europea. Standardisation mandate addressed to CEN, CENELEC
and ETSI in the field of Information and Communication Technologies. Bruselas :
s.n., 2007. M/403 EN.
93. CLEF. [En línea] http://nlp.shef.ac.uk/clef/.
94. epSOS project. [En línea] http://www.epsos.eu/.
95. CALLIOPE. [En línea] www.calliope-network.eu/.
96. EHTEL. [En línea] http://www.ehtel.org/.
97. Cortes generales de España. Ley General de Sanidad. BOE. 102. ley
14/1986.
98. MSPS. Marco Estratégico para la mejora de la Atención Primaria en España:
2007-2012. Madrid : MSPS, 2007. Proyecto AP-21.
99. Servicio Andaluz de Salud (SAS). [En línea]
http://www.juntadeandalucia.es/servicioandaluzdesalud/principal/default.asp.
100. Servicio Aragonés de Salud (SALUD). [En línea]
http://portal.aragon.es/portal/page/portal/SAS.
101. Servicio de Salud del Principado de Asturias (SESPA). [En línea]
http://www.princast.es/servlet/page?_pageid=2245&_dad=portal301&_schema=PO
RTAL30.
102. Servicio de Salud de Las Islas Baleares (IB-SALUT). [En línea]
http://www.caib.es/govern/organigrama/area.do?lang=es&coduo=273.
103. Servicio Canario de Salud (SCS). [En línea]
http://www2.gobiernodecanarias.org/sanidad/scs/.
104. Servicio Cantabro de Salud (SCS). [En línea] http://www.scsalud.es/.
88
105. Servicio de Salud de Castilla La Mancha (SESCAM). [En línea]
http://sescam.jccm.es/web1/home.do.
106. Sanidad de Castilla y león (SACYL). [En línea]
http://sescam.jccm.es/web1/home.do.
107. Institut Català de la Salut (ICS). [En línea] http://www.gencat.cat/ics/.
108. Servicio Extremeño de Salud (SES). [En línea]
http://www.juntaex.es/consejerias/sanidad-dependencia/servicio-extremenosalud/index-ides-idweb.html.
109. Servizo Galego de Saúde (SERGAS). [En línea] http://www.sergas.es/.
110. Servicio Riojano de Salud (SERIS). [En línea] http://www.riojasalud.es/.
111. Servicio Madrileño de Salud (SERMAS). [En línea]
http://www.madrid.org/cs/Satellite?pagename=PortalSalud/Page/PTSA_home.
112. Servicio Murciano de Salud (SMS). [En línea]
http://www.murciasalud.es/principal.php.
113. Servicio Navarro de Salud (OSASUNBIDEA). [En línea]
http://www.navarra.es/home_es/Gobierno+de+Navarra/Organigrama/Los+departa
mentos/Salud/.
114. Servicio Vasco de Salud (OSAKIDETZA). [En línea]
http://www.osakidetza.euskadi.net/v19-oskhome/es/.
115. Agencia Valenciana de Salud (AVS). [En línea] http://www.san.gva.es/.
116. Instituto Nacional de Gestión Sanitaria (INGESA). [En línea]
http://www.ingesa.msc.es/.
117. IDC Consultores. Análisis Multicliente del Mercado Español de Tecnologías
de la Información en el Sector Sanitario. Madrid : IDC España, 2005.
118. MSPS. Las TIC en el SNS - El programa sanidad en línea. s.l. : red.es, 2010.
119. SCS. Drago - AP. [En línea]
http://www2.gobiernodecanarias.org/sanidad/scs/contenidoGenerico.jsp?idDocumen
t=771b94b5-089c-11de-8a2d-f3b13531fc76&idCarpeta=dd11d63d-af24-11dd-97eecf6480f43e6e.
120. —. Drago-WEB. [En línea]
https://www.gobiernodecanarias.org/dragoweb/index.htm.
121. MSPS. Conjunto Mínimo de Datos de Informes Clínicos. 2008.
122. —. POLITICA DE ESTÁNDARES Y NORMALIZACIÓN DE DATOS. 2008.
89
123. IHTSDO. IHTSDO-Spain. [En línea] http://www.ihtsdo.org/members/spain/.
124. MSPS. Documentación del pilotaje con las CCAA. 2008.
125. —. Nomenclator Digitalis. [En línea]
http://www.msc.es/profesionales/farmacia/nomenclatorDI.htm.
126. Madruga, M. Situación actual de las normas para farmacovigilancia. la
Granja de San Ildefonso : VIII Foro de Normalización de las TIC en Salud , 2010.
127. BOE. Real Decreto 4/2010.
128. —. Real Decreto 3/2010.
129. Cortes generales. Ley Orgánica 15/1999, de 13 de diciembre, de Protección
de Datos de Carácter Personal. BOE. 1999. 298. LEY ORGÁNICA 15/1999.
130. Instituto Nacional de Estadística (INE). Pirámides de población. [En
línea] http://www.ine.es/censos2011/censos2011_historia_piramides.htm.
131. García, M, Torres, MP y Ballesteros, E. El proceso de envejecimiento.
Enfermería Geriatrica. Barcelona : MASSON, SA, 2006.
132. Villa, J. II Congreso Nacional de Atención Sanitaria al Paciente Crónico.
Cuadernos. 2010. 228.
133. Innovaciones en la gestión de las enfermedades crónicas. Bengoa, R. 1718,
s.l. : JANO, 2008. 0210-220X.
134. Microsoft. Microsoft Health Vault. [En línea] http://www.healthvault.com/.
135. Google. Google Health. [En línea] http://www.google.com/intl/enUS/health/tour/.
136. Dossia. Dossia Personal Helath. [En línea] http://www.dossia.org//.
137. Microsoft. Microsoft Health Vault. Learn about devices. [En línea]
http://www.healthvault.com/Personal/devices-overview.aspx.
138. MyLifeRecord. [En línea] http://www.myliferecord.net/.
139. Frame, Health. [En línea] http://www.recordsforliving.com/HealthFrame/.
140. Vital Key. [En línea] http://www.vitalkey.com/.
141. Travelers Electronic Health Record. [En línea] http://www.trehrt.com/.
142. IHS. Microsoft, Google Programs for EHR use ASTM E2369. [En línea]
http://engineers.ihs.com/news/2009/microsoft-ehr-astm-041209.htm.
143. IBIME-UPV. LinkEHR Normalization Platform. [En línea]
http://www.linkehr.com/.
90
144. Proof-of-concept Design and Developement of an EN13606-based Electronic
Health Record Service. Muñoz, A, y otros. s.l. : Journal of the American Medical
Informatics Association (JAMIA), 2008, Vol. 14 . ISSN 1067-5027.
145. IBIME-UPV. Details on CEN/ISO EN13606 Invitational Workshop . [En
línea] http://pangea.upv.es/en13606/index.php/en13606-invitational-workshopmadrid-june-2010.
146. Comisión de las Comunidades Europeas. La telemedicina en beneficio de
los pacientes, los sistemas sanitarios y la sociedad. 2008. COM(2008)689 final.
147. MSPS. Plan de Calidad para el SNS - Tecnología / Tarjeta Sanitaria del SNS.
[En línea] http://www.msps.es/organizacion/sns/planCalidadSNS/tic01.htm.
148. MedlinePlus. [En línea] http://www.nlm.nih.gov/medlineplus/.
149. Sociedad Española para el Estudio de la Obesidad (SEEDO). [En línea]
http://www.seedo.es/.
150. American National Standards Institute. [En línea] http://www.ansi.org/.
151. ISO. ISO - Technical committees. TC215 - Health Informatics. [En línea]
http://www.iso.org/iso/iso_technical_committee?commid=54960.
152. WHO | The Anatomical Therapeutic Chemical Classification System with
Defined Daily Doses (ATC/DDD). [En línea]
http://www.who.int/classifications/atcddd/en/.
153. National Library of Medicine. UMLS® Metathesaurus®. UMLS®
Metathesaurus®. [En línea]
http://www.nlm.nih.gov/pubs/factsheets/umlsmeta.html.
154. The University of Iowa - College of Nursing. [En línea]
http://www.nursing.uiowa.edu/excellence/nursing_knowledge/clinical_effectiveness/
nic.htm.
155. The University of Iowa - College of Nursing. [En línea]
http://www.nursing.uiowa.edu/excellence/nursing_knowledge/clinical_effectiveness/
noc.htm.
156. Casado López, M. Ministerio de Sanidad y Política Social. 3 Foro sobre
Sistema de Información Sanitaria del SNS. [En línea] Octubre de 2009. [Citado el:
]
http://www.msps.es/estadEstudios/estadisticas/sisInfSanSNS/3ForoSISNS/docs/Ma
rianoCasado_ponencias3Foro.pdf.
157. WHO | International Classification of Primary Care, Second edition (ICPC-2).
[En línea] http://www.who.int/classifications/icd/adaptations/icpc2/en/index.html.
158. loinc.org/. [En línea] http://loinc.org/.
91
159. Ingram, D. openEHR. The origin of EHR. [En línea] 2002.
http://www.openehr.org/about/origins.html#dsy20-OE_centc251.
160. Schloeffel, P, y otros. Ocean Informatics. [En línea]
http://www.oceaninformatics.com/Media/docs/Relationship-between-CEN-13606HL7-CDA--openEHR-2ba3675f-2136-4069-ac5c-152139c70bd0.pdf.
161. openEHR. progress on openEHR IP, SNOMED CT, IHTSDO collaboration.
[En línea] Julio de 2010. http://www.openehr.org/299OE.html?branch=1&language=1.
162. Vallecino, A. Institute for Enterprise Architecture Developers. [En línea]
http://www.enterprise-architecture.info/Images/Documents/RM-ODP.pdf.
163. Villagrasa, J. HL7 spain. [En línea]
http://www.hl7spain.org/Ficheros/0/Documentos/SemHL7%20Detalles%20V2%281
%29.pdf.
164. Villalta, J. HL7 Spain. [En línea]
http://www.hl7spain.org/Ficheros/0/Documentos/semHL7_presentacionV3%282%29
.pdf.
165. —. HL7 Spain. Documentación. [En línea] 2004.
http://www.hl7spain.org/Ficheros/0/Documentos/semHL7_presentacionV3%282%29
.pdf.
166. —. HL7Spain. [En línea]
http://www.hl7spain.org/Ficheros/0/Documentos/semHL7_introCDA%281%29.pdf.
167. CEN/ISO. Health Informatics - Electronic Health Record Communication.
Parts 1-5. 2008. ISO/EN 13606: 2008.
168. ISO/IEEE. Health Informatics - Personal Health Device communication. Part
20601: Application profile- Optimized Exchange protocol. 2008. IEEE Std 1107320601™-2008.
169. Consejo nacional de la población. Envejecimiento de la población mundial.
[En línea] http://www.conapo.gob.mx/publicaciones/enveje2005/enveje01.pdf.
170. Ministerio de Educación. Intituto de Tecnologías Educativas. Evolución de
la población. [En línea]
http://ficus.pntic.mec.es/ibus0001/poblacion/evolucion_poblacion.html.
171. Naciones Unidas. Desarrollo en un mundo que envejece. Estudio económico y
social mundial . s.l. : Departamento de Información Pública, 2007. DPI/2460D.
172. INE. Proyección de la Población de España a Corto Plazo, 2008-2018. 2009.
92
173. Comisión de las Comunidades europea. «Juntos por la salud: un
planteamiento estratégico para la UE (2008-2013)». Bruselas : s.n., 2007. COM
(2007) 630. COM (2007) 630.
174. Oxford Health Alliance. [En línea]
ttp://www.oxha.org/initiatives/economics/chronic-disease-an-economic-perspective.
175. Beale, T y Heard, S. Archetype Definition Language (ADL 1.4). s.l. :
openEHR, 2007.
176. Diemer s.l. [En línea] http://www.diemersl.com/index2.htm.
177. Accu-chek. [En línea] http://www.accu-chek.es/es/.
178. Biox. [En línea]
http://www.biox.com.cn/bioxen/ArticleShow.asp?ArticleID=461.
179. Omrom. [En línea] http://www.omron.com/.
180. Quirumed. [En línea] www.quirumed.com.
181. A&D. [En línea] http://www.andweighing.com/.
182. Microlife. [En línea] http://www.microlife.es/.
183. Suministros médicos. [En línea] http://www.suministromedico.com.
184. MedLine Plus. Examen de glucemia. [En línea]
http://www.nlm.nih.gov/medlineplus/spanish/ency/article/003482.htm.
185. Familidoctor.org. Diabetes y nutrición. [En línea]
http://familydoctor.org/online/famdoces/home/common/diabetes/living/349.html.
186. Diabetesvoice.org. [En línea]
http://www.diabetesvoice.org/files/attachments/article_450_es.pdf.
187. Autocontrol de la glucosa en la sangre. Gonzalez, A. 5, s.l. : The Journal of
Clinical Endocrinology & Metabolism , 2007, Vol. 92.
188. Fisterra. Determinación de la temperatura corporal. [En línea]
http://www.fisterra.com/material/tecnicas/temp/temp.asp.
189. portalesmedicos.com. [En línea]
http://www.portalesmedicos.com/publicaciones/articles/410/1/Constantes-vitalesTemperatura-corporal-pulso-frecuencia-respiratoria-presion-arterial-Enfermeriamedica-Apuntes-de-enfermeria.html.
190. Mafresa. [En línea] http://www.rincondelasalud.com/es/articulos/saludgeneral_la-fiebre_20.html.
93
191. familidoctor.org. Presión arterial sanguinea. [En línea]
http://familydoctor.org/online/famdoces/home/common/heartdisease/risk/092.html.
192. Medline. Presión arterial. [En línea]
http://familydoctor.org/online/famdoces/home/common/heartdisease/risk/092.html.
193. botanical-online. Presión arterial. [En línea] http://www.botanicalonline.com/medicinalshipertension.htm.
194. Medline. Pulso. [En línea]
195. misrespuestas.com. salud- Pulso. [En línea]
http://www.misrespuestas.com/que-es-el-pulso.html.
196. vida y salud. El ritmo cardiaco o pulso. [En línea]
http://www.vidaysalud.com/daily/corazon/el-ritmo-cardiaco-o-pulso/.
197. Europapress. europapress.es. Vivir a mucha altitud puede ayudar a perder
peso. [En línea] http://www.europapress.es/chance/elbuenvivir/noticia-vivir-muchaaltitud-puede-ayudar-perder-peso-20100205163632.html.
198. MedLine. [En línea] http://www.vidaysalud.com/daily/corazon/el-ritmocardiaco-o-pulso/.
199. fisterra. Espirometria. [En línea]
http://www.fisterra.com/material/tecnicas/espirometria/espirometria.asp.
200. Sociedad Española de Neumología y Cirugía Torácica. [En línea]
http://www.separ.es/doc/publicaciones/normativa/normativa_001.pdf.
201. medicinapreventiva.com. [En línea]
http://www.medicinapreventiva.com.ve/espirometria.htm.
202. fisterra. Espirometria. [En línea]
http://www.fisterra.com/material/tecnicas/espirometria2/espirometria.asp.
203. Sociedad Castellano Leonesa de Patología Respiratoria. [En línea]
http://www.socalpar.es/cursos_documentos/tecnica_de_realizacion.htm.
204. Grupo prevenir. Espirometria. [En línea]
http://www.grupoprevenir.es/pruebas_medicas/espirometria.html.
205. Magdalena Mateos, F. http://www.eccpn.aibarra.org/. [En línea]
http://www.eccpn.aibarra.org/temario/seccion4/capitulo56/capitulo56.htm.
206. Robledo Carmona, JM, Jimenez Navarro, M y Robledo Carmona, L.
http://www.medynet.com/. [En línea]
http://www.medynet.com/usuarios/jraguilar/Manual%20de%20urgencias%20y%20E
mergencias/ecg.pdf.
94
207. MedLine. Electrocardiograma. [En línea]
208. Magdaleno, F. Electrocardiograma. [En línea]
http://www.eccpn.aibarra.org/temario/seccion4/capitulo56/capitulo56.htm.
209. osakidezta. [En línea]
http://urgenciaspediatria.hospitalcruces.com/doc/generales/proto/Cap4.7_electrocar
diograma.pdf.
210. Lab Test Online. Lab Test Online. [En línea]
http://www.labtestsonline.es/tests/LipidProfile.html.
211. MedlinePlus. Perfil Lipídico. [En línea]
212. abajarcolesterol. [En línea] http://www.abajarcolesterol.com/%C2%BFcomose-diagnostica-una-dislipidemia/.
213. MedLine. Diabetes. [En línea]
214. fundaciondiabetes. La diabetes. [En línea]
http://www.fundaciondiabetes.org/box02.htm.
215. Sociedad Española de la Diabetes. La diabetes. [En línea]
http://www.sediabetes.org/apartado.asp?seccion=6&apartado=27&iMenu=8.
216. familidoctor.org. La diabetes. [En línea]
http://familydoctor.org/online/famdoces/home/common/diabetes/living/356.html.
217. Medline Plus. Hipertensión. [En línea]
218. Sociedad española de Hipertensión (SEH). Documentación. [En línea]
http://www.seh-lelha.org/documentos.htm.
219. dmedicina. Enfermedades: Hipertensión. [En línea]
http://www.dmedicina.com/enfermedades/enfermedades-vasculares-y-delcorazon/hipertension-arterial.
220. saludvascular.com. Hipertensión. [En línea]
http://www.saludvascular.es/518466/.
221. SEEDO. Obesidad y Salud. [En línea]
http://www.seedo.es/Obesidadysalud/tabid/108/Default.aspx.
222. OMS. Obesidad y sobrepeso. [En línea]
http://www.who.int/mediacentre/factsheets/fs311/es/index.html.
95
223. MedLine. Sobrepeso. [En línea]
224. sobrepeso.es. Sobrepeso. [En línea] http://www.sobrepeso.es/.
225. finisterra. EPOC. [En línea] http://www.fisterra.com/guias2/epoc.asp.
226. familidoctor.org. EPOC. [En línea]
http://familydoctor.org/online/famdoces/home/articles/706.html.
227. forumclinic.org. EPOC. [En línea]
http://www.forumclinic.org/enfermedades/epoc.
228. todoasma.org. Asma. [En línea] http://www.todoasma.com/.
229. MedLine. Asma. [En línea]
http://www.nlm.nih.gov/medlineplus/spanish/asthma.html.
230. Asmayvida.com. Asma. [En línea] https://www.asmayvida.com/Default.aspx.
231. Instituto nacional del cáncer. Cancer. [En línea]
http://www.cancer.gov/espanol.
232. MedLine. SIDA. [En línea]
233. fundacionbelen.org. Movilidad reducida. [En línea]
http://www.fundacionbelen.org/base_datos/movilidad_reducida.html.
234. Puleva Salud. Discapacidad. [En línea]
http://www.pulevasalud.com/ps/subcategoria.jsp?ID_CATEGORIA=1004.
235. Claves de la evolución demográfica en el cambio de milenio. Solsona, M y
Viciana, F. suppl1 pp.08-15, Barcelona : Elsevier España, S. L., mayo de 2004,
Gaceta Sanitaria, Vol. 18. ISSN 0213-9111.
236. Gonzalez López-Valcarcel, B. Instituto de Estudios Fiscales. Instituto de
Estudios Fiscales. [En línea] Octubre de 2004.
http://www.ief.es/investigacion/Recursos/Seminarios/EconomiaPublica/2004_07octu
bre.pdf.
237. SESPAS. Informe SESPAS 2003: Invertir para la salud. Prioridades en salud
pública. s.l. : SESPAS, 2003. ISBN: 84-482-3280-1. .
238. openEHR Fundation. [En línea] http://www.openehr.org/home.html.
239. http://www.nlm.nih.gov/medlineplus/. [En línea]
240. tuotromedico.com. Glucosa en sangre. Análisis de glucosa en sangre. [En línea]
http://www.tuotromedico.com/temas/glucosa_en_sangre.htm.
96
241. Dulce diabetes. Examen. [En línea]
http://www.dulcediabetes.com/html/contenido_4.html.
242. systems, Alma. [En línea]
97
98
Anexos
99
Anexos.
100
Anexo A: Historia Clinica Electrónica y normalización.
Anexo A . Historia Clínica Electrónica y
normalización.
La implementación de un sistema de HCE puede realizarse bajo cualquier tipo
de premisa o arquitectura. Pero si se aspira a conseguir interoperabilidad hay una
serie de requisitos que deberán cumplirse. Estos requisitos necesitan ser fijados de
alguna manera y la forma de hacerlo es mediante estándares y normas. Debido a la
universalidad del problema, numerosas instituciones han lanzado propuestas
acerca del uso de herramientas (sistemas de codificación y clasificación, propuestas
de transmisión de la información, etc.) que permitan la transmisión de la HCE de
forma interoperable. En los siguientes apartados se enunciarán las organismos y
herramientas más relevantes para lograr este propósito.
A.1 Instituciones, normas y estándares.
Entre las instituciones que se han listado en la sección 1.1 se pueden encontrar:
 ANSI (53), como representante oficial de ISO en los Estados Unidos (EEUU).
Coordina tanto el desarrollo como la adopción de estándares en EEUU y tiene
capacidades de acreditación.
 ASTM (54), acreditada por ANSI. El comité técnico E31 es el encargado de la
informática médica, el cual ha desarrollado una serie de estándares
internacionales como el CCR o el ASTM E1238-97 Standard que es una
especificación para la transferencia de de observaciones clínicas entre sistemas
informáticos independientes.
 CEN (46), como referencia a nivel europeo. En concreto el encargado de tratar
los temas relacionados dentro de la informática médica es el CENTC251 (47),
que posee espejos nacionales en todos los países miembros de esta organización.
Entre sus aportaciones se pueden destacar normas como la EN 13606 para el
intercambio de información médica, HISA (EN 12967), el cual define una
arquitectura estándar para sistemas de información de cuidado de la salud y
CONTSYS (EN13940), un sistema de conceptos que define la continuidad del
cuidado. Otras organizaciones relevantes son CEN/ISSS (48) y en concreto su
grupo de salud CEN/ISSS e-Health (49) que realiza investigación específica en el
ámbito de la e-Salud, o CELENEC (52) que trabaja en temas relacionados con la
armonización de estándares.
 DICOM (35) , que se centra en las comunicaciones e intercambio de imágenes
médicas. Fue fundada por NEMA, y desde entonces comenzó a establecer
relaciones con otros organismos como el ASTM, HL7 o CEN.
 ETSI (50), debido a su experiencia en la estandarización de sistemas y servicios
de telecomunicaciones, tanto fijos como móviles. La ETSI es el principal
organismo de estandarización de las TICs en Europa.
 HL7 (37) es una SDO en el dominio de la salud, tanto información clínica como
administrativa: farmacia, imágenes diagnósticas, seguridad del paciente, etc.
Está avalada por ANSI (150) y como su nombre refleja, los estándares que
produce están referidos a la séptima capa del Modelo OSI (Open System
Intercommunication Model).
 IEC (36) que se encarga del desarrollo de estándares para tecnologías
eléctricas, electrónicas o relacionadas con estos ámbitos.
101
Anexos.
 IHE (38) es una iniciativa entre profesionales de la sanidad y empresas cuyo
objetivo es mejorar las comunicaciones entre los distintos sistemas sanitarios.
Su aportación estriba en la definición de casos de uso específicos para el
intercambio de información. Entre ellos los más conocidos son el Pacient Care
Coordination (PCC) y Cross Enterprise Document Sharing (XDS). También se
encarga de la promoción de otros estándares como DICOM o HL7.
 ISO (33), cuya principal actividad es el desarrollo de normas técnicas en
cualquier ámbito y para ello colabora con varias instituciones internacionates
como ITU-T o IEC. El ámbito de la informática médica esta tratado por el
ISO/TC215, el cual a su vez se divide en diferentes subcomités que trabajan en
ámbitos distintos como son (129): Data structure, Data interchange, Semantic
Content, Security, Pharmacy and medicines busines, Devices, Business
requirements for Electronic Helath Records y SDO Harminization.
 IEEE (32) que desarrolla estándares en una gran cantidad de campos, incluido
el ámbito de la salud donde mantiene relaciones con ISO/TC 215 y CEN/TC 251.
Por ejemplo, gracias al acuerdo con ISO/TC 215 representantes de IEEE pueden
participar en las votaciones a través de la coordinación internacional, aunque
sus votos no son vinculantes.
 ITU (44), dado que su principal función es la coordinación en el funcionamiento
en redes de telecomunicación y sus servicios, así como el desarrollo de
tecnologías de la comunicación. De especial relevancia será la ITU-T (45), pues
su campo de actuación es el de las telecomunicaciones.
 NEMA (51), que proporciona estándares para dispositivos eléctrico y los publica
a través de ANSI o IEC.
 OASIS (39), una organización sin ánimo de lucro que cuyos objetivos conducen
hacia el desarrollo, convergencia y adopción de estándares de lógica de negocio
(e-Business). En el campo de la salud se encarga de ello IHC (40), encargado de
articular los requerimientos para estándares basado en WS y XML.
 OMG (41), que produce y mantiene especificaciones para el desarrollo de
aplicaciones empresariales interoperables.
 W3C (43), como referente internacional en el desarrollo de estándares para
web.
Los estándares referentes en el desarrollo de HCE corresponden a diferentes
ámbitos de aplicación: análisis y requerimientos (ver Tabla A-1), arquitectura(ver
Tabla A-2), modelado y metodología (ver Tabla A-3), comunicación (ver Tabla A‐1),
infraestructura (ver Tabla A-5), privacidad (ver Tabla A-6), seguridad (ver
Tabla A-7), de token (ver Tabla A-8), calidad (ver Tabla A-9), de políticas (ver
Tabla A-10), terminología y ontologías (ver Tabla A-12) y gestión segura de la
identidad(ver Tabla A-11).
HI =Health Informatics, IT = Information Technologies, ISMS =Information Security Management Systems
SAGE = Security Algorithms Group of Experts, ESI = Electronic Signatures and Infrastructures
ASTM E2212-02a
Standard Practice for Healthcare Certificate Policy
ISO 18812:2003
HI - Clinical analyser interfaces to laboratory information systems – Use
profiles
ISO 22857:2004
HI - Guidelines on data protection to facilitate trans-border flows of
personal health information
ISO TR 20514:2005
HI - EHR - Definition, scope and context
ISO TS 18308:2004
HI - Requirements for an electronic health record architecture
Tabla A-1. Estándares sobre requerimientos y análisis de sistemas de HCE.
102
CEN EN 12967:2006
HI - Service architecture (HISA) - Part 1: Enterprise viewpoint - Part
2: Information viewpoint - Part 3: Computational viewpoint (HISA)
CEN EN 13606:2006
HI - EHR communication – Part 1: Reference model - Part 4: Security
requirements and distribution rules
Tabla A-2. Estándares sobre arquitectura en sistemas de HCE.
ASTM E1715-01
ASTM E2085-00a
IETF RFC 3281
CEN CR 12587
CEN EN 13940:2006
CEN EN 14463:2006
An object-oriented model for registration, admitting, discharge, and
transfer functions in computer-based patient record systems
Standard guide on security framework for healthcare information
An Internet Attribute Certificate Profile for Authorization
CEN Report: Medical Informatics - Methodology for the development of
healthcare messages
HI - System of concepts to support Continuity of care - Part 1: Basic
concepts
HI - A syntax to represent the content of medical classification systems
(ClaML)
CEN ENV 13940:2002
HI - System of concepts to support continuity of care
CEN TR 15300
CEN Report: Health Informatics - Framework for formal modelling of
healthcare security policies
ISO HL7 21731:2006
ISO DIS 27799
ISO IEC 10118
ISO IEC 10181
ISO IEC 10736
ISO IEC 10745
ISO IEC 13335:2004
ISO IEC 15408:2005
HI - HL7 version 3 - Reference information model - Release 1
HI - Security management in health using ISO/IEC 17799
IT - Security techniques - Hash-functions
IT - Open Systems Interconnection – Security frameworks for open
systems
IT, Telecommunications and information exchange between systems,
Transport layer security protocol
IT, Open Systems Interconnection, Upper layers security model
IT - Security techniques - Management of information and
communications technology security - Part 1: Concepts and models for
information and communications technology security management
IT - Security techniques - Evaluation criteria for IT security - Part 1:
Introduction and general model- Part 2: Security functional
requirements - Part 3: Security assurance requirements
ISO IEC 27001:2005
IT - Security techniques – ISMS - Requirements
ISO IEC 27002
Previous ISO/IEC 17799:2005 Information technology – Security
techniques - Code of practice for information security management
ISO IEC 27003
ISO IEC 27004
ISO IEC 27005
ISO IEC NP 27000
ISMS- Implementation guidance
ISO IEC TR
13335:1998
IT - Guidelines for the management of IT Security - Part 3: Techniques
for the management of IT Security - Part 4: Selection of safeguards Part 5: Management guidance on network security
ISO PAS 28000:2005
Security management systems for the supply chain
ISO PAS 28003:2006
Security management systems for the supply chain – Requirements for
bodies providing audit and certification of supply chain security
management systems
ISMS - Measurements
ISMS- Risk assessment
IT - Information security management - fundamentals and vocabulary
Tabla A-3. Estándares sobre modelado y metodología en sistemas de HCE.
103
Anexos.
CEN EN 1064:2006
HI - Standard communication protocol - Computer-assisted
electrocardiography
CEN EN 12052:2005
HI - Digital imaging - Communication, workflow and data
management
CEN EN 13608-1:2006
HI - Security for healthcare communication – Part 1: Concepts and
terminology – Part 2: Secure data objects – Part 3: Secure data
channels
CEN EN 13609-1:2005
HI - Messages for maintenance of supporting information in
healthcare systems - Part 1: Updating of coding schemes
CEN EN 14720-1:2006
HI - Service request and report messages - Part 1: Basic services
including referral and discharge
CEN EN 14822:2006
HI - General purpose information components - Part 1: OverviewPart 2: Non-clinical - Part 3: Clinical
CEN ENV 13607:2000
HI - Messages for the exchange of information on medicine
prescriptions
CEN ENV 13609:2000
HI - Messages for maintenance of supporting information in
healthcare systems - Part 2: Updating of medical laboratory-specific
information
CEN ENV 13730:2002
HI - Blood transfusion related messages - Part 1: Subject of care
related messages
CEN TS 14822-4:2006
HI - General purpose information components - Part 4: Message
headers
ETSI ETR 277
(March 1996)
SAGE; Requirements specification for an encryption algorithm for
use in audio visual systems
ETSI ETR 278
(March 1996)
SAGE; Report on the specification and evaluation of the GSM cipher
algorithm A5/2
ETSI SR 002 176
V1.1.1 (2003-03)
ESI; Algorithms and Parameters for Secure Electronic Signatures
ETSI SR 002 298
V1.1.1 (2003-12)
Response from CEN and ETSI to the "Communication from the
Commission to the Council, the European Parliament, the European
Economic and Social Committee and the Committee of the Regions:
Network and Information Security: Proposal for a European Policy
Approach"
ETSI TR 101 375
V1.1.1 (1998-09)
SAGE; Report on the specification, evaluation and usage of the GSM
GPRS Encryption Algorithm (GEA)
ETSI TR 101 690
V1.1.1 (1999-08)
SAGE; Rules for the management of the GSM CTS standard
Authentication and Key Generation Algorithms (CORDIAL)
ETSI TR 101 740
V1.1.1 (1999-08)
SAGE; Rules of the management of the standard GSM GPRS
Encryption Algorithm 2 (GEA2)
ETSI TR 102 038
V1.1.1 (2002-04)
TC Security - Electronic Signatures and Infrastructures (ESI); XML
format for signature policies
ETSI TR 102 047
V1.2.1 (2005-03)
International Harmonization of Electronic Signature Formats
ETSI TR 102 272
V1.1.1 (2003-12)
ESI; ASN.1 format fo signature policies
ETSI TS 101 733
Electronic Signature Formats
ETSI TS 101 862
Qualified Certificate profile
104
TS 101 903 V1.2.2
(2004-04)
XML Advanced Electronic Signatures (XAdES)
ETSI TS 102 023 V1.2.1
(2003-01)
ESI; Policy requirements for time-stamping authorities
ETSI TS 102 176
V1.2.1 (2005-07)
ESI; Algorithms and Parameters for Secure Electronic Signatures;
Part 1: Hash functions and asymmetric algorithms - Part 2: Secure
channel protocols and algorithms for signature creation devices
ISO 12052:2006
HI - Digital imaging and communication in medicine (DICOM)
including workflow and data management
ISO 17432:2004
Health informatics - Messages and communication - Web access to
DICOM persistent objects
ISO 18232:2006
HI - Messages and communication - Format of length limited
globally unique string identifiers
ISO IEC 13888
IT – Security techniques – Non-repudiation
ISO IEC 14888
IT, Security techniques, Digital signature with appendix, multiple
Parts (1-3).
ISO IEC 9796
IT, Security techniques, Digital signature scheme giving message
recovery, multiple Parts (1-2).
ISO IEC 9797
IT, Security techniques, Message authentication codes.
ISO IEC 9798
IT - Security techniques – Entity authentication
ISO TR 21089:2004
HI - Trusted end-to-end information flows
NEMA DICOM 3.0
Digital Imaging and Communications in Medicine
Tabla A-4. Estándares sobre comunicación en sistemas de HCE.
ETSI TS 101 861 V1.3.1 (2006-01)
Time stamping profile
ISO IS 17090:2002
HI - Public key infrastructure - Part 1: Framework and
overview - Part 2: Certificate profile - Part 3: Policy
management of certification authority
ISO TS 21091:2005
HI - Directory services for security, communications and
identification of professionals and patients
ISO TS 21298
Functional and structural roles
ISO IEC 27001:2005
IT - Security techniques – ISMS) – Requirements
ISO/IEC 15816:2002
(ITU-T X.841)
IT - Security techniques – Security information objects for
access control
ISO/IEC TR14516:2002
(ITU-TX.842)
IT - Security techniques - Guidelines for the use and
management of Trusted Third Party services
ISO/IEC 15945:2002
(ITU-T X.843)
IT - Security techniques - Specification ofTTP services to
support the application of digital signatures
ITU-T X.1051
ISMS - Requirements for telecommunications (ISMS-T)
NIST Special Publication 800-61
Computer Security Incident Handling Guide
CORBA
Common Object Request Broker Architecture
Tabla A-5. Estándares sobre infraestructuras en sistemas de HCE.
105
Anexos.
Standard guide for properties of a Universal Healthcare Identifier
ASTM E1714-00
Standard guide for individual rights regarding health information
ASTM E1987-98
CEN EN 14484:2004
HI - International transfer of personal health data covered by the
EU data protection directive - High level security policy
CEN EN 14485:2004
HI - Guidance for handling personal health data in international
applications in the context of the EU data protection directive
CEN ENV 12924
Medical Informatics - Security Categorisation and Protection for
Healthcare Information Systems
ISO IEC DTS 25237
HI: Pseudonymisation Practices for the Protection of Personal
Health Information and Health Related Services
ISO TS 21091
HI - Directory Services for Security, Communications, and
Identification of Professionals and Patients
ISO 22857:2004
HI - Guidelines on data protection to facilitate trans-border flows of
personal health information
ISO TS 22600:2006
HI - Privilege management and access control - Part 1: Overview
and policy management- Part 2: Formal models
ISO/IEC PDTS 25237
HI: Pseudonymisation Practices for the Protection of Personal
Health Information and Health Related Services
OASIS 200201
Directory Services Mark-up Language (DSML) v2.0
OASIS SAML
Security Assertion Mark-up Language (SAML) v2.0
OASIS SPML
Service Provisioning Markup Language (SPML) v2.0
OASIS XACML
eXtensible Access Control Mark-up Language TC v2.0 (XACML)
Tabla A-6. Estándares sobre privacidad en sistemas de HCE.
CEN CR 13694
CEN Report: Health Informatics - Safety and security related
software quality standards for healthcare (SSQS)
CEN TR 15299
HI - Safety procedures for identification of patients and related objects
CEN TS 15260
HI - Categorisation of risks from health informatics products
ISO DTS 25238
HI - Classification of safety risks from health informatics products
ISO TR 21730:2005
HI - Use of mobile wireless communication and computing technology in
healthcare facilities – Recommendations for the management of
unintentional electromagnetic interference with medical devices
Tabla A-7. Estándares sobre seguridad en sistemas de HCE.
CEN ENV13729
HI - Secure user identification – Strong authentication using
microprocessor cards
CEN ENV 1387
Machine readable cards - Health care applications - Cards: General
characteristics
CEN ENV 1867
Machine readable cards - Health care applications – Numbering system
and registration procedure for issuer identifiers
CEN ENV 13735
HI - Interoperability of patient connected medical devices
ISO 20301
HI - Health cards - general characteristics
ISO 20302
HI - Health cards - numbering system and registration procedure for
issuer identifiers
ISO 21549
HI - Patient health card data
Tabla A-8. Estándares sobre token en sistemas de HCE.
106
STM E2117-00
Standard guide for identification and establishment of a quality
assurance program for medical transcription
ISO 13485:2003
Medical devices - Quality management systems – Requirements for
regulatory purposes
ISO 14969:2004
Medical devices - Quality management systems - Guidance on the
application of ISO 13485
ISO 15378:2006
Primary packaging materials for medicinal products – Particular
requirements for the application of ISO 9001:2000, with reference to
Good Manufacturing Practice (GMP)
ISO 9000:2005
Quality management systems - Fundamentals and vocabulary
ISO 9001:2000
Quality management systems - Requirements
ISO TS 16949:2002
Quality management systems - Particular requirements for the
application of ISO 9001:2000 for automotive production and relevant
service part organizations
IWA 4:2005
Quality management systems - Guidelines for the application of
ISO 9001:2000 in local government
CEN CR 13694
CEN Report: Health Informatics - Safety and security relatedsoftware
quality standards for healthcare (SSQS)
Tabla A-9. Estándares sobre calidad en sistemas de HCE
ASTM E2212-02ª
Standard Practice for Healthcare Certificate Policy
Tabla A-10. Estándares sobre políticas en sistemas de HCE
CORBA PIDS
Person Identification Service
HL7/CORBA EIS
Entity Identification Service
HL7 MPI
Master Patient Index
ISO
Digital Object Identifier
LOINC
Logical Observation Identifiers Names and Codes
ASTM E1714-00
Standard guide for properties of a Universal Healthcare Identifier
Tabla A-11. Estándares sobre seguridad en la gestión de identidades en sistemas de HCE.
107
Anexos.
ASTM E1633-02a
Standard Specification for Coded Values Used in the Electronic Health
Record
ASTM E2457-06
Standard Terminology for Healthcare Informatics
CCOW v1.5
Clinical Context Object Workgroup Version 1.5
CEN EN 1068:2006
HI - Registration of coding systems
CEN EN 12264:2005
HI - Categorial structures of systems of concepts - Model for
representation of semantics
CEN EN 12435:2006
HI - Expression of the results of measurements in health sciences
CEN EN 15521:2006
HI - Categorical structure for terminologies of human anatomy
CEN EN 1614:2005
HI - Structure for nomenclature, classification, and coding of
properties in clinical laboratory sciences
CEN EN 1828
Categorial structure for classifications and coding systems of surgical
procedures
CEN EN 1828:2002
HI - Categorial structure for classification and coding systems of
surgical procedures
CEN ENV 12017
Medical Informatics Vocabulary (MIVoc)
CEN ENV 12611
Categorial structure of systems of concepts - medical devices
CEN TS 14463:2006
HI - A syntax to represent the content of medical classification systems
(ClaML)
HL7v2.XML
HL7 Version 2.5
ISO 15225:2000
Specification for a nomenclature system for medical devices for the
purpose of regulatory data exchange
ISO 18104:2003
Health informatics - Integration of a reference terminology model for
nursing
ISO 19218
Medical devices - Coding structure for adverse event type and cause
ISO 20225
Global medical device nomenclature for the purpose of regulatory data
exchange
ISO 21731
HL7 version 3 - Reference information model
ISO TS 17117:2002
HI - Controlled health terminology - Structure and
indicators
ISO TS 21667:2004
Health informatics - Health indicators conceptual framework
LOINC
LOINC
high-level
Tabla A-12. Estándares sobre terminologías y ontologías en sistemas de HCE.
108
A.2 Terminología médica y codificación.
La terminología médica y codificación de conceptos se desarrollan por diferentes
tipos de organizaciones, principalmente colegios y asociaciones profesionales pues
serán principalmente los miembros de esa institución los usuarios de la
terminología en sí. Sin embargo, algunas de esas de esas codificaciones han
adquirido importancia internacional al ser comúnmente aceptadas, como por
ejemplo el DSM-IV, desarrollado por la APA, que es el principal sistema de
codificación en temas psiquiátricos. Otras han conseguido el apoyo de instituciones
relevantes internacionales como la ICD (CIE en español) por parte de la OMS. En
cualquier caso, y debido a estos hechos, la mayor parte de las terminologías son
muy sectoriales, se refieren a un campo específico de la medicina salvo dos
excepciones UMLS thesaurus, compuesta por la agregación de diferentes
terminologías médicas, y SNOMED-CT, que se perfila como terminología de
referencia en el marco internacional.
La descoordinación entre organizaciones ha causado la concurrencia de distintas
terminologías centradas en la misma temática, como 3M Health Information
Systems (EE.UU) Su objetivo era reemplazar al IDC-9-CM (77). Algunas opciones
adicionales de las mencionadas en la sección 1.1 son:
 CDAM: Catalogue des Actes Médicaux (Francia)
 INAMI: Nomenclature des Actes de l`institut National d'Assurance contre la
Maladie et l'Invalidité (Bélgica)
 NSLO: Nordic Short List of Surgical Operations (Países Nórdicos)
 VESKA-Operationsschlüssel (Suiza)
 ICCS: International Classification of Clinical Services (EE.UU) (facturación.)
 QML: Quick Medical Language, que ya se encuentra en desuso. Para médicos
internistas, de diagnostico.
Entre las terminologías referenciadas en el apartado 1.1, se pueden destacar
aquellas más conocidas agrupadas por las organizaciones que las promueven y/o
desarrollan:
 Organización Mundial de la Salud (OMS), o en ingles World Health
Organization (WHO), es la autoridad coordinadora de la acción sanitaria en el
sistema de Naciones Unidas. Este organismo ha promovido una familia de
clasificaciones internacionales (WHO – FIC),
que comprende 3 ejes:
International Classification of Diseases (ICD), International Classification of
Functioning, Disability and Health (ICF), International Classification of Health
Interventions (ICHI) :
o En la IDC, o Clasificación estadística Internacional de Enfermedades y otros
problemas de salud (CIE) en español, se determinan los códigos utilizados
para clasificar las enfermedades y una amplia variedad de signos, síntomas,
hallazgos anormales, denuncias, circunstancias sociales y causas externas de
daños y/o enfermedad. Esta clasificación se divide en varias partes: un listado
tabular, un índice de las enfermedades y en las versiones MC un listado de
procedimientos. Actualmente existe una 10 edición CIE-10, aunque en
muchos países se sigue usando la versión previa CIE-9. Y se está trabajando
en una versión 11.
109
Anexos.
o En la ICF, 0 Clasificación Internacional del Funcionamiento, de la Discapacidad y de la Salud (CIF) se utilizan aprox. 1500 items de "función corporal", "estructura corporal", "activad y participación" y "factores ambientales" clasifica la salud y la discapacidad. o La ICHI, se presenta como un instrumento común para la presentación de informes y análisis de la distribución y evolución de las intervenciones de salud con fines estadísticos. ISe estructura con varios grados de especificidad para el uso en los distintos niveles de los sistemas de salud, y utiliza una terminología comúnmente aceptada para permitir la comparación de datos entre países y servicios.
Otro sistema de clasificación de la OMS es la Anatomical Therapeutic Chemical
Clasification (ATC) (127), un sistema de clasificación de medicamentos
reconocido internacionalmente que recoge de manera cualitativa la composición
de fármacos: códigos de principio activo, subgrupo terapéutico, y la Dosis Diaria
Definida (DDD).
 National Library of Medicine (NLM), donde se puede encontrar el Unified
Medical Language System Thesaurus (UMLS) (153). UMLS se define como una
base de datos que hace referencia a conceptos biomédicos o relacionados con la
salud de otros vocabularios o clasificaciones biomédicas.
Una de sus propiedades es que es capaz de conservar el nombre, significado y
las relaciones establecidas en el vocabulario del que procede, pues estas
diferentes visiones del mundo pueden ser útiles en diferentes tareas o aspectos.
Así, cuando un concepto aparece en más de una estructura jerárquica de
distintas terminologías, se incluyen ambos contextos.
Al ser una agregación de vocabularios, el alcance de éste se puede calcular
como agregación del alcance de cada una de las terminologías a las que engloba.
Sin embargo, esto no siempre es lo óptimo puesto que algunas fuentes de datos
pueden ser muy útiles para determinadas aplicaciones, pero completamente
prescindibles en otras: será necesario excluir la totalidad o parte de esa
terminología para evitar falsos significados.
A diferencia de otras terminologías, es de libre distribución para
investigadores aunque el uso de parte de su terminología puede estar ligado a la
aceptación de acuerdos extra, los que puede conllevar algún tipo de tasa.
 Iowa University y NANDA International, son las máximas impulsoras de
los principales sistemas de codificación propios de enfermería: NANDA se
encarga de etiquetar o supervisar la parte de diagnóstico (65), Nursing
Interventions Classification (NIC) (129) permite describir tratamientos
administrados por enfermería y Nursing Outcomes Classification (NOC) (155)
engloba la parte de resultados. Así el trabajo coordinado de estos 3 sistemas de
clasificación se ha convertido en habitual en muchos sistemas de atención: para
etiquitar un determinado problema se usa NANDA; inmediatamente después se
establecen los objetivos / resultados esperados en el paciente, mediante la
taxonomía de NOC y por último, a la hora de seleccionar las Intervenciones a
realizar para lograr esos objetivos se usará la taxonomía de la NIC.
110
 World Organization of Family Doctors (WONCA), o organización Mundial
de los Médicos Generales de Familia. Esta Organización publico en 1987 la
Clasificación Internacional de Atención Primaria (CIAP) (156) (157), también
llamada International Classification of Primary Care (ICPC) en inglés. Esta
clasificación permite la recogida y análisis de tres importantes componentes de
la consulta médico-paciente: la razón de consulta, el problema atendido, y el
proceso de atención. Esta clasificación está respaldada por la OMS que la ha
aceptado junto con la WHO FIC como punto de encuentro de clasificaciones.
 Regenstrief Institute, que en 1994 como respuesta a la creciente necesidad de
transmitir los datos que producían los laboratorios a hospitales y consultas
médicas, comenzó a desarrollar Logical Object Identifier Name and Codes
(LOINC), (158) un conjunto de identificadores únicos para facilitar el
intercambio y sondeo de resultados clínicos. Actualmente LOINC engloba
terminología de laboratorio (hematología, serología, microbiología, toxicología,
farmacología, conteo celular, etc.) y terminología clínica (signos vitales,
hemodinámica, gestión ventilatoria pulmonar, eco cardiograma, imagen
urológica, procedimientos gastroendoscopicos, etc).
Los código LOINC están dispuestos jerárquicamente, sin embargo esa jerarquía
no esta expresada en forma de red semántica o relacional que pueda ser
consumida fácilmente. Junto con LOINC también se distribuye el programa
Regenstrief LOINC Mapping Assistant (RELMA), el cual facilita la elección del
código LOINC correcto. Ambas herramientas (LOINC y RELMA) son de libre
distribución.
 IHTSDO (56) es una SDO sin ánimo de lucro que, entre otras terminologías,
posee los derechos de SNOMED-CT. SNOMED-CT es la más extendida de todas
las terminologías médicas y está considerada como una de las terminologías
multi-idioma en asistencia sanitaria más integrales del mundo.
SNOMED-CT fue creada desde el Colegio de Patólogos Americano (College of
American Pathologists, CAP) mediante la combinación de SNOMED-CR y un
sistema computarizado de nomenclatura y clasificación conocido como Clinical
Terms (CT) Versión 3. La terminología SNOMED comenzó en 1965 como una
nomenclatura sistematizada de Patologías y posteriormente se fue extendiendo
a otros campos médicos.
Enviroments/
geographical
locations
Physical force
Pharmaceutical/
biologic product
Body structure
Clinical Finding
Specimen
Organism
Special concept
SNOMED-CT
Physical object
Event
Observable
entity
Procedure
Staging and
scales
Record artifact
Situation with
explicit context
Qualifier value
Social context
Fig. A-1. Niveles superiores en la organización de SNOMED-CT.
111
Anexos.
SNOMED-CT divide su contenido de forma jerarquizada, tal y como se puede ver
en la Fig. A-1. Así de los nodos raíz comprenden hallazgos clínicos (en esta
categoría encontraríamos el subconjunto de enfermedades), procedimientos
(acciones realizadas en el proceso de atención), estructura corporal (tanto
anomalías como situaciones de normalidad), substancias (principios activo,
alérgenos, etc.), productos farmacéuticos o biológicos, etc.
Dentro de SNOMED se definen unos conceptos, identificados por un
“ConceptID” que nunca cambiará. Cada concepto se define mediante relaciones
lógicas con otros conceptos y cada concepto posee un nombre comprensible por
humanos (FSN, Fully Specified Name).
Los conceptos representan diferentes niveles de granularidad o precisión en el
nivel de detalle clínico, pudiendo encontrar conceptos más generales o específicos
según el nivel apropiado de detalle (ver Fig. A-2).
Del mismo modo, a un mismo concepto se le pueden asignar varios descriptores
que pueden ser distintos FSN (cada uno de ellos con un identificador único), un
término por el que se designa habitualmente, sinónimos, etc.
Las relaciones que definen un determinado concepto, pueden ser de 4 tipos: de
definición (como las relaciones IS_A), cualitativas, históricas (que se encargan de
relacionar conceptos inactivos con conceptos activos.Así un concepto puede pasar a
inactivo si es un duplicado de otro, pero se puede establecer una relación SAME_AS
entre ellos) o aditivas (como PART_OF, que se conserva para mantener la
compatibilidad hacia detrás con SNOMED-RT).
Procedure
IS_A
Procedure on
lymph node
Agregate level
IS_A
Biopst of lymph
node
IS_A
Surgical biopsy of
lymph node
Clinical detail
level
IS_A
Excisional biopsy
of lymph node
Fig. A-2. Relaciones y granularidad en SNOMED-CT.
112
Una característica relevante de SNOMED-CT es la posibilidad de establecer
subconjuntos, los cuales se aplican a una lengua, país, dialecto, organización o
contexto en particular. Y extensiones del núcleo de la aplicación, de este modo la
terminología puede crecer de manera unilateral en algunos países para adaptarse a
situaciones particulares no especificadas en el núcleo de la terminología. Por
ejemplo, el núcleo no puede especificar alguna enfermedad tropical que
determinados países si pueden necesitar. Además, como ya se indicaba en el
apartado 1.1 se pueden establecer mapeos con otras terminologías como puede ser
CIE, NIC, NOC, NANDA, LOINC, etc. La estructura general de SNOMED-CT
quedaría conforme a la Fig. A-3.
Fig. A-3. Estructura de datos de SNOMED-CT.
113
Anexos.
114
Anexo B: openEHR
Anexo B . openEHR
openEHR es una fundación internacional sin ánimo de lucro cuyo objetivo es
precisamente el lograr una historia electrónica interoperable y mejorar el cuidado
sanitario en la sociedad de la información. Por ello ha establecido relaciones con el
CENTC251, ITSHIDO o HL7 (159) (160) (161).
La propuesta formulada desde openEHR se basa en las especificaciones
abstractas que definen los siguientes modelos: Reference model (RM), Service
Model (SM) , Archetype Model (AM) donde los dos primeros se corresponden con
los puntos de vista computacionales y de información del modelo RM/ODP
(Reference Model of Open Distributed Processing) de ISO (162).
Los principios básicos sobre los que se estructura openEHR son:
 La separación ontológica entre el modelo de la información, el modelo del
conocimiento y las diferentes terminologías. A esta separación se le conoce
habitualmente como modelado en dos niveles (two-level-modelling). De este
modo el primer nivel, o RM, se implementa en software y los arquetipos y
templates (definidas por el Achetype Object Model, AOM) actúan como enlace
con diferentes terminologías y clasificaciones, lo que representa un salto
conceptual con los sistemas que mantienen que integran la terminología
médica por software. (ver Fig. B-1)
 Separación de responsabilidades. Los dominios complejos se subdividen en
áreas tratables. Es lo que se conoce como un “sistema de sistemas”. Así, En
cada una de estas áreas se forman un conjunto de modelos que la describen.
 Separación de los puntos de vista, consecuencia natural de la separación
de responsabilidades. Al separar esas responsabilidades entre diferentes
componentes es necesario definir qué información ha de tratar cada
componente y la manera que los distintos componentes comunican información
entre ellos. En el RM/ODP se definen cinco puntos de vista:
o De la empresa, encargada del ámbito y políticas del sub-sistema.
o De la información, que se encarga de la semántica de la información que
necesita ser almacenada y tratada en el sistema.
o Computacional, que describe el sistema como un conjunto de objetos que
interactúan entre sí.
o De ingeniería, que se encarga del soporte a la distribución de la información.
o Tecnológica, encargado de describir la tecnología que soportará el sistema
en base a la infraestructura de hardware, software y comunicaciones, así
como la representación y distribución de los datos.
Dentro de esta opción, un sistema de HCE (EHR system) se compone de un
repositorio de EHR, un repositorio de arquetipos, terminología (si está disponible)
e información de identificación o demográfica. Esta última se puede presentar en
forma de repositorio demográfico o un índice maestro de pacientes.
115
Anexos.
Information
Knowledge
Reference Model
Archetype model
Based on...
Instances
Data
Instances
Constrain at
run-time
Fig. B-1. Información vs. Conocimiento.
Fig. B-2. Estructura de jerárquica del EHR de openEHR.
116
Anexo B: openEHR
Un registro de salud electrónica (Electronic Health Record, EHR), se organiza
de manera jerárquica, tal y como se puede ver en la Fig. B-2. Entre las entidades
que representan niveles superiores encontramos:





COMPOSITION– como la unidad básica de la que se compone un EHR.
EHR Access – como el objeto encargado de la definición del acceso y
control del EHR.
EHR Status – encargado de almacenar información de estado y control, y
opcionalmente el identificador del paciente asociado a ese EHR.
DIRECTORY – una estructura opcional de carpetas para organizar las
Composition
CONTRIBUTIONS- el conjunto de registros para cada cambio realizado
en el EHR. Cada Contribution referencia a una o más versiones de
cualquier elemento que haya sido versionado o firmado.
Dentro de una COMPOSITON se puede encontrar una estructura similar a la
mostrada en la
Fig. B-3. Una COMPOSITION es un compendio de entradas, que pueden estar
organizadas, o no, bajo SECTIONS. Como se aprecia en la figura una SECTION
puede contener más otras SECTION.
Una ENTRY es una afirmación clínica y, en lo que se refiere a contenido, es
una de las piezas clave dentro de openEHR. De este modo, la clase ENTRY se
divide en 5 subclases tal y como se muestra en la Fig. B-4, donde las clases
OBSERVATION, EVALUATION, INSTRUCTION y ACTION están destinadas al
proceso de atención. La elección de esta tipología de entradas no es casual y esta
fundamentada en el proceso de resolución de problemas: en primer lugar el
facultativo observa al paciente y sus síntomas, basándose en sus conocimientos
evalúa la situación y se forma una hipótesis, en base a esa hipótesis se prescriben
instrucciones que terminarán materializándose en acciones. El resultado de esas
acciones podrá ser observado, iniciando de nuevo el ciclo.
Fig. B-4. Clases ENTRY de openEHR.
Fig. B-3. Estructura de una
COMPOSITION de
openEHR.
117
Anexos.
En cuanto a los requerimientos de privacidad (el dererecho de un paciente a
limitar quien ve sus datos personales) y confidencialidad (la obligación de terceras
partes de respetar la privacidad de los datos revelados) de un EHR, son
solventados por políticas concretas, entre ellas se pueden destacar:
 La política de seguridad, que dicta entre otras medidas que:
o Un registro no puede ser borrado, y si se necesitara realizar esta acción se
tomarían las medidas necesarias para marcar ese registro en concreto
como borrado en el control de versiones.
o Todos los cambios en un registro quedarán auditados, quedando registrado
el instante en el que se realizó esa modificación, quien la realizó y
opcionalmente una firma digital y otra información relevante.
o El contenido de médico se separará de la información demográfica.
o El control de acceso queda establecido por una lista que contenga tanto
individuos en particular como categorías (roles, grupos de personal, etc.).
o Los pacientes podrán determinar diferentes niveles de privacidad en las
COMPOSITION.
Opcionalmente, se podrán implementar otras políticas de seguridad como son
un registro en el acceso, limitación en el acceso a los registros, no repudio de la
firma digital, etc.
 Integridad: Esta característica se consigue mediante el control de versiones
especificado en paquete de control de cambios. Cualquier cambio en un registro
se conserva, apareciendo versiones de dicho registro que podrán utilizarse para
funciones de auditoria. Dichas versiones podrán ser firmadas digitalmente, y
para la creación de esas firmas puede crearse mediante clave privada de
encriptación (clave RSA-1) o mediante el uso de hash (MD5).
 El anonimato de la información se consigue mediante la separación de la
infrmación clínica y administrativa de la demográfica, como ya se había
comentado.
Hasta el momento, se han comentado aspectos relativos al nivel más bajo
dentro de la aproximación al modelo dual: los relativos al RM. El otro eje del
modelo lo constituían los arquetipos y plantillas (templates). Todas las piezas
contenidas dentro del RM son susceptibles de ser arquetipadas: los arquetipos son
instancias del modelo de arquetipos. Los arquetipos establecen resticciones al RM,
definiendo un conjunto de instancias que se consideran conformes al arquetipo.
Una template puede definirse como una estructura que contine uno o varios
arquetipos, donde cada uno de esos arquetipos restringe COMPOSITIONs,
SECTIONs, subclases de ENTRY, etc.
Los arquetipos tienen un propósito general, son reutilizables y pueden estar
compuestos por otros arquetipos más simples. Su usó puede extenderse
ampliamente (un mismo arquetipo puede ser utilizado por varios sistemas). Una
template, sin embargo, suele desarrollarse de forma local en un sistema y suele
corresponder con los formularios habituales con los que se trabaje en dicho
sistema como puede ser un examen prenatal. Su función suele ser la de captura
de datos y validación de la información.
Los arquetipos poseen un lenguaje de propio de implementación, el Archtype
Description Language (ADL), del cual se puede encontrar una descripción en el
Anexo H.
118
Anexo B: openEHR
Otra de las características de openEHR es la separación de terminologías de la
implementación software. El uso de terminologías, tiene diferente matiz
dependiendo del ámbito en el que se aplique:
 Dentro del RM existen atributos codificados por una terminología definida en
openEHR. Estos atributos son conjuntos de códigos aceptados
internacionalemente como códigos de países (ISO 3166).
 Los arquetipos poseen una terminología interna propia que define el
significado de cada elemento y dentro de un arquetipo se pueden producir
enlaces a terminologías externas (SNOMED-CT, LOINC, etc.) permitiendo un
mapeo directo de términos o realizar peticiones usando esas termiologías
externas.
Las especificaciones definidas por openEHR son en muchos casos compatibles
con normas y estándares disponibles. Así, para la completa compatibilidad entre
openEHR y la norma EN 13606 sólo se necesitan unas pequeñas conversiones: las
similitudes son claras tanto en el RM como en el uso de arquetipos.La conversión
hacia estándares de HL7 también es posible, aunque no es tan directa. Se puede
ver una ampliación de estos en sucesivos anexos.
119
Anexos.
120
Anexo C: Estándares HL7
Anexo C . Estándares HL7
HL7 es un conjunto de especificaciones desarrolladas por la organización del
mismo nombre, la cual está avalada por ANSI.
HL7 produce estándares
relacionados con el dominio de la salud, tanto información clínica como
administrativa: farmacia, imágenes diagnósticas, seguridad del paciente, etc. Entre
los más relevantes podemos encontrar la mensajería HL7 v2, mensajería HL7 v3,
la Arquitectura de Documento Clínico (Clinical Document Arquitecture, CDA) y
Clinical Context Object WorkGroup (CCOW), los cuales se explican en los
siguientes apartados.
C.1 Mensajería HL7 v2
HL7 v2 (163) define un protocolo para el intercambio de información clínica
mediante mensajería: en si no es ninguna aplicación ni define estructuras de datos
o una arquitectura para aplicaciones hospitalarias. Tal y como se muestra en la
Fig. C-1, el proceso se inicia con un evento disparador (o una consulta, Query) en
un sistema A que provoca que se genere un mensaje y sea transmitido a otro
sistema B, donde se procesará y, opcionalmente, se enviará una respuesta a ese
mensaje. Un ejemplo de evento podría ser el ingreso de un nuevo paciente. Un
mismo evento disparador no puede asociarse a más de un tipo de mensaje, sin
embargo un mensaje puede tener asociados varios eventos (relación 1-n). Los
diferentes tipos de mensaje se identifican con un código único de 3 caracteres.
Procesa mensaje
Fig. C-1. Modelo Básico de transacciones HL7 V2.
El mensaje es la unidad atómica de transmisión de datos entre dos sistemas y
dentro de su definición abstracta hay que considerar tanto los campos que se
envían dentro del mensaje como aquellas respuestas que se consideran válidas
como el tratamiento de errores (fallos en la comunicación).
Tal y como se muestra en laFig. C-2, un mensaje está compuesto por diferentes
segmentos los cuales pueden verse como una agrupación de entidades más simples:
los campos. Estos segmentos pueden ser obligatorios o opcionales, y pueden
aparecer una o varias veces en el mensaje (permiten repeticiones). Los segmentos
se identifican por un código único de tres caracteres. La composición de un mensaje
a nivel de segmentos puede verse en la Tabla C-1.
121
Anexos.
Mensaje
Segmento
Campo
Campo
Campo
Campo
Campo
Campo
Campo
Campo
Campo
Campo
Campo
Campo
Componentes
Campo
Fig. C-2. Estructura de un mensaje HL7 v2
Nombre
Multiplicidad
MSH
EVN
PID
PD1
NK1
PV1
PV2
DB1
ALG
DG1
DRG
GT1
ACC
1
1
1
0..1
0..N
1
0..1
0..N
0..N
0..N
0..1
0..N
0..1
Función
Encabezado
Tipo de evento
Identificación del paciente
Datos demográficos
Familiares a cargo
Información del episodio
Información adicional de episodio
Información de discapacidades
Información sobre alergias
Diagnostico
Grupo relacionando con el diagnostico
Garante (Seguros)
Datos del accidente
Tabla C-1. Composición de un mensaje HL7 V2 a nivel de segmento.
Como característica especial, en cada implementación de HL7 se permite definir
segmentos específicos para intercambiar información no prevista (segmentos Z o
segmentos de usuario).
Cada segmento posee una tabla en la que se documenta sus campos. De manera
generalizada se podrá encontrar:








SEQ – Indica el orden dentro del segmento.
LEN – Longitud máxima
DT – Tipo de dato
OPT – Indica si su uso es opcional, obligatorio, condicional o si está disponible
debido a temas de compatibilidad.
RP# - Indica si permite repeticiones y hasta que número si es el caso.
ITEM – Identificador del elemento
EI.NAME – Nombre del elemento.
Etc.
122
Los campos que conforman un segmento son cadenas de caracteres definidos por
uno de los tipos de datos de HL7, entre los que se pueden destacar:
 Alfanuméricos: string, TEXT, texto formateado.
 Numéricos: cantidades compuestas, dinero, identificadores de secuencia, números
estructurados, etc.
 Tiempo: fecha, hora, time stamps.
 Valores codificados.
 Demográficos.
 Etc.
La estrategia utilizada para la delimitación de los bloques contenidos en un
mensaje es la separación mediante caracteres de control. Los valores
habitualmente usados son los que se muestran en la Tabla C-2, aunque solo el
delimitador de segmento ha de permanecer constante.
Separador
ASCII
<CR>
|
^
&
~
\
13
124
94
38
126
92
Función
Terminador de Segmento
Separador de Campo
Separador de Componente
Separador de Subcomponente
Carácter de Repetición
Carácter de Escape
Tabla C-2. Caracteres de codificación en HL7 V2
C.2 Mensajeria HL7 v3
Diversos problemas (no disponer de un vocabulario controlado, diferentes
modelos de datos, la falta de trazabilidad entre mensajes, eventos y campos, etc.)
propiciaron la aparición de la versión 3 de HL7 (164).
Esta nueva versión facilitó una nueva metodología de desarrollo, incluyendo
mecanismos que permiten la adaptación a cualquier contexto sanitario
internacional. La compatibilidad hacía futuras versiones queda garantizada y se
asegura una compatibilidad funcional con las diferentes versiones de HL7 V2: la
definición de estructuras alternativas ante estructuras que quedan obsoletas es un
claro ejemplo de estos mecanismos.
La nueva metodología está basada en tecnologías orientadas a objeto, lo que
facilita el modelado y la semántica asociado a las actuaciones sanitarias. Para la
definición de su arquitectura se utiliza notación UML (Unified Modeling language)
en la que se establece un modelo de referencia (Reference Information Model, RIM)
constituido por 70 clases, las cuales derivan de 6 clases fundamentales. En la Fig.
C-3 se reproducen tanto el RIM completo de HL7 V3, como de las clases de las que
provienen (extraido de (144).
123
Anexos.
Fig. C-3. Nucleo y RIM completo de HL7 V3
En este caso, un mensaje se construye a partir de un modelo en concreto que
recoge la especificación exacta de los campos de un mensaje, sus agrupaciones,
secuenciación, opcionalidad y cardinalidad. Este modelo recibe el nombre de
Hierachical Message Description (HMD). Este modelo, a su vez, es elaborado a
partir de una estructura de información definida por el Refined Message
Information Model (R-MIM), un modelo que los requerimientos del conjunto de
mensajes que comparten tipología. Los conceptos usados en la construcción de un
conjunto de R-MIM orientados hacia un dominio en concreto de HL7 provienen de
un Domain Messsage Information Model (D-MIM) y los conceptos usados para la
construcción de un D-MIM provienen del RIM. Este proceso de definición se
ejemplifica en la Fig. C-4.
Fig. C-4. Metodología de definición de mensajes en HL7 V3.
124
Sin embargo, la definición de una estructura de mensaje no es suficiente, hay
otros puntos que se deberían formalizar antes:
 Roles de aplicación, que definen las responsabilidades tanto del sistema emisor
como del sistema receptor.
 Eventos de activación, que definen las circunstancias que motivan el envío de un
mensaje.
 Escenarios de usabilidad del sistema por parte del usuario. Se define un
escenario como un proceso en el que se necesita al mensaje para resolver el
problema de interoperabilidad. La formalización de un escenario, mediante
diagramas UML, es lo que se conoce comúnmente como caso de uso.
De este modo, en la construcción del mensaje no solo se centra en su estructura
sino que se definen los roles de los sistemas emisor y receptor.
C.3 Clinical Document Arquitecture
El Clinical Document Architecture (CDA) (166) es un estándar de marcaje
pensado para definir la estructura y la semántica de un documento clínico que se
requiere intercambiar entre distintos sistemas. Este documento queda definido
como un objeto de información completa y definida que puede existir fuera del
mensaje. Además de texto puede contener imágenes, sonido o contenido
multimedia.
Los documentos que cumplen con esta arquitectura presentan un esquema
similar al mostrado en la Fig. C-5: son documentos XML consistentes en una
cabecera y un cuerpo del documento. En la cabecera se identifican al documento en
si (identificador de documento, tipo de documento, etc.), los participantes en el
proceso de atención (paciente, autores del documento, médicos, etc.) y las relaciones
del documento con órdenes y otros documentos. El cuerpo del documento contiene
una parte tratable por personas (“human-readable”) obligatoria y, de manera
opcional, una parte codificada. El cuerpo del documento pude estar estructurado
en secciones y otras estructuras definidas en CDA( párrafos, listas, tablas, etc.)
Fig. C-5. Estructura de un archivo CDA.
125
Anexos.
Fig. C-6. Niveles en un documento CDA.
Dentro de arquitectura CDA se definen 3 niveles de especificación tal y como
aparecen en la Fig. C-6. Dentro del primer nivel se describe la cabecera del
documento y el tipo de documento. En el segundo nivel se asume el contenido XML
del cuerpo del documento y se recomienda una ordenación en secciones, el orden en
el que deben aparecer y códigos identificativos de sección. En el tercer nivel se
tratan las entradas, el vocabulario y la semántica en general.
La manera en la que esta arquitectura se articula con los estándares de
mensajería se ilustra en la Fig. C-7. Los documentos se encapsulan mediante
objetos MIME dentro de los mensajes HL7 y se pueden intercambiar en cualquier
evento o mensaje que intercambie documentos.
Fig. C-7. Relación de CDA con los mensajes de HL7.
126
C.4 Otros estándares.
Clinic Context Object WorkGroup (CCOW): Es el menos conocido entre los
anteriores protocolos. El objeto del protocolo es habilitar una manera en la que
aplicaciones diferentes puedan sincronizarse en tiempo real y a un nivel de interfaz
de usuario. Para ello utiliza el concepto de contexto clínico actualizado por cada
aplicación cliente.
Arden Syntax: Es un lenguaje formal que permite la descripción procedural de
conocimiento médico. Se utiliza para crear, codificar guías que permitan incorporar
sistemas de ayuda a la decisión clínica.
127
Anexos.
128
Anexo D: Norma UNE-EN/ISO 13606.
Anexo D Norma UNE-EN/ISO 13606
El siguiente desarrollo ha sido extraído directamente de “The ISO/EN13606 standard for
the interoperable exchange of Electronic Health Records”, capítulo para el special issue on
Electronic Health/Medical Record of the Journal of Healthcare Engineering, el cual se
encuentra en periodo de revisión para su publicación prevista entorno a enero de 2011:
The ISO/EN 13606 standard (167) has been developed by CEN/TC251 to
represent the information that can be included in an EHR. At the same time, it
defines the information exchange between EHR systems and provides semantic
interoperability to the transmitted data. While the main objective of this standard
is to define the way that EHRs (the whole EHR or part of it) are exchanged in order
to make them interoperable, ISO/EN 13606 does not specify neither the internal
architecture of an EHR system nor the way data are stored or consulted. In order
to achieve that, ISO/EN 13606 is based on a dual model: a Reference Model, which
supports the information, and an Archetype Model, which define the knowledge, i.e.
the concepts of the clinical domain. Archetypes are patterns that represent the
specific characteristics of the clinical data. A main concept of this dual approach is
that if knowledge changes (e.g. additional medical characteristics are required to be
included), only the archetype under the data will change. For example, the
following asseveration can be assimilated to knowledge: “A routine blood chemistry
measures the following chemical substances in the blood: glucose, urea, creatinine,
sodium and potassium”. On the other hand, information is the instantiation of that
archetype for one patient in one specific point of time: “January 2nd, 2010 at 08:43
a.m. John Smith had: glucose = 80 mg/dL; urea = 11 mg/dL; creatinine = 0.77
mg/dL; sodium = 141 mmol/dL; potassium = 4.1 mmol/dL”. Eventually, due to new
discoveries in medicine, it may become important to include additional
measurements (for example, chlorine levels) in the routine blood chemistry tests.
In such a case, only the archetype (knowledge) would change while information
remains unalterable. The ISO/EN 13606 standard is divided into five different
parts that are detailed below:
 Part 1: Reference Model. This part defines basic generic components that
support information and the relationships between those components Fig. D-1
(extracted from ISO/EN13606-1) shows a simplified scheme of these
components. The EHR is comprised of the following logic blocks (Fig. D-2):
- Extract: The top-level container of part or all of the EHR of a single
patient.
- Folder: The high level organization within an EHR (i.e. episode of care,
compartments of care, etc.)
- Composition: a single clinical encounter or record documentation session
(reports, test results, etc.)
- Section: clinical headings reflecting flow information (i.e. subjective
symptoms, findings, treatment, etc.).
- Entry: Clinical Statements.
- Cluster: The mean to organize nested multi-part data structures (tables,
time series, etc.)
129
Anexos:
- Element: A container of a single data value. It is the leaf node of the
hierarchy.
Additionally, the Reference Model sets hierarchical relationships between its
components, achieving this way syntactic interoperability. A deeper analysis
shows other relevant characteristics related to the use of the standard like the
ability of signing every single element by means of defining the
ATTESTATION_INFO class. As it can be seen, the existing association
relationship between this class and RECORD_COMPONENT is inherited by the
rest of the elements, given that all of them derive from this abstract class. The
separation of the demographic information allows transmitting clinical
information anonymously, an essential factor in health environments by reason
of security matters. Each party composing the system (organization, devices,
healthcare professional, subjects of care or other kind of people) is identified by
unique identifiers. Auditory capabilities are present through the AUDIT_INFO
class, which can be used to track what data has been introduced, when and by
whom, and also the reason for that information to be modified. It allows
recording every single request, whether accepted or not, as well as the reason for
the rejection.
 Part 2: Archetype Model. An archetype is used for modelling domain
concepts, thus constraining the Reference Model at run-time by defining the
structure of the instance and/or limiting the value range of an attribute (see
Fig. D-3). Archetypes can make use of standardized medical terminology to
simplify the decoding of the received data. The formal language for defining
archetypes is the Archetype Description Language (ADL) . In Fig. D-4 the toplevel structure of an ADL archetype is represented. The current version of ADL
language (v1.4) uses three syntaxes to describe constraints on data:
- cADL: constraint form of ADL, used to express the archetype definition
section.
- dADL: data definition form of ADL, used to express data that appears in
the language, description, ontology, and revision_history sections.
- First-Order Predicate Logic (FOPL), to express data which appears in the
declarations and invariant sections.
Fig. D-5 shows a simplified scheme of the Archetype Model, extracted from
ISO/EN13606-2. Describing a well defined archetype is not a simple task. As
seen in Fig. D-5, the ISO/EN 13606 standard offers different mechanisms to
enable this modelling, such as the archetype_description, the ontology and the
constraint_model. The archetype_description allows associating additional data
(metadata) to the archetype, for instance, a translation into a different
language. The ontology is used to bind archetype nodes to specific medical terms.
Finally, the constraint_model specifies a hierarchical schema that defines how
an instance must be built.
130
Fig. D-1 ISO/EN13606 Reference Model (simplified scheme from ISO/EN13606-1)
131
Anexos:
Fig. D-2. Component Relationships of the ISO/EN 13606 Reference Model
Information
Knowledge
Reference Model
Archetype model
Based on...
Instances
Instances
Constrain at
run-time
Fig. D-3. Relation between Information (Reference Model) and Knowledge (Archetype
Model)
Fig. D-4. Top- level structure forn an Archetype Description language (extracted from
ISO/EN 13606-2)
132
Fig. D-5. Archetype Model (simplified scheme from ISO/EN 13606-2)
133
Anexos:
Although the main feature of ISO/EN 13606 is the dual model, described in the
first two parts, it is also important to define other aspects in order to achieve
interoperable exchange of EHR, such as nomenclature issues (part 3) security
issues (part 4) or interfacing for querying (part 5).
 Part 3: Reference Archetypes and Term lists. This part sets a normative set
of coded terms each one defining a controlled vocabulary for a Reference Model
attribute contained in ISO/EN 13606-1. This part includes different groups of
terms such as terms related to the subject of an Entry (SUBJECT_CATEGORY),
internal data structure of an Entry (ITEM_CATEGORY), the status of a
particular version of a record_component (VERSION_STATUS), the physical or
electronic means by which an Entity participates (FUNCTIONAL_ROLE), the
act status values included in EN 12967-3 (ACT_STATUS), the semantics of the
relationship between the source and target record_component (LINK_NATURE)
and a subcategory of the correspondent link terms (LINK_ROLE) and, finally,
the structural organization of a Cluster (STRUCTURE_TYPE).
 Part 4: Security. This part describes a methodology for specifying the
privileges necessary to access EHR data and also some other general security
requirements that should apply to EHR communications, for example:
- It provides a double input table, the functional role of the requester and
the sensitivity of the record. The information is only accessible if the
functional role of the requester (coded with a number) is, at least, equal
than the sensitivity of the record.
- It defines both general and specific access policies able to deny or grant
access to identified parties or specific functional roles.
 Part 5: Interface Specification. This part describes a set of interfaces to
request access to the information and resolve the request. Three specific
interfaces are defined:
- REQUEST_EHR_EXTRACT, to request a specific EHR_EXTRACT (as
defined in ISO/EN 13606-1). The only mandatory parameter is
subject_of_care_identity, but optional parameters are also available. These
optional parameters can be used to specify the time range of the retrieved
information (for example, it is possible to request for retrieval all
previously requested records or any record within a given time range).
- REQUEST_ARCHETYPES, to request one or more ARCHETYPES (as
defined in ISO/EN 13606-2). There is no mandatory parameter in this case.
Archetypes can be requested based on a particular concept (for example, it
is possible to request a specified set of identified archetypes or all the
archetypes).
- REQUEST_EHR_AUDIT_LOG_EXTRACT,
to
request
a
specific
EHR_AUDIT_LOG_EXTRACT (as defined in ISO/EN 13606-4). In a
manner analogous to REQUEST_EHR_EXTRACT, it defines optional
parameters to filter the retrieval of information and determine access
policies, since special privileges are required to access specific control
information.
134
The ISO/EN13606 standard has been recently completed, since the Part 5 was
ratified on February 2010. As a multipart standard, the different parts were
approved by separate polling, while further comments on the voting process led to
changes in some parts. For example, the latest version of the Reference Model
includes several updates over the previous version, released in 2004. These
differences are mainly related to the definition of concepts that are required to be
transmitted in an EHR query/extract:
• Sensitivity is not a mandatory parameter anymore, and also it is now
represented by an integer. If sensitivity is not transmitted, a default value is
supposed to determine who is allowed to access that information.
• The attribute used to group a set of COMPOSITIONs (contribution_id) has been
moved from AUDIT_INFO class to COMPOSITION class, thus its meaning is
now more related to clinical information rather than context information.
• CLINICAL_SESSION class and its attributes are now included within
RECORD_COMPONENT and FUNTIONAL_ROLE classes. In this way,
COMPOSITION class now contains optional attributes as session_time (time
interval of the session) and territory (country where the extract is created), and
FUNTIONAL_ROLE class contains healthcare_facility (organization at which
the role was performed) and service_setting (type of service location at which the
role was performed).
• The attribute representing who is legally responsible for the care of the patient
at
the
time
of
the
COMPOSITION
is
committed
(hca_legally_responsible_for_care) has been removed.
• The optional attribute composer is replaced by a mandatory association with
committal belonging to AUDIT INFO class. Therefore, the context information
provided is now more comprehensive, since the identification of the sender, the
date and the source information must be included. In addition, a difference
between who sent it and who created it can be made, as in fact could be different
people.
• The attribute version_specific, which referred to the target of a link (previously
defined as RECORD_COMPONENT or a version of it), has been removed. Since
any version of a record component has a unique identifier, it is reasonable to
reference that identifier, regardless whether it is a version or not.
After analyzing the evolution of these fields and the inheritance between classes,
the main fields required to be transmitted are shown in ¡Error! No se encuentra el
origen de la referencia., as well as the data types (in brackets) and their meaning in
the standard. Additionally, other relevant information can be expressed by
including optional parameters. For instance, information such as the date and the
time interval the item occurred, a screenshot of the test or even information related
to whether the extract has been automatically generated by a machine or triggered
by a physician Tabla D-1 ¡Error! No se encuentra el origen de la referencia. also includes
the optional attributes archetype_id and meaning. These attributes provide
semantic interoperability by specifying the archetype that has been used or if that
record conforms to any concept domain that uses medical terminology like
SNOMED-CT.
135
Anexos:
To date, the ISO/EN 13606 standard is based on CEN/TS14796 for describing
data types but this is expected to change in the future. Due to the Memorandum of
Understanding [12] between HL7, CEN/TC251 and the Joint Initiative on SDO
[13], a new document is being discussed in order to harmonize CEN data types
(CEN/TS14796) and HL data types. This document (ISO/DIS 21090), still in a draft
status, is being designed to replace CEN/TS14796 and align with HL7 data types.
The number of classes defined in ISO/DIS 21090 is higher than in CEN/TS14796,
particularly in the case of structured text, since it is intended to cover all those
records that were previously stored as free text. Another point to take into account
is the intention of including specific classes to represent information related to the
demographic package, such as addresses or entity names.
EHR_ Header of the container.
EXTRACT After that, all compositions are transmitted
ehr_id The unique EHR identity (from which the EHR_EXTRACT was created
[Instance Identifier] for that EHR provider system for this subject of care)
ehr_system The identity of the EHR provider system
[Instance Identifier] from which the EHR_EXTRACT was created
rm_id The identity and version of the Reference Model standard under which
[String] the EHR_EXTRACT was created
subject_of_care Unique identifier
[Instance Identifier] of the subject of care
time_created Date/time at which data from this subject of care’s EHR was
[Time Point] queried/exported to create the EHR_EXTRACT
EXTRACT_ Optional parameters specified in the EHR Request.
CRITERIA They are not mandatory to repeat
all_versions Indicator if it includes
[Boolean] all historic versions
archetype_ids Set of Archetypes if they were used as a basis of selecting data to
[Set Instance Id] include in the EHR_EXTRACT
max_sensitivity Used sensitivity
[Integer] for EHR_EXTRACT generation
multimedia_included If multimedia data have deliberately been excluded
[Boolean] from the EHR_EXTRACT
other_constraints additional criteria that were used
[String] to generate the EHR_EXTRACT
time_period Date or time interval to which the
[Interval TimePoint] EHR_EXTRACT is limited
RECORD_
COMPONENT
Archetype_id
[Instance Identifier]
meaning
[Coded Value]
name
[Text]
rc_id
136
Abstract class that introduces
those mandatory fields
Unique identifier of the Archetype Node to which this
RECORD_COMPONENT corresponds.
The standardised clinical or administrative concept to which the name
attribute has been mapped. It allows terminology binding.
Name of
the record
Unique identifier
of the record
synthesised TRUE if this RECORD_COMPONENT was created
[Boolean] in order to comply with this standard
Inherited attributes of RECORD_COMPONENT
and a mandatory association with commital
COMPOSITION (from AUDIT_INFO), which contains those attributes:
committer
The party responsible for committing the RECORD_COMPONENT
ehr_system EHR system in which the
[Instance Identifier] RECORD_COMPONENT was committed
ehr_id The unique EHR identity (from which the EHR_EXTRACT was created)
[Instance Identifier] in which the RECORD_COMPONENT was committed
time_committed Date/time at which the RECORD_COMPONENT was committed within the
[Time Point] identified EHR system
ENTRY Inherited attributes of RECORD_COMPONENT
uncertain_expressed If it contains data that indicates some
[Boolean] degree of uncertainty
Abstract class (CLUSTER and ELEMENT inherits from it).
ITEM It introduces optional fields:
<obs_time> Date and time (interval) at which the ITEM occurred
<emphasis> A way of denoting that the composer
wished to mark this ITEM (optional)
CLUSTER Inherited attributes of RECORD_ COMPONENT, and:
structure_type Time/spatial organization
[Code SimpValue] of data within this CLUSTER
ELEMENT Inherited attributes of RECORD_COMPONENT and ITEM
value DATA_VALUE containing the value, unless this is indicated as absent by
[Data Value] a null_flavour attribute
Tabla D-1.Campos relevantes en el RM de ISO/EN 13606.
137
Anexos:
138
Anexo E: Estándar ISO/IEEE 11073
Anexo E . Estándar ISO/IEEE 11073
En la actualidad, no existe ninguna norma que aborde oficialmente el problema
de la integración de dispositivos en entornos de telemonitorización domiciliaria y
ambulatoria, pero sí hay una familia de normas orientada a la interoperabilidad de
dispositivos médicos en el punto de cuidado, que puede aplicarse en buena medida.
Se trata de la familia ISO/IEEE 11073 (también nos referiremos a ella como X73),
que está sufriendo modificaciones para cubrir ese campo.
El estandar ISO/IEEE 11073 es un conjunto único de normas desarrolladas y
adoptadas por todos los países para conectividad completa de dispositivos médicos,
que aporta interoperabilidad, plug&play, transparencia, y facilidad de uso y
configuración. Dicha norma está, a fecha de finalización de este documento, en fase
de desarrollo. Para su desarrollo se han unido las organizaciones CEN, IEEE e
ISO, entre otras, uniendo esfuerzos anteriores que absorben normas previas como
PoCMDC (interconexión de dispositivos e intercambio datos entre ellos) o las
normas ENV13734 (VITAL) para las capas superiores y ENV13735 (INTERMED)
para las capas intermedias. Haciendo cronología, el IEEE fue el primero que desarrolló estándares en esta
área con la aparición de Medical Information Bus (MIB) en 1984. Sin embargo, los
principales fabricantes desarrollaron sus soluciones propietarias, que no han tenido
una aceptación general. El CEN creó en 1993 un conjunto de estándares (Point-ofCare Medical Device Communication, PoC MDC) que fueron ratificados en 1999
para poder interconectar dispositivos e intercambiar datos. En el año 2000/2001 las
organizaciones de estandarización IEEE e ISO se pusieron de acuerdo y crearon el
“Pilot Project” para no competir y trabajar conjuntamente en un único conjunto de
estándares. En dicho proyecto piloto, los estándares IEEE empiezan a desarrollarse
conjuntamente. Apelando al tratado de Viena esta organización conjunta se
extendió para incluir al CEN con el fin de llegar a una armonía internacional en los
estándares. Estos acuerdos han puesto la base para que otras organizaciones de
estandarización avancen en una forma similar y trabajen de forma coordinada con
otras organizaciones como HL7, DICOM, IHE o Continua Alliance.
A principios de 2004 se aprobaron los cinco estándares existentes de la norma
11073 y, desde entonces, se han desarrollado con un alto nivel de participación
internacional. Están siendo adoptados como normas ISO a través de su comité
técnico TC215, bajo la denominación de norma 11073. También se consideran
estándares europeos por medio del TC251 del CEN. Este proceso de integración
comienza uniendo esfuerzos realizados anteriormente por cada una de las partes,
de modo que se absorben normas previas de ISO e IEEE para poder llegar a cubrir
todos los niveles/capas en la comunicación entre los dispositivos.
A partir de estas premisas, en los últimos años el vertiginoso desarrollo de
nuevos MDs wearables, con sensores de alta calidad y sobre tecnologías wireless
(como Bluetooth o ZigBee), y el incremento de accesos de banda ancha a redes
multimedia, está acelerando la evolución del estándar X73 optimizando y
adecuándola a nuevas tecnologías y contextos ubicuos. Esta versión se denomina
X73-PHD (Personal Health Devices). En esta ocasión cambia la arquitectura del
protocolo, el modelo de comunicaciones MD-CE, se define una nueva máquina de
estados finita (Finite State Machine, FSM), y el modelado del transporte y de nivel
físico que conforman la pila de protocolos X73-PHD, como se detalla en el siguiente
apartado.
139
Anexos:
Por todo ello, es evidente que este conjunto de estándares está todavía en fase de
desarrollo, en un proceso evolutivo en el que multitud de ingenieros han trabajado
en paralelo con universidades, instituciones y entidades internacionales. Esto
desemboca en una situación transitoria en su progresiva implantación dado que no
está asegurada todavía al no existir garantías de que los principales diseñadores y
fabricantes de dispositivos médicos acepten el estándar. Sin embargo, la existencia
de un estándar universal como X73-PoC para los sistemas sanitarios es una
necesidad en la comunicación de los dispositivos médicos en eSalud.
A la hora de diseñar las características del protocolo, es necesario evaluar los
entornos de uso o Use Cases de los dispositivos candidatos a implementar X73-PHD
de manera que quede convenientemente definido el rango de propiedades
soportadas por el protocolo. En general el sistema posee una topología tipo estrella
donde el CE situado en el centro recopila los datos provenientes de los agentes. Una
lista preliminar de los casos contemplados para el desarrollo se encuentra en el
borrador IEEE-11073-00013. Draft Guide for Health informatics - Personal Health
Device communication. Technical report - Overview. En él se destacan inicialmente
los siguientes casos de uso:
 Salud y bienestar
 Fitness cardiovascular y monitorización de actividad
 Fitness de esfuerzo
 Gestión de enfermedades de alto riesgo: obesidad e hipertensión
 Assisted Ambient Living
 Cuidado de pacientes de avanzada edad
 Diabetes
 Monitorización de pacientes con problemas cardiacos
Durante el desarrollo de la norma, se han reagrupado en torno a 3 tipos de uso
como puede verse en la Fig. E-1 Aquí se incluyen además los dispositivos médicos
asociados para su estandarización conforme a X73-PHD.
Fig. E-1. Tipos de Uso para X73- PHD.
140
A la hora de seleccionar el conjunto inicial de dispositivos que van a trabajar con
el X73-PHD, se realizó una encuesta a diversos fabricantes en la cual se valora,
para cada tipo de dispositivo del mercado, la necesidad de aplicar X73-PHD a sus
comunicaciones. La clasificación final se hace en base al interés de los expertos en
desarrollar un estándar para el dispositivo tanto a largo como a corto plazo, su
posible participación en el desarrollo y evidentemente la existencia de un grupo de
trabajo. Las especializaciones que se encuentran desarrolladas o en proceso de
desarrollo actualmente se pueden ver en la Tabla E-1:
Especialización
IEEE Std. 11073-10404TM-2008
IEEE Std. 11073-10406TM-2008
IEEE Std. 11073-10407TM-2008
IEEE Std. 11073-10408TM-2008
IEEE Std. 11073-10415TM-2008
IEEE Std. 11073-10417TM-2008
IEEE Std. 11073-10441TM-2008
IEEE Std. 11073-10442TM-2008
IEEE Std. 11073-10471TM-2008
IEEE Std. 11073-10472TM-2010
P11073-10406
P11073-10413
P11073-10418
P11073-10419
P11073-10420
P11073-10421
P11073-10443
expected
expected
Nombre
Pulse oximeter
Heart rate monitor
Blood pressure monitor
Thermometer
Weighing scale
Glucose meter
Cardiovascular fitness and activity monitor
Strength fitness equipment
Independent living activity hub
Medication Monitor
Basic ECG (3-leads)
Respiration rate
INR-blood coagulation
Insulin pump
Body composition analyzer
Peak expiratory flow monitor
Physical activity monitor
Spiro meter
Fetal monitor
Tabla E-1. Especializaciones en desarrollo para X73.
Esta lista evoluciona y, conforme se obtienen versiones avanzadas de
especializaciones en desarrollo, se van realizando nuevas propuestas que son
llevadas a votación (Project Approval Request, PAR) para luego ser desarrolladas
posteriormente si procede.
Las especializaciones de los dispositivos contienen a menudo definiciones de
clases nuevas en el modelo de comunicaciones para abarcar las funcionalidades
particulares del mismo. Además, el fabricante puede crear especializaciones
propias o extendidas que contienen un esquema de objetos modificado, así como su
lista de atributos definidos. Es tarea del CE el identificar estas configuraciones
para decidir si acepta la asociación con el dispositivo en cuestión en base a sus
capacidades.
141
Anexos:
El estándar IEEE-11073 está basado en 3 pilares fundamentales:
Domain Information Model (DIM): Es el encargado de representar la
información y caracteriza la información de un agente como un conjunto de
objetos. Dichos objetos tienen atributos t estos pueden representar tanto las
medidas tomadas como elementos que modelan el comportamiento del agente.
Service Model: Define el acceso a datos por medio de las primitivas {set, Get,
Action y EventReporting} que se intercambian tanto el agente como el manager
para acceder a los datos del DIM.
Communications Model (Comms Model): Modela el comportamiento dinámico
del sistema como una máquina de estados de conexión, y define las entradas,
salidas y errores que nos llevan a transitar entre estados. Obviamente es el
encargado de formar los mensajes usando reglas de Codificación de datos
Médicos {Medical Data Encoding Rules (MDER)}.
Antes de comenzar se va a hacer un pequeño incisos sobre los tipos de mensajes
existentes: El manager y el agente se van a comunicar por medio de mensajes.
Ahora bien, dependiendo de la configuración con la que trabaje el agente el formato
del mensaje va a ser variable, fijo o agrupado. La diferencia entre estos tipos de
mensajes es que en el variable, se desconoce la estructura bajo la que se transmite
y se han de transmitir todo tipo de cabeceras, en el fijo ya se conoce que campos se
van a trasmitir y en qué posición y por lo tanto se puede obviar la transmisión de
cabeceras varias y en tipo de mensaje agrupado es similar al variable pero se usa
cuando se monitorizan ciertos atributos de algunas clases en concreto y por lo tanto
no se tiene que incluir el identificador de objeto transmitiendo.
Domain Information Model
De una manera genérica el estándar define una serie de clases para modelar el
agente. Así pues, un agente se puede modelar como un conjunto de objetos que
representan una serie de datos o los parámetros que el agente puede usar para
controlar al agente (hay clases que contienen información o el estado del agente}.
Del mismo modo dentro del misma definición de clase podemos encontrar los
mecanismos que el agente usará para enviar la información al manager.
Por otro lado el Manager se comunicará con el agente por métodos conocidos
como GET ó SET y se describen en cada subclase que define el objeto. Los datos
recogidos por el dispositivo médico se envían al manager mediante eventos de
notificación {event reports}.
Las clases no pueden tratarse de manera aislada sino que se ha establecido un
sistema de herencia y relación entre ellas. Es por ello que cualquier información
que pueda transmitirse entre agente y manager deberá estar reflejada como un
atributo de uno de estos objetos y la manera en la que esos objetos se comunican
también está establecida en la misma definición de clase. Esos métodos de acceso al
agente acaban definiendo su modelo de información, y a diferencia con el manager
este estándar no define un modelo de información para el agente (se entiende por
ello, que la manera que el manager comunica los datos obtenidos de los agentes y
los parámetros que controlan el manager pueden ser objeto de reflexiones varias).
142
Un aspecto clave en la transmisión del x73 es el uso de valores codificados que
referencian a los objetos y a sus atributos (Es lo que si miras el estándar
detenidamente se llama Attribute ID, no puedes llamar a los atributos como elijas)
consiguiendo interoperabilidad con otras versiones de la implementación y siendo
de gran ayuda para implementaciones internacionales. Para cada término de
nomenclatura se define un nombre específico que define al término, un código de
valor y un identificador (ID), donde este último tiene como estructura
MDC_XXX_YYY (MDC indica Medical Device Communication). Siempre nos
referiremos a un término basándonos en su ID. Las particiones de la nomenclatura
se pueden ver en la Tabla E-2.
Partition number
Nomenclature category
0
1
2
3
4
5
6
7
8
9
10
11–127
128
129
130
131–254
255
256
257–1023
1024
1025–65 535
Unspecified
Object-oriented (OO)
Supervisory control and data acquisition (SCADA)
Events
Dimensions (units of measurement)
Virtual attributes
Parameter groups
[Body] sites
Infrastructure
File Exchange Format
ECG Extensions
Reserved
Personal health devices disease management
Personal health devices health and fitness
Personal health devices aging independently
Reserved
Return codes
External nomenclature references
Reserved
Private
Reserved
Tabla E-2. Nomenclatura
Una representación UML de las clases que contienen el DIM podemos
encontrarla en la Fig. E-2 En los siguientes sub-apartados podemos encontrar una
descripción más pormenorizada de cada una de ellas.
Fig. E-2. Diagrama de clases del X73- PHD.
143
Anexos:
MDS Class
Uso: Esta clase se usa para representar un agente y para mostrar su estado. Por lo
tanto cada agente posee uno.
Identificación: MDC_MOC_VMS_MDS_SIM
Atributos: A grandes rasgos podemos distinguir los siguientes:
Un identificador de objeto que para los MDs debe ser cero.
El tipo de dispositivo que es {báscula, tensiómetro, glucómetro…}
Fabricante y modelo
Un código donde los primeros 24 bits son un UOI, seguidos de los 40 bit que
identifican al fabricante
Un identificador de la configuración del agente dado que un agente puede
trabajar con varias configuraciones y cuando la comunique al manager ha de
poder indicar cual
Atributos contenidos en el mensajes con el formato fijo de datos.
Revisiones de componentes, números de serie, etc.
Las capacidades del dispositivo en cuanto a tiempo se refiere: resolución,
precisión, un identificador del protocolo que se está usando, etc.
Fecha y hora, tiempo relativo (entre medidas) y tiempo relativo de gran
resolución
Un atributo donde se guarda si alguien ha modificado la fecha y hora del agente
(solo se puede ver con el event report)
Si esta encendido por las baterías o porque está conectado a la red.
El % de batería y el tiempo estimado de batería que le queda.
Varios elementos de conformidad de certificación y/o de regulación.
El tipo de agente que es ( báscula, etc…), incluyendo datos adicionales como la
versión de la especialización
El tiempo mínimo que debe esperar un agente una respuesta después de emitir
un comando y antes de desasociarse del agente.
Métodos: Las acciones que se pueden al agente son las siguientes, y pueden ser
invocadas mediante el servicio ACTION. Ambos métodos son del tipo confirmado.
MDS-Data-Request: Permie al manager activar/desactivar la transmisión de
datos desde el agente. Requiere enviar una estructura Data Request y espera
recibir una estructura Data Response.
Set-Time: permite establecer un reloj con el tiempo absoluto. Enviamos una
estructura del tipo SetTimeInvoke.
Eventos: Cuando ciertas acciones sucedan el MDS, enviará ciertas notificaciones
al manager. Entre ellas se pueden encontrar las siguientes:
MDS-Configuration-Event: El agente envía al manager en la asociación
información acerca de su configuración por si el manager no la conoce o recuerda
de pasadas asociaciones.
144
MDS-Dynamic-Data-Update-Var: Se proporcionan datos dinámicamente al
manager, normalmente medidas, para todos los objetos que soporta el agente. Se
supone que los datos se transmiten con el formato de datos variable.
MDS-Dynamic-Data-Update-Fixed: Igual que el anterior pero sólo para algunos
o todos los tipos de objetos de clase métrica.
MDS-Dynamic-Data-Update-MP-Var: Idéntico a los dos anteriores, pero permite
la inclusión de datos de varías personas
MDS-Dynamic-Data-Update-MP-Fixed: Idéntico a los dos anteriores, pero
permite la incursión de datos de varías personas.
Otros Servicios: Hay dos servicios básicos:
GET: Que es usado por el manager para obtener todos los atributos de un objeto
del agente por medio del “Remote Operation Invoke | Get” command {con el
handle a cero}. Se puede invocar tan pronto el agente se haya asociado con el
manager.
SET: Para esta clase no hay atributos
Metric Class
Uso: Esta clase es la clase base de la que derivan todos aquellos objetos que
representen medidas. Es una clase abstracta (no se instanciará), pero en ella se
definen atributos y métodos que se heredarán en las clases que derivan de esta:
Numeric Class, RTS Array Class y Enumeration Class.
Identificación: MDC_MOC_VMO_METRIC.
Atributos: Como ya se ha comentado en el apartado anterior, todas las clases que
deriven de Metric los poseerán. Entre sus atributos se pueden destacar:
Un identificador único asignado por el agente.
El tipo de medida qué es. (si son pulsaciones, presión arterial, etc.)
Información adicional del tipo de medida (la posición en la que estaba el sensor
cuando se tomó la medida, tasa de cambio de la medida (lenta, rápida, etc.), etc.)
Una descripción de las características de las medidas.
La estructura de la medida (si es un valor, si son varios valores, etc.)
Si la/s muestra/s tomada/s son válidas.
Diversas medidas de seguridad para asegurar una consistencia de la
información
El código de las unidades que se están midiendo: Kilos, mg/l, etc.
La estructura que tendrá cuando usemos formato de mensajes fijo.
Enlace al objeto fuente del que se están tomando los datos.
Representaciones en ASCII del tipo de objeto y del código de las unidades de las
medidas que se están tomando.
Marcas de tiempo (tiempo absoluto, relativo o relativo de alta resolución)
Tiempo en que el agente ha estado tomando las medidas ( en segundos).
En esta clase no se definen ni eventos ni métodos ni servicios.
145
Anexos:
Numeric Class
Uso: Se usa para representar medidas numéricas.
Identificación: MDC_MOC_VMO_METRIC_NU.
Atributos: A parte de todos los mencionados en la clase Metric, según sea la
naturaleza de la medida podremos encontrar:
Un único valor en formato flotante (32-bits)
Un conjunto de valores como el anterior
Un único valor en formato flotante (16-bits)
El valor, el estado de la medida y las unidades de la medida
La desviación máxima que puede haber entre la medida enviada y la real
(problemas de precisión)
RT-SA Class
Uso: Este tipo de medida está destinado a representar formas de onda y los valores
obtenidos se envían usando el servicio EVENT REPORT.
Identificación: MDC_MOC_VMO_METRIC_ SA_RT.
Atributos: En este caso todos los atributos con los que se está trabajando son
obligatorios:
El tiempo entre muestra y muestra en octavos de milisegundo.
Un array que contiene los valores observados
Una formula entre los valores que contiene el array y los valores reales.
Una descripción del array (número de muestras, tamaño…) y del tipo de
muestras.
Nota: Realmente no se transmiten los valores medidos, sino valores adaptados que
siguen la formula Y=MX+B. Si tenemos un termómetro que mide desde los -45
grados a los 50 con una precisión de 0,5 grados, los valores de M y B se calculan
conforme a la Fig. E-3 y la tabla de conversión se realiza conforme a la Tabla E-3.
Lower-absolute-value = –45.0
Upper-absolute-value = 50.0
Lower-scaled-value = 0
Upper-scaled-value = 190
M= (50.0 – (–45.0))/(190 – 0) = 0.5
B = 50.0 – (0.5 × 190) = –45.0
Fig. E-3. Ejemplo de calculo de M y B
146
Scaled (x)
0
50
100
150
190
Converted (y)
–45.0
–20.0
5.0
30.0
50.0
Tabla E-3. Tabla de conversión según Fig E-3
Enumeration Class
Uso: Se usa para representar información de estado y/o de anotación.
Identificación: MDC_MOC_VMO_METRIC_ENUM.
Atributos: Como en otros casos, los atributos específicos de esta clase son todos
condicionales Y/O optativos:
Un código de nomenclatura que tanto puede referirse a l código de la partición
de ese atributo o al código de partición definido en el atributo tipo heredado de
Metric.
Un bit-string de 32 bits.
Idem pero de 16-bits.
Idem pero en forma de cadena.
El dato observado estructurado.
La nomenclatura de la partición para Enum-Observed-Value-Simple-OID o
Enum-Observed-Value.
PM-Store Class
Uso: Se usa para el almacenaje de datos de la clase Metric, para una posterior
retransmisión. Dentro de una estructura más formal los PM-Store contienen PMSegments y estos a su vez entradas y elementos tal y como se muestra en la Fig.
E-4 extraído de (145)
Fig. E-4. Estructura de un objeto PM-Store.
147
Anexos:
Identificación: MDC_MOC_VMO_PMSTORE.
Atributos: Los atributos que soporta esta clase permiten almacenar:
Un identificador único asignado por el agente.
Las capacidades básicas del objeto.
Información de cómo han sido obtenidas las muestras: algoritmo de muestro,
almacenaje, etc.
El número máximo de datos que puede almacenar.
El número de datos almacenado.
Sí se siguen insertando datos en alguno de los segmentos que contiene.
Una cadena que indica la intención de su uso.
La frecuencia con la que se añaden nuevas muestras.
El número de segmentos que contiene.
El tiempo mínimo que debe esperar para que se complete el borrado de uno de
los segmentos que contienen la clase.
Métodos: En este caso se definen varios métodos:
Clear-Segments: Que permite al manager borrar una serie de segmentos
almacenados en el agente. Necesita un parámetro del tipo segmSelection, y no
devuelve ningún tipo de parámetro.
Get-Segmet-Info: El manager es capaz de obtener los atributos de uno o más
PM-Segmentos.El parámetro de entrada será del tipo segmSelection y como
salida obtendrá uno del tipo SegmentInfoList.
Trig-Segment-Data-Xfer: El manager pide al agente que empieza a transmitir
un segmento PM específico. El agente se puede segar o aceptar.
Eventos: En esta clase, solo encontramos un método implementado, Segment-DataEvent, que se produce cuando el agente envía un segmento en concreto al manager,
Servicios: En este caso sólo tenemos el servicio GET, el cual permite al manager
obtener todos los atributos de un PM-Store.
PM-Segment Class
Uso: Los objetos de este tipo son los contenidos dentro de los objetos de la clase
PM-Store y por lo tanto son los que realmente contienen los datos tomados.
Identificación: MDC_MOC_PM_SEGMENT.
Atributos: Esta clase presenta los siguientes atributos:
Un identificador de la instancia del objeto.
El formato y contenido las entradas contenidas en él: si tienen cabecera, los
elementos definidos por su métrica, la clase de los objetos, etc..
De qué persona es ese segmento en concreto.
Si nuevas entradas están siendo añadidas a ese segmento.
La frecuencia con la que se añaden nuevas entradas al segmento.
Una cadena que muestra para que se pretende usar el segmento.
El tiempo en que comienza el segmento.
El tiempo en que finaliza el segmento.
Si ha habido algún cambio en la fecha/hora.
148
El número actual de entradas almacenadas.
El máximo, la media y el mínimo para cada elemento.
Los datos contenidos propiamente dichos.
El tiempo mínimo que ha de esperar una respuesta del manager después de la
emisión de un mensaje Confirmed Event Report invoke.
El tiempo minimo que el manager deberá esperar a que el agente acabe de
transferirle la información.
Esta clase no tiene ningún evento, método o servicio asociado.
Scanner Class
Esta clase tiene una estructura jerárquica un poco más compleja que las anteriores,
tal y como se puede ver en la Fig. E-5 extraida de (145).
Fig. E-5. Estructura de la clase CfgScanner.
Tanto la clase Scanner como CfgScanner son clases abstractas que nos servirán de
base para el resto de clases del tipo Scanner. A grandes rasgos estas clases sirven
de resúmenes o amalgama de otras clases, y crean notificaciones. De una manera
más profunda, podemos decir:
Scanner Class
Uso: Es una clase base y abstracta cuya principal función consiste en establecer
tres tipos diferentes de notificación de eventos.
Identificación: MDC_MOC_SCAN.
Atributos: Los atributos que se pueden encontrar dentro de esta clase, y por tanto
el resto de clases heredarán, son: Un identidificador.
El estado del objeto: si esta activo y si el manager puede interactuar con él.
El tipo de atributos (pertenecientes de una clase derivada de Metric) que pueden
ser comunicados al manager
Define el formato del mensaje que se va a utilizar en los reports del manager.
El único servicio que soportarán será el SET.
149
Anexos:
CfgScanner Class
Uso: Su función primordial es definir el comportamiento de la comunicación del
agente tal y como se muestra en la Fig. E-6 extraida de (145).
Fig. E-6. Gestión de la ventana de transmisión en la clase CfgScanner.
Identificación: MDC_MOC_SCAN_CFG.
Atributos: La información que se puede encontrar del objeto se puede resumir en:
Si las tramas necesitan confirmación o no.
El tiempo que debe esperar el agente para considerar que se ha “caído” la
comunicación y pasar a “desasociado”.
El numero de eventos que el agente puede transmitir sin necesidad que le llegue
un ACK, aunque de momento es siempre 1.
EpiCfgScanner Class
Uso: Se usará para notificar información de manera “episódica”, es decir que el
tiempo entre un dato y el siguiente. Cada vez que se produzca un cambio en uno de
los atributos que se notificará, guardando siempre un tiempo mínimo entre
notificaciones.
Identificación: MDC_MOC_SCAN_CFG_ EPI.
150
Atributos: El único atributo nuevo que podemos encontrar en esta clase es ese valor
mínimo entre dos notificaciones consecutivas.
Eventos: Dentro de esta clase se pueden distinguir los diferentes tipos de eventos,
todos ellos “unbuffered”, porque el agente no necesita almacenar información en un
buffer y esperar a que ocurra el próximo evento de transmisión. Entre los eventos
se distinguen:
Unbuf-Scan-Report-Var: Se usa el mensaje de formato variable (tipo, longitud,
valor) para notificar cualquier cambio en los objetos o atributos monitorizados.
Unbuf-Scan-Report-Fixed: Se usa el mensaje de formato fijo para notificar que
dato de los monitoreados ha cambiado.
Unbuf-Scan-Report-Grouped: Es la manera más compacta de realizar el envío de
los cambios en los objetos/atributos. Scan-Handle-Attr-Val-Map, campo
Heredado de Scanner, informa de que objetos y atributos están incluidos y la
forma del mensaje.
Unbuf-Scan-Report-MP-Var: Como Unbuf-Scan-Report-Var, pero permite la
inclusión de muchas personas.
Unbuf-Scan-Report-MP-Fixed: Como Unbuf-Scan-Report-Fixed, pero permite la
inclusión de más de una persona.
Unbuf-Scan-Report-MP-Grouped: Como Unbuf-Scan-Report-Grouped,
permite la inclusion de multiples personas.
pero
PeriCfgScanner class
Uso: Esta clase se utiliza para enviar la información de efectos que se muestrean
de manera periódica. La información también se manda de manera periódica y
contiene todos los eventos almacenados hasta la fecha. Así si suponemos dos
objetos, uno (objetoA) que toma muestras cada 3 segundos y otro (objetoB) que
realiza muestras cada segundo, y nosotros establecemos nuestro periodo de
muestreo (Reporting-Interval) en 1 segundo, recibiremos los objetos con una
periodicidad como la marcada en la Fig. E-7.
objetoB
1s
objetoB
1s
objetoA, objetoB
1s
objetoB
Fig. E-7. Ejemplo de recepción de tramas
Identificación: MDC_MOC_SCAN_CFG_ PERI.
Atributos: El único atributo que tenemos en esta clase es el Reporting-Interval, que
como ya se ha explicado es el periodo cada cual el manager interroga al agente por
los objetos/atributos que se estén monitorizando.
Eventos: Dentro de esta clase podemos distinguir los diferentes tipos de eventos,
todos ellos “buffered”, porque el agente necesita almacenar información en un
buffer y esperar a que ocurra el próximo evento de transmisión.
151
Anexos:
Sepueden distinguir los siguientes eventos: Buf-Scan-Report-Var: Se usa el mensaje de formato variable (tipo, longitud,
valor) para notificar cualquier cambio en los objetos o atributos monitorizados.
Buf-Scan-Report-Fixed: Se usa el mensaje de formato fijo para notificar que dato
de los monitoreados ha cambiado.
Buf-Scan-Report-Grouped: Es la manera más compacta de realizar el envío de
los cambios en los objetos/atributos. Scan-Handle-Attr-Val-Map, campo
Heredado de Scanner, dirá que objetos y atributos están incluidos y la forma del
mensaje.
Buf-Scan-Report-MP-Var: Como Buf-Scan-Report-Var, pero permite la inclusión
de muchas personas.
Unbuf-Scan-Report-MP-Fixed: Como Buf-Scan-Report-Fixed, pero permite la
inclusión de más de una persona.
Unbuf-Scan-Report-MP-Grouped: Como Buf-Scan-Report-Grouped, pero permite
la inclusión de multiples personas.
Service Model
El modelo de servicio establece mecanismos conceptuales de intercambio de
servicios (Esos servicios que ya se habían definido dentro del DIM). Esos
mecanismos acaban mapeándose en mensajes que acabarán intercambiándose el
manager y el agente. El protocolo hace distinción entre mensajes de asociación
(Association Service) y mensajes de comunicación de datos y servicio (Objects Access
Services).
Dentro del Association Service podemos identificar varios tipos de mensajes,
representados en la Fig. E-8:
Association Request: Un mensaje de petición de Asociación.
Association Response: Acepta la asociación si la comunicación es bidireccional.
Release Request: petición de liberación de la asociación.
Release Response: Acepta la liberación de la asociación.
Abort: Indica que la asociación termina de manera abrupta, seguramente por
un fallo y es por ello que ya no se espera ninguna respuesta.
Fig. E-8. Tipos de mensaje asociados a Association Service.
152
Dentro de Objects Access Services se pueden encontrar los siguientes métodos:
GET Service: El manager obtendrá los atributos de objetos MD y PM-Store.
Este método solo será válido si el agente está en estado operativo y se hace
referencia al MD o al handle de un objeto que se haya definido en la
configuración o bien el agente se encuentre en estado asociado y se esté
referenciando al MD.
SET Service: El manager podría ser capaz de cambiar alguno de los atributos
de los objetos del manager.
EVENT REPORT Service: Lo utiliza el agente para enviar las actualizaciones
de configuración y los datos medidos. El manager deberá mandar una
confirmación o un mensaje de error con el código correspondiente, si así lo pide
el agente.
ACTION Service: Se usan para que el manager invoque los métodos soportados
por los objetos del agente. Si el agente no soportase la acción o se produjese un
error en la ejecución del método, se debería responder con un mensaje de error
igualmente.
En cuanto al envío de la información:
Si lo que se quiere enviar es la CONFIGURACIÓN, entendiendo
configuración como el conjunto de objetos y atributos que contiene el agente:
Cada una de las posibles configuraciones que puede tener un agente está
identificada con el valor del campo Dev-Configuration-Id, el cual se transmite
al manager. Durante toda la asociación el número de objetos ha de
permanecer fijo, pero a estos objetos se les puede añadir nuevos atributos o
cambiar de valor. Si deseásemos el utilizar una configuración distinta,
deberíamos desconectarnos y volver a establecer la conexión.
Para añadir un nuevo atributo, se usará el mensaje de formato variable,
pero si un atributo cambia de valor podremos usar el mensaje de formato fijo,
variable o agrupado dependiendo de la configuración. Estos cambios, se
“perderán” una vez se haya desasociado el dispositivo. Si queremos hacer esos
cambios permanentes, deberemos crear una nueva configuración y asociarle
un nuevo identificador. Además de la configuración estándar, en la
especialización de dispositivos hay una serie de objetos (con sus atributos) que
deben transmitirse con la configuración del agente.
Para optimizar el tamaño de los mensajes, podemos distinguir dos tipos de
configuraciones, estándar y extendida:
 Una configuración estándar no deja de ser una configuración en una
especialización de dispositivos (como la ISO/IEEE 11073-104zz), que tiene su
id entre en un mínimo y un máximo (salvo las reservadas). Ahora bien, el
manager es el elemento clave: si el manager conoce una determinada
especialización de dispositivos, conoce todas las configuraciones estándar
dentro esta especialización. Así, no es necesario que el manager pregunte la
configuración si el id de esa configuración corresponde a una configuración
estándar y ambos dispositivos pasan al estado operando. Aunque esto sucede
así un agente debe proporcionar su configuración si le es requerida y si usa
un id de configuración debe implementar todos los elementos del modelo de
servicios y comunicación.
153
Anexos:
 La configuración extendida es más compleja: la configuración puede tener
diferentes objetos, con diferentes atributos, etc.. En este caso el identificador
está comprendido en otro rango. En este caso la única manera de que no se
transmita la configuración después de transmitir el id sería que el manager
ya la conociera por algún método {el agente ya se hubiera asociado
previamente, la configuración hubiera sido pre-cargada}.
Como el identificador de configuración solo es único de manera local, en el caso
de la configuración extendida dos configuraciones extendidas de dos agentes con
ids idénticos pueden no contener los mismos objetos.
Agent-initiated measurement data transmission se usan por el agente para
ENVIAR INFORMACIÓN COMO RESULTADO DE UNA NUEVA
MEDIDA. A su vez el manager puede indicar al agente cuando puede empezar a
mandar datos o cuando parar.
A lo largo de este manual se ha hablado de tipos de mensaje con formato fijo,
varible o agrupado, los cuales se muestran en la Fig. E-9.
Comparision between different reporting formats
Obj-handle x
2 bytes (Using MDER)
Attribute ID x_y
Length x_y
4 bytes (Using MDER)
Variable Format
Obj-handle 1
Fixed Format
Grouped Format
Obj-handle 1
Attribute ID 1_1
Length 1_1
Value_1_1
Value_1_1
Value_1_1
Value_1_2
Value_1_2
Value_1_3
Value_1_3
Attribute ID 1_2
Length 1_2
Value_1_2
Attribute ID 1_3
Length 1_3
Value_1_3
Obj-handle 2
Obj-handle 2
Attribute ID 2_1
Length 2_1
Value_2_1
Obj-handle n
Value_2_1
Value_2_1
Obj-handle n
Attribute ID n_1
Length n_1
Value_n_1
Value_n_1
Value_n_1
Value_n_2
Value_n_2
Attribute ID n_2
Length n_2
Value_n_2
Fig. E-9. Mensaje varible, fijo y agrupado.
154
Como se puede ver en este diagrama, la diferencia entre un tipo y otro es la
cantidad de “información de cabecera” que hay que mandar: identificadores de
objeto, identificadores de atributo, y longitud del valor del atributo que se está
mandando.
La trama de formato variable es mucho más flexible porque permite ir
añadiendo objetos y atributos sin ninguna restricción, pero se paga un precio en
cuanto al incremento de información de control; el formato fijo y agrupado
introduce menos información de control porque el formato del mensaje que vas a
transmitir está definido en un atributo (Attribute-Value-Map ó Scan-Handle-AttrVal-Map) y el agente transmite la info pertinente en el mismo orden y longitud. El
manager obteniendo previamente el valor de ese atributo es capaz de decodificar
correctamente la información.
Otro aspecto importante en la formación de la tramas, es que estas pueden
llegar a contener datos de varias personas si el agente ha sido diseñado para ello:
hay un formato de trama para enviar datos de varias personas y hay un formato de
trama que te permite enviar los datos de una única persona.
El estándar también te da la posibilidad de desarrollar agentes que pueden
tener un sistema de almacenaje de datos por si el agente es capaz de obtener una
medida y no es capaz de contactar con el manager con una serie de condiciones:
Las medidas tienen que ser objetos del tipo metric, pero no RT-SA.
Es necesario almacenar referencias temporales y el agente no transmitirá
aquellos datos que no tengan una coherencia {por ejemplo si tenemos una
referencia a tiempo relativo y alguien cambia la hora, pues no sabemos
exactamente cuándo }
Tras enviarle los datos al manager se ha de asegurar que los ha recibido y
borrarlos luego.
Podremos enviar estos datos con cualquier tipo de mensaje pero nunca
excederemos la cantidad de 25 datos por mensaje.
155
Anexos:
Comms Model
La comunicación entre un agente y un manager siempre es punto a punto, y si
un manager tiene la capacidad de hablar con varios agentes a la vez deberá ser
capaz de gestionar cada una de esas conexiones por separado.
Características de la comunicación:
En este estándar se está suponiendo que el perfil del la capa de transporte
puede dar servicios tanto fiables como best-effort. En concreto, asume que hay un
canal primario de tipo fiable que se va a utilizar para todos los mensajes que tienen
relación con la asociación del agente con el manager, todos los que definen el
modelo de servicio y necesitan confirmación {get, set, action y los even-report} y
todos los mensajes de error que surgen por falta de conexiones.
En cuanto a los canales secundarios, pueden ser tanto fiables como best-effort y
se usan para aquellos mensajes del modelo de servicio que no necesitan una
confirmación.
En función de si el canal es fiable o best effort, las PDUs han de cumplir una
serie de condiciones (lo ya conocido: si pueden llegar o no duplicadas, pueden
perderse o no, pueden desbordar al receptor o no, etc.) , pero si se establece que el
tamaño de trama agente-manager no puede exceder 63K y 8K en sentido contrario,
así como que el tamaño de la trama debería indicarse como un metadato entre las
diferentes capas del protocolo y que la capa de transporte debe comunicar el
tamaño de la trama a su homónimo.
Máquina de estados:
Cada vez que el agente necesite enviar algún dato al manager tendrá que
asociarse. Todo este proceso pasa por una serie de estados, tanto para el manager
como para el agente. Así:
PARA EL AGENTE (ver Fig. E-10): En un principio partimos del agente esta
desconectado del mundo, pero cuando le llega una señal que indique que se ha
establecido la conexión al nivel de transporte pasa al estado conectado. Una vez
entra en ese estado, pasa directamente a desasociado, que es un sub-estado de
conectado. Cuando el agente lo decida puede mandar una petición de asociación
{assocReq} y así pasa al sub-estado asociando. Si recibe una señal de
confirmación {RxAssocRsp(Accepted)} pasa a asociado, pero si recibe un señal de
rechazo {RxAssocRsp(rejected)} vuelve al estado desasociado. Una vez que
estamos en asociado, podemos encontrarnos dos diferentes casos: que el manager
ya conozca la configuración que estamos usando y pasemos directamente al
estado operando o que la desconozca y pasásemos al estado configurando. Si
estamos en el estado configurando, se mandarán configuraciones al manager
hasta que conozca una en concreto y recibiremos una señal
{RxConfigEventReportRsp} que nos haga pasar al estado operando y será en ese
momento cuando podamos intercambiar datos con el manager. Obviamente este
proceso no puede tardar varios años en ocurrir y como ya se explico en el DIM
hay una serie de Tiempos de Timeout que se si son rebasados llevan al estado
desasociado.
PARA EL MANAGER (ver Fig. E-11): La máquina de estados del manager es
muy similar a la del agente; prácticamente simétrica.
156
Disconnected
Transport disconnect indication
Transport connect indication
Connected
Associated
Disassociating
assocRelReq
+entry / TxAssocRelReq
Operating
RxAssocRelReq/
TxAssocAbort
TxAssocRelRsp
RxAssocAbort
RxAssocRelRsp
Unassociated
TxAssocAbort
RxAssocAbort
Configuring
RxAssocRelReq/
TxAssocRelRsp
RxConfigEventReportRsp
(accepted-config)
Waiting Approval
assocReq
RxAssocAbort
Or
TxAssocAbort
RxAssocRsp
(accepted)
RxConfigEventReportRsp
(unsupported-config)
RxAssocRsp
(rejected)
Associating
+ entry / TxAssocReq
TxConfigEventReportReq
RxAssocRsp
(accepted-unknown-config)
Sending Config
Fig. E-10. Máquina de estados en el agente
Disconnected
Transport disconnect indication
Transport connect indication
Connected
Associated
Disassociating
assocRelReq
+entry / TxAssocRelReq
Operating
RxAssocRelReq/
TxAssocAbort
TxAssocRelRsp
RxAssocAbort
RxAssocRelRsp
Unassociated
TxAssocAbort
RxAssocAbort
RxAssocRelReq/
TxAssocRelRsp
Configuring
TxConfigEventReportRsp
(accepted-config)
Checking Config
RxAssocReq
RxAssocAbort
Or
TxAssocAbort
TxAssocRsp
(accepted)
TxConfigEventReportRsp
(unsupported-config)
TxAssocRsp
(rejected)
Associating
+ entry / LookupConfig
RxConfigEventReportReq
TxAssocRsp
(accepted-unknown-config)
Waiting for Config
Fig. E-11. Máquina de estados en el manager.
157
Anexos:
Esto es lo que puede llamarse comportamiento normal del sistema. Obviamente
hay saltos imprevistos ente estados debidos a errores, como por ejemplo:
Un dispositivo puede pasar al estado desasociado si ocurre algún problema con
la conexión a nivel de enlace: se cae la conexión wireless, etc.
Generar un mensaje de Abort Association.
Si se sobrepasa el timeout de espera a que se reciba la aceptación de la petición
de asociación un determinado número de veces.
Si se cumplen diversos tiempos de timeout.
Basándonos en todos los casos anteriores, podemos ver la importancia de todos
esos mensajes tienen. En un análisis más pormenorizado podemos llegar a analizar
las principales tramas que se intercambian agente y manager de las tramas en los
campos que las contienen para analizar la información transportan:
Association Request
…
…
Fig. E-12. Trama Association Request.
Dentro
de
esta
trama
(ver
Fig. E-12) se pueden identificar por orden:
APDU Choice: Se Elige aarq para indicar que estamos solicitando asociarnos.
Tamaño: el tamaño del resto de la trama en bytes.
Assoc Version: Indica si soporta la versión 1 del protocolo de asociación {32
bytes}
Data Protocol List: Es una lista de todos los protocolos que el agente soporta, y
se listarán en orden de preferencia para el agente. En el ejemplo de arriba, se
158
puede ver que en el count = 1 {sólo soporta un protocolo de intercambio de la
información}, así que sólo tendremos que identificar un protocolo,
idDataProtocol = 20601 lo que indica que sigue este protocolo. Si tuviera
idDataProtocol = 65535 indicaría que es un protocolo específico de fabricante.
Tamaño: Este otro campo identifica el número de bytes de la trama que restan.
PhdAssociationInformation: la cual contiene información relativa a que versión
del protocolo se está implementando, normas de cifrado (Se ha de dar soporte a
MDER, pero también se pueden ofrecer otras añadiendo nuevos bits), la versión
de la nomenclatura utilizada, todas las unidades y características adicionales
que el dispositivo soporta, un identificador único de dispositivo (En concreto
System-Id del objeto MD, el cual tenía 20 bits que identificaban al fabricante y
40 que identifican al dispositivo, el id de la configuración con la que se está
intentando asociar, que modo de comunicación soporta{envío periódico de datos,
simple, sin duración en el tiempo, si esas opciones son válidas para todos los
objetos, solo para algunos, etc..), )
Otro tamaño: Indica de esa posición al final
Una serie de tramas que solo se rellenarían si en las especializaciones se dijera
que han de tener un valor distinto de vacío.
La respuesta a esta trama sería:
Association response
Fig. E-13. Trama Association response.
Dentro de esta trama (ver Fig. E-13) se pueden distinguir:
APDU: Un campo que indica que el tipo de trama es un Association Response.
En concreto en este campo hay un “aare”.
El tamaño de la trama.
159
Anexos:
AssociateRessult: que nos dice que código nos devuelve el manager: en el ejemplo
se acepta la asociación pero no se conoce la configuración que quiere utilizar el
agente.
La identidad del protocolo que el manager ha decidido utilizar entre todos los
que el agente le ofrece. En este caso se van a comunicar con el x73.
La norma de cifrado elegidas de entre las que le ofrece el agente; como en el
caso anterior solo nos ofrecía una.
En el caso que la asociación sea aceptada o aceptada sin conocer la configuración
se indicará que versión de la nomenclatura se está utilizando.
Si la respuesta es del tipo accepted-config-unknown, se deberán indicar las
unidades de funcionamientos y características opcionales que el manager elija.
Un identificador único del manager, que podría servir al MD para saber que se
está comunicando con el correcto manager. Este identificador está incluido
dentro del campo de tipo de sistema.
Release Request
Fig. E-14. Trama Release Request
Esta trama (ver Fig. E-14) la puede enviar tanto CE como MD, pues ambos
tienen la capacidad de solicitar el final de la asociación. Tras indicar que estamos
ante una solicitud de liberación de la asociación, lo único a indicar es el motivo por
el que queremos desasociarnos que comprende valores tan variados como que el
manager haya rechazado todas las configuraciones que le ha ofrecido el agente, que
haya cambiado la configuración mientras este en el estado Operating, o
simplemente sin indicar ninguna condición especial lo que es una salida normal,
que no se debe a causas especiales.
Release Response
Fig. E-15. Trama Release Response.
Esta trama (ver Fig. E-15) es la que se envía en respuesta al Release Response.
Tras indicar que es una trama de aceptación liberación del estado de asociación, se
indica el tamaño y la razón.
160
Abort
Fig. E-16. Trama Abort.
Como ya se ha indicado anteriormente, una trama de abort (ver Fig. E-16) se da
cuando se notifica que se va a salir del estado asociado de una manera unilateral,
sin esperar la respuesta de la otra parte. Como en casos anteriores, el primer
campo que contiene esta trama es un indicativo de su tipo: ABRT en este caso.
Luego tras el tamaño, la razón por la que se finaliza la asociación: Un overflow en
un buffer, por que el tiempo de respuesta ha sobrepasado el time-out o porque no se
ha recibido el mensaje de configuración en un determinado tiempo.
Data Request Action.
Fig. E-17. Trama Data Request Action.
Esta trama (ver Fig. E-17) la genera el manager, para obtener información del
agente.
En el primer campo se indica que la trama va a ser una APDU presentation. Una
trama de este tipo no es más que una versión codificada de DataAPDU y esta está
definida como un OCTECT STRING. Por lo tanto, pondremos dos bytes que
indiquen su tamaño como indica las reglas de codificación MDER (obviamente se
está suponiendo su uso, aunque el estándar deja posibilidades a otras reglas de
codificación). Dentro de esa trama, los campos que vamos a representar son:
Invoke-Id: Un identificador de comunicación. Es un número de 16 bits sin signo.
El manager tiene que limitar el número de mensajes salientes porque el agente
podría no ser capaz de manejar mas que un mensaje a la vez.
Un mensaje. El contenido del mensaje que va a ir a continuación. Como se indica
en este ejemplo, ese campo para este tipo de trama tomará el valor 0x0107, lo
que nos definirá los campos siguientes:
o Un handle de objeto, un identificador único.
o El tipo de acción que se va a realizar.
o Y tras un campo que indicará la longitud, tendremos los argumentos que se
enviarán que corresponden a una estructura DataRequest, el cual da soporte
para un identificador y poder distinguir entre diferentes peticiones, el modo
de la petición, una indicación del tiempo que se le permite transmitir a un
agente, un identificador de persona, un OID que identifica la subpartición y
una secuencia de handles.
161
Anexos:
Data Request Action Response
Fig. E-18. Trama Data Request Action Response.
Esta
trama
(ver
Fig. E-18) es la respuesta del agente. En este caso sólo cambia el mensaje que se
está transmitiendo. También cambiarán los argumentos, que en este caso
corresponderán a una estructura DataResponse en la cual se indica el uso de
tiempo relativo (todo a 1 si no se soporta esta característica), los datos resultantes
de la petición, y si estamos en el caso data-req-mode-single-rsp el tipo de evento y
los parámetros que lleva asociado. El tipo de evento corresponde con los eventos
que se definían para el objeto MD.
Data Reporting
Fig. E-19. Trama Data Reporting.
El comienzo de esta trama (ver Fig. E-19) es un campo indicativo de su tipo (PRST
en este caso). A estos campos le siguen un identificador de la comunicación, el
tamaño de la trama hasta ese punto, un identificador del objeto, parámetros de
configuración de cómo se realiza la comunicación (si se utiliza tiempo absoluto o
relativo, el tipo de mensaje que se utiliza (fijo, varible, etc.), etc.) el tamaño de la
trama y los objetos en concreto.
162
Data Request Action.
Fig. E-20. Trama Data Request Action.
Esta trama (ver Fig. E-20) se genera en el manager para obtener información
del agente.En el primer campo se indica que la trama va a ser una APDU
presentation;
Una trama de este tipo no es más que una versión codificada de DataAPDU y
esta está definida como un OCTECT STRING. Por lo tanto, pondremos dos bytes
que indiquen su tamaño como indica las reglas de codificación MDER. Dentro de
esa trama, los campos que vamos a representar son:
Invoke-Id: Un identificador de comunicación. Es un número de 16 bits sin signo.
El manager tiene que limitar el número de mensajes salientes porque el agente
podría no ser capaz de manejar mas que un mensaje a la vez.
Un mensaje. El contenido del mensaje que va a ir a continuación. Como se indica
en este ejemplo, ese campo para este tipo de trama tomará el valor 0x0107, lo
que nos definirá los campos siguientes:
o Un handle de objeto{ era un identificador único}
o El tipo de acción que se va a realizar
o Y tras un campo que indicará la longitud, tendremos un los argumentos que
se enviarán que corresponden a una estructura DataRequest, el cual da
soporte para un identificador y poder distinguir entre diferentes peticiones,
el modo de la petición, una indicación del tiempo que se le permite transmitir
a un agente, un identificador de persona, un OID que identifica la
subpartición y una secuencia de handles.
163
Anexos:
164
Anexo F: Envejeccimiento de la población y cronicidad de las enfermedades
Anexo F . Envejecimiento de la población y
cronicidad de las enfermedades.
El envejecimiento de la población ocurre cuando se produce un transito de
regímenes de alta mortalidad y natalidad a otros en los que dichos niveles se
encuetran controlados (169). Las mejoras tecnológicas y sociales han permitido,
principalmente, una reducción en la tasa de mortalidad de la población. El
descenso de la tasa de natalidad en países desarrollados se debe a un mayor control
y planificación familiar. (170) Esto hace que haya diferentes velocidades de
envejecimiento de la población: así, se prevé que la población de África conserve
población relativamente joven hasta mediados del siglo XXI. (171)
Si se utiliza como base los datos de la revisión de 2008 de las expectativas de la
población mundial, se pueden relizar las pirámides poblaciones del año 2000 a
nivel mundial y la prevista para el año 2050 (Ve Fig. F-1). En ella se puede
observar la tendencia que se describía anteriormente: a pesar del peso específico
que pueden ejercer los países subdesarrollados maquillando el envejecimiento
global, sí se puede apreciar un ligero estrechamiento de la base. La evolución de la
pirámide hacía una forma más acampanada clasifica la pirámide como regresiva.
Pirámide poblacional 2000
+100
90‐94
80‐84
70‐74
60‐64
50‐54
40‐44
30‐34
20‐24
10‐14
0‐4
400000
300000
200000
100000
0
Mujeres
100000
200000
300000
400000
300.000,00
400.000,00
Hombres
Piramide poblacional 2050
+100
90‐94
80‐84
70‐74
60‐64
50‐54
40‐44
30‐34
20‐24
10‐14
0‐4
400.000,00
300.000,00
200.000,00
100.000,00
0,00
Mujeres
100.000,00
200.000,00
Hombres Fig. F-1 Evolución de la pirámide poblacional a nivel mundial
165
Anexos:
Fig. F-2. Previsión de la situación en España
En este tipo de pirámides, el grupo de población adulta predomina sobre el de la
población joven y el porcentaje de ancianos es importante. Una ejemplificación de
esta problemática reside en el incremento de la dependencia en países
desarrollados donde, por ejemplo, según (171) el porcentaje de personas
dependientes crecerá desde 49 a 75 en 2050. Además se puede observar un
envejecimiento gradual de la propia población envejeciente. En concreto, este
estudio predice que el grupo de la población de mayores de 80 años que apenas
llega al 1,5 % se cuadriplicará en 2050.
Si se tomara como ejemplo un caso en concreto, como puede ser España, existen
predicciones de cuan acentuado puede ser el estrechamiento de la pirámide
poblacional. En la Fig. F-2 se muestra el resultado de un estudio (172) realizado
por el Instituto Nacional de Estadística (INE) donde se avala un posible descenso
en la tasa de natalidad. Además se pone de relieve una situación que no se había
contemplado hasta este instante: la contribución de población inmigrante a este
estudio. Este hecho, que podría adquirir un carácter conformador de los resultados
se desestima previendo una severa corrección de la inmigración en próximos años.
El envejecimiento de la población conlleva una serie de consecuencias, todavía
imprevisibles en la actualidad. Entre esas consecuencias se pueden encontrar el
envejecimiento de la mano de obra o el futuro de las pensiones. Tampoco es
desestimable el efecto sobre el sistema de salud. El problema es uno de los
principales focos que se tratan desde la comunidad europea, como el planteamiento
estratégico de la salud pública para la UE (173), entre cuyos objetivos se
encuentran promover la buena salud en una Europa que envejece, proteger a los
coiudadanos frente a las amenazas de la salud y la promoción de sistemas
sanitarios dinámicos y el uso de nuevas tecnologías.
166
Anexo F: Envejeccimiento de la población y cronicidad de las enfermedades
Este documento toca dos puntos clave: el envejecimiento de la población como la
prevención de la enfermedad, aspectos que fundamentan esta TFM, y que en cierta
medida se encuentran relacionados. Como se ha venido comentando en el desarrollo
de esta tesis, el cambio en el espectro demográfico conlleva cambios en el foco de
acción sanitaria: la cronicidad en las en enfermedades se convierten en un aspecto
clave. Con una población envejecida y la mayor co-morbilidad de las enfermedades
crónicas se dispara el gasto sanitario y, en concreto, el farmacéutico.
¿Pero es tan grave la prevalencia de las enfermedades crónicas? Sí. Muchos
estudios los corroboran, entre ellos uno realizado por la OMS en el que se concluye
que más de la mitad de las muertes en el mundo se deben a solo cuatro condiciones
crónicas (diabetes, enfermedades pulmonares, algunos cánceres y enfermedades del
corazón) causadas por tres factores de riesgo: tabaquismo, mala alimentación y
falta de actividad física. (174)
Fig. F-3. Distribución Mundial de las Muertes según Causa por Grupos de Países
Fig. F-4. Distribución Mundial de Muertes por Causa y Región del Mundo
167
Anexos:
Las Fig. F-3 y Fig. F-4 son las figuras más ilustrativas encontradas de la
importancia de las enfermedades crónicas, donde se presentan como principal
causa de muerte, aunque para el autor la expresión tal vez no sea la más adecuada
pues, por ejemplo la diabetes que es una de las enfermedades crónicas más
habituales no causa la muerte, sino las complicaciones asociadas a sufir esa
patología. Las personas ya no mueren de una enfermedad, sino estando enfermas.
¿Es esta situación evitable? Sí. Y la respuesta la encontramos en el mismo
informe de la OMS: si la mala alimentación es la causa de sobrepeso, actuando
sobre la alimentación podremos, al menos, mitigar sus efectos. Y como, bien se
apuntaba en (173), es necesario cambiar hacia un modelo más activo, donde el
paciente sea parte integrante del equipo responsable de su propia salud.
168
Anexo G: Comparativa entre UNE-EN/ISO 13606 e ISO/IEEE 11073
Anexo G . Comparativa entre UNE-EN/ISO
13606 e ISO/IEEE 11073
Este anexo estudia la viabilidad, parcial ó total, entre la norma EN 13606 y el
estándar ISO/IEEE 11073. Dicho estudio constituye la base de la implementación
del servidor de HCE y del protocolo de comunicaciones extremo a extremo entre el
CE y MS, y se centra en el análisis detallado de ambos modelos de referencia:
Reference Model en UNE-EN/ISO 13606 (146) y Modelo de Información DIM en
ISO/IEEE 11073 (145)
EHR_EXTRACT: Es el “contenedor” de mayor orden jerárquico. Realmente se
puede obtener de manera cuasi-estática toda la información salvo quién es el
paciente del que se asocian los datos. En principio en la clase PM-Segment sí que
hay un campo que indica a qué paciente/persona pertenecen los datos que se están
tomando, pero para el resto de clases derivadas de METRIC no es obvio. Hay una
relación entre el objeto MD y todas las clases que heredan de METRIC, pero no un
campo específico. El resto de “clases contenedoras” en el extracto heredan de
RECORD_COMPONENT, por lo tanto van a tener una serie de campos comunes a
todas ellas. En las tablas Tabla G-1, Tabla G-2 se analizan todos los campos
posibles.
Nombre del atributo
Authorising_party
ehr_id
ehr_system
rm_id
subject_of_care
Time_created
Tipo de dato
Obligatorio
II
II
II
String
II
TS
No
Sí
Sí
Sí
Sí
Sí
Equivalencia_X73
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
Tabla G-1. Atributos de EHR_EXTRACT.
Atributos por Asociación
all_compositions
Criteria
Folders
demographic_extract
Tipo de dato
Set<Compositions>
Set<extract_criteria>
Set<folders>
Set<II>
Obligatorio Equivalencia_X73
No
No
No
No
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
Tabla G-2 Atributos por asociación de EHR_EXTRACT.
FOLDERS: Es una clasificación OPCIONAL mediante la cual, un centro sanitario
puede organizar las COMPOSITIONS conforme a un criterio dado: todas las que
correspondan a un episodio (alguien se nota débil y se hace análisis, va al médico,
al especialista de respiratorio, etc.), las que correspondan a la misma especialidad
(todas las de psiquiatría, todas las de endocrinologia, etc.), etc. Un FOLDER puede
tener otros FOLDERS. Se realiza un análisis más pormenorizado en las tablas
Tabla G-3 y Tabla G-4
169
Anexos:
Nombre del atributo
Archetype_id
meaning
name
Orig_parent_ref
Policy_ids
Rc_id
sensitivity
synthesised
Tipo de dato
Obligatorio
II
CV
TEXT
II
Set<II>
II
Integer
Boolean
No
No
Sí
No
No
Sí
No
Sí
Equivalencia_X73
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
Tabla G-3. Atributos de FOLDER.
Atributos por asociación
links
Feeder_audit
Sub-folders
Attestations
compositions
Tipo de dato
Obligatorio
Set<LINKS>
AUDIT_INFO
Set<Folder>
Set<attestation-info>
Set<Composition>
No
No
No
No
No
Equivalencia_X73
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
Posible sentido
Tabla G-4. Atributos por Asociación de FOLDER.
COMPOSITION: Una COMPOSITION está definida como toda interacción médico
paciente. Session_time es el intervalo de tiempo mediante el cual está teniendo
lugar la recogida de datos. No es un campo obligatorio, pero podría armonizarse con
X73 de distintas formas:
Accediendo a el atributo Date-and-Time del objeto MD justo después de
asociarse y justo antes de desasociarte.
Una vez que has recibido todas las medidas de una asociación entre MD y CE,
siempre y cuando se almacenen en un PM-Segment (en ese caso se ha de
establecer una medida temporal de cuando se tomaron) seleccionar la mayor y
la menor.
Implementar el atributo condicional Absolute-Time-Stamp y quedarte con el
mayor y el menor de cada uno de ellos.
Una COMPOSITION puede estar estructurada en SECTIONS. Esta división no
tiene otra función que la de facilitar la lectura o navegación dentro de la
COMPOSITION y su uso es OPCIONAL. El análisis se halla en las tablas Tabla
G-5 y Tabla G-6
170
Nombre del atributo
Archetype_id
meaning
name
Orig_parent_ref
Policy_ids
Rc_id
sensitivity
synthesised
Contribution_id
Session_time
Territory
Tipo de dato
Obligatorio
II
CV
TEXT
II
Set<II>
II
Integer
Boolean
II
IVL<TS>
CS
No
No
Sí
No
No
Sí
No
Sí
No
No
No
Equivalencia_X73
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
Posible sentido
No tiene sentido
Tabla G-5. Atributos de COMPOSITION.
links
Feeder_audit
Attestations
Other_participants
Committal
Content
Composser
Tipo de dato
Obligatorio
Set<LINKS>
AUDIT_INFO
Set<Attestation_info>
Set<Functional_role>
AUDIT_INFO
Set<Content>
Functional_role
No
No
No
No
SI
No
No
Equivalencia_X73
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
ENTRIES
No tiene sentido
Tabla G-6. Atributos por asociación de COMPOSITION.
SECTIONS: Su función es la de estructurar la información dentro de una misma
COMPOSITION para favorecer su lectura o reflejar el flujo de información dentro
de un encuentro clínico. Una SECTION puede estar subdividida en otras
SECTION, y así sucesivamente. El estudio completo de esta entidad se encuentra
en las tablas Tabla G-7 y Tabla G-8. Nombre del atributo
Archetype_id
meaning
name
Orig_parent_ref
Policy_ids
Rc_id
sensitivity
synthesised
Tipo de dato
Obligatorio
II
CV
TEXT
II
Set<II>
II
Integer
Boolean
No
No
Sí
No
No
Sí
No
Sí
Equivalencia_X73
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
Tabla G-7. Atributos de SECTION.
171
Anexos:
Tipo de dato
links Set<LINKS>
Feeder_audit AUDIT_INFO
Members Set<Contents>
Obligatorio Equivalencia_X73
No
No
No
No tiene sentido
No tiene sentido
No tiene sentido
Tabla G-8. Atributos por asociación de SECTION.
ENTRY: Contiene toda la información relacionada con una medida/observación o
batería de medidas/observaciones. En resumen, representa la unidad mínima de
significación clínica. Puede estar compuesta por CLUSTERS y /o ELEMENTS. En
concreto, el meaning de una entrada lo podemos obtener a partir del atributo type
que heredan todas las clases de METRIC y tras identificarlo enlazarlo con una de
las terminologías médicas. El Campo Info_provider, tampoco es obligatorio, pero
podría servir para indicar explícitamente que los valores que se están teniendo en
cuenta son obtenidos de manera remota a la consulta médica. Este atributo es del
tipo FUNTIONAL_ROLE y, a su vez, está compuesto por los siguientes atributos:
funtion  Se obtiene de manera estática. healthcare_facility  Se obtiene de manera estática. mode 
Se obtiene de manera estática. performer 
system‐Id del objeto MDS service_setting 
Se obtiene de manera estática. Se puede observar el estudio completo en las tablas Tabla G-9 y Tabla G-10
Nombre del atributo
Archetype_id
meaning
name
Orig_parent_ref
Policy_ids
Rc_id
sensitivity
synthesised
act_id
Act_status
Subject_of_information_category
Uncertainly_expressed
Tipo de dato
Obligatorio
II
CV
TEXT
II
Set<II>
II
Integer
Boolean
String
String
CS
Boolean
No
No
Sí
No
No
Sí
No
Sí
No
No
No
Sí
Tabla G-9. Atributos de ENTRY.
172
Equivalencia_X73
No tiene sentido
Posible sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
Tipo de dato
Obligatorio
links
Feeder_audit
Items
Info_provider
Other_participants
Subject_of_Information
Set<LINKS>
No
No
No
No
No
No
AUDIT_INFO
Set<ITEM>
FUNCTIONAL_ROLE
Set<FUNCTIONAL_ROLE >
RELATED_PARTY
Equivalencia_X73
No tiene sentido
No tiene sentido
CLUSTER, ELEMENT
Posible sentido
No tiene sentido
No tiene sentido
Tabla G-10. Atributos por asociación de ENTRY.
CLUSTERS: Es una estructura que sirve para estructurar información compleja. Dentro de los CLUSTERS se pueden encontrar anidados otros CLUSTERS o ELEMENTS. Deriva de ITEM. Como ocurría en la ENTRY el meaning se puede obtener a partir del atributo Type. Y como ya habíamos comentado anteriormente, el instante en el que se adquiere una medida no tiene porque ser el mismo que cuando se ingresan los datos en el sistema sanitario. Se necesita conseguir el instante en el que se adquiere una medida. Se puede observar un estudio completo en las tablas Tabla G-11 y Tabla G-12. Nombre del atributo
Archetype_id
meaning
name
Orig_parent_ref
Policy_ids
Rc_id
sensitivity
synthesised
Emphasis
Ítem_category
Obs_time
Structure_type
Tipo de dato
Obligatorio
II
CV
TEXT
II
Set<II>
II
Integer
Boolean
CV
CS
IVL<TS>
CS
No
No
Sí
No
No
Sí
No
Sí
No
No
No
Sí
Equivalencia_X73
No tiene sentido
Posible sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
Posible sentido
No tiene sentido
Tabla G-11. Atributos de CLUSTER
links
Feeder_audit
Parts
Tipo de dato
Obligatorio
Set<LINKS>
AUDIT_INFO
Set<ITEM>
No
No
No
Equivalencia_X73
No tiene sentido
No tiene sentido
Posible sentido
Tabla G-12. Atributos por asociación de CLUSTER
173
Anexos:
ELEMENTS: Un ELEMENT es la unidad contenedora más baja. Son los
elementos que acaban conteniendo los Data Value En cuanto al tiempo tenemos la
misma consideración que en el apartado anterior. El meaning de los elementos se
pueden transmitir para identificar los elementos dentro de una medida compleja:
por ejemplo, diferenciar sistólica de diastólica. En este caso podemos obtener esos
valores del Metric-Id-List campo que está en metric. Como se ha hecho referencia a
estas clases o tipos de dato, vamos a poner que atributos tienen:
Nombre del atributo
Tipo de Dato
Obligatorio
II
CV
TEXT
II
Set<II>
II
Integer
Boolean
CV
CS
IVL<TS>
Data Value
No
No
Sí
No
No
Sí
No
Sí
No
No
No
No
Archetype_id
meaning
name
orig_parent_ref
policy_ids
rc_id
sensitivity
synthesised
emphasis
ítem_category
obs_time
value
Equivalencia_X73
No tiene sentido
Posible sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
Posible sentido
Dato
Tabla G-13. Atributos de ELEMENT.
Tipo Dato
links Set<LINKS>
Feeder_audit AUDIT_INFO
Obligatorio
No
No
Equivalencia_X73
No tiene sentido
No tiene sentido
Tabla G-14. Atributos por asociación de ELEMENT.
AUDIT_INFO: Representa información de cuándo y quién manda la información,
tanto en la vez inicial como en las sucesivas versiones de ese dato
Nombre del atributo
Tipo de Dato
Obligatorio
commiter
ehr_system
previous_version
reason_for_revision
time_committed
versión_set_id
versión_status
II
II
II
CV
TS
II
CS
Sí
Sí
No
No
Sí
No
No
Tabla G-15. Atributos de AUDIT_INFO.
174
Equivalencia_X73
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
ATTESTATION_INFO: Sirve para dar soporte a cualquier tipo de “testimonio” o
prueba de que es verdad. Así en algunos países europeos cuando te hacen una eco o
prueba similar debe quedar constancia de que imagen mostraba la pantalla cuando
se hizo un diagnostico. (Ver Tabla G-16, Tabla G-17)
Nombre del atributo
Attested_view
proof
Reason_for_attestation
Time
Tipo de dato
Obligatorio
ED
ED
CV
TS
No
No
Sí
Sí
Equivalencia_X73
No tiene sentido
No tiene sentido
No tiene sentido
No tiene sentido
Tabla G-16. Atributos de ATTESTATION_INFO.
target
attester
Tipo de dato
Obligatorio
Set<RECORD_COMPONENT>
Sí
Sí
FUNCTIONAL_ROLE
Equivalencia_X73
No tiene sentido
No tiene sentido
Tabla G-17. Atributos por asociación de ATTESTATION_INFO.
FUNCTIONAL_ROLE: Documenta la participación de una tercera persona,
dispositivo o componente software cuando se obtiene la información. Realmente,
dentro del X73 estos campos no tienen mayor valor, pero las composiciones creadas
a partir de datos adquiridos remotamente. (Ver Tabla G-18)
Nombre del atributo
funtion
healthcare_facility
mode
performer
service_setting
Tipo de Dato
Obligatorio
CV
II
CS
II
CV
No
No
No
Sí
No
Equivalencia_X73
No tiene sentido
Constante
Posible sentido
Posible sentido
Tabla G-18. Atributos de FUNCTIONAL_ROLE.
RELATED_PARTY: Sirve para identificar la relación del subject_of_information
con la del subject_of_care. (Ver Tabla G-19)
Nombre del atributo
party
relationship
Tipo de dato
Obligatorio
II
TEXT
No
Sí
Equivalencia_X73
No tiene sentido
No tiene sentido
Tabla G-19. Atributos de RELATED_PARTY.
175
Anexos:
LINK: Sirve para establecer relaciones entre distintos registros que no están
recogidos dentro de un mismo elemento contenedor, como relaciones causa/efecto.
(Ver Tabla G-20, Tabla G-21)
Nombre del atributo
follow_link
nature
role
Tipo de dato
Obligatorio
boolean
CS
CV
Sí
Sí
No
Equivalencia_X73
No tiene sentido
No tiene sentido
No tiene sentido
Tabla G-20. Atributos de LINK.
target
Tipo de dato
Set<RECORD_COMPONENT>
Obligatorio
SÍ
Equivalencia_X73
No tiene sentido
Tabla G-21. Atributos por asociación de LINK
DATA TYPE: Quedaría la definición de los data type en los ELEMENTS. Dentro
de los data type hemos de identificar que elementos son susceptibles de ser
transmitidos via X73. Identificamos los siguientes tipos:
Valores numéricos, tanto simples (peso, temperatura) como complejos (presión
arterial). Su equivalente es el tipo NUMERIC. A partir de esta clase se pueden
decir que conceptos se están transmitiendo.
Formas de onda (Pulsioximetria). Su equivalente sería la clase RS-TA, pues está
pensada para la transmisión de formas de onda de manera continua.
Dentro de estos valores, básicamente podemos clasificar todos los valores obtenidos
como PQ o cantidades físicas. Atributos del que constan este tipo de datos es:
Value

De Compound Basic/Nu observed value,
dependiendo si se transimite más de un valor o solo uno dentro de la clase.
Las unidades

De Unit-Code de la clase METRIC.
Propiedad (No es obligatorio)  La propiedad va asociada a las unidades.
Precisión (No es obligatorio)  Acuraccy de la clase NUMERIC.
176
Anexo H: Archetype Description Language y arquetipos
Anexo H . Archetype Description Language y
arquetipos.
Archetype Description Language
La representación de un arquetipo queda establecida a través de un lenguaje
propio denominado Archetype Description Language (ADL), que actualmente se
encuentra en su versión 1.4 . ADL se basa en la definición de otros tres lenguajes
para establecer las citadas restricciones al modelo de referencia y sigue la
estructura que se detalla en la Fig. H-1, la cual ha sido extraída de (175):
 Constrait form of ADL (cADL), usado para expresar la definición del arquetipo
(definition).
 Data definition form of ADL (dADL), para expresar el contenido de las
secciones language, description, ontology, and revision_history.
 First-Order Predicate Logic (FOPL), para definir el contenido de las secciones
declarations e invariant.
Aunque muchas de las secciones son opcionales, eso no ocurre con la sección
ontology que permite establecer correspondencias con diferentes terminologías
médicas como SNOMED-CT.
En futuras versiones de ADL, la sintaxis del lenguaje cambiará de tal forma que
un arquetipo obedezca de una forma más cercana a la estructura de un documento
dADL, consiguiendo que la estructura del arquetipo represente más
fidedignamente la definición de clases del modelo de objetos de arquetipos
(Archetype Object Model, AOM), o comúnmente denominado modelo de arquetipos
del cual puede verse una versión simplificada en la figura Fig. D-5
Fig. H-1. Esquema de un arquetipo.
177
Anexos:
Un documento del tipo dADL es aquel que sólo contiene objetos de un mismo
modelo de información. No existen palabras reservadas, todos los identificadores se
asumen que provienen del modelo.
Utilizando sintaxis dADL cualquier bloque puede expresarse como un objeto
serializado. Sin embargo, en determinadas ocasiones, es necesario expresar algún
bloque mediante una sisntaxis abstracta denominada plug-in syntax que facilita el
parseo del diseño y el reconocimiento del bloque.
Aunque ya se ha comentado que no existen palabras reservadas en este tipo de
lenguaje, sí existen una serie de caracteres reservados:







< 
abreun bloque.
> 
cierra un bloque
= 
indica que un atributo es igual a un bloque .
(,) 
es el delimitador de tipos o de bloques expresados en sintaxis plug-in.
<# 
abreun bloque expresado en sintaxis plug-in.
#> 
cierra un bloque expresado en sintaxis plug-in.
Dentro de los delimitadores <>:
o “ ” delimitan strings.
o ‘ ’ delimitan las caracteres.
o | delimita intervalos.
o [ ] delimitan términos codificados.
 Los caracteres – se utilizan para indicar comienzo de comentario.
 Los nombres de los tipos comienzan con letra mayúscula, mientras que los
nombres de los atributos comienzan con letra minúscula.
 El uso de ; es completamente opcional.
Como característica básica, todos los datos que contienen un documento dADL
están dispuestos de forma jerarquica y se pueden identificar unívocamente. De este
modo, cada uno de los nodos puede ser identificado mediante un path que recorra
todos los nodos desde el nodo raíz a la ubicación actual.
En cuanto a los tipos de datos que contiene, un documento dADL es capaz de
devolver varios tipos primitivos (string, integer, reales, double, carácter), instancias
de fecha y hora en varios formatos ISO 8601 (fechas completas o incompletas: una
fecha sin indicar día, una hora sin indicar segundos, etc- ), listas o intérvalos de
todos los citados tipos y algunos tipos de datos especiales (términos codificados,
identificadores URI (Uniform Resource Identifier)).
El uso de la sintaxis cADL permite establecer restricciones en cualquier
objeto definido for un modelo de información orientado a objetos. Su función
primordial es la defición de estructuras válidas a partir de modelos de
objetos demasiado generales. Dicha estructura se obtine mediante la
sucesión anidada de restricciones a los diferentes tipos que contienen
restricciones a los atributos de dichos tipos, expresadas como restricciones a
los tipos de dichos atributos. Por ejemplo un tipo “persona” se puede
restringir restringiendo alguno de sus atributos, por ejemplo su nombre. La
manera de restringir ese nombre es restringirdo el tipo de dato que es
nombre, por ejemplo el nombre es un texto que no puede contener números.
178
En cADL, se pueden identificar un conjunto de palabras reservadas, entre las
que se pueden encontrar:






matches, ~matches, is_in, ~is_in
occurrences, existence, cardinality
ordered, unordered, unique
infinity
use_node, allow_archetype
include, exclude
Este vocabulario clave puede reemplaarse puede ser reemplazado por sus
equivalentes matemáticos. De este modo se puede sustituir matches o is_in por ∈, o
sustituir un modificador como not por ~.
El lenguaje que se utiliza en las secciones invariant y definition se denominan
afirmaciones (assertions) y es un subconjunto de FOPL. En este caso también
existen palabras reservadas:
 exists, for_all,
 and, or, xor, not, implies
 true, false
Estas palabras, como ocurría anteriormente, pueden sustituirse por sus
equivalentes matemáticos. Así, en la Tabla H-1 se puede encontrar una tabla
resumen de todas las principales palabras clave (reservadas), el símbolo
matemático al que equivalen y su significado.
Entre esas palabras clave se encuentran algunas que no pueden sustituirse por
su equivalente matemático, principalmente:
 existence, que determina si un determinado atributo es obligatorio o no.
 cardinality, que indica que ese atributo en concreto es un contenedor y contiene
una serie de entidades. Junto a esta palabra clave aparecerá el rango de
entidades que pueden contener.
 ocurrences, indica cuantas instancias de un nodo pueden aparecer.
Símbolo
Significado
matches, is_in
∈
pertenencia
exists
∃
existencia
for_all
∀ Para todo
implies
⊃, →
Texto
Implicación material
and
∧
Y lógico
or
∨ o
xor
∨
O exclusiva
not, ~
∼, ¬
Negación
Tabla H-1. Equivalente matemático de palabras reservadas.
A continuación se recogen los arquetipos diseñados en función de estas premisas.
179
Anexos:
Arquetipos
En los siguientes subapartados se adjuntan los aquetipos diseñados en la
realización de esta TFM:
Peso
archetype (adl_version=1.4)
CEN-EN13606-ENTRY.TelemedicineWeight.v1
concept
[at0000]
language
original_language = <[ISO_639-1::es]>
translations = <
["en-gb"] = <
language = <[ISO_639-1::en-gb]>
author = <
["name"] = <"Pilar Muñoz">
>
other_details = <
>
>
>
description
original_author = <
["date"] = <"20100131">
["organisation"] = <"Universidad de Zaragoza">
>
lifecycle_state = <"Draft">
details = <
["en-gb"] = <
purpose = <"Telemedicine Weight">
use = <"Weight obtained in away from any HealthCare Centre">
>
["es"] = <
language = <[ISO_639-1::es]>
purpose = <"Peso obtenido en telemedicina">
use = <"Peso obtenido de manera telematica al centro sanitario">
>
>
definition
ENTRY[at0000] occurrences matches {1..1} matches { -- Peso en telemedicina
items existence matches {0..1} cardinality matches {0..*; unordered} matches {
ELEMENT[at0001] occurrences matches {1..1} matches { -- Peso
value existence matches {0..1} matches {
PQ[at0002] occurrences matches {1..1} matches { -- Valor del peso
units matches {
CS[at0004] occurrences matches {0..1} matches { -codeValue existence matches {0..1} matches {"kg"}
codingSchemeName existence matches {0..1} matches {"UCUM"}
}
}
value matches {|>0.0..<500.0|}
}
}
name matches {
SIMPLE_TEXT[at0005] occurrences matches {0..1} matches { -- Nombre de la medida
180
}
originalText matches {"Peso"}
}
meaning matches {
CV[at0006] occurrences matches {0..1} matches { -- código de la medida
codeValue matches {"272102008"}
codingScheme matches {
OID[at0007] occurrences matches {1..1} matches { -- Id. terminologia
oid matches {"2.16.840.1.113883.6.96"}
}
}
codingSchemeName matches {"SNOMED-CT"}
}
}
obs_time matches {
IVLTS[at0008] occurrences matches {0..1} matches { -- Instante de toma de la medida
high matches {
TS[at0009] occurrences matches {1..1} matches { -- Toma de la medida
time matches {*}
}
}
width existence matches {0..1} matches {*}
}
}
}
}
}
name matches {
SIMPLE_TEXT[at0003] occurrences matches {0..1} matches { -- Significado
originalText matches {"peso"}
}
}
archetype_id matches {"CEN-EN13606-ENTRY.TelemedicineWeight.v1"}
ontology
terminologies_available = <"SNOMED-CT06", ...>
term_definitions = <
["es"] = <
items = <
["at0000"] = <
text = <"Peso en telemedicina">
description = <"peso corporal">
>
["at0001"] = <
text = <"Peso">
description = <"Valor del peso">
>
["at0002"] = <
text = <"Valor del peso">
description = <"Valor del peso">
>
["at0009"] = <
text = <"Toma de la medida">
description = <"Toma de la medida">
>
>
>
["en-gb"] = <
items = <
["at0000"] = <
text = <"Telemedicine Weight">
description = <"Body Weight">
>
181
Anexos:
>
["at0001"] = <
text = <"Weight">
description = <"Weight value">
>
["at0002"] = <
text = <"Weight Value">
description = <"Weight Value">
>
>
["at0009"] = <
text = <"Measurement time">
description = <"Measurement time">
>
>
>
constraint_definitions = <
["en-gb"] = <
items = <
>
>
>
term_binding = <
["SNOMED-CT06"] = <
items = <
["at0000"] = <[SNOMED-CT06::272102008]>
>
>
>
constraint_binding = <
>
Pulso
CEN-EN13606-ENTRY.TelemedicineHeartRate.v1
concept
[at0000]
language
translations = <
["en-gb"] = <
author = <
>
other_details = <
>
>
>
description
original_author = <
["date"] = <"20100131">
>
182
details = <
["en-gb"] = <
purpose = <"Telemedicine Heart Rate">
use = <"Hear rate obtained in away from any HealthCare
Centre">
>
["es"] = <
purpose = <"Pulso obtenido en telemedicina">
use = <"Pulso obtenido de manera telematica al centro
sanitario">
>
>
definition
ENTRY[at0000] occurrences matches {1..1} matches { -- Pulso en
telemedicina
items existence matches {0..1} cardinality matches {0..*;
unordered} matches {
ELEMENT[at0001] occurrences matches {1..1} matches { -Pulso
PQ[at0002] occurrences matches {1..1} matches { - Valor del pulso
units matches {
CS[at0004] occurrences matches {0..1}
matches { -codeValue existence matches {0..1}
matches {"BPM"}
codingSchemeName existence matches
{0..1} matches {"UCUM"}
}
}
value matches {|0.0..<200.0|}
}
}
name matches {
SIMPLE_TEXT[at0005] occurrences matches {0..1}
matches { -- Nombre de la medida
originalText matches {"Pulso cardiaco"}
}
}
meaning matches {
CV[at0006] occurrences matches {0..1} matches { - código de la medida
OID[at0007] occurrences matches {1..1}
matches { -- Id. terminologia
oid matches {"2.16.840.1.113883.6.96"}
}
}
}
}
obs_time matches {
IVLTS[at0008] occurrences matches {0..1} matches {
-- Instante de toma de la medida
183
Anexos:
matches {
high matches {
TS[at0009] occurrences matches {1..1}
-- Toma de la medida
time matches {*}
}
}
}
}
}
}
name matches {
SIMPLE_TEXT[at0003] occurrences matches {0..1} matches {
-- Significado
originalText matches {"Pulso"}
}
}
archetype_id matches {"CEN-EN13606ENTRY.TelemedicineHeartRate.v1"}
}
ontology
["es"] = <
items = <
["at0000"] = <
text = <"Pulso en telemedicina">
description = <"Frecuencia cardiaca.">
>
["at0001"] = <
text = <"Pulso">
description = <"Valor del pulso">
>
["at0002"] = <
text = <"Valor del pulso">
description = <"Valor del pulso">
>
>
["at0009"] = <
>
>
>
["en-gb"] = <
items = <
["at0000"] = <
text = <"Telemedicine Weight">
description = <"Body Weight">
>
["at0001"] = <
text = <"heart rate">
description = <"heart rate value">
>
["at0002"] = <
text = <"Heart rate value">
description = <"Heart rate value">
>
["at0009"] = <
184
>
>
>
>
["en-gb"] = <
items = <
>
>
>
term_binding = <
["SNOMED-CT06"] = <
items = <
["at0000"] = <[SNOMED-CT06::250764009]>
>
>
>
>
Tensión arterial
CEN-EN13606-ENTRY.TelemedicineBloodPreassure.v1
concept
[at0000]
language
translations = <
["en-gb"] = <
author = <
>
other_details = <
>
>
>
description
original_author = <
["date"] = <"20100131">
["email"] = <"[email protected]">
>
details = <
["en-gb"] = <
>
["es"] = <
185
Anexos:
purpose = <"Para ser usado en Telemedicina">
use = <"Para datos adquiridos de forma remota al centro
sanitario">
>
>
definition
ENTRY[at0000] occurrences matches {1..1} matches { -TelemedicineBloodPreassure
items cardinality matches {1..1; unordered} matches {
CLUSTER[at0001] occurrences matches {1..1} matches { -Tensión arterial
parts existence matches {0..1} cardinality matches
{2..2; unordered; unique} matches {
ELEMENT[at0003] occurrences matches {1..1} matches
{ -- Tensión Sistólica
PQ[at0008] occurrences matches {1..1}
matches { -- Sistólica
units matches {
CS[at0004] occurrences matches
{0..1} matches { -codeValue existence matches
{0..1} matches {"mm[Hg]"}
codingSchemeName existence
matches {0..1} matches {"UCUM"}
}
}
value matches {|>60.0..<200.0|}
}
}
meaning existence matches {0..1} matches {
CV[at0014] occurrences matches {0..1}
matches {"163030003"}
codingScheme existence matches {0..1}
matches {
OID[at0021] occurrences matches
{0..1} matches { -oid existence matches {0..1}
matches {"2.16.840.1.113883.6.96"}
}
}
}
}
name matches {
SIMPLE_TEXT[at0019] occurrences matches
{0..1} matches { -originalText existence matches {0..1}
matches {"Tensión sistólica"}
}
}
}
ELEMENT[at0006] occurrences matches {1..1} matches
{ -- Tensión Diastolica
matches { -- Diastólica
units matches {
186
{0..1} matches {
-codeValue existence matches
{0..1} matches {"mm[Hg]"}
}
}
value matches {|>50.0..<100.0|}
}
}
matches {
-codeValue existence matches {0..1}
matches {"163031004"}
matches {
{0..1} matches {
-oid existence matches {0..1}
matches {"2.16.840.1.113883.6.96"}
}
}
{0..1} matches {"SNOMED -CT"}
}
}
name matches {
{0..1} matches {*} -- Tensión diastólica
}
}
}
structure_type matches {
CS[at0020] occurrences matches {0..1} matches { codeValue existence matches {0..1} matches
{"STRC01"}
codingSchemeName existence matches {0..1}
matches {"CEN/TC251/EN13606-3:STRUCTURE_TYPE"}
}
}
obs_time existence matches {0..1} matches {
-- Fecha/hora
high existence matches {0..1} matches {
matches {*} -}
}
}
name matches {
matches { -originalText existence matches {0..1} matches
{"Tensión arterial"}
}
}
meaning matches {
187
Anexos:
CV[at0016] occurrences matches {1..1} matches {
-
codeValue existence matches {0..1} matches
{"75367002"}
codingScheme existence matches {0..1} matches
{
matches {
-oid existence matches {0..1} matches
{"2.16.840.1.112883.6.96"}
}
}
matches {"SNOMED-CT"}
}
}
}
}
archetype_id existence matches {0..1} matches {"CEN-EN13606ENTRY.TelemedicineBloodPreassure.v1"}
name matches {
-originalText existence matches {0..1} matches
}
}
}
ontology
["es"] = <
items = <
["at0000"] = <
text = <"TelemedicineBloodPreassure">
description = <"TelemedicineBloodPreassure">
>
["at0001"] = <
text = <"Tensión arterial">
description = <"Medida de la tensión">
>
["at0003"] = <
text = <"Tensión Sistólica">
description = <"Medida de la sistólica">
>
["at0006"] = <
text = <"Tensión Diastolica">
description = <"Medida de la Diastólica">
>
["at0007"] = <
text = <"Fecha/hora">
description = <"Instante de la medida">
>
["at0008"] = <
text = <"Sistólica">
description = <"Medida de la sistólica">
>
188
["at0011"] = <
text = <"Diastólica ">
description = <"Medida de la diastólica">
>
["at0013"] = <
text = <"Tensión diastólica">
description = <"Tensión diástolica">
>
>
>
["en-gb"] = <
items = <
["at0000"] = <
description = <"*TelemedicineBloodPreassure">
>
["at0001"] = <
text = <"Blood Preassure">
description = <"Preassure Measurement">
>
["at0003"] = <
text = <"Systolic Preassure">
description = <"*Medida de la sistólica">
>
["at0006"] = <
text = <"*Tensión Diastolica">
description = <"*Medida de la Diastólica">
>
["at0007"] = <
text = <"Date/time">
description = <"Measurement Time Stamp">
>
["at0008"] = <
text = <"*Sistólica">
description = <"*Medida de la sistólica">
>
["at0011"] = <
text = <"*Diastólica ">
description = <"*Medida de la diastólica">
>
["at0013"] = <
text = <"*Tensión diastólica">
description = <"*Tensión diástolica">
>
>
>
>
["en-gb"] = <
items = <
>
>
>
term_binding = <
["SNOMED-CT06"] = <
items = <
189
Anexos:
["at0000"] = <[SNOMED-CT06::75367002],[SNOMEDCT06::75367002],[SNOMED-CT06::75367002],[SNOMED-CT06::75367002]>
>
>
>
>
Glucomería
CEN-EN13606-ENTRY.TelemedicineWeight.v1
concept
[at0000]
language
translations = <
["en-gb"] = <
author = <
>
other_details = <
>
>
>
description
original_author = <
["date"] = <"20100131">
>
details = <
["en-gb"] = <
purpose = <"Telemedicine Blood Sugar">
use = <"Blood sugar obtained in away from any HealthCare
Centre">
>
["es"] = <
purpose = <"Glucometria en telemedicina">
use = <"Glucometria obtenida de manera telematica al
centro sanitario">
>
>
definition
ENTRY[at0000] occurrences matches {1..1} matches { -- Glucometria
en telemedicina
190
ELEMENT[at0001] occurrences matches {1..1} matches {
--
Glucometria
PQ[at0002] occurrences matches {1..1} matches {
-
units matches {
matches {
matches {"mg/dL"}
}
}
}
}
name matches {
matches {
-originalText matches {"Glucometria"}
}
}
meaning matches {
CV[at0006] occurrences matches {0..1} matches {
-
matches {
-oid matches {"2.16.840.1.113883.6.96"}
}
}
}
}
obs_time matches {
--
matches {
high matches {
time matches {*}
}
}
}
}
}
}
name matches {
}
}
archetype_id matches {"CEN-EN13606ENTRY.TelemedicineBloodSugar.v1"}
}
191
Anexos:
ontology
["es"] = <
items = <
["at0000"] = <
text = <"Glucometria en telemedicina">
description = <"Glucometria">
>
["at0001"] = <
text = <"Glucometria">
description = <"Glucometria">
>
["at0009"] = <
>
["at0002"] = <
text = <"">
description = <"">
>
>
>
["en-gb"] = <
items = <
["at0000"] = <
text = <"Telemedicine Blood Sugar">
description = <"Blood Sugar">
>
["at0001"] = <
text = <"Blood Sugar">
description = <"Blood sugar value">
>
["at0009"] = <
>
>
>
>
["en-gb"] = <
items = <
>
>
>
term_binding = <
["SNOMED-CT06"] = <
items = <
["at0000"] = <[SNOMED-CT06::170756003]>
>
>
>
> 192
Oximetria
CEN-EN13606-ENTRY.TelemedicineOximetry.v1
concept
[at0000]
language
translations = <
["en-gb"] = <
author = <
>
other_details = <
>
>
>
description
original_author = <
["date"] = <"20100131">
["email"] = <"[email protected]">
>
details = <
["en-gb"] = <
>
["es"] = <
purpose = <"Para ser usado en Telemedicina">
use = <"Para datos adquiridos de forma remota al centro
sanitario">
>
>
definition
ENTRY[at0000] occurrences matches {1..1} matches { -TelemedicineOximetry
CLUSTER[at0001] occurrences matches {1..1} matches { -Oximetry
parts existence matches {0..1} cardinality matches
{1..1; unordered; unique} matches {
ELEMENT[at0006] occurrences matches {1..*} matches
{ -- Valor de Oximetria
matches { -- Oximetria
units matches {
{0..1} matches { -codeValue existence matches
{0..1} matches {"%{Oxygen}"}
193
Anexos:
}
}
}
}
matches {
matches {"104847001"}
matches {
{0..1} matches {
-oid existence matches {0..1}
matches {"2.16.840.1.113883.6.96"}
}
}
{0..1} matches {"SNOMED -CT"}
}
}
name matches {
{0..1} matches {*} -- Oximetria
}
}
}
structure_type matches {
CS[at0015] occurrences matches {0..1} matches { codeValue existence matches {0..1} matches
{"STRC01"}
matches {"CEN/TC251/EN13606-3:STRUCTURE_TYPE"}
}
}
obs_time existence matches {0..1} matches {
-- Fecha/hora
high existence matches {0..1} matches {
matches {*} -}
}
}
name matches {
matches { -originalText existence matches {0..1} matches
}
}
meaning matches {
CV[at0016] occurrences matches {1..1} matches { codeValue existence matches {0..1} matches
{"104847001"}
codingScheme existence matches {0..1} matches
{
194
matches {
-oid existence matches {0..1} matches
{"2.16.840.1.112883.6.96"}
}
}
matches {"SNOMED-CT"}
}
}
}
}
archetype_id existence matches {0..1} matches {"CEN-EN13606ENTRY.TelemedicineOximetry.v1"}
name matches {
-originalText existence matches {0..1} matches
{"Oximetria"}
}
}
}
ontology
["es"] = <
items = <
["at0000"] = <
text = <"TelemedicineOximetry">
description = <"TelemedicineOximetry">
>
["at0001"] = <
text = <"Oximetry">
description = <"Oximetry">
>
["at0006"] = <
text = <"Valor de Oximetria">
description = <"Valor de Oximetria">
>
["at0007"] = <
text = <"Fecha/hora">
description = <"Instante de la medida">
>
["at0011"] = <
text = <"Oximetria">
description = <"Medida de oximetria">
>
["at0013"] = <
text = <"Oximetria">
description = <"Oximetria">
>
>
>
["en-gb"] = <
items = <
["at0000"] = <
description = <"*TelemedicineBloodPreassure">
195
Anexos:
>
["at0001"] = <
text = <"Oximetry">
>
["at0006"] = <
text = <"Oximetry">
>
["at0007"] = <
text = <"Date/time">
description = <"Measurement Time Stamp">
>
["at0011"] = <
text = <"Oximetry value">
description = <"Oximetry value">
>
["at0013"] = <
text = <"Oximetry value">
description = <"Oximetry value">
>
>
>
>
["en-gb"] = <
items = <
>
>
>
term_binding = <
["SNOMED-CT06"] = <
items = <
["at0000"] = <[SNOMED-CT06::75367002],[SNOMEDCT06::75367002],[SNOMED-CT06::75367002],[SNOMED-CT06::75367002]>
>
>
>
>
Temperatura
CEN-EN13606-ENTRY.TelemedicineTemperature.v1
concept
[at0000]
language
translations = <
["en-gb"] = <
author = <
>
other_details = <
>
196
>
>
description
original_author = <
["date"] = <"20100131">
>
details = <
["en-gb"] = <
purpose = <"Telemedicine Temperature">
use = <"Temperature obtained in away from any HealthCare
Centre">
>
["es"] = <
purpose = <"Temperature en telemedicina">
use = <"Temperature obtenida de manera telematica al
centro sanitario">
>
>
definition
ENTRY[at0000] occurrences matches {1..1} matches { -- Temperatura
corporal en telemedicina
ELEMENT[at0001] occurrences matches {1..1} matches { -Temperatura corporal
PQ[at0002] occurrences matches {1..1} matches { units matches {
matches {"ºC"}
}
}
}
}
name matches {
matches { -originalText matches {"Temperatura corporal"}
}
}
meaning matches {
CV[at0006] occurrences matches {0..1} matches { codeValue matches {"246508008"}
matches { -oid matches {"2.16.840.1.113883.6.96"}
197
Anexos:
}
}
}
}
obs_time matches {
--
matches {
high matches {
time matches {*}
}
}
}
}
}
}
name matches {
-originalText matches {"Temperatura corporal"}
}
}
archetype_id matches {"CEN-EN13606ENTRY.TelemedicineTemperature.v1"}
}
ontology
["es"] = <
items = <
["at0000"] = <
text = <"Temperatura corporal en telemedicina">
description = <"Temperatura corporal">
>
["at0001"] = <
text = <"Temperatura corporal">
description = <"Temperatura corporal">
>
["at0009"] = <
>
["at0005"] = <
text = <"">
description = <"">
>
>
>
["en-gb"] = <
items = <
["at0000"] = <
text = <"Telemedicine Temperature">
description = <"Temperature">
>
["at0001"] = <
text = <"Temperature">
198
description = <"Temperature value">
>
["at0009"] = <
>
>
>
>
["en-gb"] = <
items = <
>
>
>
term_binding = <
["SNOMED-CT06"] = <
items = <
["at0000"] = <[SNOMED-CT06::246508008]>
>
>
>
> ECG
CEN-EN13606-ENTRY.TelemedicineEKG.v1
concept
[at0000]
language
translations = <
["en-gb"] = <
author = <
>
other_details = <
>
>
>
description
original_author = <
["date"] = <"20100131">
>
details = <
["en-gb"] = <
purpose = <"Telemedicine EKG">
use = <"EKG obtained in away from any HealthCare Centre">
>
["es"] = <
199
Anexos:
purpose = <"ECG en telemedicina">
use = <"ECG obtenida de manera telematica al centro
sanitario">
>
>
definition
ENTRY[at0000] occurrences matches {1..1} matches { -- ECG en
telemedicina
ELEMENT[at0001] occurrences matches {1..1} matches { -ECG
ED[at0010] occurrences matches {1..1} matches { data existence matches {0..1} matches {*}
}
}
name matches {
matches { -originalText matches {"Glucometria"}
}
}
meaning matches {
CV[at0006] occurrences matches {0..1} matches { codeValue matches {"46825001"}
matches { -oid matches {"2.16.840.1.113883.6.96"}
}
}
}
}
obs_time matches {
-high matches {
matches { -- Toma de la medida
time matches {*}
}
}
}
}
}
}
name matches {
}
}
archetype_id matches {"CEN-EN13606-ENTRY.TelemedicineEKG.v1"}
200
}
ontology
["es"] = <
items = <
["at0000"] = <
text = <"ECG en telemedicina">
description = <"ECG">
>
["at0001"] = <
text = <"ECG">
description = <"ECG">
>
["at0009"] = <
>
["at0010"] = <
text = <"">
description = <"">
>
>
>
["en-gb"] = <
items = <
["at0000"] = <
text = <"Telemedicine EKG">
description = <"EKG">
>
["at0001"] = <
text = <"EKG">
description = <"EKG">
>
["at0009"] = <
>
>
>
>
["en-gb"] = <
items = <
>
>
>
term_binding = <
["SNOMED-CT06"] = <
items = <
["at0000"] = <[SNOMED-CT06::46825001]>
>
>
>
>
201
Anexos:
202
Anexo I: Diseño del cliente. Pruebas.
Anexo I . Diseño del cliente. Pruebas.
Para atestiguar el correcto funcionamiento de la aplicación diseñada se ha
implementado una aplicación cliente que invocará y consumirá la información
suministrada por el WS y que realizará funciones tanto de “tester” como “demo”:
Para acceder a la aplicación cliente se han establecido unas mínimas medidas de
seguridad, como son el acceso mediante usuario y contraseña tal y como se muestra
en la Fig. I-1. Una vez correctamente logeados nos encontraremos antes una
pantalla de bienvenida como se muestra en la Fig. I-2.
Fig. I-1. Pantalla de Log-in cliente.
Menú
Fig. I-2. Pantalla de bienvenida del cliente.
203
Anexos:
La interfaz ha sido diseñada bajo el paradigma de máxima sencillez y
usabilidad, por ello siempre se encuentra disponible el menú de acceso a cada una
de las secciones de la página en la parte izquierda de la pantalla. Las secciones que
comprenden la aplicación web son: pantalla de bienvenida (Fig. I-2), pantalla de
petición de extractos, pantalla de petición de arquetipos y documentación.
La pantalla de petición de extractos, se accede haciendo click sobre el botón EHR
Request del menú. En dicha pantalla encontramos todos los posibles parámetros
que es posible especificar según la parte 5 de la norma EN13606. Dado que muchos
parámetros son opcionales se ha optado por usar un inferfaces secundarías
desplegables que se activarán sólo cuando se quiera especificar uno de esos
parámetros. Dichas sub-interfaces, están adaptadas al tipo de dato que se necesita
especificar: no es lo mismo el parámetro all_versions que es un Boolean que el
max_sensitivity que es un integer (ver Fig. I-3). Además en aquellos campos donde
es posible especificar más de un parámetro del mismo tipo se han diseñado tablas
auxiliares de almacenamiento. Como regla general sólo auqellos valores contenidos
en las tablas serán validos a la hora de realizar la petición, sin embargo las tablas
permiten editar y eliminar cualquier componente contenido en esas tablas (ver Fig.
I-4).
Fig. I-3. Sub-Interfaces adaptadas al tipo de dato.
Fig. I-4. SubInterfaces que admiten parámetros multiples.
204
En cualquier caso se han habilitado ayudas adicionales al realizar la petición,
mediante pequeños mensajes que indican el comportamiento por defecto ante el uso
de estas sub-Interfaces, como se ve en la Fig. I-5.
Además, se han programado diferentes tipos de validadores: unos obligan a
introducir un determinado parámetro (ver Fig. I-6), otros solicitan que el
parámetro introducido se ajuste a un determinado patrón (ver Fig. I-7), etc. De
este modo aseguramos que la petición se realiza de una manera lo más correcta
posible.
Fig. I-5.Mensajes de ayuda en la interfaz
Fig. I-6. Introducción de campos obligatoria.
Fig. I-7. Validador de patrón de entrada
205
Anexos:
Una vez que se realiza la petición, se recibe el extracto correctamente generado
conforme a la norma. En este punto, la aplicación cliente es la encargada de
realizar aquellas acciones que consideren oportunas con la información recibida. En
nuestro caso, se ha decidido mostrar la información por pantalla en forma de XML
(ver Fig. I-8, Fig. I-9).
Para facilitar tanto la visualización como el análisis de los datos, se implemento
una pequeña rutina de decodificación que extrae la información de corte más
médico y la presenta en forma de tabla (ver Fig. I-8, Fig. I-9).
Se puede encontrar una demo explicativa en la siguiente url:
http://www.youtube.com/watch?v=tMjUrEPN-JA
Fig. I-8. Extracto recivido.
206
Fig. I-9. Ejemplo de entrada.
Fig. I-10. Rutina de decodificación
La pantalla de petición de arquetipos, se ha diseñado siguiendo una metodología
similar a la anterior y se accede mediante el botón Archetypes. Al implementar esta
interfaz aparece la paradoja de que todos los posibles parámetros son opcionales y,
por lo tanto, no existe ningún campo que deba preocuparnos especialmente en que
deba ser especificado. También surgió como cuestión que hacer con los arquetipos
una vez que estos sean adquiridos. Las decisiones de diseño que se tomaron fueron
las siguientes:
 Todos los parámetros de la interfaz aparecen dentro de subinterfaces que se
desplegarán a voluntad del usuario. (Ver Fig. I-11, Fig. I-12).
 Habilitaremos un campo adicional, que un path en nuestro equipo en el que se
almacenarán los arquetipos recibidos. (Ver Fig. I-11)
 Solo será posible realizar una petición de arquetipos, si existe un path y hay al
menos un parámetro introducido correctamente. (Ver Fig. I-13)
207
Anexos:
Campo adicional
Fig. I-11. Pantalla de petición de arquetipos.
Fig. I-12. Depliegue de parámetros
Fig. I-13. Restricciones en la petición
208
Llegados a este punto, simplemente hacer un pequeño inciso en la diferencia
existente entre la Fig. I-11 y Fig. I-13. En la primera, se ha ocultado el botón de
petición puesto que no se sabe si el usuario tiene intención real de realizar petición
alguna. Es en momento en el que se despliega cualquier sub-Interfaz, en el que se
entiende que sí hay una intención real y, por lo tanto, se habilita el botón de
petición y los validadores pertinentes. De este modo, añadimos dinamismo a la
página y nos aseguramos que se evitan ciertos errores.
Como en el caso anterior, también se puede consultar una demo en la url:
http://www.youtube.com/watch?v=hlzmRGzvCIo
Para terminar la descripción de la interfaz, queda hablar de la sección de
documentación, lugar creado como punto de información del lado servidor. Así, en
la Fig. I-14 se muestra como es posible la descarga de un manual en el que se
detalla la manera de interrogar al WS, instrucciones de cómo replicar el servidor,
etc.
Fig. I-14. Descarga de información.
209
Anexos:
210
Anexo J: Nuevos dispositivos médicos de uso domiciliario.
. Anexo J . Nuevos dispositivos médicos de
uso domiciliario
La revolución tecnológica que venimos sufriendo durante los últimos años nos ha
facilitado la vida de muchas maneras. Los dispositivos que somos capaces de
adquirir son cada vez más sofisticados, poseen más funcionalidades y son cada vez
más asequibles en una relación calidad precio. En el ambiente médico no estamos ante una excepción: cada vez somos capaces
de disponer de una mayor cantidad de dispositivos de una mayor variedad de
fabricantes. Y ante esa cantidad de competencia los productos necesitan
diferenciarse de la competencia incorporando nuevas funcionalidades: la función
primaria de una báscula consiste en registrar el peso de una persona, pero las
básculas actuales son capaces de medir cosas como la composición corporal, el
índice de masa corporal, el índice basal, etc. Pero esas mejoras en las prestaciones no se reducen simplemente a un
incremento en las funcionalidades que poseen, sino que cada vez son más precisas,
son más económicas, poseen memoria e incluso algún tipo de capacidad de
conectividad. En las próximas páginas (ver Tabla J-1) se realizará una recopilación de
dispositivos, las capacidades que poseen y la conectividad presentan. (148; 149;
150; 151; 152; 153; 154; 155) Pulsioxímetro Producto Marca Modelo Diemer PC‐60 Diemer D810 Diemer D820 Diemer Oximax N65 Diemer MP110 Diemer NANOX 2 Diemer NANOX C Diemer POX10 Medida Cifra
Unidad Rango Spo2 2 % 70‐99 Pulso 3 LPM 30‐240 Spo2 3 % 0‐99 Pulso 3 LPM 30‐235 Spo2 2 % 0‐99 Pulso 3 LPM 30‐254 Spo2 2 % 0‐100 Pulso 3 LPM 20‐250 Spo2 2 % 40‐100 Pulso 3 LPM 20‐250 Spo2 2 % 30‐99 Pulso 3 LPM 30‐250 Spo2 2 % 30‐99 Pulso 3 LPM 30‐250 Spo2 2 % 50‐99 Pulso 3 LPM 30‐250 Conexión RS232 Cable Cable Cable 211
Glucómetros Anexos:
Spo2 2 % 50‐99 Pulso 3 LPM 30‐250 Spo2 2 % 30‐100 Pulso 3 LPM 30‐250 Spo2 3 % 1‐100 Pulso 3 LPM 20‐250 Spo2 3 % 1‐100 Pulso 3 LPM 20‐250 Spo2 2 % 0‐99 Pulso 3 LPM 30‐254 Spo2 2 % 0‐99 Pulso 3 LPM 30‐254 Spo2 3 % 0‐100 Pulso 3 LPM 30‐254 Spo2 2 % 0‐99 Pulso 3 LPM 30‐254 Spo2 3 % 0‐100 Pulso 3 LPM 30‐255 Spo2 3 % 0‐100 Pulso 3 LPM 40‐235 Aviva Glucosa 3 mg/dL 10‐600 IRDa Accu‐Chek Compact Glucosa 3 mg/dL 10‐600 IRDa Accu‐Chek sensor Glucosa 3 mg/dL 10‐600 mmol/L 0,6‐33,3 Glucosa 3 mg/dL 10‐600 mmol/L 0,6‐33,3 ECG Presión Sanguínea ECG 3 mmHg 0‐300 USB,WIFI y SD card Pulso 3 LPM 20‐300 RS232 Spo2 3 % 40‐100 Pulso 3 LPM 20‐300 Spo2 3 % 40‐100 Diemer POX10L Diemer CAPNOX Diemer Oximax N560 Diemer Oximax N600 Diemer Rotarion Diemer Pediatric Diemer H 100B Diemer Nanox eco Ohmeda 3900 Ohmeda 3775 Accu‐Chek Báscula Electrocardiógrafo Accu‐Chek compact‐plus Biox CB‐2300‐A Diemer MP800 Cable IRDa Cable Cable DB9 IRDa Serial Cable IRDa ECG Diemer MP1000NT RS232 RS232 y WIFI IRDa Diemer ELAN 1100 Cardioline AR600 ECG Cardioline AR2100 ECG IRDa OMRON Quirumed
Quirumed
Quirumed
Quirumed
HCG801 seca 862 seca 888 seca 884 seca 700 ECG Peso
Peso
Peso
Peso
SD card RS232
212
2
2
2
2
kg
kg
Kg
Kg
0‐200 0‐160 0‐160 0‐200 Anexo J: Nuevos dispositivos médicos de uso domiciliario.
Quirumed
seca 882 Peso
Peso OMRON BF400 Porcentaje grasa
2
Kg
Kg 0‐200 RS232
IMC Peso Kg Porcentaje grasa
OMRON BF500 IMC Nivel grasa abdominal Musculo esquelético IMB Tanita Tanita BF 350 420 MA S PW 630 MA % cal Peso Tanita Kg Porcentaje grasa
Cable IMC IMB cal Peso Kg Porcentaje grasa
RS232 IMC IMB cal Peso Kg Porcentaje grasa
Termóm
etros IMC MX onda MX‐TDF2385 Temperatura 2+1 ºC 35‐42 Quirumed Spaincare Temperatura 2+1 ºC 35‐42 OMRON Eco Temp II Temperatura 2+1 ºC 32‐43 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg OMRON Tensiómetros OMRON OMRON OMRON OMRON OMRON 705 CP‐II 705 IT‐BT 705 IT M3‐
Intellisense M1‐Classic R3‐
Intellisense Bluetooth 213
Anexos:
OMRON OMRON OMRON OMRON OMRON OMRON OMRON OMRON OMRON OMRON OMRON OMRON OMRON OMRON 214
M6 R7 R3‐Iplus M2‐Compact RX‐3 RX‐3 Plus MX‐3 Plus M4‐I M7 i‐Q132 i‐Q142 M1‐Plus M1‐Compact i‐C10 Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg Anexo J: Nuevos dispositivos médicos de uso domiciliario.
OMRON OMRON OMRON A&D A&D A&D Microlife Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 0‐299 P.Diastólica 3 mmHg Pulso 3 lpm 40‐180 P.Sistólica 3 mmHg 20‐280 P.Diastólica 3 mmHg Pulso 3 lpm 40‐200 P.Sistólica 3 mmHg 20‐280 UA‐779 P.Diastólica 3 mmHg 3 3
3 lpm mmHg
mmHg 40‐200 20‐280 UA‐787 Pulso P.Sistólica
P.Diastólica Pulso 3 lpm 40‐200 P.Sistólica 3 mmHg 30‐280 P.Diastólica 3 mmHg Pulso 3 lpm 40‐200 L 0‐10 0‐99 M6‐Comfort M10‐IT R6 UA‐767 BP3BTO‐A Capacidad Diemer Diemer Espirómetros Diemer Diemer D 110 D 70 D OC D 120 Spo2 2 % Pulso 3 LPM Capacidad L Capacidad L Spo2 2 D600 Capacidad L 0‐10 Spo2 3 % 80‐100 Pulso 3 LPM 40‐120 Diemer MicroSpiro HI‐701 Capacidad MIR MiniSpir Capacidad MIR SpirobankG Capacidad 3 Spo2 Pulso % 0‐100 LPM Capacidad SpirobankII RS232 RS232 L Pulso MIR 0‐99 LPM Spo2 RS232 Pulso Capacidad Diemer % L L L 0‐10 % LPM RS232 RS232 y USB RS232 y USB L 2 0‐99 RS232 y USB 215
Anexos:
MIR SpiroLabII Capacidad Tabla J-1. Dispositivos médicos.
216
L RS232 y USB Anexo K: Informes definidos por el MSPS.
Anexo K . Informes definidos por el MSPS Entre los informes definidos por el ministerio, figuran los siguientes: Informe de Alta de Hospitalización
Datos del documento:










Tipo del Documento
Cadena de texto = “Informe clínico de Alta”.
Fecha de firma
dd/mm/aaaa
Fecha de Ingreso
dd/mm/aaaa
Fecha de alta
dd/mm/aaaa
Responsable 1
Texto libre (nombre+2 apellidos)
Categoría profesional 1
Texto = Médico Residente || Facultativo
Especialista de Área || Jefe de Sección Jefe de Servicio
Nombre Responsable 2
Texto Libre (nombre+2 apellidos)
Texto Facultativo= Especialista de Área || Jefe
de Sección || Jefe de Servicio
CM Servicio
Texto Según normativa en vigor en cada
momento. Actualmente: RD 1277/2003, de 10 de octubre, por el que se
establecen las bases generales sobre autorización de centros, servicios y
establecimientos sanitarios
Unidad
Texto Libre
Datos de la Institución emisora
 Denominación del Servicio de Salud
Texto + Logo =
SAS.
Servicio Andaluz de Salud.|| SALUD. Servicio Aragonés de Salud || SESPA.
Servicio de Salud del Principado de Asturias. || Servicio Canario de Salud ||
SCS. Servicio Cántabro de Salud. || SESCAM. Servicio de Salud de Castilla-La
Mancha. || SACyL. Gerencia Regional de Salud de Castilla y León. || DdSGC. Departament de Salut de la Generalitat de Catalunya || SES. Servicio
Extremeño de Salud. || SERGAS. Servicio Gallego de Salud. || INGESA.
Instituto Nacional de Gestión Sanitaria. || IB-SALUT. Servicio de Salud de
Illes Balears. || RIOJASALUD. Servicio Riojano de Salud. || Servicio
Madrileño de Salud. || Servicio Murciano de Salud || OSASUNBIDEA.
Servicio Navarro de Salud. || Agència Valenciana de Salut || OSAKIDETZAServicio Vasco de Salud.
 Denominador del Provisor de servicios Texto Libre + Logo
 Denominación del centro
Texto (Catalogo Nacional de Hospitales, y
RECESS cuando esté disponible + Libre) + Logo
 Dirección del Centro
o Tipo de Vía:
esté disponible)
o Nombre de la vía :
esté disponible)
o Número de la vía:
esté disponible)
o Piso:
esté disponible)
o Letra:
esté disponible}
o Código Postal :
esté disponible)
Texto (Catalogo Nacional de Hospitales, y RECESS cuando
217
Anexos:
o Municipio:
esté disponible)
o Provincia :
esté disponible)
o Teléfono:
esté disponible)
o Direccion Web/ Correo electrónico:
Texto Libre (sólo si aporta algo al paciente)
Datos del paciente










Nombre
Texto
Primer Apellido
Texto
Segundo Apellido
Texto
Fecha nacimiento
dd/mm/aaaa
Sexo
Texto = H/M
DNI/T.Residencia/Pasaporte
Texto
NASS
Texto
CIP de C Autónoma
Texto
Código SNS
Texto {Opcional/Recomendado}
CIP Europeo
Texto Dato que figure en la BD de la TSI
de la CA Se reserva este espacio en previsión de que, en el futuro, exista un
código europeo/internacional de identificación.
 Nº Historia Clínica
Texto Libre
 Domicilio
o Tipo de vía
Texto
o Nombre de la vía
Texto
o Número de la vía
Texto
o Piso
Texto
o Letra
Texto
o Código Postal
Texto
o Municipio
Texto
Texto
o Provincia
Datos del proceso Asistencial:
 Motivo del Alta
Texto = Traslado a domicilio || Traslado
de Servicio || Traslado a otro centro hospitalario || Traslado a un centro
sociosanitario || Alta voluntaria Fallecimiento || Otros
 Motivo de Ingreso
Texto Libre + Código CIE 9
 Tipo de ingreso
Texto= “ Urgente|| Programado” R
 Antecedentes
Texto Libre. Se
recomienda
la
clasificación en subapartados:
Enfermedades familiares hereditarias
Enfermedades previas
Antecedentes neonatales, obstétricos y quirúrgicos
Alergias
Hábitos tóxicos
Actuaciones preventivas: Vacunaciones infantiles,
realizadas, etc.
o Medicación previa
o Situación funcional
o Antecedentes sociales y profesionales
o
o
o
o
o
o
 Historia Actual
 Exploración Física
218
Texto Libre
Texto Libre
del
adulto,
quimioprofilaxis
Anexo K: Informes definidos por el MSPS.
 Resumen pruebas complementarias
Texto Libre
o Laboratorio
o Imagen
o Otras pruebas Se recomienda la clasificación en subapartados
 Evolución y comentarios
Texto Libre
 Diagnostico Principal
Texto Libre y Código CIE 9
Opcional)
 Otros Diagnósticos
Texto Libre y Códigos CIE 9 MC
Opcional)
 Procedimientos
Texto Libre y Código CIE 9 MC
Opcional)
 Otros Procedimientos
Opcional)
 Tratamiento
o Recomendaciones
o Fármacos
+ duración
MC (Código
(Código
(Código
(Código
Texto Libre
(Opcional)
Texto libre + Ppio Activo/código (nomenclátor MSyC) + dosis
 Otras Recomendaciones
Texto Libre
Informe clínico de Consulta Externa de Especialidades
 Tipo del Documento
Cadena de texto = “Informe clínico de Consulta
Externa”.
 Fecha de firma
dd/mm/aaaa
 Fecha de Consulta
dd/mm/aaaa
 Responsable 1
 Categoría profesional 1
Especialista de Área || Jefe de Sección || Jefe de Servicio
 Nombre Responsable 2
 Categoría profesional 2
Texto = Facultativo || Especialista de Área ||
Jefe de Sección || Jefe de Servicio
 CM Servicio
 Unidad
Texto Libre
 Denominación del Servicio de Salud
Texto + Logo =
SAS.
 Denominador del Provisor de servicios Texto Libre + Logo
219
Anexos:
 Denominación del centro
Texto (Catalogo
Hospitales, y RECESS cuando esté disponible + Libre) + Logo
 Dirección del Centro
Nacional
de
o Tipo de Vía
esté disponible)
o Nombre de la vía
Texto(Catalogo Nacional de Hospitales, y RECESS cuando
esté disponible)
esté disponible)
o Piso
esté disponible)
o Letra
esté disponible)
o Código Postal
esté disponible)
o Municipio
esté disponible)
o Provincia
esté disponible)
o Teléfono
Texto (Catalogo Nacional de Hospitales, y RECESS cuando esté
disponible)
o Direccion Web/ Correo electrónico
Datos del paciente










Nombre
Texto
Primer Apellido
Texto
Segundo Apellido
Texto
Fecha nacimiento
dd/mm/aaaa
Sexo
Texto = H/M
Texto
NASS
Texto
CIP de C Autónoma
Texto
Código SNS
Texto {Opcional/Recomendado}
CIP Europeo
Texto Libre
 Domicilio
o
o
o
o
o
o
o
o
o
Tipo de vía
Nombre de la vía
Número de la vía
Piso
Letra
Código Postal
Municipio
Provincia
Teléfono
220
Texto
Texto
Texto
Texto
Texto
Texto
Texto
Texto
Texto















Motivo de la Consulta
Antecedentes
Texto Libre Se recomienda la
o Enfermedades familiares hereditarias
o Enfermedades previas
o Antecedentes neonatales, obstétricos y quirúrgicos
o Alergias
o Hábitos tóxicos
o Actuaciones preventivas
Vacunaciones
infantiles,
del
adulto,
quimioprofilaxis realizadas, etc
Historia Actual
Texto Libre
Exploración Física
Texto Libre
Resumen pruebas complementarias
Texto Libre
Laboratorio
Imagen
Otras pruebas Se recomienda la clasificación en subapartados.
Evolución y comentarios
Texto Libre
Diagnostico Principal
(Código Opcional)
Otros Diagnósticos
(Código Opcional)
Procedimientos
(Código Opcional)
Otros Procedimientos
(Código Opcional)
Tratamiento
o Recomendaciones
o Farmacos
+ duración
Texto Libre
(Opcional)
Otras Recomendaciones
Texto Libre
Informe Clínico de Urgencias








Tipo del Documento
Cadena de texto = “Informe clínico de Alta”.
Fecha de firma
dd/mm/aaaa
Fecha y Hora de Ingreso
dd/mm/aaaa hh:mm
Fecha y Hora de alta
dd/mm/aaaa hh:mm
Responsable 1
Especialista de Área || Jefe de Sección Jefe de Servicio
de Sección || Jefe de Servicio
221
Anexos:


CM Servicio
Unidad
Texto = Servicio de Urgencia Hospitalaria ||
Servicio de Urgencia de A.Primaria || SAMU || Sº Urgencias + texto libre




Denominación del Servicio de Salud
Texto + Logo =
SAS.
Denominador del Provisor de servicios
Texto Libre + Logo
Denominación del centro
Texto (Catalogo Nacional
de Hospitales, y RECESS cuando esté disponible + Libre) + Logo
Dirección del Centro
o Tipo de Vía
esté disponible)
o Nombre de la vía
esté disponible)
esté disponible)
o Piso
esté disponible)
o Letra
esté disponible)
o Código Postal
esté disponible)
o Municipio
esté disponible)
o Provincia
esté disponible)
o Teléfono
disponible)
o Dirección Web/ Correo electrónico
Datos del paciente








Nombre
Primer Apellido
Segundo Apellido
Fecha nacimiento
Sexo
NASS
CIP de C Autónoma
222
Texto
Texto
Texto
dd/mm/aaaa
Texto = H/M
Texto
Texto
Texto




Código SNS
Texto (Opcional/Recomendado)
CIP Europeo
Nº Historia Clínica
Texto Libre
Domicilio
o
o
o
o
o
o
o
o
o


Tipo de vía
Texto
Nombre de la vía Texto
Número de la vía Texto
Piso
Texto
Letra
Texto
Código
Postal
Texto
Municipio
Texto
Provincia
Texto
Teléfono
Texto
Persona de Referencia
Teléfono de Referencia
Texto Libre
Texto Libre
(Recomendado)
(Recomendado)
 Procedencia
Texto = Médico de Familia/Pediatra de AP ||
Por decisión del paciente o familiar || Servicio de Emergencia 061
 Tipo de Consulta
Texto = Enfermedad Accidente de tráfico
Accidente Laboral Otros Accidentes
 Motivo de Alta
Texto = Ingreso || Traslado a domicilio ||
Traslado de Servicio || Traslado a otro centro hospitalario ||Traslado a un
centro sociosanitario ||Alta voluntaria || Fallecimiento || Otros
 Motivo de Consulta
 Antecedentes
exto Libre
Se recomienda la clasificación en
subapartados
o
o
o
o
o
o


Historia Actual
Exploración Física
o
o
o
o
o
o

Alergias
Medicación previa
Situación funcional
Antecedentes sociales y profesionales
TA ( / ) FC ( )lat/min
FR ( ) resp/min
Temp. ( )ºC
Saturación O2
Glucemia capilar
Resumen de exploración
o Laboratorio
o Imagen
o Otras pruebas



Texto Libre
Texto Libre (Datos recomendados)
Texto Libre
Se recomienda la clasificación en subapartados
Diagnostico Principal
(Código Opcional)
Otros Diagnósticos
(Código Opcional)
Texto Libre
Texto Libre
y
Código
CIE
9
MC
Texto
y
Códigos
CIE
9
MC
Libre
223
Anexos:




Procedimientos
(Código Opcional)
Otros Procedimientos
(Código Opcional)
Tratamiento
o Recomendaciones
o Fármacos
+ dosis + duración
Texto
Libre
y
Código
CIE
9
MC
Texto
Libre
y
Códigos
CIE
9
MC
Texto Libre
(Opcional)
Texto libre + Ppio Activo/código (nomenclátor MSyC)
Texto Libre
Informe de Historia Clínica Resumida



Tipo del Documento
Historia Clínica Resumida”.
Fecha de Creación
Fecha de última Actualización
Cadena de texto = “Informe clínico de
dd/mm/aaaa
dd/mm/aaaa



Texto + Logo =
SAS.
Denominador del Provisor de servicios Texto Libre + Logo
Texto (Catalogo Nacional de
224

o Tipo de Vía
esté disponible)
o Nombre de la vía
esté disponible)
esté disponible)
o Piso
esté disponible)
o Letra
esté disponible)
o Código Postal
esté disponible)
o Municipio
esté disponible)
o Provincia
esté disponible)
o Teléfono
esté disponible)
Datos del paciente












Nombre
Texto
Primer Apellido
Texto
Segundo Apellido
Texto
Fecha nacimiento
dd/mm/aaaa
Sexo
Texto = H/M
Texto
NASS
Texto
CIP de C Autónoma
Texto
Código SNS
CIP Europeo
Texto. Dato que figure en la BD de la
TSI de la CA. Se reserva este espacio en previsión código europeo/internacional
de identificación.
Texto Libre
Domicilio
o
o
o
o
o
o
o
o
o



Tipo de vía
Nombre de la vía
Número de la vía
Piso
Letra
Código Postal
Municipio
Provincia
Teléfono
Cuidador Principal
Texto
Texto
Texto
Texto
Texto
Texto
Texto
Texto
Texto
Texto(Nombre + 2 apellidos)
Texto Libre
Texto (Nombre + 2 apellidos)
225
Anexos:
Datos de Salud:













Existe información reservada por Decisión del paciente
Existe Documento de Instrucciones Previas
Está Incluido en protocolo de Investigación cínica
Alergias
Vacunaciones
Problemas Cerrados, Resueltos o Inactivos
Problemas y Episodios Activos
Códigos CIE 9 MC/CIAP2
Tratamiento
o Recomendaciones
o Farmacos
+ duración
Sí/No
Sí/No
Sí/No
Texto Libre
Texto Libre
Texto Libre
Texto Libre y
Texto Libre
(Opcional)
Diagnósticos Enfermería Activos
Resultados de Enfermería
Intervenciones de Enfermería
Alertas
Observaciones subjetivas
Texto Libre + Código NANDA
Texto Libre + Código NOC
Texto Libre + Código NIC
Texto Libre
Texto Libre
Informe Cínico de Atención Primaria








Tipo del Documento
Cadena de texto = “Informe clínico de Atención
Primaria”.
Fecha de firma
dd/mm/aaaa
Fecha Inicio Periodo
dd/mm/aaaa
Fecha fin Periodo
dd/mm/aaaa
Responsable 1
Texto = Médico Residente || Médico de Familia
|| pediatría de AP || Texto Libre
Texto = Médico de Familia || pediatría de AP
|| Texto Libre


Texto + Logo =
SAS.
Texto Libre + Logo
226


o Tipo de Vía
esté disponible)
o Nombre de la vía
esté disponible)
esté disponible)
o Piso
esté disponible)
o Letra
esté disponible)
o Código Postal
esté disponible)
o Municipio
esté disponible)
o Provincia
esté disponible)
o Teléfono
esté disponible)
Direccion Web/ Correo electrónico
algo al paciente)
Texto Libre (sólo si aporta
Datos del paciente












Nombre
Texto
Primer Apellido
Texto
Segundo Apellido
Texto
Fecha nacimiento
dd/mm/aaaa
Sexo
Texto = H/M
Texto
NASS
Texto
CIP de C Autónoma
Texto
Código SNS
CIP Europeo
Texto Libre
Domicilio
o
o
o
o
o
o
o
o
o


Tipo de vía
Nombre de la vía
Número de la vía
Piso
Letra
Código Postal
Municipio
Provincia
Teléfono
Texto
Texto
Texto
Texto
Texto
Texto
Texto
Texto
Texto
Teléfono de referencia
Texto ( nombre + 2 apellidos)
Texto
227
Anexos:

Antecedentes
Enfermedades familiares hereditarias
Alergias
Hábitos tóxicos
Actuaciones preventivas Vacunaciones infantiles,
realizadas, etc
o
o
o
o
o
o

o Laboratorio
o Imagen
o Otras pruebas






Texto Libre. Se recomienda la
del
adulto,
quimioprofilaxis
Texto Libre
Se recomienda la clasificación en subapartados
Resumen de episodios Atendidos
MC/CIAP2 (Código Opcional)
Diagnósticos
Procedimientos
Tratamiento
o Recomendaciones
o Farmacos
+ duración
Texto Libre y Códigos CIE 9
Texto Libre
Texto Libre
(Opcional)
Texto Libre
Informe de Resultados de Pruebas de Laboratorio








Tipo del Documento
Cadena de texto = “Informe de Resultados de
Pruebas de Laboratorio”.
Fecha de firma
dd/mm/aaaa
Responsable 1
Especialista de Área || Jefe de Sección || Jefe de Servicio || Texto Libre
de Sección || Jefe de Servicio || Texto Libre
Servicio
Texto = Análisis Clínicos || Anatomía
Patológica || Bioquímica Clínica || Hematología y Hemoterapia || Genética
|| Inmunología || Microbiología y parasitología
Unidad
Texto Libre
228




Texto + Logo =
SAS.
Texto Libre + Logo
o Tipo de Vía
esté disponible)
o Nombre de la vía
esté disponible)
esté disponible)
o Piso
esté disponible)
o Letra
esté disponible)
o Código Postal
esté disponible)
o Municipio
esté disponible)
o Provincia
esté disponible)
o Teléfono
esté disponible)
Datos del paciente











Nombre
Texto
Primer Apellido
Texto
Segundo Apellido
Texto
Fecha nacimiento
dd/mm/aaaa
Sexo
Texto = H/M
Texto
NASS
Texto
CIP de C Autónoma
Texto
Código SNS
CIP Europeo
Texto Libre
229
Anexos:

Domicilio
o
o
o
o
o
o
o
o
o
Tipo de vía
Nombre de la vía
Número de la vía
Piso
Letra
Código Postal
Municipio
Provincia
Teléfono
Texto
Texto
Texto
Texto
Texto
Texto
Texto
Texto
Texto
Datos del solicitante








Texto + Logo =
SAS.
Texto Libre + Logo
Servicio
Texto
Unidad
Texto Libre
Nombre del solicitante
Texto Libre (nombre + 2
apellidos)
Categoría profesional
Texto = Médico Residente
|| Facultativo Especialista de Área || Jefe de Sección || Jefe de Servicio ||
Médico de Familia || Facultativo || Pediatra de AP || Texto Libre

Datos de la muestra
o Fecha de Recogida de Muestras
dd/mm/aaaa
o Número de Muestra
Texto Libre
o Tipo de Muestra
Texto Libre + Código (Bioquímica:
LOINC; Hematología: LOINC; Inmunología: LOINC; Genética: LOINC;
Microbiología: Vocabulario local a partir de LOINC . Patológica: Snomed-CT)
o Grupo de Determinación
Texto = Bioquímica general ||
Sistemático orina || Hormonas || Marcadores tumorales || Niveles de fármacos y
tóxicos || Gasometría || Hematología || Hemostasia (Coagulación) || Hemoterapia
|| Hematología-Coagulación: Pruebas especiales || Inmunología - Alergia ||
Microbiología || Genética || Anatomía Patológica – Biopsias || Anatomía
Patológica – Citologías
230

Resultados
o Modelo Tipo A
 Determinación
 Resultado
 Unidades
 Rango
 Complementarios
o Modelo Tipo B
 Determinación
 Técnica
 Descriptiva
 Conclusión
Texto Libre
Texto Libre
Texto Libre
Texto Libre
Texto Libre
Texto Libre
Texto Libre
Texto Libre
Texto Libre Informes de Resultados de Pruebas de Imagen








Tipo del Documento
Cadena de texto = “Informe clínico de pruebas
de Imagen”.
Fecha de firma
dd/mm/aaaa
Responsable 1
Especialista de Área || Jefe de Sección || Jefe de Servicio || Texto Libre
de Sección || Jefe de Servicio || Texto Libre
CM Servicio
Texto = Radiodiagnostico || Medicina Nuclear
Unidad
Texto Libre




Texto + Logo =
SAS.
Texto Libre + Logo
Texto (Catalogo Nacional de
o Tipo de Vía
esté disponible)
o Nombre de la vía
esté disponible)
231
Anexos:
esté disponible)
o Piso
esté disponible)
o Letra
esté disponible)
o Código Postal
esté disponible)
o Municipio
esté disponible)
o Provincia
esté disponible)
o Teléfono
disponible)
Datos del paciente
 Nombre
 Primer Apellido
 Segundo Apellido
 Fecha nacimiento
 Sexo
 CIP de C Autónoma
 Nº Cama / Nº consulta
Datos del solicitante








Texto
Texto
Texto
dd/mm/aaaa
Texto = H/M
Texto
Texto
Texto
Texto + Logo =
SAS.
Texto Libre + Logo
Servicio
Texto
Unidad
Texto Libre
Nombre del solicitante
Texto Libre (nombre + 2
apellidos)
Categoría profesional
Texto = Médico Residente
|| Facultativo Especialista de Área || Jefe de Sección || Jefe de Servicio ||
Médico de Familia || Facultativo || Pediatra de AP || Texto Libre
232







Información Clínica
Exploración
SEMN
Fecha de la Exploración
Descripción de la Exploración
Hallazgos
Diagnostico
catalogo + código
Recomendadiones
Texto Libre
Texto Libre + Código SERAM + Código
dd/mm/aaa
Texto Libre
Texto Libre
Texto Libre
+
Cadena
nombre
del
Texto Libre
Informe de Resultados de Cuidados de Enfermería









Tipo del Documento
de Cuidados de Enfermería”.
Fecha de firma
Fecha de Valoración de Enfermeria
Fecha Alta / Derivación de Enfermería
Enfermera Responsable 1
Categoría Profesional Enfermera 1
Especialista || Enfermera Residente (EIR)
Enfermera Responsable 2
Categoría Profesional Enfermera 2
Especialista
Dispositivo Asistencial
Hospital || Urgencias Hospitalarias ||
Centro Sociosanitario || Otros
Cadena de texto = “Informe clínico
dd/mm/aaaa
dd/mm/aaaa
dd/mm/aaaa
Texto = Enfermera || Enfermera
Texto = Enfermera || Enfermera
Texto = Centro de Salud ||
Urgencias Extrahospitalarias ||



Texto + Logo =
SAS.
Texto Libre + Logo
233
Anexos:

o Tipo de Vía
esté disponible)
o Nombre de la vía
esté disponible)
esté disponible)
o Piso
esté disponible)
o Letra
esté disponible)
o Código Postal
esté disponible)
o Municipio
esté disponible)
o Provincia
esté disponible)
o Teléfono
disponible)
Datos del paciente












Nombre
Texto
Primer Apellido
Texto
Segundo Apellido
Texto
Fecha nacimiento
dd/mm/aaaa
Sexo
Texto = H/M
Texto
NASS
Texto
CIP de C Autónoma
Texto
Código SNS
CIP Europeo
Texto Libre
Domicilio
o
o
o
o
o
o
o
o
o
o
o
Tipo de vía
Nombre de la vía
Número de la vía
Piso
Letra
Código Postal
Municipio
Provincia
Teléfono
Persona de referencia
234
Texto
Texto
Texto
Texto
Texto
Texto
Texto
Texto
Texto
Texto
Texto



Causas que generan la actuación de la Enfermera
Texto Libre
Motivo de Alta/Derivación
Texto
=
Ingreso || Traslado a domicilio || Traslado de Servicio || Traslado a centro
hospitalario || Traslado a un centro sociosanitario || Alta voluntaria ||
Fallecimiento || Otros
Antecedentes
Texto Libre.
Se recomienda la clasificación en subapartados:
Intervenciones quirúrgicas
Tratamientos Farmacológicos
Alergias
Actuaciones preventivas Vacunaciones infantiles, del adulto, quimioprofilaxis
realizadas, etc
o Factores personales, familiares, sociales, culturales y laborales, destacables
o
o
o
o
o








Diagnostico Enfermero Resueltos
Protocolos en los que está incluido
Valoración Activa
o Modelo de Referencia Utilizado
o Resultados destacables
Texto Libre y Código NANDA
Texto Libre
Texto Libre
Texto Libre
Diagnostico Enfermero activos
Texto Libre y Código NANDA
Resultados de enfermería
Texto Libre y Códigos NOC
Intervenciones de enfermería
Texto Libre y Códigos NIC
Cuidador Principal
Texto Libre y vinculación con el
paciente
Información complementaria / Recomendaciones
Texto Libre
235
Anexos:
236
Anexo L: Consideradiones acerca de la toma de medidas en servicios de
telemeonitorización
Anexo L . Consideraciones acerca de la toma
de medidas en servicios de
telemonitorización.
Durante los últimos años factores como el desarrollo tecnológico y las nuevas
tecnologías han permitido el desarrollo de nuevos modelos de interactuación con
el sistema sanitario. En la mayoría de los casos, ya ni siquiera es necesario acudir
al lugar en el que se encuentra el médico para obtener un diagnostico aproximado
de nuestro estado de salud: las nuevas tecnologías, una mayor culturización de la
población y la posibilidad de adquirir determinados dispositivos médicos a un
costo razonable nos han abierto este camino.
De este modo, no hace demasiados años en un entorno rural, un anciano para
conocer su tensión arterial debía acudir al médico o al farmacéutico y tras realizar
la medida preguntar por una interpretación de la misma. Sin embargo, hoy en día
prácticamente es de conocimiento público el rango de valores de una tensión
arterial normal. Y no es un hecho extraño poseer un tensiómetro digital en tu
casa, de modo que para obtener esa medida basta con ajustarte un manguito y
darle a un botón, acción que casi todo el mundo puede realizar. La figura del
médico con el fonendoscopio escuchando los ruidos Korotkoff a la vez que se
controla el nivel de presión en un manómetro de mercurio ha quedado en los
anales de la historia de la medicina.
Sin embargo, y aunque esto nos pueda dar una idea más o menos aproximada
de cuál es nuestro estado de salud, hay pequeños matices en la toma de la medida
que en casos extremos que en la asignación de una patología a una persona,
cometamos un falso positivo o, lo que es más grave, no seamos capaces de
identificar como patológicos determinados signos y demos por normal una
situación, que cambiando las condiciones de entorno, sea claramente anómala.
Durante las próximas páginas analizaremos algunas de las medidas más
comunes que te puedes tomar en entornos remotos al centro sanitario y cuáles son
los factores que nos pueden ayudar a interpretar correctamente la medida.
237
Anexos:
a. Glucemia
 ¿Qué es?: Valor de la concentración de la glucosa en sangre.
 ¿Valores Normales? Depende del momento de la toma del día:
o Entre 80 y 120 mg/dl antes de comer.
o 160 mg/dl ó menos dos horas después de comer.
o Entre 100 y 140 mg/dl antes de acostarse.
 ¿Patologías donde se realizan este tipo de pruebas? Hemos detectado los
siguientes casos:
o Hipoglucemia: Niveles de glucosa por debajo de lo normal.
o Hiperglucemia: Niveles de glucosa por encima de lo normal. Posible caso de
diabetes (aunque también puede indicar un exceso esporádico de azúcar en
sangre debido a una alimentación muy grasa).
o Diabetes: Trastorno metabólico donde se presentan niveles de glucosa por
encima de lo normal.
 ¿Existe alguna pauta de medida? El protocolo de toma de medida varia de
persona a persona acorde con mayor o menor gravedad de su situación. En su
versión más completa se han determinado 8 instantes claves de adquisición de
la glucemia:
o Antes del desayuno, la comida y la cena.
o De 1 a 2 horas después del desayuno, la comida y la cena.
o Antes de acostarse.
o A las tres de la madrugada.
En cualquier caso, también es recomendable realizar una medida antes,
durante y después del ejercicio.
 ¿Qué factores influyen en la medida? Como ya habíamos adelantado en
puntos anteriores, el momento del día en que te tomas la medida influye en la
medida de haber tomado bebidas azucaradas ó alimentos. Sin embargo ambas
medidas tienen su importancia: una es indicativa del nivel de glucosa en
condiciones normales en nuestro organismo y las otras son indicativos de la
capacidad de metabolización que poseemos. El haber realizado ejercicio físico
también es capaz de enmascarar la medida. Así en el ejercicio de corta
duración de liviana a moderada intensidad, la concentración de glucosa en
sangre prácticamente no se modifica con relación a la glucemia en reposo. Si es
intenso puede observarse una elevación leve de la glucemia (20 a 30 mg/dl). En
el ejercicio prolongado (más de 90 minutos) la glucemia desciende entre 10 a 40
mg/dl. Posteriormente a la realización del ejercicio, el musculo y el hígado
recupera la glucosa que previamente habían liberado al torrente sanguíneo.
También es importante conocer el uso de si el paciente está recibiendo algún
tipo de medicación. Diversos tipos de insulina actúan en diferentes tiempos de
reacción. El estrés también puede modificar los niveles de glucosa en sangre: el
estrés físico (lesiones, enfermedades, etc.) suelen elevar el nivel de glucosa, sin
embargo el estrés emocional puede elevar la glucemia o disminuirla en algunos
casos de diabetes tipo 1. En cualquier caso, señalar que los niveles de riesgo en
la glucemia varían dependiendo del lugar donde se ha extraído la muestra: la
glucemia en los capilares es un 15 % superior a que podamos tomar en las
extremidades y por lo tanto no son datos comparables a las de los análisis de
sangre. Al menos directamente.
238
 ¿Debería complementarse con algún tipo de medida? El control
metabólico de la diabetes se complementa mediante la determinación de la
Hemoglobina Glicada (HbA1c), que indica fielmente el grado de control que ha
mantenido el diabético en los últimos tres meses. En este caso niveles
superiores al 6,5% son indicativos de riesgo arterial y si son superiores al 7,5%
son indicativos de riesgo cardiovascular. También puede ser necesario un
análisis parcial de orina.
 Algunas referencias consultadas: (184) (185) (186) (187)
b. Temperatura corporal
 ¿Qué es? La temperatura resulta del balance entre la producción y la pérdida
de calor, controlado por el centro termorregulador situado en el hipotálamo
anterior. Refleja el nivel térmico de un cuerpo, es decir, su capacidad para
ceder energía calorífica.
 ¿Valores Normales? Es muy difícil establecer un rango de valores para los
que considerar que la temperatura corporal es normal debido a la gran
cantidad de condicionantes en la toma de la medida, pero podemos suponer
unos rangos de normalidad en un rango de 36 a 37 grados. En la medida que
salgamos de ese intervalo, podremos encontrarnos en situación de febrícula
(entre 37 a 38 grados), fiebre (entre 38 y 40 grados) ó hiperpirexia (entre 40 y
42 grados).
 ¿Patologías donde se realizan este tipo de pruebas? Cuando medimos la
temperatura corporal, estamos intentando determinar un posible estado febril
para intentar identificar cualquier agresión física, química u orgánica en
diferentes condiciones o enfermedades.
 ¿Existe alguna pauta de medida? No en cuanto a la frecuencia temporal
que se debe tomar, aunque un estudio de la curva de temperatura puede
ayudar a determinar la curva de la temperatura puede convertirse en una
valiosa pista para el estudio etiológico de la fiebre. Así:
o Fiebre intermitente: Caracterizada por una amplia oscilación en las cifras de
la temperatura. El uso irregular de antipiréticos y los abscesos piógenos son
las causas más comunes de este patrón intermitente. También se observa en
la tuberculosis diseminada, en la pielonefritis aguda con la bacteremia y
menos frecuentemente en el paludismo.
o Fiebre continua: Es aquella con elevaciones moderadas, pero persistentes de
la temperatura, con mínimas fluctuaciones. Orienta a pensar en brucelosis,
fiebre tifoidea y neumonía neumocócica.
o Fiebre remitente: Es muy similar a la fiebre intermitente excepto porque las
fluctuaciones de la temperatura son menos dramáticas sin que ésta retorne
a las cifras normales. Ejemplos son las infecciones virales respitatorias, la
neumonía por micoplasma y el paludismo por Plasmodium falciparum.
o Fiebre recurrente: Caracterizada por periodos de fiebre alternantes con
periodos afebriles. Durante los episodios febriles, la fiebre puede presentarse
bajo una de las formas antes descritas.
o Disociación esfigmotérmica (disparidad pulso-temperatura): Se presenta con
elevación de temperatura sin incremento en la frecuencia cardiaca. Puede
observarse en la brucelosis, fiebre tifoidea y psitacosis. De manera habitual
si aumenta la temperatura corporal la frecuencia cardiaca aumenta para
tratar de enfriar la sangre y por lo tanto el cuerpo. La frecuencia
cardíaca suele aumentar 15 pulsaciones por minuto por cada grado
centígrado de elevación de la temperatura, excepto en aquellos casos
en los que se produce una disociación pulso-temperatura.
239
Anexos:
 ¿Qué factores influyen en la medida? Numerosos:
o El lugar de la toma. Hay cuatro lugares donde se puede tomar la
temperatura: Oral, rectal, axilar y en el oído. La rectal es, en media, medio
grado superior a la oral, y esta última es otro medio grado superior a la
axilar. En el oído es donde más fielmente podemos determinar la
temperatura de los órganos internos.
o Edad: los niños tienden a tener temperaturas rectales y orales más altas
(37.5 a 38.0 °C) que los adultos. Las variaciones diarias cambian a medida
que los niños crecen: En niños menores de 6 meses, la variación diaria es
pequeña. En niños de 6 meses a 2 años de edad, la variación diaria es de
aproximadamente 1°C. A la edad de 6 años, las variaciones diarias se
incrementan gradualmente a 2 °C por día. Por otra parte, en los adultos
mayores la temperatura corporal suele estar disminuida (36 oC).
o Rítmo diurno/circadiano (ciclo de 24 horas): a lo largo de la jornada las
variaciones de la temperatura suelen ser inferiores a 1.5 oC. La
temperatura máxima del organismo se alcanza entre las 18 y las 22 horas y
la mínima entre las 2 y las 4 horas. De aquí que puedan aparecer episodios
de febrícula por la noche.
 La temperatura ambiente: altas temperaturas o frío extremo.
 La indumentaria.
 El estrés: las emociones intensas como el enojo o la ira activan el sistema
nervioso autónomo, pudiendo aumentar la temperatura.
 Las enfermedades: ciertas enfermedades metabólicas (hipertiroidismo) y
aquellas que impliquen estados febriles, aumentan la temperatura, mientras
que otras enfermedades metabólicas (hipotiroidismo) pueden conducir a un
descenso de la temperatura.
 Cambios menstruales en las mujeres: en la segunda mitad del ciclo, desde
la ovulación hasta la menstruación, la temperatura se puede elevar entre 0.30.5ºC.
 El ejercicio físico: la actividad muscular incrementa transitoriamente la
temperatura corporal. Por el contrario, durante una inactividad prolongada
(dormir), la temperatura disminuye.
 ¿Debería complementarse con algún tipo de medida? A priori no es
necesario.
 Algunas referencias consultadas: (188) (189) (190)
c. Tensión Arterial
 ¿Qué es? La presión que ejerce la sangre contra la pared de las arterias. La
presión arterial tiene dos componentes:
o Presión arterial sistólica: corresponde al valor máximo de la tensión arterial
en sístole (cuando el corazón se contrae).
o Presión arterial diastólica: corresponde al valor mínimo de la tensión
arterial cuando el corazón está en diástole o entre latidos cardíacos.
Depende fundamentalmente de la resistencia vascular periférica.
 ¿Valores Normales? La presión arterial es uno de los signos vitales más
volubles, dado que sus variaciones junto con las de la temperatura y ritmo
cardiaco, están destinadas a conservar / restablecer el equilibrio interno de
nuestro organismo: la homeostasis. Sin embargo, tomando el caso más general
podemos decir que unos umbrales óptimos se encuentran entre (120 -130) / (8085) mmHg.
240
 ¿Patologías donde se realizan este tipo de pruebas? Por su importante
papel en la homeostasis, la tensión arterial se toma en múltiples patologías
como lo son:
o Hipertensión: La tensión arterial se encuentra por encima de los valores
normales. La etiología de esta enfermedad comprende causas tan diversas
como causas genéticas, obesidad, diabetes, incorrecta alimentación, estrés,
sedentarismo, etc.
o Hipotensión: La tensión arterial se encuentra por debajo de los valores de
normalidad. Suele asociarse a un flujo sanguíneo disminuido: hemorragias,
deshidratación, exceso de calor, problemas cardiacos, etc.
o Enfermedades del sistema circulatorio: La formación de placas de ateroma
en venas / arterias de nuestro sistema circulatorio conlleva una pérdida de
elasticidad en sus paredes y un mayor riesgo de ruptura del endotelio de
estas. También podemos encontrarnos a un endurecimiento de las paredes
de los vasos.
o Enfermedades renales: El riñón es el principal órgano que regula la tensión
arterial, además de ser el encargado de eliminar elementos de desecho,
hormonas, controlar el pH del cuerpo, etc. Cualquier tipo de enfermedad que
afecte a su funcionalidad (nefropatías, cáncer, lesión renal, diabetes insípida
nefrógena, etc) es susceptible de provocar valores de tensión arterial
alterados.
o Embarazo: Pueden aparecer pre-eclampsia, lo que puede causar problemas a
la viabilidad del feto.
Además, también es útil en casos de diabetes, sobrepeso, etc. Esta amplitud de
situaciones ha convertido el tensiómetro un uno de los dispositivos médicos
más comercializados
 ¿Existe alguna pauta de medida? Sí. Se deben tomar dos medidas mínimo
(promediadas) y varias tomas adicionales si hay cambios > 5 mmHg (hasta 4
tomas que deben promediarse juntas). La primera vez se debe medir ambos
brazos, quedándonos con aquel brazo en el que mayores valores se obtengan si
utilizamos un tensiómetro de antebrazo. En el caso de utilizar un tensiómetro
de muñeca, habremos de referirlo siempre al brazo izquierdo. La tensión
arterial se debe realizar siempre sentado/acostado, salvo en ancianos ó
diabéticos donde puede resultar interesante descartar un problema de
hipertensión ortostatica tras 1 min en bipedestación.
 ¿Qué factores influyen en la medida? La tensión arterial es un signo vital
que varia con gran cantidad de factores:
o Edad y Sexo: En la Tabla L-1 se puede ver una distribución aproximada
de los valores de normalidad y los umbrales de patología.
o Raza. Es más alta en los afroamericanos.
o Temperatura: El calor, pues produce vasodilatación y la tensión arterial
baja. El frio, aumenta la tensión arterial. La temperatura debería rondar los
20ºC.
o La altitud en la que te encuentres: la altitud favorece la hipertensión
(aumenta la tensión) y el estar a nivel del mar favorece la hipotensión
(disminuye la tensión).
o Episodios de estrés / ejercicio pueden elevar la tensión arterial. Evitar
realizar ejercicio físico antes de la medida y conservar la posición de la
medida al menos 5 minutos antes de la medida. Evitar situaciones de ruidos
y alarmas.
241
Anexos:
Presión Sistólica
Edad Límites normales
16-18
19
20-24
25-29
30-34
35-39
40-44
45-49
50-54
55-59
60-64
Presión Diastólica
Hipertensión
Hombres
Mujeres
Límites normales
Hombres
Mujeres
Hipertensión
Hombres
Mujeres
Hombres
105-135
105-140
105-140
108-140
110-145
110-145
110-150
110-155
115-160
115-165
115-170
Tabla L-1.
100-130
145
140
60-86
60-85
90
100-130
150
140
60-88
60-85
95
100-130
150
140
62-88
60-85
95
102-130
150
140
65-90
60-86
96
102-135
155
145
68-92
60-88
98
105-140
160
150
68-92
65-90
100
105-150
165
165
70-94
65-92
100
105-155
170
175
70-96
65-96
104
110-165
175
180
70-98
70-100
106
110-170
180
185
70-98
70-100
108
115-175
190
190
70-100
70-100
110
Valores de Tensión arterial en función de edad y sexo
Mujeres
90
90
90
92
95
98
100
105
108
108
110
o La hora del día, a primera hora de la mañana es baja y va en aumento a lo
largo del día.
o Tras comer: Después de las comidas disminuye, pues la sangre se deriva a
la zona del estomago para la realización de la digestión. Evitar
copiosamente al menos una hora antes de la toma de la medida.
o Toma de ciertos estimulantes: café, té, tabaco, etc. Evitar su consumo al
menos 15 / 30 minutos antes de la toma de la medida.
o Postura en la que se realiza la medida: Aparte de realizarse sentado ó
acostado, hay que evitar tener las piernas cruzadas.
o Medicación: Si se toman diuréticos ó beta-bloqueadores.
o Humedad.
o Como en el caso de la glucemia, y aunque solo hemos comentado dos casos,
la toma de la tensión arterial pueden apreciarse pequeñas diferencias
dependiendo del lugar donde se tome la medida (ver Tabla L-2).
o Embarazo. Durante los primeros meses del embarazo, la tensión arterial
suele disminuir, para acabar aumentando. Puede acabar presentando un
problema de preclampsia.
o Sobrepeso.
o Menopausia. Aunque difícil de demostrar debido a la multitud de factores
que convergen (aumento de peso, envejecimiento, cambios en el estilo de
vida, medicación hormonal sustitutiva, etc) parece demostrado que se
produce un aumento en la tensión sistólica, ó al menos un aumento medio de
la tensión arterial. NO
Presión sistólica
Arteria Braquial
Aorta torácica
Aorta abdominal
Arteria femoral
120
120
132
139
Presión
diastólica
80
88
86
84
Tabla L-2. Presión sistólica normal en función de ubicación de la toma.
242
 ¿Debería complementarse con algún tipo de medida? Dependerá de la
gravedad y la naturaleza de la enfermedad que se esté midiendo, así como de la
concurrencia de otras enfermedades y/ o factores de riesgo. De forma general,
se suele catalogar la Tensión arterial (TA) de acuerdo a la Tabla L-3 y el
riesgo se suele estratificar de acuerdo a la Tabla L-4.
TA Sistólica
(mmHg)
TA Diastólica
(mmHg)
<120
<130
130 – 139
<80
<85
85 – 89
Optima
Normal
Normal Alta
Hipertensión
Grado 1
Grado 2
Grado 3
Hipertensión sistólica Aislada
140 – 159
160 – 179
≥ 180
≥ 140
90 – 99
100 – 109
≥110
< 90
Tabla L-3. Umbrales de patologías de la tensión arterial
Estratificación del
riesgo
Hipertensión
grado 1
Hipertensión
grado 2
Hipertensión
grado 3
Ausencia de otros
factores de riesgo
Poco riesgo
Riesgo Moderado
Alto Riesgo
1 – 2 Factores de
Riesgo
Riesgo moderado
Riesgo Moderado
Muy alto riesgo
>2 Factores, lesión
orgánica o diabetes
Alto riesgo
Muy alto riesgo
Muy alto riesgo
Otras enfermedades
cardiovasculares
Muy alto riesgo
Muy alto riesgo
Muy alto riesgo
Tabla L-4. Estratificación del riesgo

Algunas referencias consultadas: (191) (192) (193)
d. Pulso



¿Qué es? Latido de una arteria, que se siente al presionarla levemente sobre
una saliente ósea. Cuando se contrae el ventrículo izquierdo la sangre pasa a
través de las arterias de todo el cuerpo, ésta onda de sangre es el pulso.
¿Valores Normales? El rango de valores normales varía con la edad
principalmente. Con la salvedad de otras matizaciones podemos considerar el
rango de valores normales entre 60 y 90 pulsaciones por minuto (ppm).
¿Patologías donde se realizan este tipo de pruebas? Salvo información de
contexto y matización, la principal aplicación de la medida del pulso es
determinar la frecuencia y la intensidad de los latidos del corazón. Las
patologías donde este valor toma mayor importancia es en aquellas que tengan
relación con el corazón (fallas eléctricas o estructurales) y el aparato
circulatorio: palpitaciones, enfermedad del nódulo sinusoidal, bloqueo cardiaco,
ya se está supliendo una deficiencia mediante el uso de un marcapasos, etc.
243
Anexos:
 ¿Existe alguna pauta de medida? Normalmente, el pulso se determina
contando los latidos en un determinado espacio de tiempo (15 s, 30s, etc.) y
multiplicar hasta conseguir la tasa de latidos por minuto. El paciente debe
estar por lo menos 10 minutos en reposo antes de la toma de la medida aunque
hay una modalidad mediante la cual se toma mediante la realización de
ejercicio físico (principalmente en el caso de los deportistas ó en pruebas de
esfuerzo). La medida se puede tomar en diferentes sitios:
o
Pulso Radial:
o
Pulso Carotideo:
o
Pulso Temporal.
o
Pulso Braquial.
o
Pulso Femoral .
o
Pulso Poplíteo.
o
Pulso Pedio dorsal.
o
Etc.
Fig. L‐1. Localización de los pulsos sanguineos
Si se toma el pulso de forma manual, es importante no utilizar el pulgar
porque este dedo tiene pulsaciones propias.
 ¿Qué factores influyen en la medida? Hay varios:
o Edad: El pulso cardiaco es muy elevado en edades tempranas y disminuye a medida que avanzamos en edad. La Tabla L-5 se muestran rangos
normales de la frecuencia cardiaca en función de la edad.
o Sexo: Las mujeres por término medio tienen entre 5 y 15 pulsaciones mas
por minuto que los hombres. NO
o La hora del día: Por la mañana el número de pulsaciones es menor que por
la tarde. Después de comer, podemos llegar a tener entre el 10% y 30% más
que en reposo.
o Forma Física: En atletas bien entrenados el rango normal de pulsaciones
esta en el intervalo de 40 a 60 ppm.
o Temperatura ambiente: cuanto más calor más altas las pulsaciones y de la misma manera cuanto más frió más bajas las pulsaciones. o La altitud: Si estamos en posiciones más elevadas, la concentración de oxigeno es menor y por lo tanto la frecuencia cardiaca aumenta. NO
Edad
Recien nacido - 1 mes
1 mes – 1 año
1 año – 2 años
2 años – 6 años
6 años – 10 años
10 años – 18 años
Adultos
Rango de Valores
80 - 180
80 - 140
80 - 130
75 - 120
75 - 90
65 -95
60 -100
Valor Medio
130
120
110
100
70
75
80
Tabla L-5- Frecuencia cardiaca en función de la edad
244
o Posición del cuerpo: Estando tumbado la frecuencia cardiaca es significativamente menor que de pie. o Nivel de actividad previo: El nivel de actividad sube la frecuencia cardiaca, por eso se recomienda un periodo de inactividad antes de la toma de la medida. o Uso de medicamentos: La variación puede ir tanto al alta como a la baja. o La presencia de alguna otra enfermedad: como por ejemplo fiebre, como ya se ha comentado, o insuficiencia respiratoria. o Otros aspectos: metabolismo (definido por niveles genéticos), talla (los más altos tienen frecuencias cardiacas menores) y peso (las personas delgadas tienen menor frecuencia cardiaca), nivel de excitación (estrés, etc.) o Estado mental  ¿Debería complementarse con algún tipo de medida? Realmente, la
medida del pulso va mucho más allá de ese “único” valor que se acostumbra
trabajar. Una interpretación correcta del pulso cardiaco debería comprender
las siguientes propiedades:
o Frecuencia: Se mide en pulsaciones por minuto. Según esta propiedad
podemos clasificar el pulso cardiaco como normal, taquicardico (pulso mayor
al límite superior de normalidad; normalmente 100 ppm) ó bravicárdico
(pulso menor al límite inferior de normalidad; normalmente 60 ppm).
o Ritmo: Es el patrón que presentan la separación entre pulsaciones. Así
podemos clasificar el ritmo entre regular (TAC_TAC_TAC) ó irregular
(TAC_TAC__TAC_____TAC_TAC___TAC).
o Tensión: grado de compresión de la pared arterial. Está relacionada con la
presión arterial. Lo clasifica en procesos duros o blandos.
o Amplitud: Refleja el volumen de sangre eyectado contra la pared arterial
durante la
contracción ventricular y lo clasifica entre fuerte, débil e
imperceptible.
También puede ser conveniente, tomar el pulso en diferentes partes del cuerpo
(ambos brazos, por ejemplo) para descartar posibles patologías como
ateroesclerosis, insuficiencia respiratoria, etc.
e. Peso
 ¿Qué es? El peso es una medida de la masa de un objeto o persona.
 ¿Valores Normales? Como en casos anteriores, tampoco es una magnitud
cuyo rango de normalidad sea único. Normalmente estos límites de normalidad
quedan ponderados por la altura de la persona a través del índice de masa
corporal (IMC). Los rangos de normalidad para una determinada persona son
aquellos que cumplen que 20 25. En la Tabla L-6 se puede encontrar
tanto la definición del IMC, así como una clasificación de la patología a la que
se asocia en función del rango en que este se encuentre.
245
Anexos:
Peso kg
IMC
Puede considerarse
Menos de 16
Desnutrición
De 16 a 20
Bajo peso
De 20 a 24
Peso normal
De 24 a 29
Sobrepeso
De 29 a 34
Obesidad
De 34 a 39
Obesidad severa
Más de 39
Obesidad de alto riesgo
Tabla L-6. IMC: definición y rangos.
 ¿Patologías donde se realizan este tipo de pruebas? El peso en sí no es
una patología concreta, sino las complicaciones que un exceso ó deficiencia de
peso pueden ocasionar en otras patologías. Así un control del peso puede ser
interesante en los siguientes casos:
o Diabetes: El peso influye en la diabetes en la misma medida que esta
influye en el peso. Controlando el peso, podremos llegar a tener un nivel de
vida mucho mejor en este tipo de patologías, donde según qué casos
podremos reducir la administración de insulina porque habremos revertido
la resistencia a esta.
o Problemas de hipertensión: Como consecuencia del sobrepeso, el
organismo necesita mover mayor cantidad de sangre y el corazón tendrá que
trabajar más.
o Enfermedades cardiacas y circulatorias: Normalmente, un exceso de
peso suele llevar asociado un aumento del colesterol y grasas, las cuales son
factores clave la formación de placas de ateroma y el endurecimiento de los
vasos sanguíneos.
o Problemas en el esqueleto: Con la edad los huesos sufren un proceso de
descalcificación y desgaste natural, sobre todo en las mujeres. Unos huesos
más débiles son más susceptibles de fracturarse y / o desgastarse. Con un
menor peso se puede lograr que las articulaciones sufran menos.
o Problemas respiratorios: La obesidad puede reducir la capacidad
pulmonar, lo que puede llevar a reducir problemas respiratorios y apnea del
sueño.
o Problemas hepáticos: El hígado no es capaz de metabolizar las grasas
debidamente. Un aumento del peso, puede conllevar un aumento de las
grasas y dado que somos incapaces de metabolizarlas, pueden acabar
ocasionado problemas circulatorios.
o Problemas de Anorexia: Es necesario controlar la ganancia/pérdida de
peso.
246
 ¿Existe alguna pauta de medida? Sí. De hecho, la adquisición de la medida
debería tomarse siempre en las mismas condiciones y por eso su toma en el
hogar puede ofrecer la toma adecuada de la medida:
o Se debe tomar la medida al comienzo del día, antes de tomar alimentos ó
agua.
o La medida debe tomarse con la menor cantidad de ropa posible y sin
calzado. Así no es necesario el quitar los 2 kilos aprox. que pesan la ropa y
los zapatos.
o El peso fluctúa de un día para otro, por lo tanto sería conveniente el tomar
el peso durante 3 días seguidos y obtener una media.
o La posición del cuerpo ha de ser erecta.
 ¿Qué factores influyen en la medida? En este caso los factores
condicionantes son menores, y los identificados se corresponden con la
retención de líquidos debido a diferentes causas: periodo menstrual,
enfermedades renales, etc. Sin embargo, se tiene conciencia de la existencia de
un estudio que relaciona la altitud con una pérdida de peso asociada al mal de
altura y a la segregación de menos leptina.
 ¿Debería complementarse con algún tipo de medida? Obviamente si
estamos trabajando con el IMC, o bien transmitimos ese valor directamente, lo
cual haría necesaria un gran número de decimales para conservar la precisión,
ó complementamos esa medida con la altura. Además, podría complementarse
la medida con las concentraciones de colesterol en sangre (LDL y HDL) en
casos de trastornos cardio-vasculares. Sin embargo, en determinados entornos,
donde sólo se controla una ganancia/ pérdida de peso tal vez sea sólo necesario
la transmisión del peso.
 Algunas referencias consultadas: (197) (198)
f. Pulsioximetria
 ¿Qué es? Es la medición no invasiva del oxígeno transportado por la
hemoglobina en el interior de los vasos sanguíneos. Se realiza con un aparato
llamado pulsioxímetro o saturómetro, gracias a él se obtienen los valores de
saturación de oxígeno en sangre( SaO2), aunque no la presión de oxígeno en
sangre(PaO2). Para realizar la conversión se utiliza una gráfica como la que se
puede ver en aunque podemos relacionarla mediante la Fig. L-2.
Fig. L-2. Relación entre SO2 y PO2
247
Anexos:
 ¿Valores Normales? Los valores normales de SaO2 oscilan entre 95% y 97%,
con un rango de variación del 2%. Valores por debajo del 95% (en reposo) se
asocian con situaciones patológicas y del 92-90% con insuficiencia respiratoria
crónica previa.
 ¿Patologías donde se realizan este tipo de pruebas? Al intentar
determinar la concentración de O2 en sangre, será conveniente la utilización de
un pulsioximetro en enfermedades relacionadas con el sistema respiratorio:
apnea del sueño, seguimiento de pacientes con EPOC, situaciones de hipoxia,
seguimiento de pacientes de oxigenoterapia, en pacientes anestesiados, en
situaciones de fatiga extrema, pacientes de asma, etc.
 ¿Existe alguna pauta de medida? Las pautas no son demasiado complejas:
o Evitar interferencias con otros aparatos eléctricos.
o El movimiento: los movimientos del transductor, que se suele colocar en un
dedo de la mano, afecta a la fiabilidad (por ejemplo el temblor o vibración de
las ambulancias), se soluciona colocándolo en el lóbulo de la oreja o en el
dedo del pie o fijándolo con esparadrapo.
o Evitar la luz ambiental intensa: xenón, infrarrojos, fluorescentes, etc.
o Evitar obstáculos a la absorción de la luz: laca de uñas (retirar con
acetona), pigmentación de la piel (utilizar el 5º dedo o el lóbulo de la oreja).
o Contrastes intravenosos, pueden interferir si absorben luz de una
longitud de onda similar a la de la hemoglobina.
o El pulso venoso: fallo cardíaco derecho o insuficiencia tricuspídea.
El aumento del pulso venoso puede artefactar la lectura, se debe colocar el
dispositivo por encima del corazón.
 ¿Qué factores influyen en la medida? Aunque suele ser muy fiable para
valores de SaO2 > 80% existen ciertos factores que pueden alterar la fiabilidad
de la medida:
o Anemia severa: la hemoglobina debe ser inferior a 5 mg/dl para causar
lecturas falsas.
o Mala perfusión periférica por frío ambiental, disminución de
temperatura corporal, hipotensión, vasoconstricción, etc. Es la causa más
frecuente de error ya que es imprescindible para que funcione el aparato que
existe flujo pulsátil. Puede ser mejorada con calor, masajes, terapia local
vasodilatadora, quitando la ropa ajustada, etc.
o Dishemoglobinemias: la carboxihemoglobina (intoxicación por monóxido
de carbono) y la metahemoglobina absorben longitudes de onda similares a
la oxihemoglobina. Para estas situaciones son necesarios otros dispositivos
como CO-oxímetros.
o Contrastes intravenosos, pueden interferir si absorben luz de una
longitud de onda similar a la de la hemoglobina.
 ¿Debería complementarse con algún tipo de medida? La oximetría es
una alternativa menos invasiva que la gasometría. Para obtener una medida
más completa se puede realizar mediciones del CO2 (capnografía) y pH que
serían los valores que nos faltarían de la gasometría.
248
g. Espirometría
 ¿Qué es? Es una serie de pruebas que miden la capacidad absoluta y los
volúmenes pulmonares y la capacidad con la que pueden ser movilizados. La
espirometría puede ser simple o forzada. Se pueden distinguir dos
modalidades: simple o forzada.
La espirometría simple consiste en solicitar al paciente que, tras una
inspiración máxima, expulse todo el aire de sus pulmones durante el tiempo
que necesite para ello. Así, se obtienen los siguientes volúmenes y capacidades:
o Volumen normal o corriente (Vt): Corresponde al aire que se utiliza
en cada respiración.
o Volumen de reserva inspiratoria (VRI): Corresponde al máximo
volumen inspirado a partir del volumen corriente.
o Volumen de reserva espiratoria (VRE): Corresponde al máximo
volumen espiratorio a partir del volumen corriente.
o Capacidad vital (CV): Es el volumen total que movilizan los
pulmones, es decir, sería la suma de los tres volúmenes anteriores.
o Volumen residual (VR): Es el volumen de aire que queda tras una
espiración máxima. Para determinarlo, no se puede hacerlo con una
espirometría, sino que habría que utilizar la técnica de dilución de
gases o la plestimografia corporal.
o Capacidad pulmonar total (TLC): Es la suma de la capacidad vital y
el volumen residual.
La espirometría forzada es aquella en que, tras una inspiración máxima, se le
pide al paciente que realice una espiración de todo el aire, en el menor tiempo
posible. Es más útil que la anterior, ya que nos permite establecer
diagnósticos de la patología respiratoria. Los valores de flujos y volúmenes que
más nos interesan son:
o
o
o
o
Capacidad vital forzada (FVC) (se expresa en mililitros): Volumen total
que expulsa el paciente desde la inspiración máxima hasta la
espiración máxima. Su valor normal es mayor del 80% del valor teórico.
Volumen máximo espirado en el primer segundo de una espiración
forzada (FEV1) (se expresa en mililitros): Es el volumen que se expulsa
en el primer segundo de una espiración forzada. Su valor normal es
mayor del 80% del valor teórico.
Relación FEV1/FVC: Indica el porcentaje del volumen total espirado
que lo hace en el primer segundo. Su valor normal es mayor del 7075%.
Flujo espiratorio máximo entre el 25 y el 75% (FEF25-75%): Expresa la
relación entre el volumen espirado entre el 25 y el 75% de la FVC y el
tiempo que se tarda en hacerlo. Su alteración suele expresar patología
de las pequeñas vías aéreas.
249
Anexos:
 ¿Valores Normales? Ver Tabla L-7
Parámetros
Porcentaje del valor de referencia
Patrón espirómetrico de función ventilatoria normal
FEV1
>80%
FEV1, / FVC
>75% (70 % en ancianos)
FVC
>80%
Patrón espirómetrico de función ventilatoria obstuctivo
<80%
FEV1
FEV1, / FVC
<75% (70 % en ancianos)
FVC
Normal o descendido
Patrón espirómetrico de función ventilatoria restrictivo
Normal o descendido
FEV1
>75% (70 % en ancianos)
FEV1, / FVC
FVC
<80%
Tabla L-7. Patrones espirometricos de distintas funciones ventilatorias.
 ¿Patologías donde se realizan este tipo de pruebas? Este tipo de pruebas
se realizan en todo tipo de afecciones del sistema respiratorio:
o Estudio de signos y síntomas respiratorios: disnea, tos crónica, tos con el
esfuerzo.
o Detección ye valuación de disfunción pulmonar (determinar qué tipo de
alteración respiratoria y cuantificación de su gravedad).
o Control evolutivo en enfermedades respiratorias crónicas.
o Monitorización del tratamiento broncodilatador o antiinflamatorio
bronquial.
o Detección de estenosis de vía aérea superior.
o Medición del impacto de enfermedades sistémicas sobre la función
pulmonar.
o Identificación de fumadores y trabajadores de riesgo.
o Valoración preoperatoria (pacientes con síntomas respiratorios y pacientes
asintomáticos mayores de 50 años y sometidos a cirugía mayor)
o Evaluación de la incapacidad pulmonar.
 ¿Existe alguna pauta de medida?
o Se recomendará suspender el uso de fármacos agonistas ß2-adrenérgicos seis
horas antes y el de teofilinas o derivados 12 ó más horas antes de la prueba.
o El paciente no debe fumar en la hora anterior a la espirometría.
o No es necesario el ayuno, pero se deben evitar comidas abundantes y
bebidas con cafeína en las horas previas.
o En relación con el control microbiológico de los equipos de función pulmonar,
si se sospecha que el paciente tiene una tuberculosis activa, al menos
deberían obtenerse tres baciloscopias negativas.
o Si se pretenden realizar espirometrías seriadas, sería preferible repetirlas
siempre a la misma hora del día.
o Las condiciones ambientales recomiendan una temperatura entre 17 y 40ºC.
o El paciente debe permanecer 15 minutos en reposo antes de la prueba y es
imprescindible proporcionarle una explicación del procedimiento antes de
iniciarlo. En concreto, se le debe insistir en la necesidad de evitar fugas
alrededor de la pieza bucal y en la realización de un esfuerzo inspiratorio
máximo, seguido por una espiración forzada máxima y sostenida.
250
o Es aconsejable la demostración de la maniobra por el técnico y, en caso de
o
o
o
o
o
o
pacientes poco hábiles, la realización de ensayos de la maniobra con la
boquilla suelta.
En general, se considera que la posición corporal idónea para llevar a cabo la
espirometría es con el paciente sentado erecto: Se debe evitar la inclinación
hacia delante durante la espiración, puesto que comprime la tráquea y
favorece el depósito de saliva a través de la pieza bucal. Sin embargo, la
American Thoracic Society (ATS) aconseja que la prueba se realice con el
paciente sentado o de pié, según su elección. Debe recordarse, que en
personas de edad media, la capacidad vital es 70 mL menor sentado que de
pié. El decúbito no es una posición aconsejable, puesto que los valores
obtenidos de esta forma resultan aproximadamente un 10% inferiores a los
obtenidos con el paciente sentado. Si existen enfermedades
neuromusculares, la diferencia puede superar el 40-60%.
La utilización de pinzas nasales es imperativa en la determinación de la
capacidad vital lenta o de la máxima ventilación voluntaria. Aunque es
difícil que durante una maniobra de capacidad vital forzada el paciente
espire por la nariz, también se aconseja emplear pinzas nasales,
especialmente si el tiempo de espiración forzada es muy prolongado y en
niños.
El paciente deberá respirar a través de una boquilla indeformable para
evitar la reducción de la luz por mordedura durante la espiración forzada.
Es necesario verificar que el paciente coloca la boquilla entre sus dientes y
la sujeta con los labios. No se recomienda retirar la dentadura postiza, salvo
que por su mala sujeción pueda soltarse y obstruir el flujo aéreo, puesto que
mejora la fijación de la boquilla.
Si se utiliza un espirómetro de agua, el paciente debe colocarse en posición
de reposo, efectuar una espiración máxima, seguida por una inspiración
máxima, una breve pausa de apnea y una espiración forzada y máxima. Si
se emplea un espirómetro seco o un neumotacógrafo, el paciente realizará
una espiración máxima y forzada desde la posición de inspiración máxima
hasta volumen residual.
Se recomienda que la pausa a capacidad pulmonar total no exceda los dos
segundos de duración, puesto que la fuerza de relajación de los elementos
pulmonares visco-elásticos es dependiente del tiempo. Si la maniobra de
FVC se realiza inmediatamente después de la inspiración a TLC se alcanzan
flujos espiratorios levemente superiores que si se realiza la pausa.
La sucesión de inspiración máxima y espiración forzada origina, en algunos
pacientes asmáticos, efectos de broncodilatación y broncoconstricción. Para
obviar estos problemas, sobre todo en la interpretación de pruebas de
broncodilatadores, se han desarrollado las curvas flujo-volumen parciales,
en las que la espiración forzada se realiza desde un volumen inferior a la
capacidad pulmonar total.
251
Anexos:
o Se realizarán un mínimo de tres maniobras satisfactorias de espiración
forzada, según las características detalladas. Si las maniobras obtenidas no
son satisfactorias, se repetirán hasta un máximo de ocho maniobras. En el
caso de la capacidad vital lenta, no se realizarán más de cuatro
determinaciones.
 ¿Qué factores influyen en la medida? Ya se ha comprobado que la posición
en la que se realice la medida afecta, así como talla y peso, edad, PK ejercicio y
medicación. Enfermedades: acatarrados, fiebre,
 ¿Debería complementarse con algún tipo de medida? Oximetría,
gasometría…. Depende de sospechas de otras patologías.
h. Electrocardiografía
 ¿Qué es? El registro de la actividad eléctrica del corazón. Se utiliza para
comprobar que el ritmo cardiaco es constante y uniforme y la frecuencia
cardiaca se encentra en valores normales (entre 50 y 100 ppm).
 ¿Valores Normales? Lo que realmente se acaba registrando son
derivaciones, bien sean frontales (ver Fig. L-3) o precordiales (ver Fig. L-4):
Fig. L-3. Derivaciones frontales. Fig. L-4. Derivaciones precordiales
En las frontales se pueden encontrar las bipolares (I,II,III) y algunas monopolares
(aVR, aVL, aVF). En las precordiales son todas monopolares. De la lectura de
estas ondas se puede determinar: ritmo, frecuencia, eje eléctrico, y diversos
complejos (P, PR, QRS, QTc, ST, T)
252
 ¿Patologías donde se realizan este tipo de pruebas? Se realiza esta
prueba en multitud de patologías:
o Crecimiento anómalo de las cavidades del corazón.
o Bloqueo de alguna rama.
o Arritmias (ventriculares, supraventriculares, bloqueos)
o Pericarditis
o Personas con marcapasos, etc.
Aunque hay una amplia gama de otro tipo de patologías, no directamente
relacionadas con el ámbito cardiaco, en el que se realizan estas pruebas:
o Anorexia nerviosa.
o Narcolepsia.
o Apnea del sueño.
o Hipoparatiroidismo, etc.
 ¿Existe alguna pauta de medida? Colocación correcta de los electrodos y no
realizar ejercicio previo antes.
 ¿Qué factores influyen en la medida? Hay varios:
o Edad: ECG normal en neonatos presenta algunas diferencias respecto al
adulto, como son que la frecuencia cardiaca es mayor, la onda T es negativa
de V1 a V3 ó que el PR es menor de los habitual (199) A partir de los 14
años estas diferencias deberían haber desaparecido completamente.
o Toma de medicamentos.
o Realizar deporte justo antes de la prueba.
 ¿Debería complementarse con algún tipo de medida? Según (199):
o Sexo y en y dad del paciente.
o Medicación si se está tomando.
o Calibración y velocidad del papel.
i. Perfil lipídico
 ¿Qué es? Un perfil lipídico es un grupo de pruebas solicitadas generalmente
de forma conjunta para determinar el riesgo de enfermedad cardíaca coronaria.
Incluye pruebas como:
o colesterol total.
o colesterol HDL, a menudo conocido como colesterol bueno.
o colesterol LDL, a menudo conocido como colesterol mal.
o Triglicéridos.
 Y de manera adicional:
o colesterol VLDL
o colesterol no-HDL
o proteína C reactiva (PCR)
253
Anexos:
 ¿Valores Normales? Los valores normales según (202) para personas que no
tienen otra patología están en torno a:
o LDL: 70 - 130 mg/dL (lo deseable son números menores).
o HDL: superior a 40-60 mg/dL (lo deseable son números mayores).
o Colesterol total: menos de 200 mg/dL (lo deseable son números menores).
o Triglicéridos: 10 - 150 mg/dL (lo deseable son números menores).
o VLDL: 2 - 38 mg/dL.
 ¿Patologías donde se realizan este tipo de pruebas? Se realiza en
personas que tienes riego cardiovascular, pero también para pacientes que
hayan desarrollado diabetes, hipertensión ó cualquier enfermedad causada por
ateroesclerosis. Se recomienza realizarse en pacientes con antecedentes de
dislipidemia
 ¿Existe alguna pauta de medida? De manera habitual no se debe comer
nada en las 12 horas anteriores, ni se realice ejercicio físico. Dependiendo de la
situación en particular se puede solicitar que tampoco se beba agua (líquidos) e
incluso se suspenda la toma de algún medicamento que pudiera afectar a la
toma de la medida.
 ¿Qué factores influyen en la medida? Hay algunos:
o Ayuno: Si bien para determinar el colesterol total, sus diferentes fracciones
y los triglicéridos no es necesario tener ayuno, la ingesta de cualquier tipo
de grasa modifica los valores de triglicéridos y colesterol total, HDL, LDL en
sangre. Por ello, se indica que son necesarias 12 horas de ayuno para poder
determinar el valor real de lípidos.
o Alcohol: Un consumo máximo diario de 20 grs en las mujeres y 30 grs en los
hombres aumenta el colesterol HDL. Un consumo por encima de estos
valores, aumentan los triglicéridos.
o Cigarrillo: El cigarrillo induce un aumento de concentración de triglicéridos y
colesterol LDL, reduciendo el colesterol HDL.
o Café: El café de filtro no parece modificar los valores de lípidos en sangre,
siempre y cuando se respete las 12 horas de ayuno.
o Alimentación: La concentración de colesterol total, colesterol LDL y
triglicéridos se elevan con el consumo de grasas saturadas y se reducen con
el consumo de grasas poliinsaturadas. La ingesta de ácidos grasos
monoinsaturados reducen los niveles de colesterol LDL y triglicéridos,
aumentando la concentración de colesterol HDL.
o Edad: La concentración de colesterol y triglicéridos aumenta con la edad,
con excepción del colesterol HDL.
o Actividad física: El ejercicio aeróbico reduce los niveles de triglicéridos y
colesterol total y aumenta la concentración de colesterol HDL o bueno. Se
debe evitar el ejercicio físico extenuante 24 horas antes del análisis de
sangre, ya que éste puede modificar los valores de lípidos en sangre.
o Embarazo: No se realiza análisis de lípidos en embarazo, excepto en casos de
hipertrigliceridemia familiar.
o Peso corporal: El sobrepeso y la obesidad aumentan la concentración de
triglicéridos, colesterol total y colesterol LDL.
254
Fármacos: Determinados fármacos pueden alterar el perfil lípidico. Si este
es el caso, es necesario interrumpir y modificar el tratamiento
farmacológico.
 ¿Debería complementarse con algún tipo de medida? No se ha
detectado.
 Algunas referencias consultadas: (202) (203) (204) o
255
Anexos:
256
Anexo M: Situaciones médicas de interés para la integración de los
estándares ISO/IEEE 11073 y la norma UNE-EN/ISO 13606
Anexo M . Situaciones médicas de interés
para integración de los estándares ISO/IEEE
11073 y UNE-EN/ISO 13606
En los últimos años en los países desarrollados se ha venido observando un
incremento en la esperanza de vida: nuevos tratamientos farmacológicos,
prestaciones de jubilación que permiten el desarrollo de otras actividades en edades
avanzadas, la mejora de los hábitos alimenticios, etc. han favorecido tal hecho.
Sin embargo, el hecho de vivir más años no significa vivirlos mejor como ya nos
mostró Juan Eugenio Hartzenbusch en la fábula “La vida del hombre”. Y en los
aspectos de salud no andamos demasiado alejados. Si bien es cierto que ciertas
enfermedades son de origen genético y que nada podemos hacer para prevenirlas, sí
que hay una amplia amalgama de enfermedades que, sino podemos prevenir por
completo su aparición, al menos podemos paliar sus secuelas y/o controlar sus
efectos por medio de pequeños actos regulatorios.
Dentro de ese grupo de enfermedades podemos encontrar, entre muchas otras, la
obesidad que es uno de los grandes males de nuestro tiempo. Un estilo de vida más
sedentario, la pérdida de la dieta mediterránea en favor de otros tipos alimentación
{bollería industrial, “fast food”, etc.} han sido los grandes valedores de este cambio.
Y no es sólo una cuestión estética, sino que sus efectos pueden potenciar ciertas
patologías que ya sufrimos ó incluso hacer que aparezcan otras patologías latentes.
Por ejemplo, una persona tras un problema metabólico puede desarrollar un
problema de sobrepeso u obesidad, y ese incremento de peso conllevará un
incremento de la tensión arterial que, dependiendo de la magnitud de ese
incremento, puede derivar en otro problema: hipertensión.
Y este ejemplo, aunque significativo, no es el único. Las relaciones que se
establecen entre determinadas enfermedades son numerosas, llegando sus efectos a
realimentarse. Así la diabetes tipo 2 puede producir un incremento de peso, y ese
incremento de peso puede agravar la misma diabetes.
Durante las próximas paginas se intentará realizar un ejercicio de análisis de todas
estas relaciones con el fin de valorar el riesgo total (la patología principal más todos
esos efectos secundarios) que supone una determinada enfermedad, que constantes
deberían controlarse y que dispositivos debería tener para poder hacerlo.
257
Anexos:
a. Diabetes
 ¿En qué consiste? Es un conjunto de trastornos metabólicos caracterizados por
un aumento de glucosa en el páncreas y en el plasma sanguíneo.
 ¿Existe algún tipo de clasificación por defecto? La diabetes se clasifica
respecto a su origen según la Tabla M-1.
Nombre
Etiología
Causa
Tipo I
De nacimiento
El páncreas produce poca o nada
de insulina
Tipo II
Surge con la edad
Poca cantidad ó se desarrolla
resistencia a la insulina
Gestacional
Aparece en el embarazo
Los cambios hormonales pueden
afectar al páncreas
Pre-Gestacional
Diabética que se queda
embarazada
La del origen de la enfermedad
Tabla M-1. Clasificación de la diabetes
 ¿Qué síntomas presentar? Los síntomas de la enfermedad son bastante
similares (sed constante, aumento de las ganas de orinar, hambre excesiva,
debilidad, somnolencia, nauseas y vómitos, cambios en la visión) pero se
manifiestan a distintas edades:
o La diabetes tipo 1 se manifiesta a edades tempranas. Cómo rasgo
característico suele acompañarse de una pérdida inexplicable de peso.
o La diabetes tipo 2 puede estar latente, sin llegar a manifestarse durante
mucho tiempo. Podemos encontrar hormigueos en manos y pies, picazón en
piel y genitales, piel seca y cortaduras que tardan en cicatrizar.
o La diabetes gestacional se detectará en el embarazo. Actualmente existen
protocolos donde se cataloga el riesgo de diabetes gestacional en función de la
edad y antecedentes familiares. En este caso, también podemos encontrar con
pérdidas inexplicadas de peso:
 Bajo Riesgo. Embarazadas menores de 25 años. Las pruebas se hacen si el
control de peso no es el adecuado.
 Riesgo Moderado. Embarazadas mayores de 25 años, sin ningún otro factor
de riesgo. Las pruebas se realizan en torno a la semana 24.
 Alto Riesgo. Embarazadas de más de 25 años y algún factor de riesgo
(antecedentes familiares de diabetes gestacional, o diabetes de tipo I, algún
parto anterior de bebés de gran tamaño, o incluso un parto en el que el
bebé nació muerto, y una gran acumulación de líquido amniótico). En este
caso, las pruebas se realizan casi inmediatamente.
258
 ¿Grupos de Riesgo? Aquellas personas más personas más proclives a
desarrollar diabetes cumplen uno o varios de estos requisitos:
 Factores genéticos. Si algún familiar la ha padecido.
 Obesidad. En general peso y tamaño de la cintura.
 Ser mayor de 45 años de edad
 Estilo de vida sedentario.
 Alimentación no saludable. En particular un nivel alto de triglicéridos en la
sangre.
 Tabaco y alcohol.
 Raza. Algunas razas/etnias son más propensas.
 Embarazo.
 ¿Qué frecuencia debe tener ese control? El control de la glucemia es algo
que se debe pactar con el médico. Aún así hay una serie instantes clave (ver
apartado L. a) que nos pueden ayudar a acotar el problema y a establecer unas
pautas básicas de control, como se puede ver en la Fig. 1.1-1.
Fig. M-1. Pautas de control en la diabetes
 ¿Qué complicaciones suele presentar? Las principales complicaciones
que se pueden asociar a la diabetes están listadas en la Tabla M-2. Sin
embargo, recientemente se están estableciendo relaciones entre la diabetes y
otro tipo de enfermedades como la apnea del sueño o la obesidad. En cualquier
caso las relaciones entre enfermedades respiratorias son patentes aunque sea en
segundo grado y se explique mediante otras patologías como pueda ser el
sobrepeso.
259
Anexos:
Complicaciones
Descripción
Neuropatía diabética
Los altos niveles de azúcar pueden causar
daño en los nervios
Ulcera plantar
Profunda úlcera neurotrófica de la planta
del pie causada por repetidas lesiones por
una falta de sensibilidad de esta parte
Hiperlipidemia
Enfermedad
cerebrovascular
Retinopatía
Enfermedad arterial
coronaria
Glucomerulopatia
dibética
Exceso de grasa (colesterol y triglicéridos)
en la sangre. Riesgo de enfermedad cardiaca
o un derrame cerebral
Es una interrupción del suministro de
sangre a cualquier parte del cerebro y,
algunas veces, se le denomina "ataque
cerebral" (derrame cerebral)
Deterioro de los vasos sanguíneos que irrigan la
retina que puede tener como resultado una fuga
de fluido o sangre. Se forman nuevos vasos
sanguíneos y prolifera el tejido fibroso en la
retina. La imagen enviada al cerebro se hace
borrosa.
Las arterias que suministran la sangre al
músculo cardíaco se endurecen y se
estrechan por la acumulación de colesterol y
otros materiales. Angina de pecho,
arritmias, insuficiencia cardiaca, infartos..
Alteraciones
morfológicas
renales
de
cualquier tipo producidas por la diabetes. Se
reconocen
alteraciones
glomerulares,
tubulares, intersticiales y vasculares.
Tabla M-2. Complicaciones asociadas a la diabetes.
 ¿Qué medidas fisiológicas se deben monitorizar? Para el correcto control
de la diabetes hay algunas variables fisiológicas que se deberán controlar.
Algunas de las más relevantes las encontramos en la Tabla M-3, en donde se
puede comprobar que parte de esos signos vitales se pueden controlar de manera
domiciliaria.
En la Fig. M-2 se ha intentado realizar un diagrama conceptual que plasme la
relación de la diabetes con el resto de patologías asociadas, y con aquellas
medidas que pueden monitorizarse de forma domiciliaria.
260
Variables
Glucosa en Sangre
Creatinina
Albumina
HbA1c
Tensión arterial
Dispositivo?
Glucómetro
Análisis Sanguíneo
Análisis de orina
Análisis de orina
Tensiómetro
Colesterol
Densidad de la sangre
Peso
Báscula
Complicaciones
Diabetes
Diabetes
Enfermedad cerebrovascular
Enfermedad coronaria
Glucomerulopatia diabética
Hiperlipidemia
Enfermedad
arterial
Coronaria
Enfermedad
arterial
Coronaria
Hiperlipidemia
Enfermedad
arterial
Coronaria
Ulcera plantar
Tabla M-3. Variables a monitorizar en la diabetes.
Fig. M-2. Diagrama conceptual de la diabetes
 ¿Otras recomendaciones? Independientemente del tratamiento farmacológico
y el protocolo de monitorización establecido por el médico (número de veces al
día, horas, intervalos de confianza, etc.) hay una serie de consideraciones que el
propio paciente puede tomar en cuenta para personificar ese protocolo a su
situación diaria:
261
Anexos:
 Seguir una dieta alimentaria.
 Hacer ejercicio físico: Está demostrado que la práctica del ejercicio ayuda a
controlar el nivel de azúcar en los diabéticos del tipo 2; y en el tipo 1 se sabe
que ayuda a prevenir algunas enfermedades (hipertensión, colesterol, entre
otras). Sin embargo se deberán tomar medidas proactivas como modificar la
dosis de insulina si fuera el caso ó ingerir alimentos de acuerdo al ejercicio
que se van a hacer con el fin de evitar la hipoglucemia. Este tipo de acciones
se deberán anotar para comunicarlas al médico encargado del seguimiento.
 Autocontrolarse el azúcar en casa. El diabético deber realizarse
regularmente mediciones del nivel de azúcar. Esto es fundamental para
controlar las temidas subidas (hiperglucemia) y bajadas (hipoglucemia) de
azúcar y para informar a su médico periódicamente. También es importante
que conozca cómo puede enfrentarse a ellas.
 Seguir un tratamiento farmacológico, si es necesario. Va a depender del
tipo de diabetes que padezca. En general, los pacientes de tipo 1 tienen que
inyectarse insulina; los del tipo 2 suelen tomar antidiabéticos orales o,
simplemente, deberán realizar unos cambios en su dieta diaria.
 Llevar unos correctos hábitos de higiene. Además de llevar una vida
ordenada en cuanto a horarios de comidas, sueño, ejercicio, etc., para el
diabético es importante el cuidado de los pies (y de la piel, en general).
 Llevar un control médico. Además del autocontrol, la atención médica es
esencial para un diabético. Normalmente, el médico de familia es el
encargado de hacer el seguimiento de estos enfermos (análisis de sangre,
modificación del tratamiento...); los diabéticos de tipo 1 suelen estar en manos
de endocrinos, más que nada para prevenir las enfermedades derivadas de la
diabetes.  Algunas referencias: (213) (214) (215) (216) b. Hipertensión
 ¿En qué consiste? La hipertensión arterial es el aumento de la presión arterial
de forma crónica. Es una enfermedad asintomática y, si no se detecta y trata,
puede desencadenar complicaciones severas como un infarto de miocardio, una
hemorragia o trombosis cerebral. Las primeras consecuencias de la hipertensión
las sufren las arterias, que se endurecen a medida que soportan la presión
arterial alta de forma continua, se hacen más gruesas y puede verse dificultado
al paso de sangre a su través. Esto se conoce con el nombre de arteriosclerosis.
 ¿Existe algún tipo de clasificación por defecto? Hay varias clasificaciones
de la hipertensión arterial (HTA). De manera generalizada se suele adoptar la
que se muestra en la Tabla M-4. Sin embargo, la tensión arterial (TA) está
compuesta por dos sub-medidas: la TA sistólica y la TA diastólica y una
alteración en los rangos de cualquiera de estas sub-medidas ocasiona diferentes
patologías de índole secundaria como la que se puede ver en la Tabla M-5.
262
TA Sistólica (mm Hg)
TA Diastólica (mm Hg)
Optima
<120
<80
Normal
<130
<85
130 – 139
85 – 89
Normal Alta
Hipertensión
Grado 1
140 – 159
90 – 99
Grado 2
160 – 179
100 – 109
Grado 3
≥ 180
≥110
Tabla M-4. Clasificación primaria de la hipertensión.
Hipertensión Sistólica
Aislada (HSA)
Hipertensión Diastólica
Aislada (HDA)
Hipertensión de Bata
Blanca (HBB)
Hipertensión
enmascarada
pseudo Hipertensión
Hipotensión Ortostática
TA
Sistólica
(mm Hg)
TA
Diastólica
(mm Hg)
Casos
≥ 140
< 90
Aparece con la edad
<130
≥ 90
Adultos Jóvenes
≥ 140
≥ 90
≥ 140
≥ 90
Valores
elevados
Cae 20
Valores
elevados
Cae 10
Sólo en entornos
hospitalarios
Sólo en entornos
domiciliarios
Ancianos, aunque no afecta
a órganos diana
Ancianos al ponerse de pie
Tabla M-5. Clasificación secundaria de la hipertensión
Dada la variabilidad de la tensión arterial, es muy difícil establecer unos
límites claros en los que la tensión arterial puede volverse patológica y ha de
adaptarse a la situación del paciente en cada caso. Así, una tensión de 129/84
en condiciones normales debería considerarse como adecuada, pero si la
paciente se encuentra embarazada ya se considera ligeramente hipertensa.
Además, en algunos casos se distingue entre hipertensión primaria y
secundaria (aquella donde la elevación de la tensión arterial se debe a alguna
otra enfermedad). Las principales fuentes de hipertensión secundaria son:
o Trastornos renales.
o Alteraciones de las glándulas paratiroides.
o Acromegalia, que es cuando la glándula pituitaria produce un exceso de
hormona del crecimiento.
o Tumores en las glándulas suprarrenales o en la pituitaria.
o Reacciones a medicamentos recetados para otros problemas médicos.
o Embarazo.
Caso aparte merecen otras clasificaciones de hipertensión, cuyos efectos se
encuentran localizados en ciertas partes del cuerpo, como la pulmonar, la
renovascular, la portal, las microvasculares, etc.
263
Anexos:
 ¿Qué síntomas presentar? Como ya hemos dicho, la hipertensión ó “muerte
silenciosa” es una dolencia asintomática a pesar de la gravedad de padecerla. En
algunos casos los pacientes hipertensos han podido notar mareos o palpitaciones
en la cabeza o el pecho. Sin un control periódico de este signo vital, las primeras
manifestaciones de hipertensión podrían ser los daños ocasionados por la propia
enfermedad.
presentar algún caso de hipertensión cumplen uno o varios de estos requisitos:
o Antecedentes de hipertensión.
o Raza afroamericana. Los afroamericanos tienen una mayor incidencia de
hipertensión arterial que los blancos, y la enfermedad suele aparecer a menor
edad y ser más grave.
o Es hombre. En las mujeres el riesgo es mayor después de los 55 años.
o Edad (Tener más de 60 años). Los vasos sanguíneos se debilitan con los años
y pierden su elasticidad.
o Altos de estrés. Según algunos estudios, el estrés, la ira, la hostilidad y otras
características de la personalidad contribuyen a la hipertensión, pero los
resultados no han sido siempre uniformes. Los factores emocionales muy
probablemente contribuyan al riesgo de ciertas personas que presentan otros
factores de riesgo de hipertensión.
o Sobrepeso u obesidad.
o Fumador. El cigarrillo daña los vasos sanguíneos.
o Anticonceptivos orales. Las mujeres que fuman y usan anticonceptivos orales
aumentan considerablemente su riesgo.
o Alimentación inadecuada (alta en grasas saturadas, sal, etc.).
o Bebe más de una cantidad moderada de alcohol.
o Estilo de vida sedentario.
o Diabética.
 ¿Qué frecuencia debe tener ese control? Como ocurría en el caso de la
diabetes, el número de tomas ha de consensuarse con el médico de cabecera
aunque parece ampliamente aceptada las recomendaciones de la sociedad
Española de Hipertensión:
“Realizar tres medidas a la mañana (entre las 6 y las 9 de la mañana),
y tres a la tarde (entre las 18 y 21 horas) durante 5 días.
Posteriormente, se hará la media de todas las medidas para saber cuál es la
tensión arterial media, que es la que más se ajustará (teóricamente) a la
realidad.
Una vez hecho el diagnóstico, si el paciente es hipertenso y lo que se
pretende es un control a largo plazo, se suele elegir un día de la
semana, en el que se efectúan 3 medidas a la mañana (antes de tomar
la medicación), y 3 por la tarde, separadas todas ellas unos 3
minutos. Posteriormente, se desechan la primera de la mañana y de la
tarde, porque se asume que pueden estar artefactadas al acabar de colocarse
el aparato, y se calcula la media de las demás mediciones.”
264
 ¿Qué complicaciones suele presentar? Las complicaciones que relacionadas
con esta dolencia se asocian a daños en lo que se determinan órganos diana. Los
más relevantes se pueden observar en la Tabla M-6.
Daño vascular
Daño cardiaco
Daño ocular
Enfermedad renal
La presión causa un aumento del grosor de
los músculos que tapizan las paredes de las
arterias, lo que estrecha estas.
El riesgo de ataque al corazón o un accidente
cerebrovascular aumenta ante la presencia
de un trombo.
La hipertensión obliga al corazón a trabajar
con más intensidad y aumenta de tamaño.
Cuanto mayor es el corazón, menor
capacidad de mantener el flujo sanguíneo
adecuado.
El corazón ha comienza a fallar ante el
esfuerzo. Sin tratamiento, la insuficiencia
cardíaca seguirá empeorando.
En los diabéticos, la hipertensión puede
generar rupturas en los pequeños capilares
de la retina del ojo, ocasionando derrames.
Este problema se denomina «retinopatía» y
puede causar ceguera.
La hipertensión prolongada puede dañar los
riñones si las arterias que los riegan se ven
afectadas.
Tabla M-6. Complicaciones asociadas a la hipertensión.
¿Qué medidas fisiológicas se deben monitorizar? Para el correcto control
de la hipertensión hay algunas variables fisiológicas que se deberán controlar,
entre ellas las listadas en la Tabla M-7. En base a las medidas que se deberían
monitorizar se ha intentado realizar un diagrama conceptual en la Fig. M-3 que
plasme su relación con la hipertensión, así como con el resto de patologías
asociadas
Variables
Tensión arterial
Dispositivo?
Tensiómetro
Colesterol
Peso
Báscula
Complicaciones
Hipertension
Daño cardiaco.
Hiperlipidemia
Enfermedad vascular
Enfermedad arterial Coronaria
Hiperlipidemia
Tabla M-7. Variables a monitorizar en hipertensión
265
Historia Clínica Electrónicay estandarización. Estado del Arte
Fig. M-3. Diagrama conceptual de la hipertensión.
 ¿Otras recomendaciones? Principalmente consiste en modificar el estilo de
vida del paciente para tomar medidas proactivas ante la enfermedad, lo cual es
tremendamente efectivo en personas prehipertensivas:
o Llevar una alimentación baja en grasas y sal.
o Reducir el peso excesivo.
o Comenzar un programa de ejercicio físico regular.
o Aprender a controlar el estrés.
o Dejar de fumar.
o Moderar o suprimir el consumo de alcohol. Recuerde que un consumo
moderado es un promedio de una o dos bebidas por día para los hombres y de
una bebida por día para las mujeres.
o Controlar la apnea obstructiva del sueño (AOS), si la padece. Muchos
pacientes que controlan su AOS también observan pequeñas disminuciones
en la presión arterial.
En casos donde estos consejos no son suficientes, el siguiente paso es el
tratamiento farmacológico:
o Los diuréticos ayudan a eliminar agua y sodio del organismo.
o Los inhibidores de la ECA bloquean la enzima que eleva la presión arterial.
o Otros tipos de medicamentos, como los betabloqueantes, los bloqueantes
cálcicos y otros vasodilatadores, tienen efectos diferentes, pero en general
ayudan a relajar y dilatar los vasos sanguíneos y a reducir la presión dentro
de ellos.
266 Anexo M: Situaciones médicas de interés para la integración de los
c. Sobrepeso
 ¿En qué consiste? Es el estado en el que existe un exceso de peso en relación
con la estatura (entre el 10 y el 20%; si ese exceso sobrepasa el 20% podemos
hablar de obesidad).
 ¿Existe algún tipo de clasificación por defecto? Como se indicó en el punto
L.e la clasificación se realiza en función del IMC. Según la Sociedad Española de
Sobrepeso, la clasificación de la patología acorde a esta variable es la recogida en
la Tabla M-8, que deberá complementarse con la Tabla M-9 donde se tiene
presente la distribución de la grasa en el cuerpo, dato relevante porque en
función de su localización esta poseerá diferentes funciones y metabolismo.
IMC
Puede considerarse
Menos de 16
De 16 a 18,5
De 18,5 a 25
De 25 a 27
De 27 a 30
De 30 a 35
De 35 a 40
De 40 a 50
Más de 50
Desnutrición
Bajo peso
Peso normal
Sobrepeso tipo I
Sobrepeso tipo II
Obesidad tipo I
Obesidad tipo II
Obesidad tipo III (mórbida)
Obesidad tipo IV (extrema)
Tabla M-8. Clasificación de los desordenes del peso.
Valores Límite
Hombres
Mujeres
Circunferencia de la
cintura
> 95 cm
SEEDO
Valores de riesgo
> 102 cm
> 90 cm
Valores de riesgo elevado
> 82 cm
Tabla M-9. Valores de riesgo en función de la distribución de la grasa corporal
 ¿Qué síntomas presenta? Además del consiguiente incremento de peso, se
produce un incremento de la grasa corporal la cual, en función del sexo, tiende a
localizarse sobre o bajo la cintura como se puede observar en la Fig. M-4:
Hombres:
Obesidad
androide
o
abdominal.
Acumulo de grasa por encima
de la cintura. Predisponiente
para enfermedades como:
Hipertensión, enfermedades
cardiovasculares, colelitiasis,
hiperinsulinismo y diabetes
mellitus.
Mujeres:
Obesidad
ginecoide. Se caracteriza por
la acumulación de grasa en el
bajo
vientre
caderas y
muslos.
Fig. M-4 Distribución de la grasa corporal.
267
Anexos:
 ¿Grupos de Riesgo? El riesgo a desarrollar un problema de sobrepeso u
obesidad no solo es debido a una alimentación inadecuada al estilo de vida que el
paciente tenga, más o menos sedentario, sino que en la mayoría de los casos
entra en combinación con algún problema glandular/hormonal. Entre los
factores de riesgo se pueden encontrar los siguientes:
o Alimentación inadecuada.
o Estilo de vida sedentario.
o Embarazo, menopausia, etc.
o Factores genéticos, metabolismo.
o Alteraciones hormonales: hipotiroidismo, la enfermedad de Cushing (afecta a
la hipófisis, demasiada corticotropina), el hipogonadismo, el síndrome de
Stein-Leventhal (también presenta resistencia a la insulina… relación con la
diabetes), la acromegalia (hormona del crecimiento), etc.
o Algunas enfermedades: El ovario poliquístico, el síndrome de Laurence-MoonBield, el síndrome de Carpenter, el síndrome de Summit, el síndrome de
Cohen, el síndrome de Prader-Willi, diabetes o la bulimia.
o Determinados medicamentos producen un significativo aumento de peso como
los glucocorticoides, los antidepresivos tricíclicos y los estrógenos
(anticonceptivos).
o Determinadas enfermedades cardiovasculares o respiratorias.
 ¿Qué frecuencia debe tener ese control? No se pierde peso igual todos los
días. Hay que dar tiempo a que la grasa se vaya consumiendo poco a poco.
Pesarse una vez a la semana es suficiente.
 ¿Qué complicaciones suele presentar? Un exceso de peso puede
provocar múltiples complicaciones “per se”, pero también agravar múltiples
patologías como las recogidas en la Tabla M-10:
Incremento TA
Hipertensión
Esta patología siempre se ha asociado a un mayor
riesgo cardiovascular, en especial con la trombosis
cerebral.
Incremento del
colesterol
Favorece la ateroesclerosis. Favorece efectos como
la trombosis ó infarto de miocardio
Diabetes
Su aparición afecta a órganos tan importantes
como el riñón, la retina, el corazón, o la circulación
sanguínea en general.
Varices
Problemas
respiratorios
Problemas digestivos
268
Producen hormigueos,
trombosar.
dolor
y
se
pueden
Impide que se pueda respirar con normalidad, no
sólo cuando se realiza un gran trabajo, sino
también ante mínimos esfuerzos ( Ej – síndrome
apnea del sueño)
Hernia de hiato, acidez, estreñimiento, reflujo,
mayor frecuencia de piedras en la vesícula y de
acumulo de grasa en el hígado, son los procesos
más habituales.
Artrosis
Problemas de corazón
Cáncer
Alteraciones
Psicológicas
Los huesos no están acostumbrados a soportar
tanto peso y las articulaciones se empiezan a
deteriorar. Puede afectar a la columna, tanto
cervical como lumbar; las caderas, las rodillas y los
pies. Aparecen dolores, mareos, inestabilidad y
hormigueos de manos o pies.
El corazón debe trabajar más duramente y con el
tiempo puede fallar (insuficiencia cardíaca), con
problemas de retención de líquidos y mayor
dificultad respiratoria.
Algunos tipos de cáncer (colon, mama, útero,
ovario o próstata) tienen mayor incidencia entre
las personas obesas que en la población general.
Problemas de baja autoestima, aislamiento social,
ansiedad, depresión, trastornos emocionales y del
comportamiento alimentario (bulimia, anorexia,
etc.)
Tabla M-10. Complicaciones asociadas a un exceso de peso.
del sobrepeso se han detectado algunas variables fisiológicas que se deberían
controlar, las cuales se muestran en la Tabla M-11. Del mismo modo se ha
generado un mapa conceptual que puede verse en la Fig. M-5, donde se relaciona
el sobrepeso con algunas de las medidas que podrían monitorizarse de forma
domiciliaria y algunas de patologías asociadas con un exceso de peso. Otras,
como los efectos de la obesidad y sobre el sistema inmune quedan fuera de este
primer estudio.
Variables
Peso
Dispositivo?
Báscula
Tensión Arterial
Tensiometro
Colesterol
Análisis Sanguineo
Concentración
oxigeno en sangre
de Pulsioximetro
Complicaciones
Obesidad
Hiperlipidemia
Hipertensión
Problemas vasculares
Problemas cardiacos
Ateroesclerosis.
Trombos
Apnea del sueño
Hipertensión pulmonar.
Tabla M-11. Variables a monitorizar en caso de sobrepeso.
269
Anexos:
Fig. M-5. Diagrama conceptual asociado al sobrepeso

¿Otras recomendaciones?
o Consumir alimentos de baja densidad enérgica como verduras y frutas.
o Priorizar el consumo de proteínas de leche, quesos, claras de huevos y carnes
blancas.
o En menor cantidad y sin evitarlas, consumir carnes rojas por la necesidad de
hierro que el organismo requiere.
o Grasas: incorporar la mínima cantidad para cubrir el requerimiento diario.
Utilizar grasas polinsaturadas, omega 3 provenientes de los pescados y
grasas monoinsaturadas provenientes del aceite de oliva.
o Comer poco y 3 o 4 veces por día.
o * Consumir alimentos con bajo cantidad de hidratos de carbono complejos
para tener menos hambre a corto plazo. Estos alimentos pueden ser leche y
yogures, verduras como tomates y hojas verdes, algunas frutas como cereza,
ciruela, pomelo, duraznos y peras.
o La alimentación debe ser con preparaciones de sabores neutros, no
estimulantes del apetito, sencillas y fáciles de cocinar, para poder poner
distancia con la alimentación y separarnos del vínculo adictivo con la misma.
o Consumir de 3 a 4 litros de líquidos diariamente para hidratarnos, reponer el
líquido perdido por orina y saciar el apetito.
o Realizar actividad física adaptada, por lo menos tres veces por semana.

Algunas referencias consultadas: (221) (222) (223) (224)
270
d. Problemas Respiratorios
Dentro de las múltiples etiologías a las que podemos asociar problemas
respiratorios, aunque intentemos conservar una cierta generalidad en las medidas,
nos centraremos en algunas que consideraremos de principal importancia, bien sea
por su índice de penetración en la sociedad bien sea por la gravedad en el estado de
salud de la persona afectada. Entre los más representativas encontraremos
Enfermedad Pulmonar Obstructiva Crónica (EPOC).
 ¿En qué consiste? EPOC ó Enfermedad Pulmonar Obstructiva Crónica,
además de enfermedad prevenible y tratable, presenta una repercusión
sistémica de evolución progresiva, que se caracteriza por una obstrucción crónica
y poco reversible al flujo aéreo, la cual se asocia a una reacción inflamatoria
anómala de la vía aérea frente a partículas nocivas o gases. Normalmente esta
asociada tanto a enfisemas como a bronquitis crónicas.
 ¿Existe algún tipo de clasificación por defecto? La gravedad de la
enfermedad se clasifica en función de
o EPOC leve: FEV1 ≥80%
o EPOC moderada: FEV1 ≥50% y <80%.
o EPOC grave: FEV1 ≥30% y <50%.
o EPOC muy grave: FEV1 <30% o <50% con insuficiencia respiratoria crónica
(pO2 <60 mmHg con o sin hipercapnia a nivel del mar).
 ¿Qué síntomas presentar? Los síntomas no suelen presentarse en los estadios
iniciales de la enfermedad, aunque los principales síntomas son los siguientes:
o Tos crónica: En general, productiva e inicialmente por las mañanas pero
posteriormente se presenta durante todo el día. No tiene relación con el grado
de obstrucción al flujo aéreo.
o Expectoración: Como consecuencia de un aumento de la hipersecreción de
moco por las glándulas pulmonares se produce un incremento de esta. El
volumen diario de la expectoración es, normalmente, menor de 60 ml/día y de
característica mucoide.
o Disnea (dificultad para respirar, falta de aire): Se desarrolla de forma
progresiva a lo largo de la evolución de la enfermedad hasta limitar las
actividades de la vida diaria.
o Disminución a la tolerancia al ejercicio.
o Infecciones respiratorias recurrente.
 ¿Grupos de Riesgo? La causa principal de desarrollar EPOC es el tabaquismo.
Aunque existen otro tipo de elementos que te pueden llevar a condicionar la
enfermedad:
o Exposición a ciertos gases o emanaciones en el sitio de trabajo.
o Exposición a cantidades considerables de contaminación o humo de cigarrillo.
o Uso frecuente de gas para cocinar sin la ventilación apropiada.
o Alergias.
o Alcoholismo.
o Factores genéticos: Existe cierta predisposición genética a desarrollar la
enfermedad, la cual es mayor en ciertas razas.
271 Anexos:
 ¿Qué frecuencia debe tener ese control? La frecuencia con la que se deben
realizar el seguimiento de la enfermedad depende del grado de su avance. De
hecho los controles rutinarios que deben realizarse todos los enfermos de EPOC
cuya situación se considera estable se realizan cada 3 meses/6 meses/ 1 año y
comprenden pruebas tan diversas como espirometrías, gasometrías y
radiografías de torax si el facultativo lo considera adecuado. Sin embargo hay
ciertos controles que se pueden realizar periódicamente como lo son el peso cuyo
exceso puede empeorar el problema respiratorio ó oximetrías si se decide tratar
la EPOC mediante oxigenoterapia en el hogar. Y existen ciertos criterios que
permiten discriminar que pacientes pueden ser atendidos de manera
domiciliaria y quién de ellos han de ser atendidos de forma hospitalaria, entre
ellos la frecuencia respiratoria, la frecuencia cardiaca y algunas de claro corte
subjetivo como el grado de disnea y la confusión del paciente.
También es necesario controlar el FEV1 ante episodios de exacerbación.
 ¿Qué complicaciones suele presentar? Un diagrama que puede indicar la
evolución de la enfermedad es el siguiente es el representado en la Fig. M-6.
Fig. M-6. Complicaciones asociadas a la EPOC.
272
Todo ello nos puede llevar a dos grandes riesgos:
o
o
o
o
o
La insuficiencia respiratoria crónica se produce por una constante falta
de oxígeno en la sangre (hipoxemia), debido a la destrucción alveolar como
consecuencia del enfisema, lo que altera el intercambio de gases. (Esa
dificultad en el intercambio de gases es lo que produce hipertensión
pulmonar) Suele aparecer de forma insidiosa y puede agravarse durante el
sueño y provocar un deterioro de las funciones superiores. Para compensar
la hipoxemia es necesario el suministro permanente de oxígeno, o al menos
durante 16 horas al día, en el propio domicilio del paciente.
El cor pulmonale se debe al efecto de la hipoxemia sobre la circulación
pulmonar (hipertensión pulmonar). La EPOC obliga al corazón a trabajar
más de lo normal, especialmente al ventrículo derecho. El estrechamiento de
los vasos sanguíneos del pulmón junto con la destrucción de los alvéolos y
sus capilares hace que el corazón tenga que hacer más fuerza para
transportar la sangre. Este esfuerzo le hace aumentar de tamaño y altera el
ritmo cardiaco. Cualquier agudización de la enfermedad o un simple
resfriado hace que el corazón no pueda bombear la suficiente sangre, por lo
que también se afectarán otros órganos como el hígado o los riñones,
aparecerán edemas en las extremidades inferiores.
La menor resistencia al ejercicio puede derivar en un incremento / exceso de
peso, que como ya se vio puede agravar los problemas respiratorios.
La falta de oxígeno también puede afectar al cerebro y al sistema
nervioso en su conjunto, produciendo dolor de cabeza, insomnio,
irritabilidad, reducción de la capacidad mental…
Para compensar la falta de oxígeno, el organismo fabrica más glóbulos rojos
(policitemia secundaria) para facilitar su transporte. Aunque esta estrategia
puede ayudar, en parte también es la causa de que la sangre sea más
espesa y se obstruyan los pequeños vasos sanguíneos, lo que a su vez causa
nuevos problemas que van complicando más las cosas.
de la EPOC hay algunas variables fisiológicas que se deberán controlar y se han
reunido en la Tabla M-12 Cómo podemos ver hay varios factores que se pueden
controlar de manera domiciliaria. En la Fig. M-7 se pretende reflejar las
relaciones entre las distintas patologías y los efectos principales que conviene
vigilar.
Variables
FEV1
Saturación de Oxigeno
en sangre
Frecuencia cardiaca
Peso (IMC)
Gasometría
(presión
de O2, CO2 y PH)
Dispositivo?
Báscula
Pulsioximetro
Complicaciones
EPOC
Análisis Sanguineo
Bascula
Complicaciones cardiacas
Sobrepeso
EPOC
Análisis sanguineo
Problemas
(trombos)
vasculares
Tabla M-12. Variables a monitorizar en la EPOC
273
Anexos:
Fig. M-7. Diagrama conceptual asociado a la EPOC
 ¿Otras recomendaciones?Entre las medidas recomendadas para detener el
avance / paliar los síntomas se encuentran las siguientes:
o Dejar el tabaco.
o Alimentación equilibrada.
 Algunas referencias consultadas: (225)(226) (227)
Asma
 ¿En qué consiste? El asma es una enfermedad que se caracteriza por producir
una irritación y obstrucción de los bronquios, pero a diferencia de la EPOC fa
inflamación de los bronquios es reversible.
 ¿Existe algún tipo de clasificación por defecto? La clasificación encontrada
con respecto a esta patología son un tanto difusas y siempre se deberá clasificar
al paciente en la más restrictiva. Hay que tener en cuenta que es una
enfermedad caracterizada por alternar periodos de crisis con calma:
o Asma leve intermitente: menos de dos episodios de síntomas leves por
semana, asintomático entre los episodios de crisis, exacerbaciones leves y de
corta duración, menos de dos episodios de síntomas nocturnos por mes, no hay
alteración del crecimiento en los niños. Estudios de función pulmonar: VEF1
> 80%, variabilidad del flujo pico (VFP) < 20%.
274
o Asma leve persistente: hasta dos episodios de síntomas por semana,
exacerbaciones que pueden o no interferir con la actividad física, menos de
dos episodios de síntomas nocturnos por mes, no hay alteración del
crecimiento en los niños. Estudios de función pulmonar: VEF1 > 80%, VFP
entre el 20 y el 30%.
o Asma moderada: síntomas diarios, uso diario de agonistas beta dos
adrenérgicos de acción corta, limitación de la actividad cotidiana durante las
exacerbaciones, más de dos exacerbaciones por semana, más de un episodio
de síntomas nocturnos por semana, no hay alteración del crecimiento en los
niños. Estudios de función pulmonar: VEF1 entre el 60 y el 80%, VFP > 30%.
o Asma severa: síntomas continuos, actividad física y cotidiana limitada,
exacerbaciones muy frecuentes, síntomas nocturnos muy frecuentes, puede
haber alteración del crecimiento en los niños. Estudios de función pulmonar:
VEF < 60% VFP > 30%.
 ¿Qué síntomas presentar? Durante las crisis asmáticas la mucosa bronquial
que recubre los conductos respiratorios se inflama y se produce un moco espeso
que obstruye los conductos de las vías aéreas. Como consecuencia, los músculos
que rodean estos conductos se contraen y estrechan disminuyendo su diámetro,
impiden el paso del aire y complican la respiración. Las características básicas
de la enfermedad son las siguientes:
o Inflamación: Aumenta la sensibilidad bronquial y la obstrucción. En
ocasiones su origen es alérgico. Produce un incremento de las secreciones y la
contracción de la musculatura bronquial.
o Aumento de la sensibilidad bronquial: Tras la exposición a diversos
estímulos (humos, gases, olores, aire frío o ejercicio), los bronquios de los
asmáticos se contraen produciendo el estrechamiento de la vía aérea.
o Obstrucción bronquial: Es variable y reversible de manera espontánea o
con tratamiento. Durante las crisis el aire circula con dificultad produciendo
pitidos y sensación de fatiga o ahogo (disnea, aunque no siempre aparece).
En el momento en el que la crisis se resuelve el aire puede moverse
normalmente por los bronquios y desaparecen los síntomas.
desarrollar un proceso asmatico cumplen uno o varios de estos requisitos:
o Suele aparecer en personas menores a 40 años.
o Factores genéticos: antecedentes familiares de alergias y asma.
o Parece haber una cierta tendencia a desarrollarse más comúnmente en
varones que en mujeres antes de los 14 años.
o El padecer algún tipo de alergia.
o Infecciones de vías respiratorias. Las infecciones virales recurrentes aumentan
el riesgo de tener sibilancias, broncoespasmo y asma.
o Contaminación ambiental. El ozono, dióxido de nitrógeno, óxidos de sulfuro y
las partículas suspendidas pueden exacerbar el asma.
o Tabaquismo. Humo del cigarrillo.
 ¿Qué frecuencia debe tener ese control? El tratamiento que debe seguir
una persona asmática debería revisarse cada 3 ó 6 meses. Del mismo modo, hay
determinado tipo de crisis (las menos graves) que pueden tratarse de manera
domiciliaria.
275
Anexos:
 ¿Qué complicaciones suele presentar? El asma suele aparecer por periodos
de crisis y es en esos momentos donde las complicaciones aparecen.
 ¿Qué medidas fisiológicas se deben monitorizar? La medición del Flujo
Respiratorio Medio es útil a la hora de establecer un diagnóstico y realizar un
seguimiento de pacientes asmáticos.
 ¿Otras recomendaciones? Evitar en la medida aquellos factores que suelen
desencadenar un ataque asmático: alérgenos, estrés emocional, etc.
 Referencias consultadas: (228) (229) (230)
e. Sistema Inmune deprimido
 ¿En qué consiste? De un modo genérico consideraremos aquellos casos en los
que nuestro organismo no es capaz de responder ante diferentes agresiones de
agentes externos: virus, bacterias, etc. Entre los casos más notables podemos
destacar: personas que van a sufrir un trasplante, enfermos de VIH, cáncer,
leucemia, depresión, etc.
 ¿Existe algún tipo de clasificación por defecto? No podemos establecer
ninguna clasificación porque no nos referimos a una enfermedad en concreto,
aunque se podrían establecer algún tipo de baremación en función de la
gravedad de la enfermedad y su prolongación en el tiempo. Así no es lo mismo
estar hablando de un transplantado, donde la inmunosupresión se produce de
manera inducida y va a tener una duración determinada aproximadamente, que
de un paciente seropositivo donde la situación se va a prolongar durante toda la
vida del paciente.
 ¿Qué síntomas presentar? Los síntomas varían de enfermedad a enfermedad,
aunque se pueden identificar una serie de rasgos comunes:
o Infecciones persistentes o recurrentes.
o Infección severa por microorganismos que usualmente no producen infección
grave.
o Respuesta desfavorable al tratamiento.
o Recuperación lenta o incompleta de una enfermedad.
o Etc.
 ¿Grupos de Riesgo? No hay un grupo especifico de riesgo, salvo en el caso de
enfermedades de inmunodeficiencia congénita donde los factores genéticos son
clave.
 ¿Qué frecuencia debe tener ese control? Los chequeos ante este tipo de
patologías deberían ser constantes, y la frecuencia deberá ser establecida por un
profesional sanitario.
 ¿Qué complicaciones suele presentar? Las complicaciones también
dependen de la patología subyacente, pero debido a esa debilidad en el sistema
inmune crece la probabilidad de padecer un proceso infeccioso por las múltiples
amenazas que sufre nuestro organismo, lo que además contribuye a ralentizar el
proceso de curación.
276
 ¿Qué medidas fisiológicas se deben monitorizar? No es fácil determinar un
conjunto de enfermedades que controlar para un conjunto tan difuso de
enfermedades, aunque como primera aproximación podríamos pensar en:
o Recuento leucocitario. Salvo contadas excepciones todos los sistemas son
funcionales en mayor o menor medida. Mediante un recuento leucocitario
podremos detectar una infección o una leucemia. También se usa para
monitorizar la respuesta del organismo a distintos tratamientos y para
monitorizar la funcionalidad de la médula ósea. Normalmente se determina
mediante un hemograma (análisis sanguíneo).
o Control de la temperatura corporal. Buscamos la aparición de fiebre como
indicativo de que hay un proceso infeccioso en curso.
En base a estas consideraciones se puede realizar un diagrama conceptual en
similar a ls anteriores, que puede verse en la Fig. M-8
Fig. M-8. Diagrama conceptual de sistema deprimido.
 ¿Otras recomendaciones? No exponerse a focos de infección o personas que
puedan transmitir una enfermedad.
 Algunas referencias consultadas: (231) (232)
277
f. Personas con movilidad reducida.
 ¿En qué consiste? La movilidad es el grado de capacidad motriz que posee una
persona. Debido a determinadas enfermedades degenerativas, accidentes ó
simplemente el transcurso natural del tiempo nuestra movilidad puede verse
mermada y en consecuencia determinadas patologías asociadas pueden
agravarse.
 ¿Existe algún tipo de clasificación por defecto? Es muy difícil establecer
algún tipo de clasificación, sobre todo por las múltiples causas que hayan podido
desembocar en esta situación. Si nos basamos en la clasificación que establece la
ley de Dependencia, podemos establecer 3 niveles:
o Grado I. Dependencia moderada. Cuando la persona necesita ayuda para
realizar varias actividades básicas de la vida diaria, al menos una vez al día.
o Grado II. Dependencia severa: Cuando la persona necesita ayuda para
realizar varias actividades básicas de la vida diaria dos o tres veces al día,
pero no requiere el apoyo permanente de un cuidador.
o Grado III. Gran dependencia. Cuando la persona necesita ayuda para
realizar varias actividades básicas de la vida diaria varias veces al día, y
necesita el apoyo indispensable y continuo de otra persona.
 ¿Qué síntomas presentar? Disminución de las capacidades motrices
 ¿Grupos de Riesgo? Entre las personas que podemos clasificar en este grupo
podemos encontrar entre otros:
o Ancianos.
o Personas con patología articular: artritis, ciáticas, osteoporosis, etc.
o Ausencia de elementos estructurales integradores ó cualquier otra condición
que favorezca el aislamiento social (vivir en un 5 sin ascensor)
o Personas con patologías respiratorias graves.
 ¿Qué frecuencia debe tener ese control? La que determine un médico en
función de la criticidad de la medida y lo voluble que esta sea.
 ¿Qué complicaciones suele presentar? Hay varias complicaciones que se
pueden hacer patentes en este tipo de enfermos:
o Riesgo de sobrepeso. Al tener limitada su movilidad, es menos probable que
se ejerciten y aparezca una cierta tendencia a ganar peso. Y como ya se vio,
ese incremento de peso tiene cierta influencia en el desarrollo de otras
enfermedades: diabetes, hipertensión, etc.
o Daños cutáneos (escaras). El permanecer mucho tiempo en la misma posición
hace que aparezcan llagas o úlceras en la piel.
o Atrofia de los músculos. Músculos que no se ejercitan se atrofian. Por lo tanto
la situación de movilidad reducida va a acentuarse con el tiempo.
o Dolor crónico. Además de otro tipo de causas, la movilidad reducida provoca
un deterioro de las articulaciones.
o Incremento de las infecciones. El sistema inmune acaba degenerando.
278 Anexo M: Situaciones médicas de interés para la integración de los
 ¿Qué medidas fisiológicas se deben monitorizar? Para un control
genérico a personas de movilidad reducida se debería monitorizar, entre otros,
los parámetros recogidos en la Tabla M-13 . En función de esos parámetros se
puede realizar un diagama conceptual como el mostrado en la Fig. M-9.
Variables
Dispositivo?
Complicaciones
Peso
Báscula
Obesidad
Tensión Arterial
Tensiometro
Hipertensión
Problemas vasculares
Problemas cardiacos
Glucosa
glucometro
Apnea del sueño
Hipertensión pulmonar.
Tabla M-13. Variables a monitorizar en casos de movilidad reducida.
Fig. M-9. Diagrama conceptual para la movilidad reducida.
 ¿Otras recomendaciones? La principal recomendación sería intentar
mantener el mayor grado de movilidad posible. También es necesario actuar
proactivamente para evitar problemas relacionados, como el sobrepeso.
 Algunas referencias consultadas:(233) (234)
279
Anexos:
A la fecha de realización de esta TFM quedan pendientes la redacción de fichas de
enfermedades coronarias, renales y de embarazo, esta última no por enfermedad
sino por situación en la que se deberá tener un especial cuidado.
280

Integración de datos ISO/IEEE11073 provenientes de dispositivos

Transcripción

Documentos relacionados

ESTR. COLINEAL ISOSTATICA.- Hallar el desplazamiento del punto

GIANFRANCESCO MAINERI

Cajas Metálicas Octagonales 4

GUÍA RÁPIDA DE NUEVA VERSIÓN DE GESTIÓN EDUCATIVA