PDF

UNIVERSroAD POLITCNICA DE MADRID
ESCUELA TCNICA SUPERIOR DE INGENIEROS DE

TELECOMUNICACIN
Modelo de Historia Clnica Electrnica

para Teleconsulta Mdica
TESIS DOCTORAL
Carlos Hernndez Salvador

Ingeniero de Telecomunicacin
Madrid, 2004
Departamento de Tecnologa Fotnica

Grupo de Bioingeniera y Telemedicina
E.T.S.I. de Telecomunicacin
UNIVERSIDAD POLITCNICA DE MADRID
Modelo de Historia Clnica Electrnica

para Teleconsulta Mdica
TESIS DOCTORAL
Autor: Carlos Hernndez Salvador

Ingeniero de Telecomunicacin
Director: Francisco del Pozo Guerrero

Doctor Ingeniero de Telecomunicacin
Madrid, 2004
Tribunal nombrado por el Magnfico y Excelentsimo Sr. Rector de la Universidad

Politcnica de Madrid, el da
de 2004.
Presidente:
Vocales:
Secretario:
Suplentes:
Realizado el acto de defensa y lectura de la Tesis el da

en Madrid, acuerda otorgarle la calificacin de
Los Vocales
El Presidente
El Secretario
Agradecimientos
En primer lugar quiero dar las gracias a mi Director de Tesis, Francisco del Pozo Guerrero, por tres
razones, vlidas todas ellas para que este trabajo de tesis haya visto su final: su direccin del trabajo,
las discusiones que ha dado lugar la elaboracin y refinamiento del mismo, y su insistencia en
proseguir antes, durante y despus de cualquier tropiezo.
En segundo lugar quiero agradecer a Adolfo Muoz Carrero y Victor Arroyo Tous, del Laboratorio
de Bioingeniera y Telemedicina del Hospital Universitario Puerta de Hierro por su ayuda en varias
fases del trabajo, en especial en la edicin de arquetipos y mensajes respectivamente.
En tercer lugar, quiero agradecer la ayuda recibida, sus rpidas contestaciones a preguntas, y la
posibilidad de disponer de documentos del Grupo de Trabajo EHRCom en fases muy iniciales de
elaboracin, a David Lloyd del Centre for Health Informatics & Multiprofessional Education University College of London (CHIME-UCL), y a Thomas Beale de operiEHR Foundation y Ocean
Informatics Pty Ltd.
En cuarto lugar, a Miguel ngel Gonzlez de Mingo por toda una vida de compaerismo y amistad.
Tambin quiero agradecer al resto de los miembros del Laboratorio de Bioingeniera y Telemedicina:
Mario Pascual Carrasco, Juan Fragua Mndez, Pilar Garca S agredo y Laura Otero Garca, por la
ayuda recibida siempre que la he necesitado, y han sido muchas, muchas, muchas veces.
Mi agradecimiento a Ignacio Fernndez Lozano, Jefe de la Unidad de Arritmias del Servicio de
Cardiologa del Hospital Universitario Puerta de Hierro, y a Jos Mara Fernndez Villanueva
Tcnico de la Unidad, por su trabajo desinteresado y la aportacin de su experiencia clnica que ha
permitido especificar arquetipos incluidos en el trabajo.
Tambin quiero agradecer a Jos Luis Castillo Olivares, Jefe del Servicio de Ciruga Experimental
del Hospital Universitario Puerta de Hierro, su ayuda en mis inicios profesionales y posteriormente
su amistad y colaboracin siempre que la solicit; as como mi recuerdo a tantas personas de ese
servicio con las que he trabajado.
Mi agradecimiento a Valentn Cuervas Mons, Jefe del Servicio de Medicina Interna del Hospital
Universitario Puerta de Hierro, y Decano de la Facultad de Medicina de la Universidad Autnoma de
Madrid, por su amistad, consejos y ayuda recibida.
Gracias tambin a Juan Caada Vicinay, amigo, ingeniero, catedrtico, pero sobre todo hombre
culto, que en conversacin sobre el tema de este trabajo me hizo ver el paralehsmo entre lo que
supone en nuestro campo la aplicacin del doble modelo y lo que supusieron en su tiempo las
aportaciones de Guillermo de Occam (1285-1349), precursor del empirismo ingls.
Finalmente quiero mostrar mi mas profundo agredecimiento a mi mujer Pilar, hermanos y familia.
ndice
ndice
Captulo 1. Introduccin
1. Introduccin
1.1 Teleconsulta entre profesionales sanitarios
1.1.1 Aspectos estructurales de la teleconsulta
1.1.2 Aspectos legales y de seguridad de la teleconsulta
1.1.3 Tipos de teleconsulta
1.1.3.1 Teleconsulta a un especialista
1.1.3.2 Teleconsulta en trabajo cooperativo
1.1.3.3 Teleconsulta en telepresencia
1.1.3.4 Sesiones clnicas distribuidas
1.2 Descripcin del problema. Integracin de la teleconsulta en el proceso asistencial
1.2.1 Soporte a la colaboracin en equipos asistenciales
1.2.2 iâricin de un nuevo escenario
1.3 Descripcin del planteamiento del trabajo
10
1.4 Descripcin del documento
12
Captulo 2. Hiptesis y Objetivos

2. Hiptesis y Objetivos
15
2.1 Hiptesis departida
15
2.2 Objetivos del trabajo
16
2.2.1 Objetivo primario
16
2.2.2 Objetivos especficos
17
Captulo 3. Situacin actual de la normalizacin de la historia cKnica

electrnica
3. Situacin actual de la normalizacin en HCE
19
3.1 Dominio de la informacin clnica
20
3.2 Propuesta de desarrollo de estndares
22
3.2.1 Requerimientos de usuario
23
3.2.2 Paradigmas de Diseo
24
3.2.2.1 Separacin de responsabilidades
24
3.2.2.2 Separacin de puntos de vista
25
3.2.2.3 Separacin Conocimiento / Informacin
26
ndice
3.2.3 Nueva metodologa de desarrollo
28
3.2.3.1 Terminologa en la HCE
28
3.2.3.2 Modelo de Referencia
29
3.2.3.3 Modelo de Conocimiento
30
3.2.3.4 Variabilidad en ios conceptos
31
3.2.3.5 Arquetipos
32
3.2.3.6 Propuesta con doble modelo
33
3.2.4 Representacin del conocimiento del dominio
34
3.2.4.1 Anlisis ontolgico
35
3.2.4.2 Anlisis del contexto
36
3.2.4.3 Propuesta sobre Arquetipos y Tompiates
39
3.2.4.3.1 Consideraciones semnticas
40
3.2.4.3.2 Consideraciones de usuario
41
3.2.4.3.3 Tmplales
42
3.2.4.4 Propuesta de doble modelo + representacin controlada
43
3.3 Modelo Universal del dominio
44
3.3.1 CEN/TC251AVG1, WG2
45
3.3.2 HL7RIM
46
3.3.3 openEHR
47
3.3.4 OMG-HDTF
48
Captulo 4. Material y Mtodos

4.
Material y Mtodos
4.1
Material. Modelos de referencia
4.1.1
Modelo de referencia EHR_Extract (prENV13606:2003)
51
51
51
4.1.1.1
Resumen
52
4.1.1.2
Clases y relaciones relevantes
56
4.1.1.2.1
Clase EHR_EXTRACT
56
4.1.1.2.2
Clase RECORD_COMPONENT
57
4.1.1.2.3
Clase LINK
57
4.1.1.2.4
Clase VERSIN
57
4.1.1.2.5
Clase FOLDER
58
4.1.1.2.6
Clase AUDITJNFO
58
4.1.1.2.7
Clase ATTESTATIONJNFO
59
4.1.1.2.8
Clase COMPOSmON
59
4.1.1.2.9
ClaseCONTENT
60
4.1.1.2.10
Clase SECTION
60
ndice
4.1.1.2.11
Clase ENTRY
61
4.1.1.2.12
Cl&selTEM
61
4.1.1.2.13
Clase CLUSTER
62
4.1.1.2.14
Clase ELEMENT
62
4.1.2
Modelo de referencia HL7 RIM (subconjunto para GPICs)
4.1.2.1
Entidad
63
4.1.2.2
Rol
64
4.1.2.3
Participacin
64
4.1.2.4
Actividad
65
4.2
Material. Conceptos del dominio
4.2.1
Componentes de informacin de propsito general (GPIC)
4.2.1.1 Descripcin de los GPICs

4.2.1.1.1
Reglas de actuacin
66
66
66
67
4.2.1.1 GPICs No-Clnicos
67
4.2.1.2 GPICs Clnicos
68
4.2.2
Sistema de conceptos en asistencia continuada
70
4.2.2.1 Actores
70
4.2.2.2 Temas de salud y su gestin
71
4.2.2.3 Situaciones
72
4.2.2.4 Actividades
73
4.2.2.5 Mandatos (Responsabilidad)
74
4.2.2.6 Informacin
4.3
62
Material. Lenguajes de definicin de arquetipos
4.3.1
XML. Definicin de los arquetipos hasta la actualidad
.76
77
77
4.3.1.1
Arquetipos tipo Transaccin
77
4.3.1.2
Arquetipos tipo Organizativo
78
4.3.1.3
Arquetipos tipo Contenido
78
4.3.1.4
Elementos adicionales
79
4.3.2
4.3.2.1
Introduccin de im lenguaje especfico

dADL- Lenguaje de definicin de datos
80
81
4.3.2.L1
Estructura de dADL
82
4.3.2.1.2
Tipos bsicos en dADL, preguntas y caminos
82
4.3.2.2
cADL- Lenguaje de definicin de restricciones
83
4.3.2.2.1
Estructura
84
4.3.2.2.2
Restricciones sobre tipos bsicos
87
4.3.2.3
ADL-Lenguaje de Definicin de Arquetipos
87
4.3.2.3.1
Secciones de cabecera
88
4.3.2.3.2
Seccin Definicin
88
iii
ndice
4.3.2.3.3
Seccin Ontologa
88
4.3.2.3.4
Relaciones entre arquetipos
89
Otros posibles lenguajes a utilizar
91
4.3.3
4.4
Metodologa
92
3.4.1
Mtodos y herramientas para construccin de mensajes
92
4.4.2
Mtodos y herramientas para construccin de arquetipos
94
4.4.2.1
Principios de los arquetipos
95
4.4.2.2
Niveles de acuerdo
96
4.4.3
Proceso de edicin en ADL
97
4.4.4
Proceso de anlisis de ADL
97
4.4.5
Herramienta de 'debug' ADL
99
Captulo 5. Integracin de la teleconsulta en la actividad asistencial

5.
Integracin de la teleconsulta en la actividad asistencial
101
5.1
Aspectos bsicos del diseo de integracin
101
5.2
Los mensajes en la integracin
104
5.2.1
Tipos de mensajes utilizados
104
5.2.2
Ejemplos de uso de mensajes peticin/informe servicio
105
5.2.2.1
Escenarios de peticin de servicio..
5.2.2.1.1
5.2.2.2
Escenarios de informe sobre servicio
5.2.2.2.1
5.2.3
Escenarios de peticin con requerimientos especficos
Escenarios de informe con requerimientos especficos
Otros aspectos relevantes
105
106
107
107
108
5.2.3.1
Tipos de datos en im informe
108
5.2.3.2
Tipos de sujeto de prueba
109
5.2.3.3
Tipos departes implicadas
109
5.2.3.4
Contenido del mensaje
110
5.3
Los arquetipos en la integracin
111
5.3.1
Arquetipos basados en GPICs
111
5.3.2
Arquetipos basados en Extract
114
Captulo 6. Resultados
6.
Resultados
6.1
117
Especificacin del mensaje de peticin de teleconsulta
6.1.1
6.1.1.1
Descripcin general del mensaje de peticin de teleconsulta

TransmisinMensaje
6.1.1.1.1
MensajeRelacionado
117
118
118
120
iv
ndice
6.1.1.2
PeticinDeServicioAsistencial (GPICJD = 3.054) [A]
121
6.1.1.2.1
ReceptorServicioAsistencial (GPICJD = 2.031) [P]
122
6.1.1.2.2
SujetoDePrueba (GPICJD = 2.032) [P]
127
6.1.1.2.3
ParteSanitariaParticipante (GPIC_ID = 2.053) [P]
128
6.1.1.2.4
PeticinDeServicioRelacionada (GPICJD = 3.055) [AR]
132
6.1.1.2.5
ObjetoAnalizableUsado (GPICJD = 3.002) [P]
132
6.1.1.2.6
ProvisinServicioAsistencial (GPICJD = 3.060) [AR]
134
6.1.1.2.7
InformacinClnicaRelacionada (GPICJD = 3.022) [AR]
137
6.1.1.2.8
InformeSobreServicioRelacionado (GPICJD = 3.057) [AR]
141
6.1.1.2.9
EncuentroRelacionado (GPICJD = 3.059) [AR]
142
6.1.1.2.10
TransporteSujetoVivoRelacionado (GPIC_ID = 2.067) [AR]
143
6.1.2
Modelo de informacin del mensaj e (MIM) de peticin de teleconsulta
144
6.1.3
Descripcin jerrquica del mensaje (DJM) de peticin de teleconsulta
153
6.2
Especificacin del mensaje de informe sobre teleconsulta
6.2.1
Descripcin general del mensaje de informe sobre teleconsulta
160
160
6.2.1.1
TransmisinMensaje
160
6.2.1.2
InformeSobreServicioAsistencial (GPICJD = 3.056) [A]
160
6.2.1.2.1
ReceptorServicioAsistencial (GPIC_ID = 2.031) [P]
161
6.2.1.2.2
SujetoDePrueba (GPICJD = 2.032) [P]
162
6.2.1.2.3
ParteSanitariaParticipante (GPICJD = 2.053) [P]
163
6.2.1.2.4
164
6.2.1.2.5
PeticindeServicioRelacionada (GPICJD = 3.055) [AR]
164
6.2.1.2.6
EncuentroRelacionado (GPIC_ID = 3.059) [AR]
165
6.2.1.2.7
ProvisinServicioAsistencial (GPICJD = 3.060) [AR]
166
6.2.1.2.8
InformacinClnicaRelacionada (GPIC_ID = 3.022) [AR]
167
6.2.2
Modelo de informacin del mensaje (MIM) de informe sobre teleconsulta
170
6.2.3
Descripcin jerrquica del mensaje (DJM) de informe sobre teleconsulta
176
6.3
Arquetipo peticin de teleconsulta
180
6.4
Arquetipo informe sobre teleconsulta
183
6.5
Arquetipo informe estudio electrofsiolgico
186
Captulo 7. Conclusiones y Trabajo futuro

7.
Conclusiones
7.1
Trabajo futuro
207
209
ndice
Captulo 8. Bibliografa
8. Bibliografa
213
Captulo 9. Anexos
Anexo 1. GPICs No-CUnicos
225
Anexo 2. GPICs Clnicos
226
Anexo 3. Clases de Entidades
227
Anexo 4. Cdigo Determinador de Entidades
228
Anexo 5. Clases de Roles
228
Anexo 6. Tipos de Participacin
232
Anexo 7. Estado de la Participacin
234
Anexo 8. Modo de Participacin
234
Anexo 9. Control Contexto de Participacin
235
Anexo 10. Clases de Actividad
235
Anexo 11. Cdigo Mood de Actividad
239
Anexo 12. Estado de Actividad
240
Anexo 13. Tipos de Relacin entre Actividades
240
Anexo 14. Control Contexto de Relacin entre Actividades
243
VI
ndice
Lista de Tablas
Tabla 3.1 Relacin entre instancias de los modelos de refrnela y conocimiento
32
Tabla 2.2 Analoga con el lenguaje
33
Tabla 3.3
39
Relacin entre ontologas, contextos y modelo de referencia
Tabla 3.4 Comparacin de dos mtodos de organizacin
42
Tabla 3.5 Ejemplos de templates
43
Tabla 4.1 Modelos para desarrollo de mensajes
92
Lista de Figuras
Figura 3.1 Modelo clsico (nico) de desarrollo
27
Figura 3.2 Diagrama de bloques del doble modelo
33
Figura 3.3. Sistema de informacin distribuido y con separacin de

informacin y conocimiento
44
Figura 3.4 Modelo universal del dominio
45
Figura 3.5 CEN/TC251AVG1 y WG2 (parcial)
46
Figura 3.6 HL7 RIM
47
Figura 3.7 openEHR
48
Figura 3.8 OMG-HDTF
49
Figura 4.1 Modelo de referencia EHR_Extract
53
Figura 4.2 Composicin. Conceptualmente, se corresponde con un

CDA Document de HL7
59
Figura 4.3 Modelo de referencia de los GPICs
63
Figura 4.4 Estructura de un arquetipo en ADL
81
Figura 4.5 Modelo referencia de PERSONA
85
Figura 4.6 Organizacin HL7 del desarrollo de mensajes
93
Figura 4.7 Organizacin CEN del desarrollo de mensajes
93
Figura 4.8 Estructura anlisis ADL
98
Figura 5.1 GPIC_ID = 3.054 Peticin de Servicio Asistencial

Figura 5.2 GPIC_ID = 3.056 Informe sobre servicio asistencial
Figura 5.3 GPICJD = 3.001 Objeto analizable
Figura 5.4. GPICJD = 3.003 Espcimen
Figura 5.5. GPICJD = 3.009 Producto de estudio
Figura 5.6. Parte del modelo EHR_Extract involucrado en el arquetipo
Figura 6.1 Receptor de servicio asistencial y GPICs asociados
123
Figura 6.2 Sujeto de prueba y GPICs asociados
127
vn
ndice
Figura 6.3 Parte sanitaria participante y GPICs asociados
129
Figura 6.4 Objeto Analizable Usado y GPICs asociados
132
Figura 6.5 Provisin del servicio asistencial y GPICs asociados
135
Figura 6.6 Informacin clnica relacionada y GPICs asociados
138
Figura 6.7 MIM mensaje de peticin de teleconsulta
144
Figura 6.8 MIM mensaje de informe sobre teleconsulta
170
vm
Resumen
Resumen
El diseo y desarrollo de los sistemas de soporte de las teleconsultas entre profesionales sanitarios en
sus diferentes versiones (sncrono, asincrono; entornos de trabajo cooperativo, sesiones, etc)
tradicionalmente se han llevado a cabo separadamente de los sistemas orientados a soportar otros
servicios asistenciales, y apartados de la problemtica tecnolgica relacionada con la documentacin e
historia clnica electrnica. La teleconsulta no formaba parte del propio proceso asistencial.
Como consecuencia, los resultados de una teleconsulta mdica, o bien terminaban almacenados en la
propia base de datos del sistema de teleconsulta desarrollado quedando all aislados, o bien eran
incluidos en la historia clnica del paciente de una forma indirecta por el profesional solicitante de la
teleconsulta, generalmente como anotaciones de la consulta o como formulario textual 'ad-hoc'.
El objetivo central de esta tesis ha sido elaborar una estrategia y realizar los desarrollos necesarios que
permitan la integracin efectiva de la teleconsulta entre profesionales sanitarios en el proceso
asistencial cotidiano, en un contexto de normalizacin de la historia clnica electrnica.
Los trabajos de revisin de la norma CEN/TC251 prENV13606:1999 Partes 1-4 estn suponiendo no
solamente cambios en el modelo de informacin y en los vocabularios controlados de la terminologa
del dominio, sino que estn provocando un verdadero cambio de paradigma en la arquitectura de los
sistemas sistemas de informacin que manejan las historias clnicas electrnicas que soporten la
norma.
Las nuevas normas, como modelos que van a tratar sobre todo con la complejidad y el cambio en el
conocimiento e informacin manejada, se basan en la separacin de responsabilidades ('servicios
middleware'), y cada uno de esos servicios modelado en varios niveles: Separacin de puntos de vista
(ISO RM/ODP), y Separacin de informacin y conocimiento (doble modelo). Los sistemas (el
software) son construidos a partir de los modelos de informacin (referencia). Los modelos de
conocimiento (cuyas instancias son los arquetipos y los templates) se procesan en tiempo de
ejecucin. Basada en estos paradigmas surge una metodoga cuyas caractersticas son: la existencia de
un doble modelo (referencia y conocimiento), y el desarrollo controlado de los conceptos del dominio.
Establecido y aplicado el nuevo escenario de estandarizacin a aquellas partes que pueden afectar a la
integracin de la teleconsulta, las contribuciones realizadas en esta tesis son:
Se ha propuesto una estrategia de integracin de la teleconsulta entre profesionales sanitarios en el
proceso asistencial, basada en la actuacin en tres campos del nivel de conocimiento del dominio:
Componentes de informacin de propsito general (GPICs), arquetipos/templates, y sistema de
conceptos de continuidad asistencial. Considera el autor que estas actuaciones de bajo nivel de
abstraccin, sern mucho mas efectivas en el proceso de integracin, que abordar un modelo de
IX
Resumen
referencia genrico de la teleconsulta en el escenario de continuidad asistencial, de dudosa

aplicabilidad.
Se han desarrollado los modelos de informacin de mensaje (MIM) y las descripciones jerrquicas
de mensaje (DJM) de los mensajes de peticin de teleconsulta e informe sobre teleconsulta, basados
en GPICs y siguiendo la metodologa actualizada del CEN/TC251. Dichos mensajes son considerados
las herramientas bsicas de integracin de la teleconsulta en el proceso asistencial considerado como
trabajo colaborativo.
Se han especificado en lenguaje ADL los dos arquetipos directamente relacionados con la soUcitud
de teleconsulta e informe sobre la misma, teniendo como modelo de referencia la parte del RIM en el
que estn basados los GPICs. Tambin se ha especificado un tercer arquetipo de resultados
(hallazgos) de un servicio realizado que fuera previamente solicitado, teniendo como modelo de
referencia el EHR_Extract 13606:2003. Este ltimo es la especificacin de un arquetipo que sirva
como ejemplo para los muy numerosos casos prcticos de solicitud de informe de un profesional a
otro sobre un producto de estudio determinado, que en la totalidad de los casos quedar almacenado
en la HCE.
Se han estudiado las posibilidades de formalizar los conceptos de continuidad asistencial en base a
GPICs y/o arquetipos tanto primarios como organizativos. Se ha desarrollado un modelo de referencia
del escenario de continuidad asistencial inspirado en un modelo de trabajo colaborativo sntesis de
varios existentes en la literatura, aunque de momento solo puede apuntarse una cierta metodologa y
la realizacin de algunas tareas iniciales. Dado que muchos de los conceptos de continuidad
asistencial son de muy alto nivel, y no estn todava especificados los arquetipos previsiblemente
involucrados, es una tarea que se vislumbra conformar una de las lneas futuras de trabajo.
Summary
Summary
The design and development of technology to support teleconsultation between health care
professionals, regardless their specific use (synchronous or asynchronous operaton, cooperatve
work, clinical sessions, etc.), has been normally approached to end with systems isolated from the rest
of the health care servces it is supposed to oprate with; away from the technological environment
associated to the electronic documentation and clinical records. Teleconsultation today is not
integrated normally into the care processes.
As a consequence, the results from medical teleconsultations either end within the own
teleconsultation system datbase, isolated from the rest of the patient's information, or they are
attached manually to that patient folders as text annotation or written reports.
The objective of the present work has been to propose a new strategy and the design of the supporting
technology, to allow the effective integration of the teleconsultation between professionals into the
regular health care processes, within the context outhned by the standardisation of the electronic
health record (EHR).
The reviewing process in progress of the CEN/TC251 EHRExtract: prENV13606:1999 (Parts 1-4), is
imposing important modifications, not only in the information models and the controlled domain
terms vocabularies, but also on the health information system architecture paradigm.
The new standards, considered as models to handle the complexity and the changes of the knowledge
and information involved, are based on the concept of responsibilities separation (middleware
Services); modelling each of these services at several levis: separation of points of view (ISO
RM/ODP) and information and knowledge separation (double model). The systems (software) are
built from information models (reference). The knowledge models (whose specifc instances are the
archetypes and templates) are processed at runtime. Based on these paradigms we propose to apply a
methodology whose main characteristics are: They use a double model (knowledge and information)
and the controlled development of the domain concepts.
Once defined the new standardisation scenario in these parts relevant to the integration of the
teleconsultation services, the main contribution of this work are as follows:
It has been proposed a new strategy to intgrate the teleconsultation between health professionals
within the care processes, based on the intervention at three different knowledge domain levis:
general-purpose information components (GPICs), archetypes/templates and continuous care concepts
system. The author consider that these low level abstraction approach will be much more efficient in
the integration tasks than approaching a generic reference model of teleconsultation in a continuous
care scenario, of doubtful apphcation.
XI
Smnmary
Information message models (MIM) has been proposed and developed as well as the of hierarchical
message descriptions (HMD) of: teleconsultaton request messages and teleconsultaton reports, based
on GPICs, according to the updated CEN/TC251 methodology. These messages are considered the
basic integration tools for teleconsultaton in a coUaboratve work based care process.
Two archetypes, direcy related with the teleconsultaton requests and teleconsultaton reports have
been specfed n ADL language, having the RIM part on which the GPICs are based as reference
model. A third archetype on results (fndings) has been also specified, from the EHR_Extract
13606:2003 reference model; that exemplfes the large amount of practical cases where a report s
requested between professionals related to a specfc study, to be fnally stored withn the HCE.
It has been studed the possblties to formalse the contnuty of care concept based on GPICs
and/or archetypes both prmary and organsatves. A reference model of the contnuty of care
scenaro has been proposed, nspred on a variety of coUaboratve work models publshed n the
lterature. At present only a methodology ntal frame and the definition of some intal tasks has been
acheved; outlning however a clear future work, having in mind that most contnuty of care concepts
nowadays are at a hgh level wthout any specifcation of the archetypes envisaged.
xu
INTRODUCCIN
1.
Introduccin
1.1 Teleconsulta entre profesionales sanitarios

En este trabajo se define teleconsulta como la consulta que realiza un profesional sanitario presente
localmente, a uno (o ms) profesionales sanitarios distantes, acerca del caso de un paciente, su
diagnstico y tratamiento, usando tecnologas de la informacin y las comunicaciones (TICs) para
salvar la distancia espacial entre los dos (o mas) participantes [G8][FdP].
En la definicin se establece explcitamente que el tema objeto de la interaccin est directamente
relacionado con el caso de un paciente, su diagnstico y posible tratamiento, el cual requiere de la
experiencia de otro profesional no presente en el lugar en que se encuentra el paciente. Define adems
el tipo de ayuda tecnolgica usada, basada en TICs, para puentear la distancia espacial.
La teleconsulta entre profesionales ha sido y sigue siendo, uno de los elementos clave de la
telemedicina. Permite transferir experiencia y conocimiento a reas pobremente atendidas
[Gilb][Pliil], puede servir como herramienta de despistaje [Joll][Pall], y usarse en tareas de formacin
[Dem][Saw]; puede disminuir costes [McCu][0akl], y probado ser coste-efciente [Harn][Lam],
aunque en estos aspectos se necesitan mas y mejores estudios [Mair][Whit][Jack][Bui]; puede
dinamizar el proceso asistencial [Batt][Tach], y mejorar el grado de satisfaccin de pacientes y
personal sanitario [Mair][Aarnl][Gran][Larc]. Por todo ello puede ser considerada como una
herramienta a tener muy en cuenta en la resolucin de los problemas asistenciales actuales mas
importantes [Walll].
La teleconsulta entre profesionales se usa en una amplia variedad de especialidades mdicas,
incluyendo: ciruga [Aarn2], radiologa [Lee][Salv], cardiologa [McCo], anatoma patolgica
[Kays][Meck],
dermatologa
[Joll][Loan],
oftalmologa
[Lam2][Smyt],
neurologa
[Paiv],
neurociruga [Wagn], ciruga plstica [Pap], tratmiatologa [SmRS], ortopedia [Lamb][Baru]

psiquiatra [McLa], otorrinolaringologa [Plin], medicina nuclear [Thor], ginecologa [Chan],
endoscopy [Balb], pediatra [SmAC], neonatologa [Sabl] y otras [Jaat].
No obstante, despus de mas de dos dcadas de proyectos piloto y ensayos, su inclusin en la

actividad asistencial cotidiana es baja o muy baja [Wall2][May]; y en cualquier introduccin sobre el
tema tiene todava sentido enumerar beneficios [G8] y problemas [Wall2][Sico] de la teleconsulta
entre profesionales sanitarios. Se pueden ambos resumir en:
Beneficios. La teleconsulta puede proporcionar ms y mejor informacin mdica en cualquier tiempo
y lugar; puede mejorar la calidad del diagnstico y del tratamiento, a travs del acceso a un experto; y
en general, puede mejorar la calidad de los servicios asistenciales proporcionados y la calidad de vida
del paciente. Puede tambin considerarse como un medio de mejorar la comunicacin entre
profesionales sanitarios, mejorando su competencia y calidad de servicio.
Problemas. El grado de validacin y el nivel de evidencia en su eficiencia y eficacia es bajo. Siguen
sin estar determinados con exactitud cual es el resultado de su comparacin con la consulta presencial,
as como dnde y cundo debe usarse [Scha]. Es muy notoria la ausencia de guas y protocolos
conocidos y aceptados.
1.1.1 Aspectos estructurales de la teleconsulta

En general, y de forma casi exclusiva, la teleconsulta ha sido analizada desde la perspectiva del
servicio de comunicaciones utilizado [FdP].
El actor origen iniciar el proceso de teleconsulta porque percibe que en el caso concreto de ese
paciente, la necesita. A continuacin, y dq)endiendo del entorno organizativo en el que se encuentre,
decidir si existe o no localmente un experto disponible. Si existe, obviamente tendr lugar
localmente una consulta presencial. Si no existe, con el consentimiento informado del paciente,
iniciar el proceso.
Son numerosas las propuestas de protocolos y guas a seguir en la realizacin de distintos tipos de
teleconsulta [Tach2][daSi][Ette][Guil].
Un posible principio gua en la organizacin de la teleconsulta puede (y debe?) ser adherirse lo mas
posible a la organizacin de una consulta tradicional, aunque en el contexto de telemedicina; con ello
se evitar en lo posible rupturas con el sistema de funcionamiento tradicional y se mantendrn
relaciones satisfactorias entre los proveedores de servicios locales.
El flujo de trabajo genrico de una teleconsulta entre profesionales contiene los siguientes pasos [G8]:
Bsqueda de un experto disponible para contactar.
Decisin sobre el(los) medio(s) de comunicacin a usar; ambos profesionales local y remoto
tienen que tener acceso.
Preparar la descripcin del caso y la peticin; ambas pueden estar muy influidas por el medio de
comunicacin.
Si el medio de comunicacin permite transmitir material para el diagnstico (p.ej imgenes,

seales, vdeo, etc), tomar la decisin de transmitir -s o no- esa informacin.
En caso de s transmitir esa informacin, es necesario prepararla, p.ej digitalizar y/o importar
datos a la descripcin del caso.
Si el medio de comunicacin permite teleconsulta sncrona, tomar la decisin de qu tipo de
teleconsulta se va a iniciar.
Si se ha elegido teleconsulta sncrona, la conexin puede establecerse, establecindose el tipo de
dilogo que permita el(los) servicio(s) telemticos. El material diagnstico puede, segn los
casos, ser transmitido antes o en paralelo.
Si se ha elegido teleconsulta asincrona, el comportamiento del profesional consultado (p.ej tiempo
y tipo de respuesta, etc) ha de ser mutuamente acordado con anterioridad, sobre todo si la
teleconsulta es frecuente.
En teleconsulta asincrona, la peticin con la descripcin del caso y eventualmente el material
diagnstico, ha de ser transmitido.
En teleconsulta asincrona la respuesta puede ser retransmitida por diferente medio de
comunicacin, segn lo que se haya negociado.
1.1.2 Aspectos legales y de seguridad de la teleconsulta

Aunque posteriormente estos aspectos no sean incluidos en el desarrollo del trabajo (aptdo 1.3),
parece conveniente incluir una descripcin de los mismos, si bien de forma superficial.
[Brah][Stan][Mill][Heij][G8].
La introduccin de la teleconsulta en los procesos de diagnstico y tratamiento no cambia
bsicamente la base legal de la medicina que ha sido establecida por la jurisdiccin a lo largo del
tiempo; pero es obvio que el nuevo contexto introduce cambios, y es necesario introducir nuevas
medidas tcnicas y/o organizativas para asegurar la legalidad del proceso.
Con todas las reservas que es convienente tener en lo relativo a generalizar en el tema de los aspectos
jurdicos, se puede asumir lo que sigue a continuacin.
Aspectos relativos a la responsabilidad entre consultante y consultado son los siguientes:
Autorizacin y competencia. Los profesionales sanitarios que practican teleconsulta son responsables
de la calidad de los servicios que ofrecen (incluido el equipamiento). El profesional solicitante debe
elegir un experto competente, el cual solo puede aceptar casos en los que est cualificado.
Confianza vs deberes de evaluacin. El profesional consultado debe contar con que el profesional
solicitante proporcionar toda la informacin relevante; y l se obliga a evaluar cuidadosamente el
material transmitido. Si pasa por alto errores obvios del colega que empez el tratamiento, se hace
responsable debido al insuficiente control que ejerci sobre su parte del proceso. El profesional
solicitante debe confiar en la especializacin y experiencia del consultor a menos que ste cometa un
error obvio de diagnstico.
Responsabilidad en tratamiento y mtodos. El profesional que lleva el tratamiento es el responsable
de sus decisiones y libre de elegir el mtodo que prefiera. No est obligado a seguir el consejo del
consultado.
Obligacin. El profesional solicitante es el responsable de los daos, tanto si sigue el consejo del
consultor como si no. El consultor involucrado en planear la estrategia teraputica, comparte
responsabilidad mdica de acuerdo a los principios generales de responsabilidad.
Responsabilidad de la organizacin. En caso de que ocurran errores debido a fracasos en la
comunicacin u organizativos, es responsabilidad de la organizacin. El remitente es responsable de
la integridad de los datos transmitidos. El destinatario tiene que identificar al remitente y verificar la
integridad de la informacin transmitida.
Se recomienda que todas las instituciones que solicitan o proporcionan teleconsulta deben establecer
una poltica interna de acuerdo con las leyes disponibles. Conformidad con, o desviacin de esta
poltica debe quedar registrada.
Documentacin. Se obligan ambos lados a documentar de forma apropiada el curso entero de la
teleconsulta: manera de identificacin del paciente, preguntas del profesional solicitante, cantidad y
calidad de los datos transmitidos, los hallazgos, recomendaciones o segunda opinin del consultor,
etc.
Seguridad y proteccin de datos. A menos que se tomen precauciones especiales, la lectura ilegal y
manipulacin de datos electrnicos, la falsificacin del remitente o el destinatario pueden llegar a
hacerse, crendose problemas de confidencialidad.
La necesidad de seguridad de los datos requiere el uso de estndares. No obstante, el encriptado y las
firmas digitales no pueden garantizar una proteccin completa e indefinida, puesto que futuros
desarrollos podran permitir descifrar los datos que parecen estar bien protegidos hoy.
Las metas siguientes pueden ser logradas mediante el despliegue de 'Public Key Infrastructure' (PKI):
Autenticidad. Identificacin correcta y comprobable mutua de compaeros de comunicacin;
Integridad. Ninguna manipulacin del contenido del documento puede ocurrir en la transmisin.
No-repudio. El remitente y el receptor se demuestra su identidad y no pueden negarse despus.
Privacidad. Slo el destinatario legtimo puede leer el documento.
Contrato servicio de teleconsulta. Un contrato que regule las interacciones y obligaciones entre los
profesionales/instituciones involucradas en un servicio de teleconsulta debe cubrir los problemas
siguientes:
Poltica de teleconsulta. Deben obligarse ambos lados a trabajar de acuerdo con su poltica de
teleconsultas, la cual especificar detalles de preparacin, conduccin, e interaccin.
Seguro de responsabilidad.
Costes.
Captulo 1. Introducdn
Aspectos relativos a cruces de frontera (jursdicional).
Otros aspectos relacionados con el paciente son:

Documentacin_historia_del_paciente.
Es necesario cumplir la legislacin correspondiente al
contenido de las historias clnicas, relativa a periodo de disponiblidad, etc.

Proteccin de datos y secreto profesional. La legislacin nacional para la proteccin de los datos
difiere ampliamente. Con respecto a la teleconsulta se recomienda adoptar las normas mas restrictivas,
p.ej se prohibe la transmisin de los datos relativos a un paciente a una persona individual a menos
que sea pedida por una regulacin legal o se dispone del consentimiento del paciente. Para lograr un
mximo de seguridad, la cantidad de datos transferida debe reducirse al mnimo suficiente para la
teleconsulta.
Si el traslado de los datos es urgentemente necesario y el paciente (o persona en su representacin) no
puede dar su consentimiento, los profesionales sanitarios pueden decidir en base al consentimiento
presumible del paciente, considerando cuidadosamente los beneficios y los riesgos.
Consentimiento informado del paciente. Slo es vlido si al paciente se le ha dado toda la informacin
necesaria y explicaciones en una conversacin preliminar, la cual no debe ser reemplazada por la
entrega de un formulario. Debe ser firmado por el paciente y documentarse en la HCE del solicitante.
El consentimiento y su propsito debe ser comunicado al consultor, quin debe asegurarse de la
informacin. Para ser efectivo, el consentimiento del paciente debe referirse a la transmisin de sus
datos y especificar qu datos pueden transferirse.
Adems el paciente debe ser informado sobre lo siguiente, si es posible:
Alternativas a la transferencia de datos y posibles consecuencias de la negativa del paciente a
aceptar la teleconsulta.
Los riesgos tpicos: acceso no-autorizado a sus datos y su transmisin no-controlada, interrupcin
de la transmisin de los datos causada por razones tcnicas, etc.
Aspectos relativos a costes, cruces de frontera, etc
1.1.3 Tipos de teleconsulta

En este trabajo se adopta como taxonoma de los distintos tipos de teleconsulta, la propuesta por del
Pozo et al. [FdP], en el que describen un escenario genrico y cuatro escenarios especficos.
El escenario genrico de los servicios de teleconsulta entre los profesionales mdicos puede
describirse como sigue: dos profesionales situados en localizaciones distintas necesitan trabajar
conjuntamente sobre un caso especfico para elaborar una decisin sobre el paciente bajo estudio. El
profesional sanitario que desea compartir el caso e inicia la teleconsulta se denomina profesional
consultante mientras que el profesional que atiende esa demanda de teleconsulta se denomina
profesional consultor. Iguales calificativos se usan para definir los lugares desde los que cada uno de
estos profesionales realiza su trabajo.
Normalmente, la informacin (anamnesis, imgenes, pruebas clnicas, etc.) necesaria para realizar la
sesin de teleconsulta procedente de la historia clnica del paciente se produce en el sitio consultante
donde, adems, en algunas situaciones puede estar el paciente fsicamente presente. En ciertas
ocasiones esa informacin o parte de ella puede estar alojada en un tercer lugar al que ambas partes
tienen acceso. Ambos lugares, consultante y consultor, disponen de plataformas tecnolgicas de
teleconsulta para soportar las operaciones de: a) captura de informacin; b) procesado de la misma; c)
acceso a las redes de comunicaciones y d) herramientas de soporte al trabajo cooperativo.
Dentro de este escenario genrico de teleconsulta cabe identificar cuatro escenarios especficos,
identificados por sus protocolos de trabajo, las necesidades exigidas a los servicios y las plataformas
tecnolgicas necesarias para implementar aquellos.
1.1.3.1
Teleconsulta a un especialista
En este primer escenario especfico el proceso comienza cuando el mdico o profesional sanitario del
centro consultante enva la informacin relevante de su paciente al centro consultor pare obtener del
profesional consultor, generalmente un especialista, soporte, apoyo o informes para la elaboracin de
un diagnstico sobre el caso en cuestin. Esta operacin puede materializarse de varias formas: 1) en
tiempo real, con la ayuda de un canal de videoconferencia u otras formas de dilogo (ej.: punteros
compartidos sobre pantallas donde se muestra en ambos extremos la misma informacin mas un canal
de voz y, normalmente, algunas herramientas de visualizacin, procesado y marcado compartidos en
tiempo real), o 2) en diferido en todos aquellos casos en los que el informado del caso recibido por el
profesional consultor no necesite la colaboracin en tiempo real de su contraparte, el mdico
consultante. En este escenario se asume que el tipo, contenido y formato de la informacin enviada ha
sido previamente consensuada entre ambas parte, generalmente siguiendo las pautas del especialista
consultor.
1.1.3.2
Teleconsulta en trabajo cooperativo
Un escenario semejante al anterior es aquel en el que los dos profesionales deciden una sesin de
teleconsulta para elaborar conjuntamente un diagnstico de un caso, motivados porque consideran
necesaria la colaboracin de otros especiaUstas. En este caso, para mantener los trminos de
teleconsulta adoptados antes se sigue llamando profesional consultante a aquel que inicia la sesin de
diagnstico cooperativo. Aunque las sesiones han de ser necesariamente en tiempo real, varias son las
opciones para su implementacin, requiriendo cada una de ellas soluciones tecnolgicas muy
diferentes. La videoconferencia es una opcin, ineludible cuando se necesita la telepresencia
(presencia virtual) del profesional consultor en el lugar consultante. En aquellos otros casos en los que
6
no se requiere la presencia del paciente en el lugar consultante la videoconferencia no es

imprescindible. En general, segn propia experiencia, los profesionales en sesiones de trabajo
cooperativo prefieren, en vez de verse mutuamente, compartir las imgenes y vdeos del caso con la
mxima calidad, normalmente enviados previamente a la sesin de dilogo y el soporte de esas
sesiones en tiempo real con un canal de voz y herramientas para la intensificacin, marcado de las
imgenes sobre la pantalla compartida, etc.. Por ltimo, ha de tenerse en cuenta que en algunos casos
estas teleconsultas de trabajo cooperativo pueden tambin montarse de manera secuencial asincrona.
1.1.3.3
Teleconsulta en telepresencia
Un escenario de teleconsulta importante es el que est orientado a que el especialista consultor pueda
estar virtualmente presente en el lugar consultante, junto con el profesional consultante para atender a
un paciente all presente. Para instrumentar este escenario de telepresencia se necesita un servicio de
videoconferencia y los instrumentos biomdicos necesarios para capturar y manejar toda aquella
informacin del paciente que sea pertinente para la teleconsulta, que haya especificado el especialista
consultor para poder elaborar un juicio sobre la situacin y estado del paciente. La disponibilidad de
un canal de videoconferencia ofrece la posibilidad de visualizar las imgenes generadas del paciente
sobre un negatoscopio as como cualquier otro material impreso. Sin embargo si el especialista para
elaborar su diagnstico necesita una calidad mayor de la muy limitada proporcionada por el canal de
videoconferencia es necesario disponer de estaciones ad hoc que permitan el envo de esas imgenes
sin perdida de calidad
1.1.3.4
Sesiones clnicas distribuidas
En los departamentos clnicos de cualquier hospital las sesiones clnicas son parte principal de la
rutina clnica y fundamento del aprendizaje continuado de los profesionales mdicos. En ellas un
mdico o varios presentan un caso clnico apoyado en la informacin pertinente disponible (historia
clnica, imgenes radiolgicas, resultados de tests clnicos, etc.) a sus colegas de los departamentos
afnes y a cualquier otro especialista (radilogo, cardilogo, etc.) que hayan estado involucrados o
simplemente les interese el caso, con el objetivo de consensuar las decisiones teraputicas mas
apropiadas al caso en estudio. La participacin en las sesiones clnicas de profesionales ubicados en
otros centros remotos, sin necesidad de desplazarse y evitando los inconvenientes de sus ausencias en
sus respectivos centros asistenciales, define otro escenario de la teleconsulta en el que es fundamental
proporcionar servicios conversacionales multimedia que permitan una implementacin virtual
alternativa la fsica presencial. En este caso el panel de mdicos responsables de la sesin clnica
emplearn canales de videoconferencia, dispositivos para la digitalizacin o transmisin de las
imgenes/vdeos relevantes y las herramientas de trabajo cooperativo.
1.2
Descripcin del problema. Integracin de la teleconsulta en el

proceso asistencial.
La teleconsulta entre profesionales sanitarios ha sido tradicionalmente considerada como un servicio

telemtico que ocurra sobre un "canal" distinto, apartado de la problemtica tecnolgica relacionada
con la documentacin y la historia clnica electrnica (HCE) [Hors]. Los diseos y desarrollos de
teleconsultas en sus diferentes versiones (sncrono, asincrono; entornos de trabajo cooperativo,
servicios de 'store&forward', etc) se han llevado a cabo separadamente de otros servicios necesitados
por el paciente; no formaba parte del propio proceso asistencial.
Como consecuencia de esta forma de hacer las cosas, los resultados de la teleconsulta, o bien
terminaban almacenados en la propia base de datos del sistema desarrollado quedando all aislados, o
bien eran incluidos en la historia clnica del paciente de una forma indirecta por el profesional, por lo
general el participante mas involucrado en la atencin, generalmente como anotaciones de la consulta
o como formulario textual 'ad-hoc' [Hustl][Lian].
Esto podra ser razonable siempre que la teleconsulta consistiera en una simple conversacin
telefnica o sesin de videoconferencia; pero actualmente (aptdo 1.1.1, aptdo 1.1.3) la teleconsulta
incluye la preparacin y transmisin de informacin procedente de la HCE del paciente, siendo en
muchos casos informacin multimedia (p.ej. seales, sonidos, imgenes, secuencias de vdeo), en
otros informacin textual o parcialmente codificada, e incluso se utilizan herramientas de ayuda al
diagnstico basadas en computador. El resultado es que en la propia teleconsulta, o muy relacionado
con ella, se genera nueva informacin de valor diagnstico, y la propia teleconsulta puede pasar en
ltima instancia a ser parte de un proceso asistencial, pudiendo ser considerada como un servicio
asistencial o un componente entre otros de un servicio asistencial.
Se hace necesario por tanto, que partes relevantes de esa informacin sean contribuciones a la HCE
del paciente [Hust2], avanzando en el proceso de integracin del servicio de teleconsulta entre
profesionales sanitarios en el escenario de la propia actividad asistencial [Balch][Cell][Hors][Lian].
Al plantear el problema de la integracin es necesario tener en cuenta desde un principio que el
proceso asistencial, tal y como se realiza actualmente, es bsicamente una actividad cooperativa entre
los profesionales que intervienen, siguiendo ima agenda, en la provisin de los diferentes servicios
asistenciales (ver aptdo 3.2.2) al sujeto de atencin [Ecch][Bruu].
1.2.1 Soporte a la colaboracin en equipos asistenciales.

Particularizando el amplsimo campo del trabajo colaborativo en general [Elli][Fari], y de la asistencia
sanitaria en particular [PICN][Weer], se puede resumir que los profesionales sanitarios necesitan
soporte [Meij][Lloy][HelI][Pine][Mykk] en los siguientes temas:
8
Agenda
Diseminacin de la informacin (de un miembro del equipo hacia los dems)
Recuperacin de la informacin (de los otros miembros del equipo hacia uno)
Coordinacin en la provisin de servicios (p.ej tratamiento) en el corto plazo.
Planificacin de la provisin de servicios (p.ej tratamiento) en el medio-largo plazo.
Compartir la HCE del paciente, permitiendo que los diferentes profesionales involucrados en su
asistencia aporten entradas documentando su actuacin, permite implcitamente la colaboracin. No
hay un soporte especfico de colaboracin directa entre profesionales, pero la documentacin comn
mejora el acceso a la informacin y agiliza la diseminacin y recuperacin de la informacin relativa
a las actividades de los otros miembros del equipo, y a los resultados de esas actividades.
No obstante, es obvio que no basta con compartir la HCE; es necesario disponer de herramientas de
colaboracin [Glou] que permitan dar un mayor o menor soporte a las cinco necesidades listadas
anteriormente.
Existen dos aproximaciones generales a la necesidad de dar soporte:
Percepcin de trabajo en equipo. Los profesionales necesitan disponer de la informacin sobre:
Agenda, actividades de tratamiento y planes de atencin, etc, pero tambin es relevante conocer la
informacin contextual (quin, qu, cundo, dnde, para qu, y cmo) auxiliar. Podra ser de inters
[Pinelle] que en cada escenario concreto (p.ej atencin domiciliaria, interfaz primaria-especializada,
urgencias, etc) se describieran niveles mnimos de 'conocimiento', mejorando de forma considerable
el 'workflow' del proceso asistencial; pero es obvia la dificultad de alcanzar acuerdos generalizados
en ese nivel.
Integracin de los procesos de comunicacin en la HCE. Diseminar y obtener informacin dentro del
equipo es una de las actividades bsicas de la colaboracin [Weerakkody; Pinelle]. Dada la naturaleza
de esa comunicacin (p.ej notificaciones, actualizaciones, avisos, etc) y la variable disponibiUdad de
los profesionales, mucha de esa comunicacin ha de ser asincrona (p.ej email, mensajera, etc). Pero
incluso esas facilidades de comunicacin habrn de estar integradas en la HCE, porque sta
proporciona dos tipos de informacin contextual de gran importancia, ya que los miembros del equipo
que atienden al paciente comparten una parte de la HCE; y la comunicacin puede ser acerca de algo
especfico (p.ej un documento, o un evento) cuyo pleno contexto est contenido en la HCE.
1.2.2 Aparicin de un nuevo escenario.

Conforme la teleconsulta sea gradualmente aceptada como un procedimiento asistencial mas, se
incrementar la demanda de servicios accesibles, responsables, seguros, eficientes y eficaces [Chro].
Accesibles, haciendo disponible el conocimiento y experiencia mdicos en el lugar y tiempo que se

necesite. Para ello ser necesario contar con infraestructura de redes y servicios de comunicaciones, y
la capacidad de proveer la informacin actualizada necesaria [GomA].
Responsables, requiriendo registros detallados de las sesiones de teleconsulta [Hust2]. Estos registros
debern incluir, no solo los datos de gestin (p.ej para evaluacin y contabilidad), sino la informacin
clnica necesaria, incluyendo la peticin de teleconsulta, informacin diagnstica (p.ej Rx, ECGs, etc)
e informes. Puesto que estos registros de teleconsulta sobrevivirn a las sesiones en que fueron
creados, los documentos clnicos y otros datos mdicos necesitarn estar en formatos estndares para
facilitar su portabilidad y accesibilidad. Tambin necesitarn estar atestados para alcanzar los
requerimientos de integridad y no-repudio. Como las sesiones de teleconsulta sern considerados
contactos mdicos, los registros de las sesiones de teleconsulta habrn de ser incluidos en HCE del
paciente.
Eficientes y eficaces. Para que los servicios de teleconsulta sean eficientes y eficaces es necesario
seguir guas [Burg] de tecnologa apropiada para el entorno fsico concreto. El uso de guas
contribuye a asegurar la compatbihdad, interoperabilidad, escalado, y fiabilidad de los sistemas y
equipos usados [Suth]. Pero no basta con eso, es tambin necesario hacer disponible informacin
clnica relevante para delinear el estado del paciente y seleccionar el tratamiento mas adecuado en un
tiempo adecuado. Protocolos clnicos y gua de actuacin para diagnstico y tratamiento, publicados
por las organizaciones profesionales [ACC][ACR] proporcionan informacin relevante.
1.3 Descripcin del planteamiento del trabajo

El propsito central de este trabajo es contribuir al proceso de integracin en el proceso asistencial de
la teleconsulta entre profesionales sanitarios, desde una perspectiva global de estandarizacin.
Se asume como hiptesis inicial, que solamente en un entorno de funcionamiento (entidades, roles,
participaciones, y actividades) regido por estndares, ser posible documentar los procesos y manejar
(adquirir, procesar, almacenar, presentar y transmitir) la informacin, de forma que los sistemas sean
interoperables.
A partir de una primera hiptesis tan general, el trabajo necesitara atender y tratar todos los aspectos
(y los estndares involucrados) relacionados directa o indirectamente con la asistencia en el marco de
la cual se produce la teleconsulta entre profesionales. Es evidente la considerable amplitud del
escenario, dada la gran cantidad de estndares involucrados y las diferentes organizaciones emisoras;
pues sera necesario abarcar normas acerca de:
Comunicaciones. Diferentes transmisiones de informacin digital.
10
Protocolos y Guas. Necesarios para guiar la definicin, adquisicin, transmisin, presentacin,

interpretacin, almacenamiento, mantenimiento, y subsiguiente acceso y uso de la informacin
diagnstica.
Acceso de actores. Disponibilidad de expertos desde una perspectiva global. Probabilidad de que im
experto dado, independientemente de su lugar de residencia, tenga acceso a la tecnologa necesaria.
Identificacin. Verificar la identidad de los usuarios de forma instantnea. La verificacin del grado
de experiencia es principalmente una cuestin de confianza.
Seguridad. Preservar los derechos y privacidad del paciente.
Documentacin. Proporcionar los medios para la necesaria documentacin de la teleconsulta en una
HCE normalizada.
Es obvia la imposibilidad de abarcar en un nico trabajo todo el escenario; no obstante, se ha optado
inicialmente por un planteamiento de trabajo muy poco restrictivo, dado que en primer lugar ha sido
analizada en profundidad, y en toda su extensin, la situacin actual de estandarizacin en el mbito
de la HCE (ver Cap. 3).
Las lneas generales de las distintas etapas de la propuesta de desarrollo de estndares en HCE que es
considerada actualmente por el autor de mayor inters, son las siguientes:
Requerimientos. Los requerimientos de usuario son los admitidos en la norma ISO/TS 18303 [18303].
Diseo. Tres paradigmas de diseo: la separacin de responsabilidades ('middleware'), la separacin
de puntos de vista (ISO RM/ODP modelo de referencia para proceso distribuido en sistemas abiertos)
[ISRM] y la separacin de conocimiento e informacin en el dominio de la asistencia sanitaria
(propuesta de doble modelo) [Beall].
Desarrollo. El desarrollo propuesto tiene dos caractersticas principales: la existencia de un doble
modelo (referencia y conocimiento), y el desarrollo controlado de los conceptos del dominio
manejados por los futuros sistemas de informacin.
La situacin actual de la normalizacin en HCE, queda finalmente descrita en un modelo universal
sobre el que se han mapeado las normas de las diferentes organizaciones emisoras [Beal2].
Entre las tres vas posibles de trabajo: CEN [CEN], HL7 [H17], openEHR [openEHR], se ha optado
por el CEN con importantes aportaciones de OpenEHR en la revisin actual.
A continuacin se ha llevado a cabo la restriccin del 'scope' del presente trabajo, quedando ste
bsicamente delimitado como una contribucin a la integracin de la teleconsulta, en el contexto de
una asistencia continuada entre niveles asistenciales [13940], una HCE estandarizada conforme al
CEN [13606:2003 Parts 1-5], unos componentes de informacin de propsito general GPICs [14822
Parts 1-4] y unos mensajes de solicitud de servicio e informe sobre servicio [14720].
Quedan por tanto fuera del trabajo, todas las normas relativas a Requerimientos, Acceso,
Identificacin y Seguridad.
11
Captulo 1. Introducxn
Los tres paradigmas contenidos en la metodologa de diseo adoptada, permite en este trabajo:
La sq)aracin de responsabilidades -'middleware'-, una bien delimitada identificacin de los
servicios involucrados que son: 'EHR_Extract' [13606:2003 Part] y 'Message' [13606:2003
Part5][14720].
La separacin de puntos de vista, focalizar el trabajo en el punto de vista de Informacin [ISRM],
y
La separacin radical entre informacin y conocimiento en el dominio provoca [Beall], por un
lado, la plasmacin de los servicios como modelos (de informacin) de referencia, y por otra, la
aparicin de los arquetipos como descripciones controladas de los conceptos del dominio
expresados como modelos formales con estructura jerrquica (ver Cap. 3 y Cap. 4).
Siguiendo la metodologa de desarrollo de la propuesta de doble modelo, se afronta el problema de

integracin de la teleconsulta en los siguientes trminos:
Se dispone de:
-
Los modelos de referencia de 'EHR_Extract' [13606:2003 Part] y 'Message' [14720].
Los GPICs [14822]

Especificacin y refrenda de arquetipos [13606:2003 Parts 2-3]
Los conceptos del dominio de asistencia continuada [13940].
Es necesario estudiar y desarrollar:

El modelo de informacin de mensajes para peticin e informe sobre teleconsulta, considerada
como un servicio asistencial mas, en el contexto de asistencia continuada.
Arquetipos que recojan las restricciones sobre la o las clases del modelo que describan la gestin
de la informacin en una teleconsulta integrada.
1.4
Descripcin del documento
El documento se divide en los siguientes captulos:

En el captulo 2, titulado Hiptesis y Objetivos, se describe muy brevemente el planteamiento del
trabajo consistente en aceptar como viables una serie de condiciones previas de estandarizacin en
todo el entorno de la HCE (contenido del captulo siguiente), que son el punto de partida necesario
para acceder a los objetivos del trabajo que son estudiar y desarrollar la integracin de la teleconsulta
entre profesionales sanitarios en el proceso asistencial.
En el captulo 3, titulado Situacin actual de la normalizacin en HCE, se describe la propuesta de
desarrollo de estndares que el autor considera de mayor rigor conceptual y mayor proyeccin en
nuestro entorno. Se describen: 1) Los requerimientos de usuario recogidos en la norma ISO/TS18303;
2) Los tres paradigmas de diseo de estndares, descritos como: Separacin de responsabilidades,
12
Captulo 1. Introducdn
separacin de puntos de vista, y separacin de informacin y conocimiento en el dominio; 3) Una

nueva metodologa de desarrollo, basada en un doble modelo, referencia y de arquetipos; 4) Una
representacin del conocimiento del dominio basada en dos tipos de anlisis, ontolgico y de
contexto; 5) Un modelo universal del dominio, en el que se mapean las normas existentes
actualmente, procedentes de las distintas organizaciones emisoras.
En el captulo 4, titulado Material y mtodos, se describe todo el material necesario para el desarrollo
del trabajo, tal y como est disponible en la actualidad. En el apartado de Material se describen: 1)
Los modelos de referencia de los servicios 'EHR_Extract' y de los mensajes de solicitud_de_servicio
e informe_sobre_servicio; 2) Los conceptos del dominio que pueden estar mas relacionados, por un
lado el sistema de conceptos manejados en el escenario de asistencia continuada, y por otro los
modelos formales de los componentes de informacin de propsito general GPICs; 3) Los lenguajes
de definicin de arquetipos, en particular un lenguaje especfico (ADL), que se compone de dos
sintaxis: Lenguaje de definicin de datos (dADL) y Lenguaje de definicin de restricciones (cADL),
as como el proceso de 'parsing' de dicho lenguaje. En el apartado Mtodos se describe: 1) La
metodologa actual de construccin de arquetipos, consistente en una descripcin de los principios de
los arquetipos y unos niveles de acuerdo; y 2) la herramienta de 'debug' de ADL.
En el captulo 5, titulado Integracin de la teleconsulta en la actividad asistencial, se describen los
objetivos del trabajo, objetivo primario y objetivos especficos. A continuacin se repasan aspectos
bsicos relacionados con las tres reas del nivel de conocimiento en las que se realizan desarrollos de
integracin y que constituyen el objetivo del trabajo de tesis: 1) mensajes de peticin e informe
[14720] basados en GPICs [14822]; 2) arquetipos relacionados con la peticin e informe sobre
servicios asistenciales; y 3) conceptos del dominio de asistencia continuada [13940]. El propsito de
estos apartados es clarificar lo mas posible lo expuesto en el siguiente apartado de resultados.
El captulo 6, titulado Resultados se divide en dos partes: 1) Especificacin de los mensajes de
peticin de servicio/teleconsulta e informe sobre servicio/teleconsulta y 2) especificacin de
arquetipos relacionados con la integracin de la teleconsulta. La especificacin de cada mensaje se
compone de las partes siguientes: Descripcin general del mensaje. Modelo de informacin del
mensaje (MIM), y Descripcin jerrquica del mensaje (DJM). En el apartado relativo a arquetipos se
especifican los siguientes arquetipos: arquetipo basado en el GPIC peticin de servicio/teleconsulta
(GPIC_ID = 3.054) y GPICs asociados; arquetipo basado en el GPIC informe sobre
servicio/teleconsulta (GPIC_ID = 3.056) y GPICs asociados, y finalmente un ejemplo de arquetipo
tipo entrada para describir los hallazgos encontrados en un estudio electrofisiolgico, como ejemplo
(entre muchsimos posibles) de informe sobre procedimiento clnico.
En el captulo 7, titulado Conclusiones, se discuten brevemente los resultados obtenidos, se describen
otras posibles aportaciones en el contexto habilitado para la reaUzacin de este trabajo de tesis, y se
apuntan lneas de trabajo del prximo futuro.
13
En el captulo 8, titulado Bibliografa se incluyen todas las referencias.

A continuacin se adjuntan una serie de anexos necesarios como referencia sobre todo para el
captulos de resultados:
Anexo 1.
Listado de GPICs No-Clnicos
Anexo 2.
Listado de GPICs Clnicos.
Anexo 3.
Listado de cdigoClase de Entidades
Anexo 4.
Listado de cdigo/Determinador de Entidades
Anexo 5.
Listado de cdigoClase de Roles
Anexo 6.
Listado de cdigoTipo de Participaciones
Anexo 7.
Listado de cdigoEstado de Participaciones
Anexo 8.
Listado de cdigoModo de Participaciones
Anexo 9.
Listado de cdigoControlContexto de Participaciones
Anexo 10. Listado de cdigoClase de Actividades

Anexo 11. Listado de cdigoMood de Actividades
Anexo 12. Listado de cdigoEstado de Actividades
Anexo 13. Listado de cdigoTipo de Relacin entre Actividades
Anexo 14. Listado de cdigoControlContexto de Relacin entre Actividades
14
HIPTESIS Y OBJETIVOS
2.
Hiptesis y Objetivos
2.1 Hiptesis de partida

Las principales hiptesis de partida en este trabajo de tesis son las siguientes:
Los diseos y desarrollos de los sistemas de soporte de las teleconsultas entre profesionales
sanitarios en sus diferentes versiones (sncrono, asincrono; entornos de trabajo cooperativo, sesiones,
etc) tradicionalmente se han llevado a cabo separadamente de los sistemas orientados a soportar otros
servicios asistenciales, y apartados de la problemtica tecnolgica relacionada con la documentacin
clnica y la HCE. No formaba parte del propio proceso asistencial.
Como consecuencia, los resultados de la teleconsulta, o bien terminaban almacenados en la propia
base de datos del sistema de teleconsulta desarrollado quedando all aislados, o bien eran incluidos en
la historia clnica del paciente de una forma indirecta por el profesional, por lo general el participante
mas involucrado en la atencin (el solicitante de la teleconsulta), generalmente como anotaciones de
la consulta o como formulario textual 'ad-hoc'.
Esto podra ser razonable si la teleconsulta consistiera en una simple conversacin telefnica o
sesin de videoconferencia, pero actualmente la teleconsulta incluye la preparacin y transmisin de
informacin (texto, multimedia o parcialmente codificada) procedente de la HCE del paciente, e
incluso se utilizan herramientas de ayuda al diagnstico basadas en computador.
El resultado es que en la propia teleconsulta, o en un contexto muy relacionado con ella, se genera
nueva informacin de valor diagnstico, y la propia teleconsulta puede pasar en ltima instancia a ser
parte de un proceso asistencial, pudiendo ser considerada como un servicio asistencial o un
componente entre otros de un servicio asistencial.
15
Se hace necesario por tanto, que partes relevantes de esa informacin sean contribuciones a la HCE
del paciente, avanzando en el proceso de integracin del servicio de teleconsulta entre profesionales
sanitarios en el escenario de la propia actividad asistencial.
El proceso asistencial, tal y como se realiza actualmente, es bsicamente una actividad cooperativa
entre los profesionales que intervienen, los cuales aceptan unos mandatos que les confieren
responsabilidad y siguen una agenda en la provisin de los diferentes servicios asistenciales.
Lx)S profesionales sanitarios necesitan soporte en los siguientes temas: Agenda, diseminacin de la
informacin, recuperacin de la informacin, coordinacin en la provisin de servicios en el corto
plazo, y planificacin de la provisin de servicios en el medio-largo plazo.
Que los diferentes profesionales involucrados puedan compartir la HCE del paciente, permitiendo
que aporten entradas documentando su actuacin, permite implcitamente la colaboracin. No hay un
soporte especfico de la colaboracin entre profesionales, pero la documentacin comn agiliza la
diseminacin y recuperacin de la informacin relativa a las actividades de los otros miembros del
equipo, y a los resultados de esas actividades. Sin embargo no basta con compartir la HCE; es
necesario disponer de herramientas de colaboracin que permitan dar un mayor o menor soporte a las
cinco necesidades listadas anteriormente.
Al margen de las herramientas especficas de soporte automtico del flujo de trabajo, es obvio que la
teleconsulta entre profesionales sanitarios en sus muy diferentes configuraciones, ser un pilar bsico
en la mejora del soporte al trabajo colaborativo. Su integracin en el proceso asistencial es
absolutamente necesario.
La integracin de la teleconsulta ha de realizarse obUgatoriamente en un contexto global de
estandarizacin.
2.2 Objetivos del trabajo

2.2.1 Objetivo primario
El objetivo general primario de este trabajo de tesis es, tras analizar el contexto general de
estandarizacin en el campo de las TICs en la HCE y la asistencia clnica, la realizacin de tareas de
desarrollo tendentes a una efectiva integracin de la teleconsulta entre profesionales sanitarios en el
proceso asistencial, en un contexto de asistencia continuada.
La idea bsica que soporta la integracin de la teleconsulta en el contexto delimitado por una HCE
estandarizada conforme al CENTC251 [13606:2003], unos mensajes de solicitud de servicio e
16
informe sobre servicio [14720:2003] basados en unos componentes de informacin de propsito

general GPICs [14822:2003], y una asistencia continuada [13940:2000], se concreta en la decisin de
considerar la teleconsulta como un procedimiento incluido en la provisin de un servicio asistencial, o
bien ser considerada ella misma un servicio asistencial propiamente dicho.
Por lo tanto, la secuencia de actuaciones en un escenario prctico ser la siguiente:
La teleconsulta ser solicitada por un profesional mediante un mensaje_peticin_de_servicio, que
ser enviado a la(s) parte(s) interesadas. El mensaje de peticin de servicio incluye el tipo de
servicio/teleconsulta solicitado, informacin sobre la condicin del paciente, y toda la
informacin contextual necesitada por parte del(los) receptor(es) del mensaje.
La teleconsulta (=servicio asistencial, o parte del servicio) se lleva a cabo.
El o los proveedores del servicio asistencial elaborarn un informe sobre el servicio asistencial
llevado a cabo que se enviar al profesional (o la parte) solicitante mediante un
mensajeJnforme_sobre_servicio. El mensaje informe contiene un GPIC o conjunto de GPICs que
contienen o referencian una agrupacin de informacin clnica que constituye la informacin que
ha de incluirse en la HCE del paciente cuyo caso gener la peticin del servicio/teleconsulta.
Obviamente en este trabajo solamente se atendern aquellos aspectos relativos a la teleconsulta entre
profesionales sanitarios, y no sern incluidos (salvo a modo de ejemplo en algunas ocasiones) los
aspectos puramente clnico-diagnstico-asistenciales que constituyen el servicio asistencial.
2.2.2 Objetivos especficos

Los desarrollos tendentes a la integracin de la teleconsulta en la actividad asistencial incluidos en
este trabajo se circunscriben a tres mbitos de actuacin pertenecientes al nivel de conocimiento del
modelo universal correspondiente al CEN/TC251AVG1,WG2 (ver fg. 3.6): GPICs, arquetipos y
sistema de conceptos de continuidad asistencial.
Los objetivos especficos de este trabajo de tesis son los siguientes:
Objetivo 1. Desarrollo de los mensajes de peticin de servicio/teleconsulta asistencial e informe sobre
servicio/teleconsulta asistencial. Se desarrollarn los modelos de informacin de mensaje (MIM) y la
descripcin jerrquica del mensaje (DJM), siguiendo la metodologa actualizada del CEN/TC251.
Objetivo 2. Desarrollo de arquetipos directamente relacionados con la solicitud de teleconsulta e
informe sobre la misma, as como -a modo de ejemplo- un arquetipo de resultados (hallazgos) de un
servicio realizado. Habiendo adoptado el doble modelo, referencia y conocimiento, como arquitectura
del sistema de informacin (ver cap. 3), es obvio que la siguiente contribucin sea la especificacin de
17
los arquetipos mas relacionados con la propia teleconsulta. As mismo se ha considerado de inters,
dado que ser parte esencial de lo que en la mayora de los casos quedar almacenado en la HCE, la
especificacin de un arquetipo que sirva como ejemplo para los muy numerosos casos prcticos de
solicitud de informe de un profesional a otro sobre un producto de estudio determinado.
Objetivo 3. Estudio y desarrollo iniciales de las posibilidades de formalizar los conceptos de
continuidad asistencial en base a GPICs y/o arquetipos, tanto primarios como organizativos. En este
tercer objetivo obligatoriamente solo puede apuntarse una cierta metodologa y la realizacin de
algunas tareas, dado que muchos de los conceptos de continuidad asistencial son de muy alto nivel
(fig. 3.6), y no estando todava especificados muchos de los arquetipos involucrados, es una tarea que
excede los lmites de este trabajo.
18
SITUACIN ACTUAL DE LA
NORMALIZACIN EN HCE
Captulo 3. Situacin actual nomazacin HCE
3.
Situacin actual de la normalizacin en HCE.
Es conocida por todos los que se acercan al campo de la estandarizacin en el dominio de las TICs en
la medicina clnica, la gran cantidad de normas distintas, la disparidad de enfoques y criterios, el
solape existente entre ellas, y en definitiva la enorme dificultad para incluso entender en muchos
casos qu se est queriendo normalizar.
La aproximacin a la situacin actual de la normalizacin ha consistido tradicionalmente en la
descripcin mas o menos contextual de las normas procedentes de los diferentes entes de
estandarizacin CEN/TC251 [GEN], HL7 [H17], OMG-HDTF [OMG], ISO/TC215 [ISO], etc, siendo
en ocasiones muy difcil relacionar entre s normas procedentes de distintas organizaciones, e incluso
a veces de la misma organizacin [Beall].
La aproximacin realizada en este trabajo y presentada en este captulo es diferente. Pretende una
doble finalidad: por un lado presentar una actualizada metodologa de desarrollo de sistemas
(estndares), como productos resultantes de modelos diseados a partir de los requerimientos de los
usuarios, pero teniendo tambin en cuenta requerimientos de las otras etapas del proceso de
desarrollo; y por otro lado, establecer un nico campo de juego, denominado modelo universal, para
poder ubicar sobre l las normas publicadas y realizar correctas comparaciones (analogas y
diferencias) entre las procedentes de los diferentes entes de estandarizacin.
Para ello se ha adoptado en gran medida la propuesta de la openEHR Foundation [openEHR], que est
influyendo de forma determinante en la revisin de la GEN prENV13606:1999 [13606:1999], y
permitiendo cada vez mayores dosis de armonizacin con HL7. No obstante en la norma GEN
prENV13606:2003 [13606:2003 Part] se han introducido numerosas modificaciones sobre el modelo
de referencia propuesto por openEHR. La participacin del autor en los proyectos GEHR [Gehr] y
EHCRSupA [EHGRSupA] y el contacto continuado con algunos de los autores referenciados en la
19
Captulo 3. Situacin actual nomalizadn HCE
bibliografa, le ha permitido seguir y participar en alguna pequea medida en el proceso de

elaboracin de la norma europea prENV13606.
Lx)s siguientes apartados del captulo contienen una serie de anlisis y principios de diseo de
sistemas, que atienden los aspectos mas importantes en los que se fundamenta lo que es una actual
propuesta de estandarizacin.
Se comienza reconociendo el continuado fracaso en este campo y sealando las especiales
caractersticas de la informacin clnica que lo explican.
A continuacin se describen en lneas generales las distintas etapas (requerimientos, diseo y
desarrollo) de la propuesta de desarrollo de estndares.
Los requerimientos de usuario son los admitidos en la norma ISO/TS 18303 [18303].
Los paradigmas de diseo son: la separacin de responsabilidades ('middleware'), la separacin de
puntos de vista (ISO RM/ODP modelo de referencia para proceso distribuido en sistemas abiertos) y
separacin de conocimiento e informacin en el dominio (propuesta doble modelo).
El desarrollo propuesto tiene dos caractersticas principales: la existencia de un doble modelo
(referencia y conocimiento), y el desarrollo controlado de los conceptos del dominio manejados por
los futuros sistemas de informacin.
A continuacin, surgen los arquetipos como descripciones controladas de los conceptos del dominio
expresados como modelos formales con estructura jerrquica.
La representacin del conocimiento se apuntala sobre dos tipos de anlisis, el ontolgico y el de
contexto. Aunque es todava un terreno muy abierto, se hace una propuesta concreta sobre arquetipos
y templates.
Finalmente se describe un modelo universal y se mapean sobre l, las normas de las diferentes
organizaciones.
3.1 Dominio de la informacin clnica.

El punto de partida del anlisis es la constatacin de que en el caso de las TICs en el campo sanitario,
los estndares estn hechos de especificaciones, que casi en su totalidad son esencialmente modelos.
Los modelos se pueden definir como descripciones abstractas de ideas, que pueden ser inventadas o
procedentes del mundo real. Su estructura se formaliza para que los humanos puedan acordarlos y los
computadores puedan usarlos. Los modelos se usan, entre otras cosas, para describir y construir
sistemas, intercambiar informacin y compartir conocimiento.
En general en el dominio de la medicina clnica y en particular en el campo de la HCE, es hoy muy
evidente la enorme e histrica dificultad en la obtencin de buenos modelos, en definitiva de buenos
estndares de arquitectura de HCE, mensajes y terminologa [Rectl][Shum]. Podra ser prolija la
20
descripcin de grandes proyectos de desarrollo de sistemas HCE, grandes en tiempo y recursos

involucrados, que finalmente han sido de muy dudosa eficacia durante su limitado uso y veloces en
alcanzar la obsolescencia.
La aproximacin usual que se ha venido haciendo para definir un estndar, ha sido considerar los
requerimientos de los usuarios del dominio y de los sistemas de informacin sanitaria y, a partir de
ellos, definir modelos de los conceptos del dominio que luego sern usados para construir software y
sistemas a partir de ellos. Es decir, se ha simplificado el proceso a: Requerimientos/Anlisis/Diseo,
sin tener en cuenta las restantes actividades de la ingeniera del software: Desarrollo/Prueba/
Uso/Mantenimiento.
Sin embargo, el dominio de la medicina clnica se caracteriza por una serie de peculiaridades, que lo
diferencia de otros dominios, y que ha provocado que esta metodologa simplificada no trabaje bien.
Se resumen en:
Riqueza de conocimiento. El nmero de conceptos individuales es muy grande (p.ej SNOMED-CT,
aprox. 350.000) [Snom] y muchos conceptos pueden ser muy complejos.
Alta velocidad de cambio. Ocurren fi-ecuentemente cambios en los conceptos objeto de modelado.
Continuamente, las nuevas tecnologas y los resultados de la investigacin biomdica introducen
nuevos conceptos. Tambin se producen cambios en los procesos asistenciales, sobre todo en el flujo
de trabajo operativo. Son todos ellos factores de cambio en el dominio que conllevan modificaciones
en el software y la informacin manejada.
Longevidad de la informacin. En muchos casos los datos almacenados duran toda la vida del
paciente, e incluso unos aos ms para satisfacer requerimientos legales o servir a propsitos
epidemiolgicos, educativos u otras investigaciones. La HCE ha de ser utilizable sin tener en cuenta
los cambios tambin frecuentes de plataforma/base de datos/herramientas utihzados.
Necesidad de interoperabilidad. Actualmente, la asistencia sanitaria es considerada una actividad
cooperativa (intervienen mltiples agentes sanitarios), centrada en el paciente (los procesos se
configuran en torno a su conveniencia) y que intenta utilizar de forma coste-efectiva los diferentes
recursos (distintos proveedores de servicios). Los sistemas que gestionen el conocimiento y la
informacin deben ser interoperables, permitiendo el acceso de mltiples usuarios y la informacin
ser compartida por los distintos proveedores de servicios, y por sistemas de diferentes fabricantes.
Es obvia la necesidad de compartir la informacin. Se produce una diversificacin de los contactos
del paciente (hospital, atencin primaria, etc) con el sistema saitario; los pacientes interactan en
mas de un punto de atencin; y todos los profesionales involucrados necesitan acceder a la
informacin del paciente.
Es necesario compartir tanto el contenido (trminos, cantidades, el etc), como las estructuras
(conceptos, p.ej presin arterial, resultados de una prueba, etc), como las instancias de conocimiento
del dominio (p.ej extracto; peticin/contestacin de un informe). Tambin es necesario compartir
21
Captulo 3. Situacin actual nomaUzacin HCE
para poder preguntar sobre poblaciones, para salud pblica, estudios estadsticos, educacin; estando
por lo general la informacin (casi siempre resumida) compartida por sistemas heterogneos.
Otros aspectos que fomentan la interoperabilidad son: Las personas cada vez son ms mviles
(vacaciones, cambios de domicilio, etc); la progresiva implantacin de nuevos servicios asistenciales
basados en telemedicina; la necesaria autorizacin a las partes (requerimiento de privacidad / modelo
de consentimiento); el soporte a la infraestructura de seguridad, y otros.
Necesidad de procesamiento inteligente. Los datos deberan se procesables en el nivel semntico de
los conceptos (componentes estructurales de conocimiento), para que trabajen mucho mas
eficientemente los motores de bsqueda, las herramientas de soporte y ayuda a la toma de decisiones,
las guas de prctica clnica y la vas de atencin asistencial. (Se ver con detalle en apartados
posteriores).
Necesidad de viabilidad econmica. Se necesitan sistemas que no caigan rpidamente en la
obsolescencia provocada sobre todo por la alta velocidad de cambio en el conocimiento y la
informacin manejados.
La informatizacin de todo lo que existe debajo del paraguas que denominamos historia clnica se ha
convertido en un problema engaoso [Shum], que solo podr ser afrontado desde la perspectiva de
una ingeniera de sistemas que posibilite obtener modelos que:
Permitan acomodar cambios constantes en el conocimiento (clrco) manejado; sin los gastos de
reconstruir, re_probar y reusar el software y las bases de datos involucrados.
Permitan desarrollar sistemas en plazos de tiempo asumibles.
Sean comprensibles por los humanos en todos sus aspectos formales.
3.2 Propuesta de desarrollo de estndares

La propuesta de la openEHR Foundation [openEHR] contiene las mismas etapas clsicas de la
ingeniera
de
sistemas:
anlisis/diseo
->
desarrollo/prueba
->
uso/mantenimiento,
pero
enriqueciendo de forma significativa el proceso de anlisis/diseo, es decir propone tener como

entradas no solamente los requerimientos de los usuarios, sino tambin uno o varios paradigmas de
diseo, una o varias metodologas de anlisis/diseo, patrones de anlisis/diseo, aspectos culturales,
restricciones de diseo y restricciones econmicas.
El proceso de anlisis/diseo debe tener por tanto las siguientes entradas:
Requerimientos de usuario. Los requerimientos reales de los sistemas de informacin, articulados por
los usuarios del dominio.
Paradigma(s) de diseo. Siempre hay uno implcito (p.ej. orientacin a objetos), aunque
frecuentemente tanto modeladores como desarroUadores no llegan a ser totalmente conscientes de sus
22
alternativas o sus lmites. Elegir explcitamente uno o varios paradigmas, o definir una alternativa,
mejora muy significativamente los resultados del proceso.
Metodologa de anlisis/diseo. Dentro de un paradigma, generalmente son posibles varias
metodologas, que proporcionan diferentes escenarios de elaboracin de los productos tcnicos
finales.
Patrones de anlisis/diseo. Conocimiento de trabajo previo existente, tanto acadmico como
prctico. Se presenta un doble reto: encontrar patrones existentes, lo que conlleva trabajo de
investigacin, y aplicar el elegido de forma adecuada, lo que requiere comprender en toda su
profundidad el problema a resolver.
Aspectos culturales. Categora importante dentro de los requerimientos; algunos son evidentes (p.ej.
seguridad y privacidad), otros mucho mas ocultos provienen de aspectos procedentes de la burocracia,
la tradicin, etc., en general difciles de modelar.
Restricciones de diseo. Las restricciones sobre los modelos y los mtodos usados son impuestas por
el contexto del mundo real en el que los sistemas sern usados, y por las tecnologas que se usarn en
el desarrollo de los sistemas.
Restricciones econmicas. Limitacin de recursos, p.ej. financiacin, tiempo y herramientas
disponibles.
3.2.1 Requerimientos de usuario

Se usan los ya disponibles en el estndar ISO/TS18303 [18303] que configura el conjunto de
requerimientos clnicos y tcnicos que debe soportar la arquitectura de una HCE que permita usar,
compartir e intercambiar partes o historias enteras, a travs de diferentes proveedores de servicios,
pases y sectores de salud.
Los aproximadamente 600 requerimientos iniciales se obtuvieron de mas 30 fuentes distintas
[Kalral], entre las que se encuentran los proyectos europeos GEHR [Gehr] y EHCR-SupA
[EHCRSupA] en los que el autor particip como investigador. Un posterior proceso de refinamiento
ha dejado el nmero de requerimientos en 123. Se refieren a temas que estn agrupados en el
siguiente formato jerrquico:
Estructura. Organizacin del registro (secciones, formato, portabilidad, usos secundarios, archivo).
Organizacin de los datos (datos estructurados, datos no-estructurados, datos clnicos, datos
administrativos). Tipos y forma de datos (tipos de datos, soporte para diferentes tipos de datos, datos
referencia, datos de contexto, enlaces). Soporte de la representacin de conceptos (soporte para
mltiples sistemas de codificacin, representacin unvoca de la informacin, representacin de
texto).
23
Procesos. Procesos clnicos (Soporte de procesos clnicos, aspectos y problemas del estado de salud,
razonamiento clnico, soporte a la decisin-guas-protocolos, plan de atencin, rdenes y servicios,
atencin integrada, aseguramiento de la calidad). Registro de procesos (captura de datos,
recuperacin-peticin-vistas de datos, presentacin de datos, escalabilidad)
Comunicacin. Mensajes. Intercambio de extractos.
Privacidad y proteccin. Privacidad y confidencialidad. Consentimiento. Control de acceso.
Integridad. Auditacin.
Mdico-Legal. Soporte de requerimientos legales. Actores (paciente, identificacin del paciente,
identificacin del usuario, identificacin del agente sanitario, autor responsable, atestado de entradas).
Competencia clnica. Exactitud. Preservacin del contexto. Permanencia. Control de versiones.
tica. Soporte a la justificacin tica.
Consumidor/Cultural. Soporte de aspectos del consumidor. Soporte de aspectos culturales.
Evolucin. Soporte de la evolucin de la arquitectura y sistemas de HCE.
3.2.2 Paradigmas de Diseo

La propuesta de la openEHR Foundation para unos modelos que van a tratar sobre todo con la
complejidad y el cambio en el conocimiento e informacin manejada, se basa sobre los siguientes tres
paradigmas:
Separacin de responsabilidades
Separacin de puntos de vista
Separacin Conocimiento/Informacin
La finalidad ltima es conseguir im diseo de modelos que permitan que las modificaciones en la
representacin del conocimiento puedan ser incorporadas al sistema posteriormente a su desarrollo y
uso sin necesidad de reescribir software.
3.2.2.1
Separacin de responsabilidades
Los sistemas verdaderamente complejos solo son tratables si su funcionalidad se divide en partes o
subsistemas, construyendo lo que Maier [Maier] denomina un Sistema de Sistemas. Las principales
caractersticas son:
Cada sistema o componente debe tener una responsabilidad bien definida. Es necesario por tanto
identificar las responsabilidades de cada componente, permitiendo un modelado, un desarrollo y
un uso independientes para cada sistema. Cada componente debe ser usable y reusable por s
mismo.
La interdependencia entre los componentes debe ser baja, y tambin debe serlo entre sus modelos.
Es necesario por tanto que exista un bajo acoplamiento entre los modelos de cada componente.
24
Captulo 3. Situacin actual nomal2acin HCE

Los interfaces entre los sistemas deben estar definidos con claridad. Es necesario por tanto
describir formalmente los interfaces entre los modelos.
Sin duda una de la mejores contribuciones en este apartado sigue siendo el trabajo del grupo
OMG/HDTF [OMG] dedicado a la especificacin de servicios y de interfaces para esos servicios en el
dominio sanitario.
Posterior experiencia, tanto acadmica como de desarrollos prcticos, ha conducido a describir como
buena, es decir presentando una responsabilidad clara, un bajo acoplamiento, y un interfaz definido,
una particin del universo del dominio en servicios/responsabilidades/funcionalidades tales como las
siguientes^:
-
Historia Clnica Electrnica (HCE eq EHR).

Seguridad. Control de acceso.
Identificacin de las partes; p.ej. Pacientes, Demographics.
Datos de Referencia; p.j. Medicamentos, interacciones entre
Terminologa.
Modelos clnicos (modelos formales de conceptos clnicos).
Flujo de trabajo (soporte a los procesos asistenciales).
Gestin de eventos; p.ej. gestin de rdenes.
Guas clnicas. Protocolos y Vas de asistencia.
Soporte a la toma de decisiones (descansa en codificacin y modelos clnicos).
Aspectos administrativos de la gestin de pacientes (Admin).
Localizacin de recursos.
Cada sistema/servicio/modelo es relativamente pequeo y puede ser especificado, construido y usado

de forma independiente. Cada servicio provee informacin a los dems via un interfaz. El propio
proceso de estandarizacin (un estndar para cada servicio) asegurar que los servicios podrn
comunicar entre s, y por tanto cooperar.
3.2.2.2
Separacin de puntos de vista
La estructura de cada estndar se puede describir siguiendo el estndar ISO Modelo de Referencia
para Procesamiento Distribuido en Sistemas Abiertos (ISO RM/ODP) [ISO/RM], el cual usa cinco
puntos de vista para distinguir los diferentes aspectos de los sistemas distribuidos:
^ Esta divisin del dominio (TICs en la medicina clnica) obviamente no est estandarizada, y probablemente
tarde en estarlo, si es que alguna vez llega a estar. Algunos servicios/sistemas se adoptarn rpidamente de
forma generalizada; otros, la experiencia ir "asentando" cual es la divisin mas idnea para cada campo de
actividad dentro del dominio.
25
Captulo 3. Situacin actual nomalizacin HCE

Empresa. Incluye las denominadas actividades de negocio, es decir, propsito, responsabilidad y
polticas del sistema especificado.
Informacin. Incluye la semntica de la informacin que necesita ser almacenada y procesada en el
sistema.
Computacin. Incluye la descripcin del sistema como un conjunto de objetos que interactan a travs
de los interfaces, permitiendo la distribucin del sistema.
Ingeniera. Incluye los mecanismos que soportan la distribucin.
Tecnolgico. Incluye la descripcin de los componentes con los que se construye el sistema
Como consecuencia de este paradigma, cada sistema (antes por la influencia 'middleware' se ha
llamado servicio) necesita ser definido en trminos de los distintos puntos de vista. En la etapa que
nos ocupa (proceso anlisis/diseo) los nicos puntos de vista de inters son: Informacin (lo que
entra y es procesado por del sistema) y Computacin (interfaz del servicio).
Por tanto, para cada servicio del apartado anterior se habr de elaborar un modelo desde el punto de
vista informacin, que se denomina Modelo de Referencia; y un modelo desde el punto de vista
computacin, que se denomina Modelo de Servicio. El modelo de servicio es un API de alto nivel (los
definidos por OMG-HDTF [OMG], p.ej PIDS, TQS, COAS, etc, pertenecen a este nivel).
3.2.2.3
Separacin Conocimiento / Informacin
Del conjunto global de ideas en un dominio, la distincin entre conocimiento e informacin es como
sigue:
Conocimiento. Hechos que han sido acumulados a lo largo del tiempo, procedentes de muchas
fuentes, y que son verdad en todas las instancias de las entidades que se describen. Son declaraciones
acerca de clases de cosas (entidades), p.j. "El septum atrial separa las aurculas izquierda y derecha
del corazn humano". Son el tipo de declaraciones que estn en las enciclopedias y las bases de
conocimiento, y se pueden considerar como modelos mentales de entidades del dominio.
Informacin. Hechos u opiniones (declaraciones) recogidos_de o relativos_a entidades especficas;
p.ej Jos Espaol (14 aos) tiene un defecto en el septum atrial. Frecuentemente se denominan Datos
a estas declaraciones (informacin) cuando se almacenan y gestionan en un sistema informtico.
Informacin es lo que los sistemas crean y procesan.
Un tem de informacin es una instancia de un concepto de informacin (p.ej. una clase en un modelo
orientado a objetos, una entidad en un modelo entidad/relacin, etc); pero tambin es un ejemplar de
un tem de conocimiento (p.ej modelos de Persona, Resultado_de_Prueba, Orden, etc)
A la hora de disear un sistema, la aproximacin clsica ha sido construir ambos tipos de semntica
(informacin y conocimiento) en un nico modelo desde el ptmto_de_vista informacin.
26
Independientemente de la metodologa usada (p.ej. orientada a objetos, E/R, etc.), se mezclaban

ambos sobre el software y las bases de datos utilizadas.
El desarrollador del modelo y el especialista del dominio que aporta el conocimiento del dominio,
mediante discusin ad-hoc identificaban los conceptos del dominio y diseaban un nico modelo que
se mapeaba sobre un esquema (p.ej. relacional, orientado a objetos, etc), dando lugar a un desarrollo
software que manejaba un almacn de datos definido por el esquema.
Un diagrama de grandes bloques puede vers en la figura 2.1.
Entorno de Usuario
Entorno Desarrollo
basado
Figura 3.1 Modelo clsico (nico) de desarrollo.
Sin embargo, esto ha demostrado ser una mala idea, por varias razones:
Se implican en el proceso de diseo personas con muy diferentes experiencias y habilidades; forzarlos
a trabajar en estrecha conjuncin ha sido tradicionalmente una fuente constante de conflictos, sobre
todo por la obligatoriedad de aprender ambos, conceptos y terminologa del dominio del otro, siendo
casi siempre poco efectivo el aprendizaje de nuevos formalismos.
Pero lo realmente ineficaz a medio plazo, es que el diseo as realizado se vuelve rpidamente
obsoleto, o nunca se termina del todo. El conocimiento est siempre creciendo, siempre cambiando, y
el conocimiento de entidades complejas es complejo. Todo ello ha conducido tradicionalmente a
sistemas con grandes problemas de mantenimiento y actualizacin.
Es necesario aprovechar que en todo modelo existen dos grupos bien diferenciados de conceptos: Un
nmero pequeo de conceptos genricos, la "gramtica del dominio", que es manejado por el
desarrollador del modelo; y un nmero muy grande de conceptos - modelos de conocimiento- que son
entendidos y descritos por los especialistas del dominio.
Se propone en el proceso de anlisis/diseo usar una metodologa basada en un modelo de: gramtica
+ vocabulario + frases, es decir un modelo tcnico que sea capaz de expresar instancias de
conocinento modeladas separadamente como conceptos especficos de conocimiento del dominio.
27
Captulo 3. Situacin actual nomazadn HCE
Dicho en otros trminos, separar conocimiento de informacin, es decir, separar dentro del
pxmto_de_vista informacin dos modelos: un Modelo de Referencia y un Modelo de Conocimiento.
El modelo de referencia maneja items de informacin (conceptos genricos); el modelo de
conocimiento maneja items de conocimiento (modelos de conocimiento).
Esta metodologa da respuesta a los dos grandes problemas existentes. Al problema de requerimientos
del cambio: el modelo de referencia es pequeo, genrico y a prueba de cambios. Y al problema de
gestin de la colaboracin en el desarrollo: desacoplo del proceso llevado a cabo por el experto del
dominio y el proceso de construccin del software. Permitir a los dos grupos de personas trabajar de
forma independiente y comunicarse a travs de herramientas de colaboracin.
3.2.3 Nueva metodologa de desarrollo

Basado en los tres paradigmas de diseo descritos en el apartado anterior, se propone una metodoga
cuyas caractersticas mas importantes son dos: la existencia de un doble modelo (referencia y
conocimiento), y el desarrollo controlado de los conceptos del dominio manejados por los futuros
sistemas de informacin.
3.2.3.1
Terminologa en la HCE
La necesidad de llegar a un desarrollo controlado de los conceptos del dominio se hace evidente
atendiendo a la tradicional dificultad existente en la relacin terminologas/HCE. Una descripcin
muy esquemtica del problema se describe a continuacin.
En el nivel tcnico mas elemental, las terminologas se usan en la HCE para tres propsitos:
Nombres de items, los cuales forman el contexto semntico de los datos (valores).
Datos (valores), para valores expresados textualmente.
Preguntas, para intentar encontrar en la HCE informacin necesitada.
El mayor problema, y la mayor causa de confusin proviene de la necesidad de especificar
correctamente el significado de trminos que son combinacin de otros trminos. Rector [Rect2]
caracteriza el problema usando dos nociones:
Encapsulacin, cantidad y forma de la informacin en una entidad terminolgica.
Eleccin entre trminos pre-coordinados (predefinidos usando una nica entidad terminolgica) y
post-coordinados (creados en el "punto de uso" por la combinacin de pequeas entidades
predefinidas).
28
Es obvio que existen muchos trminos que son compuestos de trminos mas bsicos, y su inclusin en
una terminologa determinada provocara una explosin combinacional de trminos pre-coordinados
que la hara inmanejable [Rectl][Rect2].
Se reconocen en general cuatro clases de significado de trminos combinados:
Cualificacin. Trminos cualifcadores aadidos a un trmino raz, hacen el significado mas
especfico. Las instancias del nuevo trmino lo son siempre del raz. Deben ser representados de tal
forma que preguntas generales realizadas a la HCE acerca del trmino raz, sean positivamente
contestadas.
Modificacin. Trminos modificadores que cambian el significado del trmino raz, (p.ej trminos
adicionales riesgo_de, miedo_de). Las instancias del nuevo trmino pueden no serlo del raz. Muy
difcil encontrar reglas de representacin; en la gran mayora de los casos a preguntas generales
reaUzadas a la HCE acerca del trmino raz, han de ser negativamente contestadas.
Negacin. Es un tipo de modificacin. Muy problemtica su representacin.
Especificacin. Casi todas las combinaciones de trminos que definen una entidad anatmica,
fisiolgica o bioqumica, especifican una entidad precisa o un aspecto de una entidad mayor, es decir,
son instancias de especificacin. Tambin los son las combinaciones de trminos que forman los
nombres de secciones; especifican el tipo de informacin que se espera est registrada en esa seccin.
En principio existen dos posibles soluciones a los problemas que plantea la pre-coordinacin: la postcoordinacin de trminos (fuera de la terminologa) y el uso de modelos estructurados.
Post-coordinacin. El modelo de referencia debera incluir un tipo de Trmino_codificado que
permitiera un trmino raz y tuviera trminos adicionales asociados, indicando claramente si el
significado es cualificacin o modificacin. Pero en muchos casos de trminos con modificadores es
bastante obvio que no es una buena solucin (p.ej diversas opciones en un diagnstico diferencial). En
el caso de combinaciones de trminos cuya funcin es especificar alguna entidad, es evidente que
puede llegar a haber tal cantidad, que llega a ser inmanejaable.
Modelos estructurados. Modelos que describen coordinaciones particulares de trminos, tal y como
son usadas en un contexto particular. Esta aproximacin es la escogida desde hace tiempo en todas las
organizaciones de estandarizacin: CEN (categoras estructuradas) [12226], openEHR (arquetipos)
[Beal3], HL7 (tmplales) [Elk], dado que provee una plataforma de estandarizacin de la postcoordinacin de trminos, de acuerdo a usos reales.
3,2.3.2
Modelo de Referencia
El modelo de referencia es igual a la gramtica, es decir, es un conjunto de reglas para construir

sentencias. Contiene los conceptos mas genricos del dominio, por lo que si est bien diseado, no
cambia, y precisamente por ello es por lo que puede ser utilizado para comunicar. Pero para describir
algo real necesita:
29
Un diccionario de palabras (vocabulario)

Sentencias con significado (conceptos vlidos de conocimiento del dominio).
Solo con gramtica + vocabulario se pueden construir sentencias sin ningn significado; son vlidas
tcnicamente desde un punto de vista formal, pero no lo son desde su semntica.
El modelo de referencia ha de ser lo menos voltil posible, por lo tanto en su elaboracin se deben
seguir normas como las siguientes:
Un modelo de referencia debe incluir una clase solamente si existe un anq>lio acuerdo de que es
necesaria, y su inclusin no viola otros principios de modelado.
Clases que representan conceptos lgicamente distintos, sin importar cuan similares sean, debern
aparecer separadas en el modelo de referencia, porque ellas pueden ser significativamente
distintas en el desarrollo.
Un modelo de referencia debe incluir un atributo o una relacin solamente si al menos existe un
amplio acuerdo sobre un caso de uso para l.
Un modelo de referencia debera excluir clases que modelan directamente entidades especficas
del dominio (p.ej paciente, medicacin), porque su propsito es construir bloques genricos para
expresar tales entidades, no modelarlas directamente.
Acerca del diseo de clases y atributos incluidos en el modelo de referencia, Page-Jones [PagJ] invoca
dos principios bsicos de un buen diseo de software: Alta cohesin (relacin entre los elementos que
constituyen una unidad encapsulada), y bajo acoplamiento (medida de la dependencia entre dos
elementos software).
Pruebas que pueden realizarse a un modelo de referencia para medir su cohesin son:
Para cualquier instancia de una clase, es aplicable en todos los posibles contextos en los que
puede ser creada?
Para cualquier atributo (incluso los heredados) de una clase, es apHcable a la mayora de las
instancias de la clase, independientemente de dnde fueron creadas?
3.2.3.3
Modelo de Conocimiento
Un dominio contiene conceptos especficos y relaciones entre esos conceptos:

Conceptos. Descripciones coherentes de entidades del dominio que son identificados separadamente
por usuarios del dominio y usados de una manera autocontenida para registrar informacin.
Relaciones. Composicin, especializacin/generaUzacin.
El modelo de conocimiento maneja conceptos que a su vez pueden ser representados como estructuras
(modelos) de conocimiento. Un concepto se puede especificar mediante:
Un modelo formal.
Reconocido por expertos del dominio y los usuarios,
30
Unvocamente identificado
Autocontenido, y
Con una determinada granularidad de registro/transmisin de informacin.
Un concepto puede componerse de otros conceptos, o puede ser la especializacin de otro.
Una buena base de modelado es obligar a que la relacin entre conocimiento e informacin sea la
siguiente: La informacin debera ser creada tanto como sea posible, como imagen de los
componentes estructurales de conocimiento (conceptos del dominio). Es decir, los items de
conocimiento sonpatrones a los cuales los items de informacin deben ser conformes.
De esta forma, en un contexto clnico determinado, la informacin debera ser registrada de acuerdo a
una estructura de conocimiento adecuada, previamente consensuada.
Ser por tanto necesario establecer reglas y llegar a acuerdos generalizados sobre qu es un concepto
y qu no lo es, y sobre los distintos niveles de complejidad existentes; o lo que es lo mismo, llegar a
acuerdos para poder llegar a identificar las clases y los atributos del modelo de referencia por un lado,
y por otro, identificar los conceptos vlidos del dominio.
En el sistema HCE (o servicio 'EHR'), ejemplos de conceptos y de no-conceptos son:
"Presin arterial" es im concepto, pero no lo es "presin sistlica".
"Orden de medicacin", pero no "nombre genrico".
"Direccin", pero no "nombre de la calle".
y ejemplos de conceptos compuestos:
"Prescripcin" = lista de "orden de medicacin" + las instrucciones
"historia familiar" = lista de "historia de miembro familiar"
3.2.3.4
Variabilidad en los conceptos
El problema de la variabilidad dentro de un concepto queda explicitado con el hecho de que se sigue
llamando a una instancia de conocimiento "presin arterial" aunque: Algunos elementos sean
optativos; o puedan agregarse nuevos elementos por cambio en el protocolo de medida (p.ej cuarto
soitdo); o aparezcan cambios en los nombres de los elementos (p.ej "presin sangunea sistlica" vs
"sistlica" vs "presin sistlica" vs "presin, sistlica").
En un caso mas complejo, como es el concepto "orden de medicacin", puede estar en un estado entre
varios posibles. La variabilidad est entonces definida por una mquina de estados, que contiene:
Estados (propuesto, ordenado, en_ejecucin, cancelado, retrasado, abortado, completado) y eventos
(ordenar, comenzar, cancelar, abortar, finalizar, etc).
El problema es que en general, siendo el mismo concepto, se reconocen muchas posibles variaciones
sobre una definicin ideal de dicho concepto. De hecho un concepto puede ser una constelacin de
posibles casos.
31
Para controlar de alguna forma esa variabilidad es necesario ser capaces de definir restricciones sobre:
Nombres de elementos (p.ej. que casen con patrones / listas de trminos)
-
Tipos valor, p.ej. CANTIDAD | RANGO_CANTIDAD

Valor de rangos, p.ej. O - 500 mm[Hg]
Estructura: optativo, obligatorio, nuevo
etc
de esta forma se llega a que un concepto del dominio sea en realidad formalmente un modelo de
restricciones.
Lo que realmente se podra es expresar formalmente un concepto del dominio como un conjunto de
restricciones sobre las instancias de las clases del modelo de referencia. Ver Tabla 2.1
Tabla 3.1 Relacin entre instancias de los modelos de refrencia y conocimiento.

Instancia en el modelo de referencia
valor
variable de estado (valor)
tipo
relacin
> 1 elemento
lista
tabla
Instancia en el modelo de conocimiento

rango del valor / unidades, etc
estado / tabla de eventos
conjunto de tipos
cardinalidad de la relacin
relacin funcional
N, clasificar, ordenar, etc
N, nombres de columnas, nmero de las, etc
llegando finalmente a que el modelo de conocimiento sea un modelo de restricciones del modelo de
referencia. Las instancias de este modelo de restricciones son denominados Arquetipos.
3.2.3.5
Arquetipos
Un arquetipo se define como un modelo formal de un concepto clnico en-uso (no un concepto de
referencia) [Beal3]. La definicin de ese concepto perteneciente al dominio puede ser voltil. Cada
arquetipo, perteneciente a la parte de conocimiento del dominio, es xm concepto completo y distinto
del dominio. Es presentado como estructura + restricciones.
Los arquetipos definen configuraciones vlidas de los datos (por tanto, instancias del modelo de
referencia), pobladas por la terminologa del dominio. Los arquetipos se pueden: conq)oner,
especializar y versionear. Los arquetipos tienen 'id' y 'paths' para ser identificados y localizados.
Los arquetipos son creados por especialistas del dominio usando herramientas y salvndolo como un
XML-esquema (hasta ahora), o mas recientemente en documentos escritos en el lenguaje ADL.
Los sistemas los usan para compartir conceptos del dominio, controlar la creacin y aprobacin de
datos, y para realizar preguntas. Son la base para realizar preguntas/peticiones inteligentes.
32

El modelo de conocimiento (tambin llamado modelo de arquetipos) cuyas instancias son los
arquetipos, est basado en el modelo de referencia, ver figura 3.2, tal y como se expuso en el apartado
anterior (ver Tabla 3.1).
Un manera de ayudar a comprender mejor qu son los arquetipos es realizar una analoga con el
lenguaje, ver Tabla 3.2.
Tabla 2.2 Analoga con el lenguaje
Lenguaje Natural
Escenario de modelado
Significado
Gramtica
Modelo de referencia
Vocabulario
Sentencias
Sentencias modelo
Trminos codificados
Tipos (valores)
Datos
Arquetipos
Modelo de sentencias vlidas,

(estructuras de datos vlidas)
Diccionario de palabras permitidas
Meta-gramtica
Modelo de Arquetipos
3.2.3.6
Informacin real
Modelos sentencias con significado,
(conceptos de conocimiento del dominio)
Modelo todas las sentencias modelo,
(modelo de conocimiento).
Propuesta con doble modelo
Como resumen de los apartados anteriores se puede invocar que los principios sobre los que se asienta
la propuesta del doble modelo son los siguientes:
Un modelo de referencia debe describir solamente conceptos del dominio genricos y no voltiles,
para maximizar su aplicabilidad e inmunidad al cambio.
Entorno de Referencia + Conocimiento
Entorno de Usuario
Entorno Desarrollo
Figura 3.2 Diagrama de bloques del doble modelo
33
Separacin del dominio y el desarrollo del software. El software y las bases de datos deben estar
basados en el modelo de referencia, no en los modelos de conocimiento del dominio. La informacin
(los datos) son instancias del modelo de referencia.
Otros aspectos tcnicos de inters son:
Lx)s arquetipos son definiciones formalizadas de conocimiento y estandarizadas. Se puede
proporcionar interoperabilidad entre sistemas a nivel conceptual (interoperabilidad semntica).
Se podr realizar procesamiento automtico sofisticado. Pueden asumirse arquetipos y semntica
del modelo de referencia.
Rpida estandarizacin y despliegue: el modelo de referencia y el software que maneja los
mensajes puede terminarse y desplegarse sin saber ningn arquetipo de antemano; los sistemas los
procesarn correctamente cuando ellos lleguen 'online'.
Localizacin: los arquetipos creados por especialistas del dominio no requerirn ningn tipo de
acreditacin para ser usados localmente.
3.2.4 Representacin del conocimiento del dominio

En este apartado se describen brevemente los principios que subyacen a los recientes acuerdos en el
seno de 'EHRcom Task Forc' sobre la revisin de CEN ENV13606:1999, y que en ltima instancia
lo que pretenden es resolver, mediante una nueva metodologa, el 'gap' existente entre el nivel de las
instancias del modelo de referencia y el nivel mas bajo del contenido, el vocabulario (palabras,
trminos y frases) utilizado.
El problema del significado de la informacin, y la preservacin de ese significado cuando la
informacin es transferida entre sistemas de informacin (interoperabilidad semntica), es complejo.
Un primer paso es comprender que el significado no es producto solamente del contenido, sino del
contenido + contexto.
Tradicionalmente el significado de la informacin era producto del sistema de informacin (esquema
usado, p.ej relacional) en el cual estaba almacenado y de la terminologa usada. La semntica del
sistema de informacin, en mayor o menor extensin, estaba presente en el modelo de la informacin
(de referencia). El 'gap' semntico existente entre el modelo de referencia y el vocabulario,
usualmente era puenteado mediante cdigo de programacin y convenciones acordadas con los
usuarios. Esto significaba mezclar la semntica del nivel del dominio con el sistema de informacin
mismo, lo que ha conducido a sistemas que gestionan mal el manejo de informacin que, como es el
caso de este domiio, a veces es compleja y cambia frecuentemente.
Muchos de los sistemas de informacin actuales utilizan metadatos, aproximacin a menudo muy
sinlar a los arquetipos, pero no establecen una separacin tan radical y formalizada entre
34
informacin y conocimiento. En realidad, el doble modelo supone de hecho una importante

innovacin en el campo del desarrollo de software para sistemas de informacin.
La representacin del conocimiento descansa sobre dos tipos de anlisis: ontolgico y de contexto,
realizndose despus una propuesta de uso de arquetipos y templates [Beall].
3.2.4.1
Anlisis ontolgico
El anlisis ontolgico proporciona una clasificacin multinivel de conceptos de conocimiento del

dominio [Fraz]. La suma de conceptos, expresada formalmente, en un determinado nivel de
abstraccin en el dominio es una ontologa. Proporciona tambin una gua parcial para una estructura
gruesa de un dominio.
Nivel 0. Principios. Contiene los conceptos que expresan el conocimiento de hechos (procesos y
entidades) aceptados, que son verdad en todas las instancias. Son los elementos bsicos no-voltiles y
necesarios para que pueda existir un lenguaje. El conocimiento en este nivel es independiente de los
usuarios, o de procesos tales como asistencia o educacin, que admiten interpretaciones.
En este nivel se incluye el contenido de los vocabularios controlados o terminologas. Algunos son
verdaderas redes semnticas, p.ej. SNOMED-CT [SNOMED]; otros son poco mas que diccionarios de
trminos, p.ej. ICD [ICD] e ICPC [ICPC]. Tambin se incluyen en este nivel declaraciones acerca de
datos bsicos (p.ej cantidades).
Nivel 1. Descriptivo. Contiene los conceptos (composiciones de conceptos del nivel 0) que expresan
la descripcin de observaciones, pruebas (tests), prescripciones u rdenes ocurridas en el dominio.
Son miles los conceptos existentes en este nivel, pero todos tienen algo en comn, son la descripcin
autocontenida mas pequea de fenmenos diferenciados. Ejemplos de conceptos de este nivel son:
Observaciones (p.ej. presin sangunea, ndice de masa corporal, etc), resultados de pruebas (en
bioqumica, microbiologa, radiologa, cardiologa, etc), prescripciones (de medicamentos, etc). Son
entidades de informacin de uso clnico que representan composiciones particulares de varios
trminos del nivel anterior.
Nivel 2. Organizativo. Contiene conceptos creados por los profesionales del dominio para ordenar las
enormes cantidades existentes de tems descriptivos del nivel anterior sin relacionar. Los conceptos de
este nivel se construyen con jerarquas de nombres (usados como etiquetas) que pueden ser
codificados usando terminologa.
Es frecuente, sobre todo en atencin primaria, cuando se utiliza una historia orientada_ajproblemas,
organizar los items descriptivos que se producen en im encuentro mdico-paciente, mediante una
jerarqua de cabeceras denominada problema/(subjetivo, objetivo, evaluacin, plan).
35
Existen muchas otras estructuras de cabeceras [Nhsh], denominadas en muchos casos secciones, que
se utiUzan en la documentacin relativa a muchos tipos de Informes (p.ej de una intervencin
quirrgica, de anestesia, etc), exmenes (p.ej cardiovascular, oftalmolgico, etc), evaluaciones (p.ej
estado mental, etc) o resmenes (p.ej de alta, de derivacin, etc).
Nivel 3. Temtico. Contiene conceptos que expresan importantes actividades clnicas realizadas al (o
para el) paciente, o importantes categoras de conocimiento acerca del paciente. Estn relacionados
con la captura de la informacin, la contribucin de informacin a la historia, o la revisin
(incluyendo modificacin) que pueda hacerse en una sesin o un encuentro. Los conceptos en este
nivel suelen constituir la unidad de comunicacin, por ello necesitan ser completos respecto al tema
de que se trate, es decir deben incluir toda la informacin contextual relativa a su registro o creacin
(ver siguiente apartado).
Se corresponden con las clases 'COMPOSITION' (CEN), TRANSACTION (openEHR) y CDA
(HL7v3) [CDA].
Son ejemplos de conceptos de este nivel los incluidos en categoras como: items persistentes (p.ej
historia familiar, historia de vacunacin, lista de problemas, medicacin actual, precauciones
teraputicas, etc), items demogrficos (p.ej identidad del paciente, identidad del profesional sanitario,
etc), eventos (p.ej encuentro, prescripcin, prueba de laboratorio, etc), y procesos (p.ej plan de
cuidados, etc).
Aunque no siempre son incluidos en todos los trabajos [Beall], otros dos lveles de ontologas
pueden ser tenidos en cuenta:
Nivel 4. Histrico. Contiene conceptos que permiten agrupar a lo largo del tiempo composiciones del
nivel temtico anterior. Ejemplos son las categoras 'items persistentes', 'items demogrficos', o
grupos de eventos (p.ej episodios) y procesos.
Nivel 5. Comunicacin. Contiene conceptos que expresan la seleccin y el empaquetamiento de
informacin para comunicar (compartir) con otros usuarios. Se corresponden con las clases
EHR_Extract (CEN, openEHR) y CDA document (HL7v3)
3.2.4.2
Anlisis del contexto
El anlisis del contexto describe cmo y en qu circunstancias fue adquirida la informacin y cmo
permanece vlida [RosMl][Kalra2][Beall].
Para una correcta comprensin de todo lo aqu involucrado es necesario en primer lugar definir:
Situacin. Regin lintada del espacio-tiempo en la cual tiene lugar una actividad determinada.
Contexto. Suficiente descripcin de una situacin que permita cualificar cualquier conocimiento
creado o registrado en esa situacin.
36
En segundo lugar es necesario distinguir entre la realidad y el registro de esa realidad; ambas deben
ser recogidas en los modelos. Es necesario registrar no solo detalles de la realidad (p.ej declaraciones
clnicas, entradas), sino tambin detalles del registro (p.ej folder, seccin).
Aspectos fundamentales a tener en cuenta en este proceso de diferenciacin son los siguientes:
Los eventos asistenciales, se conceptualizan como sesiones clnicas, en las cuales puede haber
cualquier nmero de declaraciones clnicas.
Las sesiones clnicas dan lugar a cambios en la HCE. Cada cambio es conceptualizado como una
contribucin. Estos cambios, una vez producidos, llevan a la HCE a un nuevo (y consistente) estado.
Las declaraciones clnicas presentan una estructura {espacial y temporal), y eventualmente datos.
El modelo de la HCE ha de describir una estructura interna informada por: la estructura de lo que est
siendo registrado (p.ej entradas); la necesidad de organizarlo (p.ej secciones y folders), y la necesidad
de controlar el cambio de forma adecuada (p.ej composiciones y contribuciones).
Pero para que el conocimiento adquirido permanezca vlido sobre el espacio y el tiempo, el contexto
completo en el que fue creado o registrado necesita ser identificado, descrito e incluido en el modelo
de referencia (Cap.4, aptdo 4.1.1). Sin la informacin contextual no hay garanta de que el significado
de cualquier item, no importa cmo de ambiguo parezca cuando es registrado, se mantendr cuando
sea usado im tiempo mas tarde, por otros usuarios, o en otros sistemas.
Se identifican los siguientes tipos diferentes de contexto:
Contextos de la propia informacin, del contenido:
Contexto semntico (espacial)
Contexto temporal
Contextos del mundo real:
Contexto de generacin de la informacin
Contexto de sesin clnica, y
Contexto del proveedor
Contextos del sistema de informacin:
Contexto de interaccin del usuario
Contexto histrico
Contexto de comunicacin
Todos los apartados que siguen tienen su reflejo en el modelo EHR_Extract (Cap.4, aptdo 4.1.1).
Contexto semntico. El contenido de los conceptos (sobre todo los pertenecientes al nivel 1) se
compone de datos (valores) que pueden generalmente ser expresados en trminos de estructuras
semnticas complejas de datos (p.ej 'single', lista, rbol, tabla), y que necesitan informacin
contextual adicional para su localizacin, p.ej anatmica.
El modelo de referencia debe incluir tipos que soporten explcitamente esas estructuras espaciales de
datos.
37
Captulo 3. Situacin actual nomazacin HCE
Contexto temporal. Los valores situados dentro de las estructuras deben estar situados en un contexto
temporal. Deben soportar representar el pasado, incluyendo atributos como, p.ej valor simple en el
tiempo, serie temporal peridica discreta (valor de inicio, periodo y nmero de repeticiones), serie
temporal aperidica (lista de valores simples en el tiempo no separados por la misma duracin),
segmentos continuos de tiempo. Tambin el futuro tanto peridico (valor de inicio, periodo),
aperidico, como complejo (p.ej cada dos lunes de 8:00 a 9:00). Incluso el futuro expresado en
trminos de otras condiciones, p.ej cuando el dolor cese, cuando el peso sea < 80 Kg.
El modelo de referencia debe incluir tipos que soporten explcitamente esas estructuras temporales.
Contexto de generacin de la informacin. Situacin de granularidad pequea, asociada a la actividad
de un humano o una mquina que genera datos (valores) situados en el tiempo.
Incluye atributos comunes a cualquier tipo de informacin, p.ej: sujeto (a quin se refiere la
informacin), sujeto_relacionado (idem), generador (observador o medidor), tiempo (cuando se hace
la observacin), y razn (referencia a una fuente de conocimiento, a una gua clnica, o una
justificacin clnica). Tambin incluye atributos especficos de las distintas especies de informacin:
Emprica (p.ej localizacin), protocolo, anormalidad.
No-emprica (p.ej confidencialidad).
Prescriptiva -intenciones, rdenes, comandos- (p.ej tiempo de ejecucin), estado (mquina de
estados).
Procedimental (p.ej finalidad), acciones -conjunto de instrucciones llevados a cabo-, resultados,
varianza -entre finalidad y resultados-, estado, periodo de ejecucin previsto, periodo real de
ejecucin.
El modelo de referencia debe incluir tipos para todas las especies de informacin (emprica, noemprica, instruccional o procedimental) y para cada tipo, atributos suficientes para la informacin
contextual relativa a su generacin.
Contexto de sesin clnica. La informacin generada -recogida o creada- es, de forma mas o menos
simultnea o posteriormente, organizada y aportada a la HCE durante y debido a actividades que
conforman una sesin. Una sesin puede ser un encuentro paciente-mdico, o la elaboracin de un
informe con los resultados de una prueba. Dentro de una sesin pueden darse mltiples situaciones de
generacin de informacin. Incluye los siguientes atributos, p.ej agente sanitario, agente sanitario
legalmente responsable, sujeto (usualmente el paciente), tiempo de comienzo (de la sesin), tiempo de
finalizacin, motivacin, lenguaje, y otros.
El modelo de referencia debe incluir tipos para soportar el contexto clnico.
Contexto del proveedor. Informacin sobre el proveedor del servicio. Incluye los atributos: identidad
de la organizacin, localizacin, etc.
38
Captulo 3. Situacin actual nomaUzadn HCE
Contexto de interaccin del usuario. Cuando el usuario realiza la aportacin a la HCE se produce una
interaccin con el sistema de informacin, caracterizado por los siguientes atributos: sujeto al que se
refiere, persona que realiza la aportacin, tiempo de la aportacin, persona que autoriz la aportacin,
otro(s) corresponsable(s), lenguaje, local (tiempo, territorio, etc), conjunto de caracteres usado, nodo
(sistema), y otros.
Contexto histrico. Es la propia HCE como acumulador de los sucesivos cambios. El nico atributo
especfico es la identidad del paciente.
Contexto de comunicacin. Informacin sobre la situacin en la que un Extract es comundado de un
sistema a otro. Incluye los atributos: nodo original, nodo destino, agente sanitario solicitante, agente
sanitario receptor, agente sanitario que autoriza la creacin y envo del Extract, tiempo en el que se
produce el envo, razn de la solicitud.
Una relacin de ontologas, contextos y su proyeccin en el modelo de referencia del CEN prENV
13606-1 EHR_Extract (Cap.4, aptdo 4.1.1) se puede ver en la Tabla 3.3
Tabla 3.3 Relacin entre ontologas, contextos y modelo de referencia
Nivel ontolgico
Contexto
Modelo de referencia
Principios
Desa:iptivo
Valores
Semntico
Temporal
Declaracin clnica
~
Sesin clnica
Histrico
Comunicacin
Datos (valores)
Datos genricos
Organizador
Temtico
Histrico
Comunicacin
Entradas
Secciones
Composiciones
EHR
Extract
Para la informacin sanitaria, las mayores dificultades de contextualizarla adecuadamente incluyen

los siguientes problemas: representar relaciones semnticas complejas, establecer difciles contextos
temporales, y diferenciar el contexto de las actividades clnicas reales y el registro de esas actividades
en el sistema de informacin.
3.2.4.3
Propuesta sobre Arquetipos y Tmplales
Dejando al margen el diseo y calidad de terminacin de un pequeo nmero de arquetipos ya

escritos en el marco del proyecto GEHR-Australia [GeAu] [DSTC], los dos aspectos de mayor inters
actualmente son: la introduccin de un nuevo lenguaje de definicin de arquetipos (ADL) [Beal4],
que se ver en el apartado posterior de Material y Mtodos (Cap.4, aptdo 4.3.2), y la reciente
propuesta [Heard] de unificar y clarificar, en los dos mbitos de estandarizacin en este campo
(CEN/openEHR, HL7), el sigificado de los trminos arquetipos y tmplales, proponiendo un
escenario controlado en la resolucin del 'gap' entre modelo de referencia y vocabulario.
39
De las definiciones que se pueden encontrar en un diccionario, podra deducirse que los arquetipos
son un tipo de tmplate, puesto que [Wdic]:
Tmplate. Algo que establece o sirve como un patrn.
Arquetipo. El patrn o modelo original del cual todas las cosas de un mismo tipo son representaciones
o copias.
En la actualidad el uso de los trminos arquetipo y tmplate es confuso. El 'gap' existente entre el
modelo de referencia y el vocabulario no es igual en HL7 y CEN/openEHR.
En HL7. Las restricciones sobre el modelo de referencia RIM [HL7 RIM-RM] se aplican a travs de
Refned Message Information Models (R-MIM) y Conunon Message Element Types (CMETs), a los
que posteriormente siguen restricciones adicionales aplicadas a travs de los 'HL7 templates'.
En CEN/open/EHR. Las restricciones sobre el modelo de referencia se aplican a travs de los
arquetipos; mientras que el conjunto de arquetipos usados para una coleccin de datos particular,
puede ser fijado por un 'CEN/openEHR tmplate'.
En ambas aproximaciones los modelos son poblados por el vocabulario.
Para unificar el significado de ambos trminos, la propuesta realizada a los dos mbitos de
estandarizacin consiste en atender por separado dos grupos de consideraciones, uno que se podra
llamar consideraciones semnticas, atienden sobre todo al contenido de los diferentes conceptos que
pueden construirse; y otro que se podra llamar consideraciones de uso, tienen que ver con la
especializacin y la extensin de los conceptos.
3.2.4.3.1
Consideraciones semnticas
Las diferentes agregaciones que pueden ser consideradas conceptos discretos (distintos) y coiiq)letos
que pueden aparecer en una HCE son:
Coleccin de conceptos que juntos forman los atributos fijos de un concepto de un nivel superior,
el cual es algo mas que las partes que lo componen; p.ej presin sangunea, con sus dos presiones
y protocolo asociado: posicin, etc.
Conceptos genricos con sus atributos fijos, los cuales son un valor o una coleccin de valores
que forman un subconjunto de un conjunto mayor conocido; p.ej un diagnstico, con atributos
fijos como fecha de comienzo, estado de la enfermedad, etc; una batera de resultados de
laboratorio, con atributos fijos como fecha de la muestra, etc.
Una coleccin de conceptos de los niveles anteriores medidos frecuentemente juntos y que
pueden considerarse como conceptos; p.ej examen fsico, conteniendo observacin, palpacin,
auscultacin y otros; signos vitales, conteniendo temperatura, presin sangunea, pulso cardiaco y
frecuencia respiratoria.
Una coleccin de conceptos del nivel anterior que pueden formar una COMPOSICIN (CEN),
TRANSACTION (openEHR) o un DOCUMENTO (HL7 CDA); p.ej nota de progreso,
40
conteniendo sntomas, examen fsico, una evaluacin y un plan; informe de laboratorio,

conteniendo la batera de resultados, una interpretacin y otros detalles; informe quirrgico,
describiendo la operacin, los actores que intervinieron, complicaciones, y seguimiento requerido.
Estos ltimos de jerarqua mas elevada dependen sobre todo de la buena prctica, de casos de uso y de
convenciones en la asistencia, presentando un impacto mucho menor sobre la semntica.
El significado semntico de un artefacto (p.ej un modelo de un concepto) se deriva de las definiciones
que incluye y de sus relaciones con otros artefactos del mismo tipo y artefactos afines derivados de la
misma base de conocimiento. Con la incipiente disponibilidad de herramientas ontolgicas (p.ej
Protege [Protege]) y la comprensin de los requerimientos explicitados para proteger la semntica
(p.ej las categoras estructurales del CEN/TC251/WG2 [12226]), empiezan a existir sistemas de
informacin que usan herramientas de conocimiento y basan sus sistemas en ontologas (y modelos).
Cualquier artefacto, arquetipo o tmplate, que intente preservar la semntica debe estar relacionado de
alguna manera formal con una ontologa. Dados los requerimientos existentes de extensin y
especiahzacin, debe desarrollarse una regla estricta que gobierne el proceso de conseguirlos.
Adems, cada concepto representado como arquetipo o tmplate y definido en una ontologa, tendr
que ser discreto y completo; si no, no habra lmite para la complejidad y relaciones entre conceptos.
La finalidad de arquetipos y templates es tener y transportar significado, siendo muy conveniente
minimizar su nmero y maximizar el reuso.
La propuesta consiste en que los diferentes conceptos y colecciones de conceptos descritos
anteriormente sean: a) representados como modelos semnticos, b) estn ligados a una ontologa y c)
se denominen arquetipos primarios. Sus caractersticas mas importantes son:
Estos modelos proveern interoperabilidad semntica.
Estos modelos rq)resentan conceptos discretos y completos que no pueden ser tratados fcilmente
solo con terminologa, debido a que, requieren tanto valores como trminos; son compuestos y
necesitan registrar mltiples propiedades. Estos modelos van a ser requeridos para procesamiento
automtico.
Estos modelos son almacenados, al menos en su forma genrica en una base de conocimiento que
est unida a una ontologa formal. Esta ontologa puede soportar preguntas complejas en un
sistema de informacin.
Estos modelos sern registrados por organizaciones de estandarizacin en diferentes niveles (pais,
regin, o sector sanitario)
3.2.4.3.2
Consideraciones de usuario
Son consideraciones acerca de cmo la informacin es almacenada en una HCE; son necesarias para
un determinado uso especfico, pero no afectan a la interoperabilidad semntica. Hay dos niveles: uno
41
relacionado con la organizacin del registro y otro relacionado con las restricciones durante la captura
de datos.
Obviamente existen diferentes modelos de organizar la misma informacin; es diferente registrar un
encuentro mdico-paciente de forma tradicional (historia, examen fsico, diagnstico, plan), que
registrarlo siguiendo un mtodo orientado a problemas (subjetivo, objetivo, evaluacin, plan). Un
ejemplo puede ver en la Tabla 3.4
Tabla 3.4 Comparacin de dos mtodos de organizacin

Tradicional
Orientado a problemas
Historia
Dolor de cabeza
Dolor de muelas
Examen fsico
Fondo de ojo normal
Hinchazn bajo molar R4
Diagnstico
Abceso en la muela
Dolor de muelas
S: Dolor de muelas
O: Hinchazn bajo molar R4
E: Abceso en la muela
Dolor de cabeza
S: Mal sueo nocturno
O: Fondo de ojo normal
E: Secundario a dolor de muelas
Se propone que estas restricciones se denominen modelos organizativos o arquetipos organizativos.

Forman las SECTIONs (CEN / HL7 CDA), y ORGANISERs (openEHR). Sus caractersticas mas
relevantes son las siguientes:
Aunque su necesidad se basa sobre todo en casos de uso, todava mantienen fuertes enlaces con la
base de conocimiento; p.ej se sabra que estn relacionadas secciones denominadas examen_fsico
y examen_abdominal.
No hay necesidad de restriccin en el nmero de estos arquetipos, pero sus relaciones deben ser
comprendidas.
Estos modelos no tienen verdadero contenido semntico.
No hay necesidad de registrar estos modelos para interoperabilidad semntica.
Estos modelos pueden no estar presentes en la ontologa.
No obstante es digno de tener en cuenta que compartir estos modelos organizativos ayuda a una
interoperabilidad clnica, permitiendo a los usuarios encontrar rpida y de forma fiable agregaciones
de informacin, ayudando en la navegacin a travs de la HCE.
Tambin es importante reconocer que estos arquetipos organizativos tendrn 'slots' que podrn
rellenarse con otros arquetipos organizativos o arquetipos primarios [RosM2].
3.2.4.3.3
Templates
Para especificar el uso de arquetipos organizativos y arquetipos primarios dentro de un componente

de la HCE, es necesario otro tipo de artefactos. Ser tan especfico como sea requerido por los grupos
de usuarios, y puede ser ampliamente compartido o no. El papel de estas especificaciones es describir
42

cmo se organizan las entradas de la HCE, qu elementos opcionales de las entradas son poblados, y
qu valores o valores por defecto se le aplican.
La propuesta consiste en que estas especificaciones, que se fundamentan sobre todo en preferencias de
usuarios y entornos concretos, se denominen templates. Ensearn qu arquetipos organizativos y en
qu orden son usados, y qu primarios contendrn. Dos ejemplos, pueden verse en la Tabla 3.5.
Tabla 3.5 Ejemplos de templates

Tmplate Contacto pre-parto
Historia
Sntomas
Preocupaciones
Historia
Examen
fsico
Presin sangunea
Frecuencia cardiaca fetal
Palpacin del abdomen
Evaluacin
Plan
Tmplate Anotacin sobre Asma.

Frecuencia de 'wheezing'
Diario y continuo
S
Diario pero no continuo
Episodios por semanario
Laboratorio
'Peak Flow: 120 1/m.
Evaluacin
Asma, Intermitente
Asma, Medio-intermitente
Asma, Moderada-persistente
Asma, Severa-persistente
S
Plan
Esteroides orales
En resumen se propone:
Usar los arquetipos para describir conceptos que son incorporados a la HCE, y que pueden estar
unidos a una ontologa.
Usar los templates
para especificar restricciones para un mensaje, un documento o un
componente de la HCE, predominantemente del tipo COMPOSICIN (CEN) / TRANSACTION

(openEHR), o fragmentos de ellos, siempre en trminos de arquetipos organizativos y primarios
(y en HL7 adems de clases RMIM y CMET).
Ambos, arquetipos y templates se denominan frecuentemente modelos clnicos, como expresin
simplificada de: modelos (estructura + restricciones) que representan conceptos de conocimiento del
dominio clnico.
De todo lo anterior se deduce que el dominio quedara descrito por:
El modelo de referencia que expresa los conceptos genricos.
Los templates que expresan los requerimientos de la captura de datos en una situacin particular.
Los arquetipos organizativos, que soportan navegacin y una cierta interoperabilidad clnica.
Los arquetipos primarios, que componen las entradas y soportan la interoperabilidad semntica, y
El vocabulario (palabras y trminos), que soportan la interoperabilidad semntica.
3.2.4.4
Propuesta de doble modelo + representacin controlada

43
Captulo 3. Situacin actual nomaUzadn HCE
Actualmente se considera que un sistema de informacin que maneje HCEs, es en realidad un sistema
que gestiona (captura, procesa, comunica) instancias del modelo de referencia. La propuesta de
metodologa para salvar el 'gap' entre las instancias del modelo de referencia y la terminologa,
consiste en aceptar la existencia de un doble modelo (informacin y conocimiento), y en aceptar la
representacin controlada de los conceptos del dominio.
3.3 Modelo Universal del dominio

Para poder realizar verdaderas comparaciones entre estndares, o para poder integrar estndares
cuando se afronte un desarrollo basado en ellos, es necesario establecer una especie de modelo
universal [Beal2], entender su estructura e intentar mapear los estndares existentes en ese modelo
universal de referencia. No tiene ningn valor normativo, sin embargo constituye una herramienta del
mayor inters para tener una posicin definida y entender el estado actual de la normalizacin de la
HCE en las diferentes organizaciones de estandarizacin.
Los pilares bsicos sobre los que descansa el universo son, tal y como se ha expuesto en apartados
anteriores:
Sistemas distribuidos. Se definen servicios/sistemas en un entorno distribuido ('middleware').
Modelado de cada uno de esos servicios en varios niveles.
- Separacin de informacin y conocimiento.
- Los sistemas son construidos a partir de los modelos de informacin.
- Los modelos de conocimiento (cuyas instancias son los arquetipos y los tompiates) se
procesan en tiempos de ejecucin.
La combinacin dar lugar a sistemas de informacin basados en estndares en los cuales hay una
familia de modelos para cada servicio: modelo de referencia (MR), modelo de conocimiento (MC) y
modelo de servicio (MS), ver figura 3.3. El modelo de servicio sirve como API de alto nivel.
Figura 3.3. Sistema de informacin distribuido y con separacin de informacin y conocimiento.
44
Captulo 3. Situacin actual nomaUzacin HCE
Una primera gruesa aproximacin de modelo universal puede verse en la figura 3.4.
0rdenes_2r
(HCMxtt^
Patrones de H (^tructuras datse Qlpos de D a t ^

-, anlisis
, 1
MC
MC
Soporte
Figura 3.4 Modelo universal del dominio. (Con permiso del autor Thomas Beale).
En los siguientes apartados se mapean sobre el modelo universal el estado actual de los trabajos de las
diferentes organizaciones de estandarizacin.
3.3.1 CEN/TC251AVG1, WG2.

La situacin actual puede verse en la figura 3.5.
/El^n3!y40
CT Ordenes ~ ;
^~---TM^
(HCE-Exteacj)
Q Workflow
I 13606-21
MS n^T1
_ MS I rz
HMR.
(mtos Referend^
(Qreminologm^
" MC
\ ^
-^M\^
Arquetipos
13606-3
Modelos
clnicos LH
ysM^x
FTatrones de H (^tructuras d a t ^ ~ (Tipos de Datos^

X
4_!!!!_r
[MCI
rMCl ^^
Soporte
IGPICS
LI^^
Trminos
Dominio
(13606-3)
Figura 3.5 CEN/TC251/WG1 y WG2 (parcial). (Con permiso del autor Thomas Beale).
45
Captulo 3. Situacin actual nomal2acin HCE

En el nivel de soporte, CEN ha aprobado la Especificacin Tcnica (no norma, para agilizar su
disponibilidad) CEN/TS14796 [14796] que en realidad son un subconjunto del 'v3 Data Types' de
HL7 lo que ayudar en gran medida a posibles armonizaciones en niveles superiores [Mari].
En el nivel de conocimiento, el prENV13606:1999 Health informatics - Electronic health record
communication, bsicamente proporcionaba en la parte 2 una primera aportacin a trminos del
dominio. En la revisin prENV13606:2003 que se est llevando a cabo se aaden: arquetipos,
templates, un modelo de arquetipos (lenguaje), definiciones para mensajes, componentes de
informacin de propsito general GPICs [14822] que son compuestos de tipos bsicos de datos que se
utilizarn en la composicin (posibilidad de varios niveles) de arquetipos y mensajes.
Otra norma que se mapea en este nivel es la ENV13940 HeaUh informatics - System of concepts to
support continuity of care [13940].
En el nivel de informacin la revisin prENVI 3606:2003 en su parte 1 describe el modelo de
referencia de EHR-Extract. Se incluye en este nivel la prENV12967:1997 Health informatics Service architecture - Part 3. Computational viewpoint, que permitir especificar los modelos de
servicio de Extract, Demographics, Admin, etc.
3.3.2 HL7 RM.

La situacin actual puede verse en la figura 3.6.
CÔrdenerlr^
(M-Ex^~<;^WorMl^^
ICTS
MS
MR
IR
. R e f e r e n ! ^ / \J^TTmBslo^^
r-fT7^^ >--^-^^==^
^t
Estructuras dato^P
/ ^ Registro T^^ .
' ^ Templates tyNr=
v3DTs
(^'ipos de Datos^
HMDs
L_
CMETs
\ vec^bslario
Figura 3.6. HL7 RIM. (Con permiso del autor Thomas Beale).
En el nivel de soporte HL7 proporciona el modelo de informacin de referencia (RIM) que en
realidad es un patrn de anUsis basado en las clases: Entidad, Rol/Relacin, Participacin,
46
Acto/Relacin; y un conjunto muy completo de tipos bsicos de datos: 'v3 Data Types' [HL7 RIMRM].
En el nivel de conocimiento se definen los D-MIMs, R-MIMs y HMDs obtenidos a partir del RIM
mediante sucesivas restricciones, p.ej quitando o renombrando atributos. Los R-MIM son dos cosas a
la vez: esquemas de datos (modelos 'slots') para familias de mensajes y modelos de conocimiento,
similares a los arquetipos y templates. Los CMETs son fragmentos reusables (un solo nivel de
composicin) de R-MIM [Marley].
En el nivel de informacin HL7 proporciona el modelo 'clinical document architecture - CDA'.
3.3.3 openEHR.
La situacin actual puede verse en la figura 3.7
Informacin
MR
Demographics^
MC
Ordenes ^ ~ ^
QlCE-Extract)
(3
C
MS
MS
MR
ntrol de
Acceso
MC
^-^=hm
Mînumi
c=jaiikiSiis p
M S . --MR
Admin
r-
J)
MC
Workflov*^
Conocimiento
3c] ^ - ^ = ^ ^ ^
^ t n i c t u r a s datqs^ Q p o s de DatosT
MC
MC
Soporte
Figura 3.7. openElR. (Con permiso del autor Thomas Beale).

En el nivel de soporte, openEHR proporciona en modelo de referencia (MR) comn como patrn de
anlisis para: el control del cambio, participaciones en procesos, atestados e identificacin. Adems
tiene muy avanzados los modelos de referencia y conocimiento que describen los servicios de bajo
nivel Tipos de datos y Estructuras de datos.
En el nivel de conocimiento, se trabaja actualmente en el Servicio de Modelos Clnicos cuyos modelo
de conocimiento y modelo de servicio estn bastante avanzados. Se ha especificado el lenguaje de
definicin de datos (ADL) y se estn poniendo a punto herramientas que ayuden en la elaboracin de
arquetipos, que permitan interoperabilidad semntica y templates que permitan interoperabilidad
clnica.
47
En el nivel de informacin estn elaborados los modelos de referencia, conocimiento y servicio de los
sistemas 'EHR', 'Demographics' y 'Workflow'.
3.3.4 OMG-HDTF.
La situacin actual puede verse en la figura 3.8
Informacinr
Snfrolde^ MR
jcceso I
MC
r-
Demographics^
C _AdimnJ3J
MC
ÎAC
UUAo
,^p
HCE-Extract
Modelos
clnicos LH
nPatrones de
I, anlisis ,
^tructuras dato^) (jlpos de D a t ^ )

MC
MC
Soporte
Figura 3.8 OMG-HDTF. (Con permiso del autor Thomas Beale).
La aproximacin que ha seguido OMG-HDTF implica desarrollar los modelos de servicio de los
distintos sistemas obtenidos al separar responsabilidades. En la figura 3.9 pueden verse las
realizaciones en los niveles de informacin y conocimiento. El mayor problema es que se
especificaron esos modelos antes de especificar los modelos de referencia. Probablemente necesiten
una actualizacin teniendo en cuenta los modelos de referencia que otras organizaciones estn
elaborando.
48
MATERIAL Y MTODOS
4.
Material y Mtodos
4.1 Material. Modelos de referencia

4.1.1 Modelo de referencia EHR_Extract (prENV13606:2003)
El grupo de trabajo EURcom fue creado con el objetivo de revisar el pre-estndar prENV
13606:1999, relativo a la comunicacin de carpetas de paciente electrnicas, y proponer una
actualizacin que pudiera ser aceptada como un estndar formal en 2004. Su trabajo se ha basado en
el pre-estndar existente y su pretensin es: hacerlo ms riguroso y completo, incorporando nuevos
requisitos identificados; hacerlo interoperable con otras especificaciones, p.ej HL7 y aadir un
mecanismo para poder aplicar los modelos genricos a dominios clnicos individualizados.
El estndar est compuesto de 5 partes:
Parte 1. Modelo de referencia.
Parte 2. Especificacin para el intercambio de arquetipos.
Parte 3. Referencia de arquetipos y lista de trminos.
Parte 4. Caractersticas de seguridad.
Parte 5. Modelos de intercambio.
En el momento de redactar este trabajo slo est disponible la primera parte y primeros borradores de
la segunda y cuarta; el resto se espera a lo largo de 2004. A continuacin se describe el modelo de
referencia del servicio EHR_Extract (ver Cap. 2, aptdo 2.3.1, fg. 2.6) [13606:2003, Part 1] que ser
utilizado en este trabajo.
51
4.1.1.1
Resumen
El concepto central del modelo de referencia es el de extracto, representado por la clase

EHR_EXTRACT que contiene la parte de la historia de un paciente (o la historia entera) seleccionada
para ser transmitida a otro sistema o proceso, as como la suficiente informacin como para
identificarse a s misma y al sujeto de atencin al que se refiere la informacin, usualmente el
paciente. Ver figura 4.1.
Cada extracto formar parte de una estructura superior, el mensaje, representado por la clase
EHR_MESSAGE, que es el mecanismo para realizar efectivamente las comunicaciones, y que se
definir en la parte 5 del estndar.
El extracto puede tambin incluir una descripcin de todos los trminos referenciados en l (clase
TERMINOLOGY_EXTRACT), as como informacin demogrfica sobre los agentes que aparecen en
el mismo (clase DEMOGRAPHIC_EXTRACT). Esta informacin se incluye para evitar problemas
de interpretacin si el sistema recq)tor no tiene forma de obtenerla por s mismo (p.ej. cuando se ha
obtenido de un servidor al que el receptor no tiene acceso).
El resto de la informacin contenida puede dividirse en dos grandes grupos: a) la informacin clnica
'per se', y b) la informacin auxiliar, o contextual.
La informacin auxiliar tiene dos tareas fundamentales, por un lado provee a la informacin clnica
de todo su significado y por otro, cumple con los requisitos mdico-legales. Se guarda de la siguiente
manera:
Informacin de autora. La clase FUNCTIONAL_ROLE permite almacenar informacin sobre el
agente que ha participado en la generacin de los datos, el rol con el que lo hizo y el medio que
emple para llevar a cabo la accin. Esta clase ser utilizada por otras dentro del extracto.
Informacin de auditora. Se almacena en la clase AUDIT_INFO, y registra la informacin sobre
quin ha hecho un cambio en el registro y por qu. En el caso de que sea una correccin de datos ya
presentes, tambin almacena una referencia a los mismos. Tiene tambin la posibilidad de agrupar
varios cambios en una unidad mayor, llamada contribucin.
Informacin de atestados. Existen partes del registro que deben ser atestadas, dotndolas de un estatus
legal concreto. Para estas situaciones se utiliza la clase ATTESTATION_INFO, que permite recoger
el momento en el que se hizo el atestado, as como las pruebas necesarias, o incluso una vista de la
pantalla que vea el agente que lo realiz, que es requerimiento legislativo de algunos pases. Por
ltimo, emplea una referencia a FUNCTIONAL_ROLE para especificar el autor del atestado.
52
EXTRACT
Package
Ver on Merge2b"~ti.
2004-02-04
DL/DK
Referenca Model
LINK
DEM0GRAR4C. EXTRACT
EHR MESSAGE
ACCESS
POLICry
pares; seTEX_PARTY>
n a t u [ i : : CV
t a i g t _ r q _ i t i I 1 " II
rt)le[0,.1I : C V
foll&>vJm<[1:BL
Ue2ssge_t?eibf7s
0.-/V
RECORD^CO/JPONEfiT
rremetlj: TEXT
irrite
EXTRACT
EHR_EXTPACT
e t d r e t j p e J d O , 1 J : I)
COt45TW,INT
ifne_peDd i O . , 1 | : IVL<TS>
e h f J d l : I!
inax_3enilivity[0. ! [
subjBct_of_CErfl1^ : W
ll_warsDnA ; [ C I I : B o o l e e n
Intesr
a*etype_i-!Krti1 ^: SL
synthssl>a^1l:'BL
tJTn__ciBB.te(Ji; . T S
htH_atithaiisrnQ(0..1j : II
srchetype_id3|0..1|. SETS^
wn \<S^'. Sfrln
othe'__a}nsbtalnl3t)..1i : Strlng
pDlicy_itte(0
11:SeT<ll>
sensltrvliillj: C S . S E N S I T M TY
AUDIT
IHFO
hr_5ysterTTi;
trne_CQminitted[r : T S
CQftvTTtte-r[1:: !l
a-iisslatiori
/evaan__statLe0..1 : C S _
ress&n_fDt_Te)'islonro,.1
pr6vrcMJS_>/'erion[0..1:
O Q n l r i b u t i c n _ i d [ 0 . 1J : II
v e ' a 5 n _ s e t _ i d [ D . . i ; : II
O,.*
'6_patent_Teqa..i;
II
?m*r
^CfTIor-l
EMTRY
B f o _ p r w i i M 0 - 1 1 : FUt*:TICJ!4ilL,R0L
annolBtore}J,.i:- SETsCS_AM>tOTATICMs
BCtJHD . 1 ; S a i r g
m e t l : , TS
ssBi!on_time|i; : IVt<TS?-
CfMfld..i;: 6D
hca_le3allv_respcinsJbl6_for_iBre[0.. t ;
atle5te<J_wewI0..1i. ED
II
h I t ^ c a ^ e _ f a d l i t y i O . , 1 i ; II
service_5etSna!3 . i ; : C V
tefrlcfyp,.i; : CS_TERRITORY
ier
fTFM
err?fTS53i3..r : C V
FUMCTICKAL
ROLE
ots_timel0..1; iVL<TS>
luRdi-cntQ.,i; : CE
itan_i:iiegi:xy{D..] : C 5 _ I T E M _ C A T
p e f f w m e i f l j : II
rnode[0.-1i ; CV
ELEMEhfT
st[ucuie_typei1:: CS_STRUCTURE_TYPE
tus
Inh'Biitirg CEU
D aBTjpe go
h-ere
K
OiTA
VALU
n u i l f l B V D u r C S WULL
FLAV
Colour Code:
EHR_Exlract and
immediate associaes
Record Compwienti\ Others

and its inheritora
TX
Figura 4.1 Modelo de referencia EHR_Extract.

Informacin de la sesin clnica. En la clase CLINICAL_SESSION se recoge la informacin de la
sesin clnica en la que se aadi la informacin al registro. Esta informacin incluye la localizacin
53
de la sesin (momento, centro, servicio, territorio, legislacin pertinente) y recurre a la clase

FUNCTIONAL_ROLE para informar sobre el agente que la realiz.
Informacin de relacin con otros agentes. En la clase RELATED_PARTY se puede recoger
informacin sobre una persona relacionada con el sujeto de atencin, sin llegar a identificarla.
Informacin de enlace. El estndar cuenta con la clase LINK para permitir enlazar partes del mismo
que guarden algn tipo de relacin, p.ej de causa - efecto.
En cuanto a la informacin clnica, el estndar proporciona toda una serie de clases que permiten
reproducir en el registro la estructura requerida de carpeta.
La pieza fundamental sobre la que se construye toda la estructura es el componente, representado por
la clase abstracta RECORDjCOMPONENT,
de la que se derivan, y por lo tanto heredan sus
caractersticas, el resto de clases contenedoras de informacin clnica. Es en esta clase donde se

coloca la informacin relativa a: enlaces a otros componentes, clase LINK; informacin de auditora,
clase AUDITJNFO; y atestados, referenciados desde la clase ATTESTATIONJNFO.
De esta manera es posible especificar este tipo de informacin para cualquier componente del registro,
situado en el nivel que sea. Tambin se registra aqu la informacin relativa a qu arquetipo se ha
utilizado para crear el componente y si ste es el nodo raz del arquetipo.
De forma resumida, se puede decir que la informacin clnica se organiza de la siguiente manera: el
extracto contiene un conjunto de versiones de composiciones (informacin recogida durante una
interaccin con el sistema) que pueden organizarse enflderes para reproducir criterios organizativos
dependientes de cada centro.
La composicin contiene entradas (fragmentos de informacin), que pueden agruparse bajo secciones
(similares a los encabezamientos que aparecen en los documentos mdicos) y cada entrada contiene
elementos (contenedores de los datos simples reales), que pueden formar parte de grupos (para
reproducir las estructuras complejas de datos).
Una descripcin un poco ms detallada de esta organizacin es la siguiente:
Toda la informacin presente en el registro se guarda en composiciones (clase COMPOSITION). Esta
clase recoge la informacin que se ha aadido o modificado en una nica interaccin con el sistema.
Sin embargo, se necesita otra mucha informacin de contexto para poder interpretar correctamente su
contenido, por eso, la unin de las composiciones con el extracto se hace a travs de versiones (clase
VERSIN), cuya tarea es dotar a cada composicin de la informacin de auditora necesaria,
informando de si la composicin es original o sustituye o modifica otra. Tambin sirve de contenedor
para todos los atestados que pudieran tener la composicin o cualquiera de los conq)onentes de sta,
siendo la clase ATTESTATION_INFO la que especifica a qu parte o elemento de la composicin se
refiere el atestado, conteniendo una referencia al RECORD_COMPONENT correspondiente. La
54
composicin tambin incluye informacin sobre la sesin clnica en la que se gener (clase
CLINICAL_SESSION).
En la HCE la informacin puede estar organizada de distinta forma: por especialidad clnica, por
problemas o episodios, por servicio, etc. Para poder reproducir estas estrategias, adems de guardar
todas las versiones de las composiciones, el estndar permite organizar las composiciones poiflderes
(clase FOLDER). El extracto puede contener un conjunto de flderes, cada uno de los cuales incluye,
a su vez, ms flderes y un conjunto de referencias a composiciones (no la composicin en s,
permitindose de esta manera que una composicin pueda estar incluida en ms de un flder). As se
puede construir un rbol completo con la estructura requerida.
Cada fragmento (afirmacin, deduccin, sntoma, resultado de pruebas, trozo de la historia del
paciente, etc) de informacin recogida en una sesin clnica suele estar agrupado en secciones, segn
los temas clnicos, o secciones que indiquen p.ej el flujo de trabajo durante la misma o el proceso
deductivo seguido por el agente clnico que la realiz. Por eso cada composicin puede contener
clases que recogen estos fragmentos de informacin o entradas (clase ENTRY), o bien agruparlos
mediante un directorio de secciones (clase SECTION), que a su vez contengan ms secciones o los
fragmentos individuales. Esto se consigue incluyendo en la composicin una o ms instancias de la
clase abstracta de contenido (clase CONTENT), de la que se derivan las dos anteriores. Tambin a
cada entrada se le puede asociar informacin de otros agentes que hayan participado en la generacin
de la informacin guardada (clase FUNCTIONAL_ROLE), o sobre el sujeto al que se refiere la
informacin cuando este no es el paciente (clase RELATED_PARTY).
Cada uno de los fragmentos de informacin contenido en una entrada, puede ser un dato simple (p.ej
peso, ritmo cardiaco, etc) o ms complejo (p.ej presin sangunea, lista de medicamentos a los que el
paciente es alrgico, serie temporal de presin arterial tomada con un holter, etc). Para poder
almacenar estas estructuras de datos complejas, lo que contiene cada entrada es, de forma similar al
contenido de cada seccin, un conjunto de tem (clase abstracta TEM), que se instancia en otras dos,
elemento (clase ELEMENT), que recoge un dato simple (siempre siguiendo uno de los tipos definidos
por el CENTS 14796) y grupo (clase CLUSTER), que agrupa a un conjunto de elementos y/o otros
grupos. Adems de para la informacin clnica per se, esta estructura de grupos y elementos, se puede
repetir en cada entrada para almacenar informacin que pueda ser til para apoyar los datos clnicos,
como el proceso deductivo que ha llevado a una conclusin, el protocolo clnico seguido, etc.
Se debe recordar que todas las clases que contienen informacin clnica (COMPOSITION,
SECTION, ENTRY, CLUSTER, ELEMENT, adems de las abstractas CONTENT e TEM) se
derivan de RECORDJOOMPONENT, por lo que pueden tener asociada informacin de auditora
(clase AUDIT_INFO) especfica, si as se requiere, o ser apuntadas desde un atestado (clase
ATTESTATION_INFO) cuando ste se refiere slo a una determinada parte de la composicin,
55
puesto que estos ltimos estn todos recogidos en la versin, para dotar al extracto de una mayor
homogeneidad.
4.1.1.2
Clases y relaciones relevantes
En este apartado se describen de forma mas estructurada cada una de las clases relevantes del modelo,
aadiendo alguna informacin adicional de inters sobre lo descrito en el apartado anterior.
4.1.1.2.1
Clase EHR_EXTRACT
La entidad raz del modelo es el extracto (EHR_EXTRACT) que representa parte o la totalidad de la
HCE de un nico sujeto de atencin ('subject_of_care'), usualmente el paciente, extrada de un
sistema y con propsitos de comunicarla a otro proceso (aplicacin cliente, servicio middleware u otro
sistema). Todo extracto forma parte de una y solo una entidad de mensaje (clase EHR_MESSAGE).
Dentro del extracto, la informacin est contenida en dos partes:
Un conjunto de entidades demogrficas (DEMOGRAPfflC_EXTRACT) y de terminologa
(TERMINOLOGY_EXTRACT).
Estas entidades contienen, respectivamente, la
informacin
demogrfica de todas las entidades presentes en el extracto y toda la terminologa necesaria para
interpretar correctamente la informacin. Esta estrategia asegura que la informacin ser
correctamente interpretada por el receptor, aunque no tenga acceso a los servicios que crearon el
extracto. Adems est previsto que se incluya tambin aqu la informacin de control de acceso, que
se est definiendo en la parte 4 del estndar.
Un directorio de flderes (clase FOLDER) y un conjunto objetos con versin (clase VERSIN),
incluyendo ambos composiciones (clase COMPOSITION), que son los componentes es donde se
almacenan los datos reales.
Estas ltimas clases permiten recrear la estructura jerrquica completa del registro, segn los
requisitos mdico-legales. La composicin (clase COMPOSITION) registra la informacin recogida
durante una interaccin con el sistema (visita de un paciente, intervencin, etc.). Dentro de cada
composicin, la informacin se organiza en secciones (clase SECTION), que pueden reflejar desde las
distintas fases de las que ha constado el encuentro hasta el proceso de razonamiento del autor. Su
estructura facilita tambin la navegacin por el registro. Cada una de estas secciones, las cuales
pueden contener sub-secciones, se organiza por entradas (clase ENTRY), que guardan la informacin
obtenida en cada observacin simple, afirmacin, o hecho clnico que se guarda en el registro. Para
poder representar correctamente la complejidad que pueden tener los datos contenidos en las entradas,
stas se organizan en grupos (clase CLUSTER) y elementos (clase ELEMENT), contenedores finales
de los datos y que, al combinarse, permiten reproducir estructuras como listas, rboles o series
temporales (CENTS 14796 Tipos de datos).
56
El estndar tambin proporciona herramientas para poder organizar la informacin por episodios,
especialidades, etc, que se hace mediante flderes (clase FOLDER) que contienen referencias a las
composiciones. En los siguientes apartados se ve esta organizacin con ms detalle.
4.1.1.2.2
Oase
RECORDjCOMPONENT
Esta clase abstracta es la base para todos los elementos de la jerarqua del extracto. De ella se derivan,
y por lo tanto heredan sus atributos, el resto de componentes: FOLDER, COMPOSITION, SECTION,
ENTRY, CLUSTER, ELEMENT y dos clases virtuales ms, CONTEN! e TEM. Sus atributos
proporcionan la identificacin del componente, informacin sobre el sistema que ha generado el
componente, informacin del arquetipo usado en su construccin, y si es la raz de ese arquetipo, as
como un nivel de la sensibilidad de ese componente, que sirve para dar soporte al control de acceso al
mismo. El atributo 'synthesised' indica si este componente contiene datos reales provenientes del
sistema generador o si, por el contrario, ha sido creado para ajustar la jerarqua al estndar.
Esta clase tiene las asociaciones con otras: con la clase de enlace (clase LINK), para permitir
representar relaciones entre componentes; con la clase de auditora (clase AUDIT_INFO) para poder
registrar informacin sobre las revisiones que el componente sufra. Igualmente, el componente ser
referenciado desde la clase de atestado (clase ATTESTATIONJNFO).
4.1.1.2.3
Clase LINK
Los enlaces pueden necesitarse para, p.ej indicar una relacin causa - efecto; seguir la evolucin de
una peticin hasta obtener sus resultados; recopilar la informacin de un problema clnico, etc.
Contiene atributos para especificar la identidad del RECORD_COMPONENT enlazado, la naturaleza
del enlace, el papel del componente enlazado (si es un sntoma, un resultado, etc), as como permitir al
autor indicar si, segn su criterio, el componente enlazado debe o no incluirse en el extracto.
4.1.1.2.4
Clase VERSIN
Esta clase, adems de proporcionar un mecanismo para tratar el control de versiones dentro de la
HCE, es la contenedora de toda la informacin del extracto, a travs de su relacin con las
composiciones.
Cada
extracto
esta formado
por
un conjunto
de composiciones
(clase
COMPOSITION), que es el contenedor de los datos reales, y cada una de stas est relacionada con
aqul a travs de su versin (clase VERSIN) con quien guarda una relacin biunvoca.
La clase versin tambin se encarga de relacionar la composicin con su informacin de auditora, es
decir, cundo se ha aadido la informacin, quin es el autor, cul es la versin anterior y la razn
para el cambio si esta versin corrige una composicin anterior; as como con su conjunto de
atestaciones (clase ATTESTATIONJNFO).
57
Se puede observar que cada versin puede tener varias atestaciones, que aadir una atestacin no
modifica la versin de la composicin, y que una nueva versin no hereda las atestaciones de su
predecesora. De esta forma se cumple con los requisitos mdico-legales de la informacin.
4.1.1.2.5
Clase FOLDER
Se usa para crear una estructura organizativa de alto nivel para, p.ej, agrupar las composiciones por
episodios, o por especialidad clnica. Para conseguir esta organizacin jerarquizada el estndar utiliza
dos caractersticas: cada flder puede incluir otros flderes para crear un sistema de directorios
completo, y cada flder puede contener referencias a composiciones, a travs de su atributo de
identificacin (rc_id). De esta forma, una composicin puede pertenecer a ms de un flder.
Este tipo de organizacin es opcional y no tiene porqu estar presente en todos los extractos. Se puede
observar que, al contrario de la clase VERSIN, no contiene la informacin sino una referencia a la
misma. Por lo tanto, esta estructura sirve para organizar los datos de distinta manera, y cumplir el
requisito de dotar al estndar de las herramientas necesarias para reproducir de la manera ms fiel
posible la organizacin de las carpetas en papel, dependiente de cada centro.
4.1.1.2.6
Clase AUDITJNFO
Esta clase cumple la funcin de almacenar los metadatos relativos a la creacin o modificacin de la
informacin contenida en el extracto. Tiene dos asociaciones con otras clases, en primer lugar est
contenida en la clase VERSIN, donde almacena la informacin relativa a la inclusin o
modificacin de las composiciones (clase COMPOSITION) a la que se refiere la versin. Por otro
lado, tambin existe la posibilidad de incluirla en cada RECORDJOOMPONENT. Esto es as porque,
si bien la clase COMPOSITION es la que encapsula cada interaccin completa de adicin o
modificacin de la informacin del registro, hay sistemas clnicos que permiten la modificacin de
partes ms pequeas de la informacin o, a ms alto nivel, de flderes (que incluyen ms de una
COMPOSITION). Esa segunda asociacin es la que hace que el estndar permita reflejar estas
situaciones.
Los atributos de esta clase registran la identificacin del nodo al que pertenece la informacin
modificada, el momento en el que se hizo, el agente que lo realiz (que puede no coincidir con los
agentes con capacidad de atestarla) y pueden tambin guardar el estado de la revisin, la razn del
cambio, una referencia al RECORD_COMPONENT modificado (que ser nula si la actual es una
creacin) y un identificador de contribucin. Este ltimo atributo ('contributionid') es necesario
porque, si bien como ya se ha dicho, COMPOSITION es la clase que encapsula cada interaccin con
el registro, la unidad completa de cada cambio es una contribucin, que puede englobar una o ms
COMPOSITION. Este atributo, por lo tanto, permite registrar esta relacin.
58
4.1.1.2.7
Clase ATTESTATION INFO
Al atestar se certifica que los datos son correctos, aadiendo probablemente un cierto estatus legal a la
informacin. El agente que hace la atestacin no tiene porqu ser el mismo que cre la informacin
(un informe, por ejemplo, puede ser introducido en el sistema por un asistente y atestado por un
mdico).
Recoge informacin del momento en que se hace el atestado y los datos que lo prueban.
Opcionalmente (es requerido por la legislacin de algunos pases) puede contener tambin una imagen
de la vista de la pantalla tal cual se mostraba al agente que hizo el atestado. A travs de la asociacin
con la clase FUNCTIONAL_ROLE se identifica al autor del atestado y el rol que ejerca en el
momento de hacerlo.
Un atestado puede referirse nicamente una parte de una COMPOSITION, de la cual un mdico sea
responsable. Sin embargo, para mantener la coherencia en el registro, todos los atestados se incluyen
en la clase VERSIN a la que pertenece. La particularizacin se consigue a travs de la asociacin
'target' con la clase RECORDjCOMPONENT,
conteniendo ATTESTATIONJNFO el atributo
'rc_id' de la misma, a la que realmente se refiere el atestado.
4.1.1.2.8
Clase COMPOSITION
Esta clase cumple dos funciones dentro del extracto. Como ya se ha comentado, es el principal
contenedor de informacin; cualquier modificacin del registro se hace mediante una o ms
composiciones, cada una de las cuales hace referencia a la que modific.
data
VERSIN
1 COMPOSITION
5 composerll]: 11
re id
\content
compositions
FOLDER
"
SUb_ foi fS
CONTENT
orig_parenLr6R0..1]: String
'"T^
^0..1
FUNCTIONAL ROLE
othQr_particpatons
funclion[0.,1];CE
performer[1]; II
0..*
mode[0..1]: CV
CLINICAL SESSION
session_.time[l]: IVL<TS>
hca_!egally_responsible__for_care[0.,1]
healtlicare_facility[0..1]: ORGID
service.setingt0..1]: CV
temtory[0.,1]:CS
II
Figura 4.2. Composicin. Conceptualmente, se corresponde con un CDA Document de HL7.
59
Por otro lado, en muchos sistemas clnicos, la composicin puede ser el contenedor de todas las
entradas de informacin recogidas durante una sesin o un documento clnico, los resultados de unas
pruebas, o un informe de alta, o los resultados de una teleconsulta.
La composicin puede ser vista como la informacin que es aadida al registro de un paciente en un
determinado momento y por un determinado agente, ver figura 4.2.
Adems de heredar los atributos y asociaciones de RECORDjCOMPONENT, tiene un atributo propio
para recoger el agente que la compuso, que puede ser distinto del que cre la informacin, ya que una
composicin puede contener entradas (clase ENTRY) o secciones (clase SECTION) presentes en otra
parte del registro. Tambin aade una asociacin con la clase de sesin clnica (clase
CLINICAL_SESSION) en la que se puede incluir la informacin de contexto de la sesin clnica en la
cual se cre la composicin (momento, responsable legal del cuidado al paciente, centro, servicio y
territorio origen de la sesin) y, a su vez, esta clase proporciona una asociacin con la clase
FUNCTIONAL_ROLE, para especificar a cualquier otro agente que haya tomado parte en la sesin.
Una composicin puede aparecer vaca para poder representar el caso en que sus contenidos hayan
sido eliminados tras una revisin, por ejemplo, si, por error, fue aadida al registro de un paciente
equivocado.
4.1.1.2.9
Clase CONTENT
Esta clase abstracta es la que dota de contenido a la clase COMPOSITION. Hereda los atributos de
RECORD_COMPONENT, y contiene un nico atributo propio 'orig_parent_ref que permite crear un
mecanismo bsico de reutilizacin dentro del extracto, pues es un apuntador al contexto del nodo del
que se extrajo ste, en el caso en que no sea original. Puede materializarse en dos distintas, SECTION
y ENTRY.
4.1.1.2.10
Clase SECTION
Normalmente, las entradas que se producen durante una sesin clnica estn agrupadas bajo distintos
encabezamientos que representan las diferentes fases de la misma. Estos encabezamientos,
representados en el estndar mediante la clase SECTION, pueden mostrar el flujo de trabajo durante
la sesin, o agrupar la informacin por temas clnicos o, incluso, hacer un mapa del proceso de
razonamiento del agente clnico que la realiz. Una seccin puede contener otras secciones o entradas
(clase ENTRY). La estructura real que tenga una composicin determinada ser especificada
mediante arquetipos.
Esta clase es la equivalente a HEADEDSECTION de ENV13606, a CDASECTION de HL7 y a la
clase ORGANISER de openEHR.
SECTION
hereda,
a travs
de la clase CONTENT,
los
atributos
y asociaciones
de
RECORDJCOMPONENT, por lo que cualquier seccin puede contar con informacin propia de
60
auditora o estar referenciada como parte individualizada por los atestados presentes en la versin de
su COMPOSmON correspondiente.
4.1.1.2.11
Clase ENTRY
Es el nodo raz para cualquier declaracin o afirmacin que se haga en el registro. Representa la
informacin adquirida y guardada en una nica observacin, una batera de pruebas, una declaracin
sencilla como puede ser un fragmento de la historia del paciente, una deduccin o aserto, o una simple
accin que se vaya a reaUzar o haya sido realizada. Adems de registrar la informacin en s, a travs
de su asociacin 'data' con la clase TEM, tambin permite opcionalmente, gracias a su asociacin
'protocol' igualmente con la clase TEM, guardar detalles que soporten el proceso de razonamiento
clnico para llegar a esos datos, referencias a guas o protocolos electrnicos o cualquier otra
referencia de conocimiento. Tanto el contenido como la estructura de este segundo tipo de
informacin han sido dejados abiertos en este nivel para permitir que la consistencia y la buena
prctica aparezcan como arquetipos.
Dependiendo de la complejidad de los datos que guarde, la estructura que contiene estar compuesta
por uno o varios elementos (clase ELEMENT) o grupos (clase CLUSTER) organizando los
elementos.
Contiene atributos para registrar el proveedor de la informacin (especialmente si no es el paciente, ni
el clnico que le atiende), una lista de anotaciones (que sern definidas en la parte 3 del estndar), una
identificacin del acto que produjo esta informacin para permitir seguir su evolucin temporal.
Igualmente, a travs de sus asociaciones se puede representar a cualquier otro agente que haya
participado
en la
obtencin
de la informacin
que recoge
esta
entrada
(asociacin
'other_participations' con FUNCTIONAL_ROLE), o de la entidad a la que se refiere, usualmente el

paciente, pero tambin puede tratarse de un familiar, un feto, un donante de rganos, etc. (asociacin
'subject_of_information' con RELATED_PARTY).
Al igual que con las clases contenedoras de informacin anteriores, ENTRY tambin hereda de
RECORDjCOMPONENT la capacidad de aadir a esta clase, informacin de auditora o ser referidos
directamente por algn atestado contenido en la clase VERSIN de la que depende.
4.1.1.2.12
dascITEM
Esta clase abstracta, padre de los componentes CLUSTER y ELEMENT, permite que cada una de las
asociaciones de datos de ENTRY pueda ser un elemento simple, una lista de elementos, un nico
grupo, una lista de grupos o cualquier combinacin de ellos. As se consigue una amplia variedad de
estructuras de datos, incluyendo tablas, matrices, hstas, rboles y series temporales.
Incluye dos atributos: xmo, 'emphasis', para poder introducir im texto que permita resaltar el
contenido de la clase a un futuro lector, p.ej porque sea un valor poco usual, o un resultado
61
inesperado, si bien el estndar an no ha definido cmo usar este atributo para que sea interoperable;
el otro, 'obstime' se usa para distinguir el momento en el que se obtuvo la informacin del TEM, del
de creacin de la COMPOSITION o del que la sesin clnica tuvo lugar. Cabe resear que se puede
indicar tanto un instante como un intervalo temporal pudindose as especificar, por ejemplo, que un
sntoma apareci durante unos meses determinados, o que un tratamiento puede durar un ao.
4.1.1.2.13
Clase CLUSTER
Una nica observacin puede contener varios valores o partes, necesitndose una estructura compleja,
como una tabla, una lista o una serie temporal, para poderla representar, como puede ser el caso de
bateras de test de laboratorios de anlisis clnicos, lecturas de presin sangunea, o tratamientos
farmacolgicos. Para poder definir estructuras de datos complejas, un CLUSTER puede contener
otros CLUSTERs y ELEMENTs, siempre a travs de la clase abstracta/ZBM
En su atributo 'structuretype' se indica el tipo de estructura, tanto temporal como espacial, segn la
cual se organizan los datos contenidos.
Esta clase, al ser derivada
de TEM, hereda todos
los atributos y asociaciones de
RECORDjCOMPONENT, con lo que se puede asociar a este componente informacin de auditora

propia, as como ser referenciado desde los atestados que contenga la clase VERSIN a la que
pertenece.
4.1.1.2.14
Clase ELEMENT
La clase ELEMENT representa la hoja del rbol en la estructura de datos contenida en el extracto.
Puede contener un dato simple, tambin puede contener un valor nulo, en el caso de que el valor no se
conozca. Para poder interpretar correctamente el significado de un valor nulo contiene el atributo
'null_flavor'. En este atributo se incluir un cdigo, que se definir en la parte 3 del estndar, para
distinguir, por ejemplo, entre situaciones en las que no se conoce el valor, o que el paciente carezca de
una determinada caracterstica.
Tambin se le puede asociar informacin de auditora propia o de atestacin, al heredar los atributos y
asociaciones t RECORD_COMPONENT, a travs de TEM.
El valor real estar contenido en la clase abstracta DATA_VALUE, que se instanciar como uno de los,
que se instanciar como uno de los datos de los tipos definidos en CEN-TS14796 Data Types.
4.1.2 Modelo de referencia HL7 RIM (subconjunto para GPICs)

Las clases que forman la parte del RIM vi. 18 utilizado para los GPICs son: Entidad, Rol, Enlace entre
roles, Participacin, Actividad y Relacin entre actividades (verfg.4.3).
62
Entidad. Reprênta cosas fsicas como pueden ser personas, animales, organizaciones, productos
mdicos, dispositivos, lugares, etc.
Rol.
Define la competencia de la entidad en un rol particular para participar en una actividad
particular.
EnlaceRoles. Clase auxiliar que sirve para enlazar diferentes roles.
Participacin. Representa la parte que juega la entidad en una actividad.
Actividad. Representa actividades en el dominio de salud como son: observaciones, pruebas, consulta
con un paciente, etc.
RelacinActividades. Clase auxiliar que sirve para relacionar actividades entre s.
El CEN no utiliza todos los atributos presentes en la figura 3.3, aunque s los mas importantes. Una
breve descripcin de clases y atributos sigue a continuacin.
Entidad
cdIgoClass: CS
cdlgoDetermlnador: CS
Id: SET<II>
cdigo: CE
cantidad: 5ET<Pq>
nombre: BAG<EN>
desc: ED
cdIgoEstado: SET<CS>
tlempoEilslencla; IVL<T5>
telecom: BAG<TEL>
cdIgoRlesgo: CE
cidlgDMane]o:CE
Rol
Id: SET<II>
cdigo: CE
Indnegacln: BL
dlteccln: BAG< D>
telecom
BAG<TEL>
cdEgoEstado: SET<CE>
tiempo Efectivo:
IVL<TS>
textoCertifjcado: ED
Participacin
cdlgoTlpo: CS
cdIgoFuncln: CD
cdIgoCon tro Contexto: CS
nmeroSecuencla: INT
Indnegacln: BL
notaTexto: ED
tiempo: IVL<TS>
cdIgoModo: CS
cdIgoConod miento: CE
cdlgoFIrma: CE
textoFIrma: ED
Actividad
cdIgoClasa: CS
cdlgoMood: CS
Id: s e r < i i >
cdigo: CD
IndNegadn: BL
exprOerlvacln: 5T
texto: ED
ttulo: ST
cdlgnEstado: SET<CS>
tiempo Efectivo: GTS
tIempoActIvIdad: GTS
tlempoDIsponlblldad: TS
cdlgoPrlorldad: SET<CE>
cdlgaConfldenclalldad:
SET<TS>
nmeroRepetlcln: IVL<irJT>
Indlnterrup: BL
cdIgoNlvel: CE
Indlndependen: BL
Enlace de
Re. Activ
cdIgoTIpo; CS
tiempo Efectivo: !VL<TS>
cdigotipo: c ^
indlnversln: BL
cdlgoControlContexto: CS
IndConduccIfiContexto: BL
nmeraSecUBida: INT
numero Prioridad: INT
cdIgoC lequEo: CS
cdlgoC Ivlsln: CS
cdigol nln: CS
IndNeg cln; EL
Figura 4.3 Modelo de referencia de los GPICs.
4.1.2.1
Entidad
Los atributos mas significativos de esta clase son:

cdigoClase. Un medio de definir qu especializacin de Entidad est usndose. Siempre ha de estar
presente.
cdigoDeterminador. Proporciona un medio de especificar si la instancia de Entidad (o su
especilaizacin) describe una instancia real de alguna cosa (INST), un tipo de algo (KIND), o una
cuantificacin de algo.
63
cdigo. Es el atributo principal para la clasificacin de la elase o de todas sus especializaciones.

Indica qu tipo de Entidad est siendo referido, mediante el uso de un cdigo procedente de uno o
varios sistemas de codificacin.
desc. Proporciona una descripcin de la entidad o de sus especializaciones, utilizando texto libre o
informacin multimedia.
id. Proporciona un identificador nico para una entidad. Idealmente cada entidad tendr slo un
identifcador asignado, sin embargo, dado que diferentes sistemas pueden mantener diferentes bases
de datos, puede haber distintos identificadores asignados por distintos sistemas a una misma entidad
nombre. Proporciona el nombre de una entidad.
cantidad. Especifica la cantidad de una entidad dada (p.ej: nmero, longitud, volumen, masa,
superficie, energa, etc.).
cdigoManejo. Un cdigo, o un conjunto de ellos, utilizado para describir cmo manejar una entidad
para evitar causarle dao a ella o a otras entidades
cdigoRiesgo. Un cdigo, o un conjunto de ellos, para indicar si existe algn riesgo o peligro asociado
a una entidad
4.1.2.2
Rol
Los atributos mas significativos son:

cdigoClase. Proporciona un medio para definir, de una forma genrica, la categora del rol que una
entidad juega.
cdigo. Describe, utilizando un valor codificado, el rol que juega una entidad.
tiempoEfectvo. Describe el momento o el intervalo de tiempo durante el que la entidad jug este rol.
cantidad Este atributo es usado en composiciones-relaciones del tipo tiene-partes, tiene-ingredientes,
contiene, etc. y expresa la cantidad de la entidad destino que est contenida en otra cantidad de la
entidad origen de dicha relacin.
id. Proporciona un identificador para la entidad cuando est jugando este rol particular. Por ejemplo:
nmero hospitalario del paciente, identificador del mdico,...
direccin. Direccin apropiada para la entidad de este rol. Por ejemplo: direccin del mdico
consultado.
telecom. Nmeros y direcciones de telecomunicacin de la entidad asociada con este rol.
4.1.2.3
Participacin

cdigoTipo. Proporciona un medio para definir, de una forma genrica, la categora de la participacin
que una entidad tiene en una actividad.
64
cdigoFuncin. Proporciona un medio para definir ms concretamente el tipo de participacin, a

travs de cdigos pertenecientes a un esquema de codificacin externo.
tiempo. Especifica el intervalo de tiempo en el que tuvo lugar la participacin.
cdigoModo. Es un cdigo que especifica el modo en el que la participacin tuvo lugar, por ejemplo,
con presencia fsica, a travs del telfono, por comunicacin escrita o utilizando un servicio de
telecomunicacin.
nmeroSecuencia. Permite ordenar las mltiples participaciones en un acto, bien por razones
funcionales o como medio de establecer prioridades entre las mismas.
cdigoConocimiento. Indica si el paciente asociado a una participacin, o sus familiares, estn
enterados del servicio, especialmente de una observacin realizada. Por ejemplo un paciente puede no
ser consciente de la malignidad de un diagnstico.
cdigoFirma. Especifica si el participante ha completado algn proceso de firma relativo a su
participacin en el acto o si dicha firma es necesaria.
textoFirma. Firma por la cual la entidad asociada a la participacin avala que dicha participacin en el
acto se ha realizado y que acepta la responsabilidad por el mismo.
4.1.2.4
Actividad

cdigoClase. Proporciona un medio para indicar, usando un conjunto de cdigos predefinidos, a qu
tipo de acto se refiere la instancia de la clase.
cdigoMood. Todas las instancias de esta clase deben definir, por medio de un conjunto de cdigo
predefinidos, si la accin debe concebirse como un hecho o de alguna otra manera (una orden, una
posibilidad o un deseo).
cdigoEstado. Indica el estado de una accin (p. ej. suspendida, activa, completada, etc.).
cdigo. Un cdigo especificando el tipo de la accin (p. ej. examen fsico, visita de paciente,
transaccin financiera, etc.)
id. Identifcador de la instancia de un acto determinado.
tiempoActividad. El momento en el que la actividad tuvo lugar, o est previsto que ocurra, o podra
ocurrir (la interpretacin depende de lo que indique el atributo cdigoMood). Cuando se usa con
procedimientos y otros eventos, se indica el tiempo total de la actividad, incluyendo el tiempo
empleado en las acciones de preparacin y de limpieza.
tiempoEfectivo. Incluye nicamente el tiempo efectivo empleado en la accin. Es diferente del
indicado en activityTime. Por ejemplo en procedimientos quirrgicos, el effectiveTime es el tiempo
transcurrido entre el primer corte y la ltima sutura.
nmeroRepeticin. Es el rango que indica el mnimo y el mximo nmero de repeticiones de un acto.
cdigoPrioridad. Codifica la xirgencia con la que un acto debe programarse y realizarse (o la urgencia
con la que fue realizado).
65
texto. Descripcin en forma de texto libre (o informacin multimedia) del acto, con el detalle
necesario.
4.2 Material. Conceptos del dominio

Tal y como ya se describi en el captulo 3 (ver aptdo 3.3.1), en el nivel de conocimiento del modelo
universal segn CEN/TC251 (ver fig. 3.6), a los trminos de referencia del dominio (prENV 136062:1999) se aadan en la actual revisin los componentes de informacin de propsito general (prENV
14822 GPIC) [14822], los arquetipos (prENV 13606-2/3:2003) [13606:2003 Parts 2-3] y un sistema
de conceptos para soportar asistencia continuada (prENV 13940) [13940].
4.2.1 Componentes de informacin de propsito general (GPIC)

CEN/TC251 realiz en 1999 la propuesta de definir un conjunto de componentes de informacin de
propsito general (GPIC) que se pudieran utilizar, con diferentes propsitos, para la definicin de
estructuras de comunicacin, e iniciar un camino de armonizacin de los modelos de informacin del
dominio sanitario en Europa y EEUU, sirviendo a los diferentes mercados y con la pretensin de
hacer los resultados disponibles a ISO. Estos GPICs pueden ser ima especificacin de un componente
de un sistema de informacin o una comunicacin entre dos sistemas y se pueden utilizar para
construir un sistema o una comunicacin.
Estn basados en parte del modelo de informacin de referencia (RIM) de HL7, que proporciona un
modelo abstracto desde el que se pueden seleccionar los elementos (clases, atributos y asociacin
entre clases) que se necesitan para poder disear los GPICs.
Estos componentes se generan para proporcionar un conjunto de arquetipos (CEN) / templates (HL7)
genricos de conceptos que se encuentran en el dominio y que pueden describir:
Cosas o actividades.
Agrupaciones de cosas con actividades
Agrupacin de actividades
Relacin entre cosas y/o actividades.
4.2.1.1 Descripcin de los GPICs

Estn descritos en el documento prENV 14822 [14822]. Cada GPIC tiene un nombre y un
identifcador nico y cada uno define un ncleo que representa la descripcin de la normativa y sus
propiedades del GPIC. El interfaz con otros GPICs (modelos externos) lo realizan mediante alguna
clase del RIM.
66
Un GPIC puede contener clases abstractas, sin atributos; los tienen cada una de sus especializaciones,
que son a su vez otros GPICs.
UN GPIC puede tener extensiones (la mayora las tienen); que son tratadas como informativas. En la
descripcin del estndar, se muestran como asociaciones que atraviesan la frontera del ncleo entre
una clase del ncleo del GPIC y otro GPIC extemo al ncleo.
4,2.1.1.1
Reglas de actuacin
El RIM proporciona las clases genricas (Entidad, Actividad, etc) junto con un conjunto de atributos
genricos con sus tipos de datos y reglas acerca del nmero y tipo de relaciones con otras clases del
RIM. El GPIC toma del RIM esas clases, atributos y asociaciones de la clase que se requieren e
impone restricciones definiendo:
El propsito preciso de la combinacin de clases del RIM; es decir cual es el alcance del GPIC.
El subconjunto de atributos usados en cada clase.
El propsito exacto de cada atributo.
Limitaciones en los tipos de los datos asociados con cada atributo.
El resultado es que el RIM proporciona los bloques bsicos con los que se construyen bloques ms
grandes, los GPICs. Un ejemplo para ilustrar los fundamentos del proceso es: El RIM contiene p.ej el
concepto Persona que podr usarse en GPICs que describen pacientes, doctores, ATSs, parientes, etc.
Un GPIC usar aquellos atributos de Persona que sean apropiados a la funcin particular del GPIC
combinndola con otro concepto del RIM (clase Rol) produciendo una descripcin ajustada de la
persona/rol que describe a una persona jugando el rol de paciente, etc.
Las reglas bsicas de uso de los GPICs en comunicacin son:
Los remitentes de informacin estn obligados a soportar solamente los atributos obligatorios.
Los que reciben la informacin deben poder soportar todos atributos, tanto opcionales como
obligatorios.
Respecto al tema de localismos en los GPICs, decir que la informacin en el dominio sanitario es muy
diversa y las situaciones en las que la informacin se crea y se utiliza es ms diversa todava. Por ello,
localmente se puede no slo aadir o quitar atributos, sino tambin aadir restricciones sobre dichos
valores.
4.2.1.1 GPICs No-Clnicos

Dentro del apartado no-clnicos se incluyen los GPICs relativos a:
67
Personas_relacionadas. Incluyendo el concepto genrico de persona; una versin abreviada de

persona para uso donde un identificador y un nombre sea suficiente; y el lenguaje de la persona (el
utilizado habitualmente).
Organizaciones_relacionadas. Incluyendo organizaciones dentro de organizaciones y contactos de
personas.
Identtficacin_sujeto_de_atencin. Incluyendo los criterios para la identificacin de personas y
animales.
Sujeto_de_atencin. Incluyendo informacin de tipo general acerca de personas, animales y grupos de
animales que cumplen el rol de sujeto_de_atencin.
Sujetos_de_atencin_relacionados. Incluyendo informacin acerca de otros sujetos_de_atencin que
tienen relacin (p.ej madre), y partes relacionadas con el paciente (p.ej pariente, empleador). Este
grupo de GPICs tambin incluye descripciones de la participacin del paciente u otras personas en
actividades asistenciales.
Agente_Sanitario. Incluyendo informacin acerca de profesionales y orgaitzaciones (tambin
dispositivos), sus roles y participaciones en la provisin de servicios asistenciales
Dispositivos. Incluyendo su descripcin, uso, calibracin y localizacin de uso.
Localizaciones. Incluyendo lugares de asistencia tales como planta, cama, casa, etc. Tambin incluye
lugares no-sanitarios tales como el sitio de origen de una muestra de comida.
Transporte. Incluyendo el transporte o la disposicin para el transporte de personas, animales u
objetos inanimados.
Financieros. Incluyendo costes asistenciales, autorizacin y acuerdos sobre servicios.
Un listado de los GPICs no-clnicos y sus identificadores, descritos en prENV14822, puede verse en
el Anexo 1.
4.2.1.2 GPICs Clnicos

Dentro del apartado clnicos se incluyen los GPICs relativos a:
Objetosjinalizables. Algo derivado de un sujeto_de_atencin, o que va a serlo, como parte de una
prueba diagnstica o de laboratorio (modificacin de prENV 12539) [12539]. Objeto_analizable es
una generalizacin que incluye: muestras tomadas de un paciente, registros fsicos o digitales de
informacin derivado de un sujeto_de_atencin como parte de un servicio diagnstico. Un
objeto_analizable no necesita existir de forma tangible, sino que puede representar algo observado
brevemente por un proveedor de un servicio diagnstico. Se especializa en los GPICs Espcimen o
Producto_de_Estudio.
Espcimen. Una o mas partes tomadas de vm sistema (o subsistema), o que van a serlo, para proveer
informacin sobre ese sistema (o subsistema), o proveer una base para la toma de decisiones
(modificacin de prENV 12539) [12359]. El sistema del cual se toma una muestra puede ser un
68
paciente, o puede l mismo ser un espcimen. Se asume que el espcimen es representativo del
sistema. El trmino muestra es usado a veces con el mismo significado.
Producto_de_estudio. Registro de informacin procedente de un paciente, como parte de un servicio
de diagnstico. Puede tomar la forma de un objeto fsico, o puede consistir en informacin digital en
un sistema de informacin (modificacin de prENV 12539) [12539]. Un producto_de_estudio difiere
de una muestra en que una muestra es algo tomado de un paciente, mientras que un
producto_de_estudio es un registro de informacin derivado de un paciente. Una consecuencia de esta
distincin es que un producto_de_estudio puede ser copiado. Adems, si el producto_de_estudio es
representado en forma digital, puede ser almacenado, o transferido entre sistemas de informacin.
Ejemplos.
Una imagen de Rx; una serie de imgenes de Rx; parte de una imagen de RX. Las imgenes
pueden estar en forma digital o en film.
Un electrocardiograma (ECG) de una derivacin; de doce derivaciones. La seal puede estar en
forma digital o en papel.
Una diapositiva conteniendo una seccin tomada de la biopsia.
Una imagen observada a travs de un endoscopio; una observacin durante un examen
ecocardiogrfco.
Informacin_clnica. Informacin acerca de un paciente, relevante para la salud o el tratamiento, que
es registrada por, o en representacin de un profesional sanitario. Es una clase abstracta, que se
especializa en dos:
Item_de_Informacin_Clnica. Unidad de informacin, que en un cierto contexto se considera
indivisible. Se especializa en: Observacin Clnica, Procedimiento Clnico, Tratamiento con
Medicamento, Suministro de Medicamento, Resultado de una Prueba, Peticin de una Prueba,
Consejo, e Informacin Clnica No Clasificada.
Contenedor_de_Informacin.
Descripcin de un 'contexto' o 'contenedor' que se usa para
agrupar varios tems. A su vez se especializa en: Agrupacin de Informacin Clnica, Peticin de
Servicio Asistencial, Informe sobre Servicio Asistencial, y Encuentro.
Pruebas_deJaboratorio_y_diagnsticas. Incluyendo los relativos a resultados de las pruebas, rangos
y procedimientos de medida, etc.
Medicacin. Incluyendo dosis, vas, presentacin del producto medicinal, etc.
Servicios asistenciales. Incluyendo encuentros, peticiones de servicio e informes sobre servicios
solicitados.
Una relacin de los GPICs clnicos y sus identifcadores, descritos en prENV14822, puede verse en el
Anexo 2.
69
4.2.2 Sistema de conceptos en asistencia continuada.

Antes de pasar a describir los conceptos del dominio [prENV13940; Consorti] que estn mas
relacionados con la integracin de la teleconsulta en la actividad asistencial, conviene fijar los cuatro
trminos que siguen, a veces usados de forma confusa.
Asistencia continuada. Principio organizacional, donde uno o mas proveedores (organizaciones o
profesionales sanitarios) proporcionan varios servicios asistenciales al sujeto de atencin (p.ej
paciente).
Asistencia compartida. Principio organizacional, donde uno o mas proveedores cooperan de forma
conjunta para proporcionar servicios asistenciales a un sujeto de atencin para un determinado tema
de salud. Este principio organizacional se centra en agrupar objetivos y responsabilidades.
Asistencia "sin costuras ". Principio de calidad, centrado en la transferencia apropiada (y en tiempo)
de actividad e informacin, cuando la responsabilidad de la provisin de los servicios asistenciales es
completa o parcialmente transferida de un proveedor a otro.
Asistencia integrada. Principio organizacional, abarcando al mismo tiempo asistencia continuada,
asistencia compartida y asistencia "sincosturas".
4.2.2.1 Actores
Agentejisistencial.
El concepto mas general que incluye Persona, Organizacin, Dispositivo o
Software que lleva a cabo un rol en una actividad asistencial. Engloba al propio sujeto de atencin
(p.ej paciente), tomando parte activa en aquellos servicios asistenciales que le conciernen; al
proveedor de la asistencia (p.ej organizacin o profesional); y a terceras partes asistenciales (p.ej
personas allegadas al paciente, o agentes econmicos). Tambin se usa para representar cualquier
entidad autorizada a tener acceso a la informacin.
Parte_asistencial. Concepto que engloba al sujeto de atencin, y al proveedor involucrados
directamente, y a las terceras partes, involucrados indirectamente en el proceso asistencial.
Dispositivo_asistencial. Dispositivo o equipo usado en la provisin de servicios asistenciales.
Softwarejisistencial. Software usado en la provisin de servicios asistenciales.
Sujeto_de_atencin. Restringido a Persona que va a recibir, est recibiendo, o ha recibido uno o
varios servicios asistenciales.
Proveedor_asistencial. Concepto que engloba a la organizacin o profesional involucrados
directamente en la provisin de los servicios asistenciales.
Tercera_parte_asistencial. Parte implicada en soportar servicios asistenciales de forma indirecta (p.ej
financieramente, o mediante ayuda social).
Organizacin_asistencial. Organizacin implicada directamente en la provisin de servicios
asistenciales. Subdivisiones tales como departamentos, son tambin organizaciones. Un grupo de
profesionales es un tipo de organizacin. Un profesional solo, si acta como tal, puede ser tambin
70
considerado como una organizacin. Existen mltiples tipos de organizaciones asistenciales [RosM3],
un listado que puede considerarse exhaustivo es:
Proveedor individual, con poca relacin con otros actores. Cada proveedor da un servicio
claramente definido respecto al resto.
Conjunto de proveedores de la misma organizacin intercambiables. Alguien tendr la
responsabilidad mxima, pero cada proveedor es completamente responsable durante un cierto
periodo de tiempo.
Grupo con varias competencias y tareas. Grupo operando de acuerdo a una cadena de
responsabilidades; un miembro del grupo puede asignar una subtarea a otro miembro, y recibir un
informe. Cada tarea es un escaln hacia un objetivo.
Conjunto de grupos operando independientemente. Solo relacionados por la accin del propio
sujeto de atencin.
Conjunto de grupos programando tareas entre ellos, de una manera no predefinida. P.ej un
profesional snior detenta la responsabilidad global; asigna tareas a los grupos y recibe informes.
Conjunto de grupos operando por separado secuencialmente en cascada sobre la base de hitos,
cada uno teniendo que alcanzar un objetivo. Solo hay interaccin para el paso de responsabilidad.
Conjunto de grupos operando de acuerdo a un programa integrado y predefinido.
Profesional_asistencial. Persona implicada directamente en la provisin de servicios asistenciales.
Puede compartir atributos con la organizacin, pero puede tener responsabilidades especficas; por
ello necesita ser identificada individualmente en el proceso asistencial.
Otros_asistentes. Parte que provee asistencia para actividades de la vida diaria o soporte social. No
incluida en este trabajo.
Parte_asistencialjinanciera.
No incluida en este trabajo.
4.2.2.2 Temas de salud y su gestin

Temajdejsalud. Aspecto relativo a la salud (tambin denominado condicin o aspecto clnico) y
definido (como una etiqueta) por una parte asistencial. Es un concq)to mas amplio que problema de
salud. Puede ser un problema, una enfermedad, un diagnstico, una solicitud de procedimiento
(teraputico o preventivo) procedente del sujeto de atencin, o de un profesional. P.ej: un ataque
cardiaco, una prdida de peso, una herida, un certificado mdico, una vacunacin, etc.
Todos los servicios asistenciales proporcionados en relacin a un tema de salud, forman el contenido
de un episodio de atencin, que puede ser incluido en un folder de EHR_Extract..
Temadesalud"
enhebrado". Construccin abstracta definida por una parte asistencial que enlaza
varios temas de salud (varias etiquetas).

Cada profesional, en funcin de su experiencia, conocimientos, rol, informacin disponible,
actividades realizadas (p.ej diagnstico/tratamiento), etc, puede etiquetar un mismo aspecto clnico de
71
forma distinta. Adems un tema de salud evoluciona con el tiempo, bien porque vare el contexto, o
por la propia evolucin intrnseca del aspecto clnico, por lo que pueden aplicrsele varias etiquetas.
Para conciliar todas esas posibles etiquetas, a veces ser necesario especificar xm enlace entre ellas.
Todos los servicios asistenciales proporcionados en relacin a im tema de salud "enhebrado", forman
el contenido de un episodio de atencin acumulado, que puede ser incluido en un folder de una HCE
virtual, como la unin de todos los flders locales relativos a los distintos temas de salud
contemplados.
4.2.2.3 Situaciones
Periodo_de_servicio. Intervalo de tiempo durante el cual, bajo la responsabilidad de un profesional o
una organizacin, ocurren uno o mas contactos entre el sujeto de atencin y un proveedor asistencial,
en el marco de un mandato de atencin. Dmante un periodo de servicio se puede atender mas de un
tema de salud y empezar un nuevo mandato de atencin, anidndose un periodo de servicio en otro.
Contacto (contact). Situacin durante la cual, un proveedor asistencial realiza servicios asistenciales
para un sujeto de atencin, y/o accede al EHR. Puesto que durante un contacto se pueden tratar mas
de un tema de salud, un contacto puede estar relacionado con mas de un episodio de atencin.
Durante el contacto el profesional asistencial puede interaccionar con el sujeto de atencin, otros
asistentes, dispositivos asistenciales, softwares asistenciales, o el EHR.
Existen dos tipos de contacto:
Acceso al EHR con la presencia directa o indirecta del sujeto de atencin, denominado encuentro.
Acceso al EHR sin la presencia del sujeto de atencin (p.ej sesiones/conferencias sobre un caso;
anotaciones sobre el caso, etc).
Encuentro. Situacin durante la cual, un profesional asistencial libra servicios asistenciales a un sujeto
de atencin, accede a su EHR y lo actualiza. Es necesaria la interaccin del profesional con el
paciente, ya sea directa (cara a cara) o indirecta (teleconsulta).
El atributo mas importante es la razn del encuentro, que es el motivo por el cual el sujeto de atencin
o una tercera parte en su nombre solicita asistencia. Como puede variar entre distintos encuentros del
mismo periodo de servicio, es necesario fijarlo en cada encuentro. La razn del encuentro es distinto
de la etiqueta tema de salud, y de la peticin de atencin, la cual tiene una asociacin directa con un
mandato de atencin al comienzo del periodo de servicio, y no tiene que ser restablecida en cada
encuentro.
Acceso+actualizacin_del_EHR. Contacto restringido al acceso al EHR de un sujeto de atencin por
un proveedor asistencial, para lectura y escritura de datos e informacin, sin la presencia del sujeto de
atencin. Si no se modifica nada, no se considera contacto.
Elemento_de_contacto. Fraccin del contacto que trata especfcacmente un (y solo uno) tema de
salud, clasificando los servicios asistenciales relativos a ese tema de salud. Durante un contacto
72
pueden tener lugar varios. Tiene poco valor operacional en la realidad asistencial, pero es valioso en
la gestin de la informacin.
Episodio_de_atencin. Situacin que abarca todos los elementos de contacto manejados por un
proveedor asistencial, relativos a un mismo tema de salud Est basado en los servicios asistenciales
librados a un sujeto de atencin con respecto a un tema de salud.
No coincide necesariamente con el periodo de enfermedad. El episodio de atencin comienza cuando
un mandato del tipo peticin de atencin es expresado, y cuando una etiqueta tema de salud es
enunciada por un profesional asistencial. El episodio de atencin termina cuando el ltimo servicio
asistencial para ese tema de salud es completado, aunque persistan sntomas, u otros servicios
asistenciales sean librados por otro profesional asistencial.
El episodio de atencin, puede ser incluido en un folder de EHR_Extract..
Perodo_ acumulado_de_atencin. Situacin que abarca la provisin de todos los servicios
asistenciales relacionados con un tema de salud "enhebrado" consistente, y librados (normalmente)
por diferentes proveedores asistenciales. Puede ser incluido en un folder de un virtual EHR, como la
unin de todos los flders locales relativos a los distintos temas de salud contemplados.
4.2.2.4 Actividades
Estos conceptos direccionan el proceso de acuerdo al cual, guas clnicas genricas y protocolos son
eventualmente particularizados en programas de atencin y planes de atencin, para llevar a cabo la
asistencia a un sujeto de atencin especfico.
Gua_clnica. Conjunto de declaraciones sistemticamente desarrolladas para asistir en la decisin a
las partes asistenciales, respecto a los servicios asistenciales que han de proveerse en relacin a un
tema de salud, en unas determinadas circunstancias clnicas. Son genricas, y aunque pueden incluir
mltiples detalles operativos, no se refieren a un sujeto de atencin en particular. Deben ser
estructuradas y contener criterios e indicadores estndar de medida.
Protocolo. Particularizacin de una gua clnica para su uso en un contexto local, formalizando sobre
todo los roles de las partes_asistenciales. Tampoco se refiere a xm sujeto de atencin en particular.
Programa_de_aencin. Descripcin, adoptada por una organizacin asistencial, de xm conjunto (haz)
de servicios asistenciales planeados y debidamente personalizados, normalmente basada en uno o mas
protocolos que direccionan uno o mas temas de salud, pertenecientes a uno o mas temas de salud
"enhebrados", y abarcando todas las actividades asistenciales realizadas para un sujeto de atencin
por una o mas partes asistenciales.
Un programa de atencin involucra un sujeto de atencin, un proveedor asistencial, y uno o varios
profesionales asistenciales.
Un programa de atencin es una informacin compartible, y por lo tanto habr de ser notificada en
imo o mas repositorios de informacin compartible, de acuerdo a determinadas reglas de acceso y
distribucin.
73

Plan_de_atencin. Parte del programa de atencin correspondiente a un nico profesional asistencial.
Es una informacin compartible.
Objetvojisistencial. Final deseado de un programa de atencin.
Fin_asistencial. Final deseado de un plan de atencin. Se considera como un escaln intermedio del
obj etivo_asistencial.
Actividad_asistencial. Actividad llevada a cabo para im sujeto de atencin por un agente asistencial
con la intencin de mejorar o mantener directa o indirectamente la salud del sujeto de atencin.
Servicio_asistencial. Cualquier tipo de actividad (actos, procedimientos, intervenciones, etc) llevada a
cabo para un sujeto de atencin por un proveedor asistencial (organizacin o profesional), en relacin
a uno o mas temas de salud, en uno o mas contactos, con la intencin de mejorar o mantener directa o
indirectamente la salud del sujeto de atencin.
Haz_de_servicios. Conjunto de servicios asistenciales que han sido, estn siendo o van a ser librados
para un sujeto de atencin, por uno o mas proveedores asistenciales, en relacin a un tema de salud
"enhebrado", en el contexto de un plan de atencin o un programa de atencin.
Acttvidad_asistencial_auxiliar. Actividad llevada a cabo para un sujeto de atencin por otro asistente
distinto de un proveedor asistencial, que complementan y soportan im programa de atencin.
Actividad_asistencial_automatizada. Actividad llevada a cabo para un sujeto de atencin por un
dispositivo asistencial o un software asistencial, sin la ejecucin de ningn comando por parte de un
profesional asistencial.
4.2.2.5 Mandatos (Responsabilidad)

Solicitud_de_atencin. Peticin expresada por una parte asistencial (el propio sujeto de atencin o en
su representacin) para que ciertos servicios asistenciales sean librados al sujeto de atencin.
La gestin de la responsabilidad en la asistencia continuada gira alrededor del concepto de mandato.
Mandato. Conjunto de declaraciones que expresan el alcance y los lmites de la responsabilidad de un
profesional asistencial para jugar un determinado rol. El mandato es implcito o explcito en funcin
de legislacin local, regulaciones o simples circunstancias.
El mandato lo pueden dar:
el sujeto de atencin, una autoridad sanitaria, un ciudadano que la ley habilita, etc.
por transferencia (temporal/permanente; parcial/total) de un actor a otro.
El mandato puede ser:
abierto y genrico a todos los temas de salud que puedan aparecer (p.ej mdico de atencin
primaria)
limitado a uno o mas problemas predefinidos (p.ej mdico especialista)
74
El mandato puede implicar diversos tpos de servicios asistenciales (p.ej una visita, una prueba
diagnstica, un juicio diagnstico sobre datos existentes, una decisin teraputica, realizacin de una
terapia siguiendo un protocolo, etc.
Desde el punto de vista del flujo de trabajo en el sistema de informacin, el mandato puede ser
explcito o preasignado (implcito). Puede asegurarse que la negociacin del mandato es realizada
(propuesta, aceptacin/rechazo, notificacin), bien mediante una aplicacin informtica, o mediante
un profesional asistencial. Un mandato siempre se corresponde con la obligacin de registrar o atestar
informacin.
Existen cuatro tipos de mandatos: mandato de peticin, mandato de atencin, mandato para exportar
datos personales y mandato facilitador de continuidad, cuya descripcin sigue a continuacin.
Mandato_de_peticin.
Mandato asignado a una o mas parte asistenciales para actuar en
representacin del sujeto de atencin, en la solicitud de aquellos servicios asistenciales considerados

relevantes respecto a una necesidad asistencial percibida. Normalmente es expresado por el propio
sujeto de atencin, pero existen mltiples circunstancias en las que eso no es posible.
Es el mandato que provoca una solicitud de atencin.
Mandato_de_atencin. Mandato asignado a uno o mas proveedores asistenciales de realizar servicios
asistenciales para un sujeto de atencin, as como de gestionar localmente la informacin relativa a la
salud del sujeto de atencin.
Una vez que una solicitud de atencin es expresada a un proveedor asistencial, se le est dando un
mandato cuya responsabilidad el proveedor asistencial puede aceptar o rechazar. El alcance del
mandato puede ser restringido (por ley, regulaciones, etc), de acuerdo a la competencia del proveedor
asistencial, y por tanto el sujeto de atencin puede ser derivado y la responsabilidad transferida parcial
o totalmente.
Mandato_j)ara_exportar_datos_personales. Mediante este mandato, un sujeto de atencin u otra
persona habilitada en el mandato de peticin autoriza a una parte asistencial a enviar fuera (a un
receptor designado) datos personales del sujeto de atencin. Sin esa autorizacin no se pueden enviar
fuera, aunque puede darse la situacin contraria; implcitamente esa autorizacin existe, y la
denegacin es la que se ha de presentar explcitamente.
MandatoJacilitador_de_continuidad. Mandato asignado a un agente asistencial para monitorizar, en
representacin del sujeto de atencin, cmo son gestionados los sucesivos mandatos de atencin, y
hacer que su contenido est disponible a los agentes asistenciales autorizados, de forma que un
proveedor asistencial conozca los mandatos de atencin aceptados por los otros proveedores
asistenciales. Mas all del rol estricto, el proveedor asistencial al que se le asigna este mandato, puede
convertirse un un coordinador de los servicios asistenciales librados al sujeto de atencin.
75
Notificacin_dejnandato. Contiene informacin acerca de los cambios que han ocurrido, debido a la
evolucin en el proceso de atencin o por otras razones, en el 'status' de un mandato explcito. No
tiene que contener informacin detallada acerca del estado clnico del sujeto de atencin.
En la prctica asistencial, todos los cambios en mandatos relativos a servicios asistenciales ya librados
o por librar, han de ser notificados.
Una notificacin de mandato es informacin compartible, y por tanto habr de ser notificada en uno o
mas repositorios de informacin compartible, donde pueda ser accedida de acuerdo a reglas de
distribucin.
4.2.2.6 Informacin
La asistencia continuada implica gestionar la informacin generada desde dos perspectivas:
Gestin local de la informacin acerca del sujeto de atencin, en el lugar donde se libra el servicio
asistencial, e
Intercambio de informacin entre los proveedores asistenciales.
El conocimiento (soporte a la colaboracin) recproco entre los distintos profesionales asistenciales
involucrados en la provisin de los servicios asistenciales al sujeto de atencin, implica conocer:
El estado percibido del sujeto de atencin,
Los servicios asistenciales ya librados o planeados, con sus correspondientes fines asistenciales.
Las responsabilidades de los actores.
La presencia de los EHR local y de los Repositorio de informacin compartible existentes; la
naturaleza de la informacin clnica disponible, e incluso la existencia de informacin identificada
como valiosa para el proceso asistencial en curso.
La asistencia continuada implica un apropiado flujo de informacin entre los EHR local existentes, en
orden a permitir por una parte la sincronizacin de actividades (asistencia sin costuras), y por otra una
correcta informacin en los EHR locales.
Los conceptos relativos a la informacin son:
EHRJocal. EHR almacenado y mantenido para un sujeto de atencin, por una parte asistencial.
ComponentejdeJEHR. Parte de un EHR que es identificada a efectos de referencia y revisin (ver
aptdo 4.1.1.2.2).
Informacin compartible. Un tipo de componente de EHR que un profesional asistencial marca como
compartible, sujeto a unas reglas de distribucin.
Informacin_cUnica_especfica. Un tipo de componente de EHR que contiene informacin especfica
de un sujeto de atencin, enviado por una parte asistencial a otra parte asistencial, en inters del sujeto
de atencin y con su autorizacin, (posiblemente como resultado de una Peticin de informacin
clnica especfica previa, para cumplir con las necesidades actuales de informacin del receptor.
76

Informacin_clnica_paraJmportar.
Un tipo de componente de EHR que es candidato a ser
inq)ortado en el EHR local almacenado localmente por la parte asistencial, despus de que un
profesional asistencial ha validado su relevancia clnica (atestado).
Repositorio_de_informacin_compartible. EHR que contiene exclusivamente componentes de EHR
del tipo informacin compartible. Para asegurar y mantener su consistencia, debe colocarse bajo la
custodia de un agente asistencial a quien se le asigna un expreso mandato facilitador de continuidad.
Peticin_deJnformacin_clnica_especfica.
Peticin, enviada por una parte asistencial a otra parte
asistencial en el inters del sujeto de atencin y con su autorizacin, de una informacin especfica no
disponible en ningn Repositorio de informacin compartible.
Informacin_clnica_no_yalidada. Un tipo de componente de EHR cuya relevancia clnica no ha sido
todava validada por un profesional asistencial.
4.3 Material. Lenguajes de definicin de arquetipos

En este apartado, despus de presentar brevemente la estructura de los arquetipos desarrollados hasta
ahora en varios proyectos en UK y AustraUa, se describe con cierto detalle un nuevo formalismo
introducido muy recientemente, denominado ADL- Lenguaje de Definicin de Arquetipos, y que ser
el utilizado en este trabajo de tesis en el desarrollo de los arquetipos y templates necesarios para
integrar la teleconsulta entre profesionales en un marco conforme al escenario general de
estandarizacin (Cap. 3), sobre el modelo de referencia de EHR_Extract (aptdo 4.1.1), y usando los
concqjtos del dominio (aptdo 4.2.2).
4.3.1 XML. Definicin de los arquetipos hasta la actualidad.

Durante los aos 2000-2002 en el marco del proyecto GEHR Australia [GeAu], pero sobre todo
Titanium [GeAu] se escribieron, o al menos se esbozaron mas de 50 arquetipos, segn la informacin
disponible por el autor, no descartndose la existencia de otros, no publicados ni accesibles. Los
primeros se escribieron utilizando XML-DTDs, despus XML-Schema.
Se consideraba la existencia de tres grandes tipos de arquetipos: transaccin ('transacton'),
organizativo ('organiser') y contenido ('conten').
4.3.1.1
Arquetipos tipo Transaccin.
Los arquetipos de este tipo podan ser a su vez de dos tipos: persistentes o relativos a eventos. Se
componen de items de contenido (definidos por arquetipos tipo contenido) colocados bajo items
organizativos (definidos por arquetipos tipo organizativo).
77
Transaccin_Evento. Agregacin de entradas realizadas por un mismo clnico en una sola sesin y
con datos pertenecientes a ese momento, p.ej contactos, notas de progreso, resultados de pruebas de
laboratorio, etc.
Transaccin_Persistente. Agregacin de entradas que pertenece a un paciente y permanece vlida
sobre un periodo de tiempo (cada versin realizada por un mismo clnico), p.ej resmenes, planes de
atencin, historia familiar, etc.
El elemento denominado raz de un arquetipo tipo transaccin contiene: el Identifcador
(ID_Modelo_Clnico); el Concepto (Concepto_Modelo_Clnico) y la Documentacin. Los dos
primeros identifican el arquetipo, el tercero contiene informacin adicional (metadatos) acerca del
arquetipo y sobre uso y mal uso del mismo.
Al
elemento
raz
se
le
pueden
aadir
dos
elementos:
un
patrn
de
contenido
(ID_Patrn_Contenido_Modelo_Clnico) que permite especificar restricciones sobre el nombre de los

arquetipos
tipo
organizativo
que
contenga;
un
patrn
de
contexto
(ID_Patrn_Contexto_Modelo_Clnico) que permite especificar restricciones sobre el nombre de los

arquetipos tipo contenido_definicin (ver apartado 4.3.1.3) usados en el contexto de la transaccin.
4.3.1.2
Arquetipos tipo Organizativo.
Organizativo. Proveen la capacidad de construir estructuras jerrquicas de clasificacin en las que se

colocan items de contenido, p.ej lista de problemas, precauciones teraputicas, rdenes de
medicacin, etc.
Un arquetipo de este tipo contiene: el Identifcador (ID_Modelo_Clnico); el nombre raz
(Nombre_Raz_Organizativo) que es el nombre que aparecer en el arquetipo tipo transaccin que lo
incluya, pudiendo incluir restricciones opcionales sobre el nombre; la cardinalidad y la
documentacin.
A un arquetipo de este tipo se le pueden aadir tres elementos: un patrn de contenido
(ID_Patrn_Contenido_Modelo_Clnico) que permite especificar restricciones sobre el nombre de los
arquetipos tipo contenido que contenga y sean usados como contenido en la transaccin; un patrn de
organizacin (ID_Patrn_Organizativo_Modelo_Clnico) que permite especificar restricciones sobre
el nombre de los arquetipos tipo organizativo usados; y un organizador propiamente dicho, que
permite al organizativo raz tener una lista de organizativos, cada uno de ellos pudiendo tener una
lista, proporcionado la estructura requerida.
4.3.1.3
Arquetipos tipo Contenido.
Existen los siguientes tipos diferenciados de contenido:
78
Contenido_Subjetivo. Informacin subjetiva procedente del paciente mismo, el profesional sanitario o

cualquier otra fuente, p.ej reaccin adversa, alergias, evaluacin pie diabtico, historia miembro
familiar, etc.
ContenidoJDbservacin. Informacin ostensiblemente objetiva recogida como resultado de algn
procedimiento de observacin o registro, p.ej bioqumica, microbiologa, presin sangunea, ndice de
masa corporal, examen ocular, etc.
Contenidojnstruccin. Declaraciones de alguien describiendo acciones que han de ser emprendidas,
p.ej derivacin del paciente, orden de medicacin, etc.
Contenido_Definicin. Informacin genrica con contenido no especializado, p.ej target, etc.
Estando previstos otros dos tipos de contenido:
ContenidoJProceso. Modela procesos relativos a un tema en el cual otros tipos de contenido figuran
como observaciones, rdenes, resultados y objetivos.
ContenidoJ^regunta. Contiene la definicin y resultados de una pregunta especificada como 'match'
de un patrn.
El elemento denominado raz de un arquetipo tipo contenido contiene: el Identificador
(ID_Modelo_Clmco); el Concepto (Concepto_Modelo_Clnico) y la Documentacin. Los dos
primeros identifican el arquetipo, el tercero contiene informacin adicional (metadatos) acerca del
arquetipo y sobre uso y mal uso del mismo.
En este tipo de arquetipos el cuerpo principal del arquetipo se denomina Elemento_Proposicin y es
del tipo PROPOSICIN_JERRQUICA, pudiendo ser de cuatro tipos (ver apartado siguiente
4.3.1.4). Una vez fijado el tipo (uno de los cuatro) es posible, dependiendo del tipo de proposicin,
aadir o quitar elementos de dos tipos: GRUPOJERRQUICO y VALORJERRQUICO. Con
estos elementos se puede modelar la estructura de datos del modelo clnico (concepto).
Los arquetipos tipo contenido, sobre todo los tipo contemdo_observacin y contenido_subjetivo,
contienen elementos tales como: Sujeto (informacin acerca del paciente). Protocolo (describe el
proceso que se llev a cabo para recoger la informacin en el arquetipo), y Protocolo_Requerido
(permite al autor especificar si el Protocolo debe ser incluido en el arquetipo).
Los elementos 'Subject' y Protocolo_Requerido se incluyen en el elemento raz del arquetipo. El
elemento
Protocolo
es
del
tipo
PROPOSICINJERRQUICA,
como
ocurre
con
el
Elemento_Proposicin.
4.3.1.4
Elementos adicionales.
En este apartado se describen los elementos, ya mencionados en el apartado anterior, que pueden ser
aadidos a los modelos clnicos: PROPOSICINJERRQUICA, GRUPOJERRQUICO y
VALORJERRQUICO.
79
Proposicin Jferrquica. Define cmo se representarn los datos dentro del arquetipo tipo contenido.
Se usa frecuentemente en arquetipos tipo transaccin y tipo contenido.
Los
distintos
tipos
existentes:
PROPOSICIN_SIMPLE,
PROPOSICIN_LISTA,
PROPOSICIN_ARBOL y PROPOSICIN_TABLA, permiten representar valores simples, listas,

rboles y tablas.
El tipo PROPOSICIN_JERRQUICA consta de dos elementos: Nombre, que puede ser texto o un
trmino procedente de una terminologa (pudiendo ambos ser adems restringidos); y Contexto, que
permite al autor especificar si el contexto debe o no ser presentado.
GrupoJerrquico.
Estos elementos son usados junto con los valoresJerrquicos para construir
estructuras tales como rboles y tablas, dentro de las proposicionesjerrquicas.

El tipo GRUPO_JERRQUICO consta de tres elementos: Nombre, que puede ser texto o un trmino
procedente de una terminologa (pudiendo ambos ser adems restringidos); Cardinalidad, que puede
ser restringida especificando valores mnima y mxima; y Contexto, que permite al autor especificar
si el contexto debe o no ser presentado.
Un GRUPOJERRQUICO puede contener otros elementos tipo GRUPO_JERRQUICO y/o tipo
VALOR_JERRQUICO.
ValorJerrquico.
El tipo VALOR_JERRQUICO consta de: Nombre, que puede ser texto o un
trmino procedente de una terminologa (pudiendo ambos ser adems restringidos); y los
Tipos_de_Datos permitidos.
4.3.2 Introduccin de un lenguaje especfico

El lenguaje de definicin de arquetipos (ADL) es un lenguaje [Beal4][Heard] creado para la expresin
formal de arquetipos, los cuales, como se describi en el captulo 2, son los modelos de entidades del
dominio basados en restricciones. Existe una nueva versin ADL vl.2, pero el trabajo ha sido
realizado sobre vO.9.
ADL podr ser utilizado para escribir arquetipos para cualquier dominio donde los modelos de objetos
formales existentes describen instancias de datos. Sin duda, los arquetipos sern en los prximos aos
la forma ms usual de describir los datos en un sistema cuando se utilizan modelos de informacin
muy genricos (p.ej conceptos tales como PACIENTE, HOSPITAL, DOCTOR sean representados
por clases como PARTY). En tales casos, los arquetipos son utilizados para restringir las estructuras
vlidas de instancias de estas clases genricas. De esta manera relativamente simple, los modelos de
informacin y los esquemas de bases de datos pueden ser definidos, y los arquetipos proporcionan el
modelado semntico, totalmente fuera del software.
80

Los arquetipos expresados en ADL se asemejan a ficheros de lenguaje de programacin y tienen una
sintaxis definida. ADL utiliza dos sintaxis bien definidas: el formato de definicin de restricciones
(cADL) y el formato de definicin de datos (dADL).
Un arquetipo tiene las secciones que se ven en la figura 3.4. La sintaxis cADL se utiliza para expresar
la definicin del arquetipo y la sintaxis dADL para el resto de secciones. Las diferentes secciones son
descritas en detalle en el apartado 4.3.2.3.
Arquetipo
opcional
arqaetipo_id
- , [especializacin
arquetipo_id
Concepto
coiicepto_id
descripcin
Arquetipo __ ^
ADL
Meta-dato descriptivo
'
dADL
Definicin
Definicin
Restriccin foinal
*"~^
CJntologa
Terminologa y
defnidones de letigiiaje
-^
Figura 4.4 Estructura de un arquetipo en ADL
4.3.2.1
dADL- Lenguaje de definicin de datos
La sintaxis dADL proporciona una manera formal de expresar instancias de datos basados en un
modelo de referencia. Permite la representacin de datos de forma que sea procesable por una
mquina y legible por una persona, a la vez que se hacen las mnimas suposiciones posibles sobre el
modelo de informacin del dato al que se ajusta.
Su apariencia general puede verse en el siguiente ejemplo:
PERSONA [01234] = <
nombre = <
nombre ^ <"xxxxxx">
apellido = <"xxxxxx">
>
direccin = <
nombre_calle = <"xxxx">
nmerocalle = <"xx">
ciudad = <"xxxxx">
distrito =<"xxxxx">
pais = <"xxxxxx">
~ nombre de persona
direccin de persona
Ms de un modelo de informacin puede ser compatible con el mismo dato expresado en dADL.
Aspectos bsicos de la sintaxis son;
81
Palabras clave. dADL no tiene palabras clave, se asume que todos los identifcadores vienen del
modelo de informacin.
Comentarios. Indicados por los caracteres "~".
Citaciones. El carcter ('\') se utiliza para citar caracteres reservados en dADL, p.ej '<', '>' y "".
Identificadores del modelo de informacin. Dos tipos de indicadores: nombre de tipo y nombres de
atributo. Los nombres de tipo se muestran en MAYSCULAS y los de atributo en minsculas. En
ambos casos se utiliza el guin bajo para unir palabras.
Identificadores de instancias. Las instancias de datos se identifican con el identificador delimitado por
corchetes ([id]). Son utilizados para identificar y referirse tanto a datos expresados en ADL, como a
entidades extemas.
Punto y coma. Se utiliza para separar los bloques de dADL.
4.3.2.1.1
Estructura de dADL
Aspectos relevantes de la estructura de la sintaxis son:

Contenido. La estructura de dADL es puramente jerrquica y se compone de un modelo genrico:
id_atributo = < valor >. El id_atributo puede ser un nombre de atributo, o un nombre de atributo seguido
de un cualificador: atributo ("cualif) = < valor >, que permiten representar con facilidad listas y tablas.
La parte <valor> puede anidarse cuantas veces sea necesario.
Secciones vacas. Permiten expresar que en alguna instancia no hay ningn dato para un atributo,
aunque se muestra que dicho atributo existe en un modelo de informacin subyacente.
dADL annimo. Dato expresado en dADL que no tiene un identificador global.
dADL identificado. Se proporciona el TIPO y un nico identificador de instancia, haciendo posible el
direccionamiento de cualquier fragmento desde cualquier parte, incluidos otros fragmentos de dADL.
Dato descompuesto. Una instancia de un tipo que est compuesta de instancias de tipos ms pequeos
puede ser representada de dos formas: en un gran bloque, o la descomposicin en bloques dADL
identificados.
Objetos compartidos. La forma descompuesta de dADL se puede usar para expresar la comparticin
de un objeto por otros objetos, por el uso del mismo identificador en ms de un lugar.
Alcance de un documento. Un documento de dADL puede estar formado por mltiples rboles de
datos en dADL que transcurren uno tras otro. De acuerdo con esto, se asume que los identificadores
de nodo son nicos al menos dentro del documento.
4.3.2.1.2
Tipos bsicos en dADL, preguntas y caminos.
Los tipos de datos bsicos en dADL son: CADENA, ENTERO, REAL, DOBLE, BOOLEAN,
CARCTER, varios tipos de da/hora, listas de estos tipos y algunos tipos especiales.
dADL no utiliza nombres de tipo o atributo para instancias de tipos bsicos, slo valores:
82

Atributo = < valor >
Cadena. Todos las cadenas se muestran entre comillas. Los caracteres especiales se expresan
utilizando ISO 10646 o los cdigos de carcter especial de XML.
Entero. Se representan simplemente como nmeros.
Real. Se asume como nmero real aquel con decimales; siempre se representa al menos con una cifra
decimal.
Boolean. Son los valores verdadero y falso.
Carcter. La forma literal de mostrar los caracteres es mediante comillas simples.
Fechas y Horas. En dADL, los das y las horas se expresan en la forma marcada en ISO8601:
aaaa-mm-dd
~ un da
hh:imn [:ss[.sss] [z]]
una hora
aaaa-mm-dd hh:mm:ss [.sss] [z]
da/hora
Lista de tipos bsicos. Dato de xm tipo bsico puede aparecer slo o en una lista, separados por comas.
Preguntas. Preguntas a servicios externos se pueden incluir en dADL, p.ej:
itemsC'acOOOl") = <query("terminology", "termmologyjd = ICDIO AND code matches 7*' ")>
Esta pregunta se realiza a un servicio_de_terminologa asumido en el entorno (p.ej el OMG/HDTFTQS, o el HL7-CTS) y especifica que debera ser devuelto cualquier trmino en ICDIO cuyo cdigo
coincide con "J*'. La nica restriccin en la sintaxis de preguntar es que siga el formato general
siguiente: Queiy("servicename","querytext").
Caminos. Pueden construirse para hacer referencia a cualquier nodo en dADL data. Est compuesto
de segmentos separados por"/', donde cada segmento es el nombre de un atributo con un identificador
de objeto opcional.
[7'| id_objeto] nombre_atributo ["[' id_objeto"]'] { 7 ' nombre_atributo ["[' id_objeto"]'] }
4.3.2.2
cADL- Lenguaje de defnicin de restricciones
cADL es la sintaxis que pernte expresar las restricciones sobre datos definidos por modelos de
informacin orientados a objetos, mediante arquetipos u otros formalismos de deficin de
conocimiento.
Aspectos bsicos de la sintaxis cADL son:
Palabras clave, matches, occurrences, existence, cardinality, unordered, unique, use_node,
use_archetype.
Para uso especfico en invariantes: exists, for_all, and, or, xor, not, implies, true, false.
Comentarios. Se indican mediante "~".
Identificadores del modelo de informacin. En cADL se puede usar nombres de TIPO y cualquier
nombre de propiedad (atributo o funcin). En dADL, slo aparecan nombres de tipo y de atributo.
Los identificadores de tipo se muestran en MAYSCULAS, los de propiedad en minsculas.
83
Identificadores de nodo. En cADL, una cadena entre corchetes (p.ej [xxxx]) identifica un nodo_objeto
(ver apartado 3.3.2.4), es decir, un nodo que expresa restricciones sobre instancias de algn tipo. El
nodo_objeto siempre comienza con un nombre de tipo.
Lenguaje Natural. cADL es totalmente independiente de todos los lenguajes naturales. La nica
posible excepcin es cuando las restricciones incluyan valores de algn lenguaje y esto es fcil y
rutinariamente evitado por el uso separado de secciones de definiciones, terminologa y lenguaje. Los
comentarios pueden estar en cualquier lenguaje.
4.3.2.2,1
Estructura
Las restricciones en cADL se escriben en un bloque estructurado similar al bloque estructurado de

programacin de lenguajes como C. Un ejemplo es el siguiente:
PERSONA [001] matches {
nombre E {
NOMBRE_PERSONA[0G2] G {
nombre cardinality G {1..*} G {/.+/}
nombrefamiar G {/.+/}
titulo G {"Dr", "Miss", "Mrs", "Mr",...}
}
}
direccin cardinality G {1..*} G {
DIRECCION_LUGAR [003] G {
numerocalle existence G {0..1} G {/.+/}
nombrecalle G {/.+/}
}
}
Este ejemplo expresa la restriccin de una instancia de tipo PERSONA; la restriccin es expresada
por todo lo que hay dentro del bloque PERSONA. Los dos bloques que hay en el siguiente nivel
definen las restricciones en propiedades de PERSONA, en este caso 'ame' y 'addresses'. Cada una
de estas restricciones se expresan en el siguiente nivel, as pues la estructura general es una anidacin
de restricciones en tipos, seguido de restricciones en propiedades (de ese tipo), seguido por los tipos y
as sucesivamente.
Los identificadores en el ejemplo anterior podran corresponder a entidades en un modelo de
informacin orientado a objetos. Por ejemplo, un modelo de UML compatible con el ejemplo anterior
sera el de lafigura4.5.
Puede haber fcilmente varios modelos compatibles con un fragmento dado de cADL. Un texto cADL
incluye restricciones slo sobre aquellas partes del modelo que es til restringir.
Las restricciones expresadas en cDAL no pueden ir ms all de las del modelo de informacin. Por
ejemplo, el atributo 'familyname' de PERSON es obligatorio en el modelo de la figura anterior, y
as no sera vlido expresar una restriccin donde el atributo fuera opcional.
84
PARTE
NOMBRE_PARTE
Detalles [*]: Cadena
Aptitudes [*]: Capacida
nombre
4.
NOMBRE PERSONA
PERSONA
nmeoCalle.f ] : Cadena
nombreFamilia [1]: Cadena
ttulo [0..1]: Cadena
nombre
DIRECCIN POSTAL
direccin
nmeroCalle [ ]: Cadena
nombreCalle [1]: Cadena
localidad [1]: Cadena
codgoFostal [1]: Cadena
estado [1]: Cadena
Pas [1]: Cadena
Figura 4.5 Modelo referencia de PERSONA
En cualquier modelo UML de informacin hay 'existence', 'occurrences' y 'cardinalities' sobre

algunas propiedades y relaciones:
Existencia. Restriccin en invariantes; dice si un atributo debe existir o no, y se indica con marcadores
"0..1" o " 1 " al final de la lnea (frecuentemente se confunde con cardinalidad). Se aplica solamente a
las propiedades y se expresa de la siguiente manera:
QUANTITY matches {
units existence matches {0..1} matches {"mm[Hg]"}
}
Puede tomar los valores {0}, {0..0},{0..1}, {!}, {1..1}. Los dos primeros para decir que un atributo
no debe estar presente en la situacin particular modelada por el arquetipo; los dos ltimos son por
defecto y no se necesita ensearlos.
Ocurrencia. En cADL, una restriccin sobre ocurrencia se utiliza slo con nodos de tipos para indicar
cuantas veces en tiempo de ejecucin, una restriccin particular (una instancia de ese dato) puede
ocurrir.
Cardinalidad y tipos contenedor. Es muy comn en cADL definir restricciones sobre listas de items.
Mientras que la restriccin ocurrencia indica cuantas instancias de ese tipo pueden ocurrir, no dice
nada sobre el total de nmero de items permitidos en la lista. Para restringir esto, se requiere una
restriccin cardinalidad para la propia lista. Un ejemplo:
HISTORIA[001] ocurrences e {1} e {
peridico e {False}
eventos cardinaUty G {*} e {
EVENTO[002] occurrences e {0.1} e {}
EVENTO[003] occurrences e {0..1} e {}
EVENTO[004] occurrences e {0..1} G {}
}
}
85
La palabra clave cardinalidad indica primero que la propiedad 'events' debe ser del tipo contenedor,
como LIST<T>, SET<T>, BAG<T>, pero no indica cual; eso debe estar definido en el modelo de
informacin.
Alternativas. Bloques repetidos restringiendo objetos de la misma clase pueden tener dos posibles
significados lgicos, determinados por la combinacin de las ocurrencias individuales y de la
cardinalidad de la propiedad (contenedora).
Restriccin 'Any". Hay dos casos donde es til declarar una restriccin completamente abierta. La
primera es cuando se desea mostrar explcitamente que alguna propiedad puede tener cualquier valor,
es decir, que cualquier valor permitido por el modelo de informacin subyacente es tambin permitido
por el arquetipo. El segundo uso es para poder decir (en tiempo de ejecucin) que una propiedad debe
ser de un tipo determinado, pero puede tener cualquier valor internamente.
Identificacin de nodos. Cualquier cadena entre corchetes: [xxxx]. Son requeridos por cualquier nodo
(ver apartado 3.3.2.4) que precise ser direccionado en cualquier parte del texto de cADL o del sistema
en tiempo de ejecucin. Otra funcionalidad es darle a los nodos un significado en tiempo de diseo,
mediante la asociacin del identificador del nodo a alguna descripcin.
Caminos. Se utilizan en cADL para referirse a nodos cADL. La sintaxis de los caminos tiene la misma
forma que la estructura jerrquica general de cADL: TIPO/propiedad/TIPO/propiedad/...
Los caminos estn formados por la alternancia de identifcadores de nodo y de nombre de propiedad.
Los caminos siempre hacen referencia a un objeto o a una propiedad, segn sea el elemento final.
Ningn camino tiene validez fuera del bloque cADL en el que ocurre, puesto que no incluyen un
identificador del documento adjunto.
Referencias Internas. Es comn que un bloque interno de cADL se necesite repetir ms tarde en el
mismo bloque en una zona ms exterior. UtiUzar una parte previamente definida de un arquetipo
cADL, se lleva a cabo con la palabra use_node: use_node TYPE object_path, (ver apartado 3.3.2.4)
Invariantes. Mientras la mayora de las restricciones se pueden expresar utilizando la sintaxis
estructurada de cADL, hay algunas ms complejas (p.ej cualquier restriccin que relacione ms de
una propiedad con otra que est en esa misma categora, como son la mayora de las restricciones que
contienen frmulas matemticas o lgicas), son ms fcilmente expresadas como invariantes.
Una invariante es una declaracin en lgica de predicados de primer orden, que puede ser evaluada
como un resultado boolean en tiempo de ejecucin. A los objetos y propiedades se les hace referencia
usando caminos ('paths'). Se declaran tras la palabra clave 'invariant' en secciones al final de bloques
de tipos, cada una precedida por una etiqueta que indica el propsito de la invariante, y pueden incluir
los siguientes operadores y operandos:
Operadores
Cuantificador universal: for_all
Operadores booleanos: not, and, or, xor, implies, exists
Operadores relacinales: =, <, >, <=, >=, !=
86
Operadores aritmticos: +, -, *, /, , //, \\

Operadores de Grupo: matches (es miembro de)
Operandos
Constantes: de cualquier tipo bsico, expresada correctamente en sintaxis dADL
Referencia a propiedad: cualquier camino que termine: ".nombre_propiedad"
Referencia a objeto: cualquier camino que termine con el identificador de un nodo.
Referencias a Arquetipos.
En cualquier punto de la seccin definicin, otros arquetipos pueden ser referenciados, en lugar de
definirlos dentro del bloque. Las referencias a arquetipos son ellas mismas, restricciones sobre los
posibles arquetipos permitidos en el punto donde ocurre la referencia. En ocasiones pueden hacer
referencia a arquetipos especficos, pero en general, la intencin de los arquetipos es proporcionar
modelos generales reutiUzables de conceptos del mundo real. Como se apunt en el captulo 3 (aptdo
3.2.4.3), las restricciones locales se dejan para los templates.
4.3,2,2.2
Restricciones sobre tipos bsicos
En cADL las restricciones sobre atributos de tipos bsicos se pueden expresar sin nombres de tipo y
omitiendo un nivel de corchetes: alg;n_atributo matches {algn_patrn}.
Restricciones sobre Cadena. Puede hacerse de dos maneras: utilizando una cadena fja, o utilizando
una expresin regular.
Restricciones sobre Entero. Los enteros se emparejan utilizando rangos de enteros.
Restricciones sobre Real. Se sigue la misma sintaxis que para los enteros excepto que todos los
nmeros reales son expresados con el punto decimal y al menos un dgito decimal.
Restricciones sobre Boolean. Los valores en tiempo de ejecucin se pueden restringir a Verdadero,
Falfso, o cualquiera de los dos.
Restricciones sobre Carcter. Se pueden restringir utilizando valores manifiestos encerrados entre
comillas simples.
Restricciones sobre das, horas e intervalos de tiempo. Se restringen utilizando el mismo concepto de
rangos utilizados para expresar restricciones sobre enteros y reales.
Restricciones sobre listas de tipos bsicos. En muchos casos, el tipo de un atributo es una Hsta o un
conjunto de tipos bsicos; deben indicarse usando la palabra clave cardinalidad:
algin_atributo cardinalidad matches {....} matches {algn_patrn}
4.3.2.3
ADL - Lenguaje de Definicin de Arquetipos
Un arquetipo ADL sigue la siguiente estructura, ya vista en la figura 3.4:

archetype
identifcador_arquetipo
87
specialise
identficador_arquetipo_padre
concept
cdigo_nombre_concepto
description
seccin_metadatos (dADL)
defniton
seccin_estructura_arquetipo (cADL)
ontology
seccin_definiciones (dADL)
Aspectos bsicos de ADL son:
Palabras clave. Son pocas: archetype, specialise, concept, description, definition, terminology.
Pueden tambin aparecer como identificadores en las secciones definicin y ontologa.
Identificacin de nodo. En la seccin definicin, un esquema particular de cdigos es usado como
identificadores de nodos (ver apartado 4.3.2.4), y tambin para distinguir restricciones sobre
elementos textuales, que son dependientes del idioma. Se representan: [cdigo]. Ambos se definen en
la seccin ontologa.
Los cdigos usados como identificadores de nodos son prefijados por 'at' (p.ej [atOOOl]); hay
especializaciones de conceptos codificados localmente (p.ej [atOOOl.l]).
Los cdigos usados para establecer restricciones sobre items textuales en el cuerpo del arquetipo son
prefijados por 'ac' (p.ej [acOOOl])
4.3.2.3.1
Secciones de cabecera
Las secciones que suelen denominarse de cabecera son:

Seccin Arquetipo. Introduce el arquetipo e incluye un identificador.
Seccin Especializacin. Indica que el arquetipo es especializacin de otro arquetipo padre cuya
identidad se debe dar.
Seccin Concepto. Todos los arquetipos representan algn concepto del mundo real. El concepto est
siempre codificado, asegurando que puede ser expuesto en cualquier lenguaje en que haya sido
traducido el arquetipo.
Seccin Descripcin. Contiene informacin descriptiva (metadatos) del arquetipo, p.ej Autor,
Organizacin, Fecha de creacin. Estado, Revisin, Propsito, Uso, Mal_uso, Versin_ADL, etc.
4.3.2.3.2
Seccin Definicin
Contiene la definicin formal principal del arquetipo escrita en cADL. Ejemplos se vern en el
captulo 5, donde se describen los arquetipos desarrollados en este trabajo de tesis.
4.3.2.3.3
Seccin Ontologa
88
La seccin ontologa de un arquetipo se expresa en dADL y es donde: a) estn definidos los cdigos
que representan el significado de los nodos y las restricciones sobre texto; b) se describen las uniones
('bindings') a terminologas; c) se declaran otras definiciones ontolgicas, como las definiciones
cuantitativas, y d) el lenguaje de traduccin es aadido. Cada una de estas secciones puede tener su
propia seccin de descripcin (metadatos).
Las tres primeras cabeceras son relativas a:
Primaryjanguage. Lenguaje en el que el arquetipo fue escrito.
Languages_availables. Lenguajes disponibles en el arquetipo, es decir para los que existe traduccin.
Terminologies_availables. Terminologas para las que existe unin disponible.
Las diferentes partes de la seccin ontologa son las siguientes:
Seccin Term_deftnition. Es la subseccin donde son definidos todos los trminos locales del
arquetipo, es decir trminos de la forma [atNNNN]. En algunos casos, las definiciones del trmino
pueden haber sido extradas de terminologas existentes.
Seccin Constraintjdefinition. Tiene la misma forma que la seccin term_definition y proporciona las
definiciones, que son de la forma [acNNNN]. Las definiciones de restriccin no proporcionan las
restricciones propiamente dichas, sino que definen el significado de tales restricciones, de una manera
comprensible para el humano y utilizable en aplicaciones GUI.
Seccin Term_binding. En esta subseccin se describen las equivalencias entre trminos locales del
arquetipo y trminos encontrados en terminologas externas. El propsito es slo permitir el uso de
software de consulta para poder buscar una instancia de un trmino externo o determinar que
equivalencia usar en el arquetipo. Cada entrada simple indica qu trmino en una terminologa externa
es equivalente a los cdigos internos del arquetipo.
Seccin Constraintjbinding. Describe formalmente las restricciones sobre items de texto en el cuerpo
principal del arquetipo. Cada restriccin es descrita por separado, porque son dependientes de la
terminologa y porque puede haber mas de una unin.
4.3.2.3.4
Relaciones entre arquetipos
Nuevos arquetipos pueden ser creados basndose en otros existentes. Puede ocurrir de dos maneras,
debido a versin y debido a especializacin. Revisiones tambin estn incluidas aqu, aunque no crean
nuevos arquetipos.
Nuevas Versiones. Se pueden crear nuevas versiones de arquetipos existentes. Una versin nueva es
requerida p.ej por cambios en un arquetipo que tiene un error y genera resultados no conformes al
arquetipo. Un arquetipo no-conforme es aquel cuyos datos generados no se corresponden con el
arquetipo anterior. Un algoritmo de conversin de datos se debe proporcionar siempre con cada nueva
versin. Las versiones se indican en el identifcador de arquetipo, lo que significa que dos versiones
del mismo arquetipo lgico son, tcnicamente hablando, dos arquetipos diferentes.
89
Revisiones. Los arquetipos pueden ser revisados, lo que significa que pueden incorporarse cambios sin
crear una nueva versin o especializacin. Las revisiones se utilizan en las siguientes situaciones:
Aadir una traduccin a un nuevo lenguaje.
Aadir una nueva unin a terminologa.
Disminucin de algunas restricciones (p.ej cambiar cardinalidades de 1..1 a 0..1).
Cambios en los elementos de la seccin descripcin.
Composicin de Arquetipos. Los arquetipos estn diseados para ser compuestos en grandes
estructuras que describen secciones completas de datos en un sistema, p.ej documentos completos en
EHR, o p.ej el objeto completo PERSON en el servicio 'Demographics'.
La palabra clave use_archetype introduce una restriccin que evala
un conjunto de posibles
arquetipos que pueden ser adjuntados en ese punto. En tiempo de ejecucin, el usuario tiene que
escoger uno de ellos. Las referencias a arquetipos, definen de esta manera, las composiciones (de
arquetipos) posibles en tiempo de ejecucin, aunque en algunos casos, pueden mencionar un nico
arquetipo especfico, lo que supone que no hay que elegir nada en tiempo de ejecucin.
En general los arquetipos deben permitir la mas amplia eleccin posible en cada siguiente nivel,
siendo usados los templates para definir composiciones particulares (encadenamiento) de arquetipos.
Cuando se componen los arquetipos, los caminos se pueden utilizar para referenciar un elemento
(tem) de un arquetipo inferior, comenzando desde el arquetipo mas superior, es decir usando el
camino completo.
Especializacin. Los arquetipos pueden ser especializados. La primera regla para la especializacin es
que los datos creados de acuerdo al arquetipo especializado se garantiza que se ajustan al arquetipo
padre. Los arquetipos especializados tienen un identificador basado en el identificador del arquetipo
padre, pero con una seccin modificada. El contenido del fichero ADL de un arquetipo especializado
contiene todas las partes relevantes de su arquetipo padre, con adiciones o modificaciones de acuerdo
a las reglas de especiaUzacin. Los nodos en arquetipos especializados llevan, o bien el mismo
identificador que los nodos correspondientes en el padre, o el identificador derivado de
especializacin del identificador del nodo padre.
Existen normas sobre cmo se especializan los diferentes tipos de nodos (ver apartado 4.2.3):
nodo_objeto, reducir ocurrencias, dividir el nodo en subtipos, mediante 'usenode'.
nodo_relacin, estrechar existencia y cardinalidad
nodo_hoja, estrechar valores vUdos, p.ej reducir xm intervalo de enteros, reducir un conjunto de
cadenas.
nodo_ref_term (restricciones sobre tems texto, definidos en la seccin 'constraint_binding'),
estrechar a un subconjunto de trminos.
Identificacin de arquetipos. Los arquetipos pueden ser identificados mediante varios tipos de
identificadores (p.ej ISO-OIDs sin sigificado, multaxiales con significado, etc) y no est todava
90

asentada ninguna de las posibilidades. Aqu se usar un identifcador multiaxal; cada instancia del
identifcador describe un nico arquetipo en un espacio tridimensional: Organizacin que lo origina,
Entidad del modelo de referencia, y Concq)to del dominio.
El patrn es:
Archetype_id: archetype_originator.qualified_model_entity.domain_concept.version_id
siendo:
qualified_model_entity: model_originator.model_name.model_entity_name
domain_concept: concept_name {-specialisation}*
4.3.3 Otros posibles lenguajes a utilizar

Se realiza una breve comparacin de ADL respecto a otros posibles formalismos que tambin en
principio podran ser utilizados para escribir arquetipos; se incluye tambin la justificacin de usar
ADL.
XML-DTD. Los "primeros" arquetipos [Gehr2] fueron escritos en este lenguaje. ADL presenta una
sintaxis mas simple; es en verdad leble por humano, mientras que XML ciertamente no lo es; y
presenta im mecanismo formal basado en terminologa ('pathsV 'meaning') de identificacin de
nodos.
XML-Schema. Los "segundos" arquetipos [Gelh][Oacis] fueron escritos como instancias XML
conformes a XML-schemas; siendo equivalentes a instancias sealizadas del 'parse rbol'. Con las
herramientas de 'parsing' de ADL es posible convertir ADL a cualquier nmero de 'forms'
incluyendo varios formatos XML, pero tambin otros (p.ej IDL), proporcionando una mayor
flexibilidad. Los formatos XML pueden ser considerados una derivacin de la sintaxis ADL.
OWL (Web Ontology Language). Es formalmente una extensin de RDF ('Resource Description
Framework') para definir ortologas, de forma que puedan ser usadas en la web [OWL]. Es un
lenguaje ontolgico de propsito general, usado en primer lugar para definir clases de cosas de tal
manera que puedan soportar inferencias sobre los datos que representan. En principio, no hay asumido
ningn modelo de clases particular. Usualmente las definiciones de las clases son declaraciones de
restricciones sobre un modelo implcito en el cual se supone que los datos estn basados.
ADL y OWL son semnticamente equivalentes, pero existen sutiles diferencias que pueden resumirse
en: a) ADL tiene una sintaxis no-XML, no estando afectado por ninguna de las limitaciones de la
sintxis XML; b) los arquetipos en ADL siempre estn escritos respecto a algn modelo; y c) en ADL
est incluido la identificacin de nodos y el procesamiento de caminos ('meanings').
Es muy probable que en el futuro haya herramientas que permitan que arquetipos en ADL sean
totalmente convertibles en OWL y viceversa, permitiendo que el mismo arquetipo sea usado en
entornos XML y no-XML.
91
OCL (Object Constraint Language). Lenguaje desarrollado en OMG [OMG-OCL] para escribir
restricciones dentro de los modelos, incluyendo precondiciones, postcondiciones e invariantes. No
tiene carcter estructural, son declaraciones en lgica de predicados de primer orden acerca de
elementos de modelos UML. Por lo tanto es difcil utilizarlo para describir arquetipos desde un punto
de vista estructural, tal y como ven los expertos del dominio los modelos (conceptos).
No obstante OCL es de gran inters para ADL, dado que los arquetipos en ADL tienen invariantes y
actualmente se escriben en una sintaxis muy similar a OCL. Adems quizs los arquetipos lleguen
algn da a tener pre y postcondiciones.
Es muy posible, al igual que con OWL, que arquetipos en ADL puedan ser expresados sin prdidas en
OCL.
KIF (Knowledge Interchange Format). Es un lenguaje de representacin de conocimiento cuyo fin es
ser capaz de describir formalmente semnticas que puedan ser compartidas entre distintas entidades
software [KIF]. Es un lenguaje que define todos los conceptos que menciona; por lo tanto, es una
situacin muy diferente, ya que normalmente lo que se hace con ADL es definir restricciones sobre
conceptos procedentes de modelos ya definidos.
4.4 Metodologa
4.4.1 Mtodos y herramientas para construccin de mensajes
Las metodologas de desarrollo de mensajes seguidas por HL7 v3.0 (1999 - 2001) y CEN/TC251
(1996 - 2000) [12587], pueden verse en las figuras 4.6 y 4.7. En el fondo (no as en la documentacin
generada) son bastante similares, pues ambas metodologas comprenden la elaboracin de una
sucesin de modelos de casos de uso, de informacin, de interaccin, y de diseo. Una comparacin
de modelos y los acrnimos utilizados, puede verse en la Tabla 3.1.
Tabla 4.1 Modelos para desarrollo de mensajes.
Modelo
Informacin
Referencia
HL7 v3.0
RIM
CEN/TC251
Modelo
Informacin
Dominio
D-MIM
DIM
Modelo
Informacin
Mensaje
R-MIM
GMD
Representacin
Jerrquica
Mensaje
HMD
HMD
Componentes
Reusables
C-MET
GPICs
Los acrnimos del CEN/TC251 son:

DIM. Modelo que describe los atributos, propiedades, vocabularios y asociaciones de las clases de un
dominio particular.
GMD. Modelo (subconjunto del DIM) que describe un mensaje individual apropiado al ropsito de la
comunicacin.
92

HMD. Representacin jerarquizada del contenido de GMD.
GPIC. Conq)onente de informacin de propsito general.
Declaracin
alcance
proyecto
Crear
casos de
uso
Dibujar coa tenidos

ioiciales a partir de
RIH
Ideotificar
actores y
eventos
Disear clases prnc

Crear diagramas de
transicin entre
estados
I Introducir
nuevo
material
Desarrollar modelo
informacD mensaje
Desarrollar
especificacin
objetos mensaje
Figura 4.6 Organizacin HL7 del desarrollo de mensajes
IDENTIFICAR LA NECESIDAD DE MENSAJE
Especificacin
del alcance
Requerimientos
de usuario
Modelo
I n f o r m acin
Dom Inio
Escenarlos
Roies comunicacin
+
Servicios s o p o r t a d o s
Descripcin
General
Mensaje ( G M D )
Descripcin
Jerrquica
lensaje (HMD)
Syntaxis
Especificacin
Impiementacln
Mensaje
PREPARAR MENSAJE PARA IMPLEMENTACION
Figura 4.7 Organizacin CEN del desarrollo de mensajes

La mayor diferencia estriba en que la metodologa seguida por CEN/TC251 no especificaba ninguna
implementacin, es decir no declaraba ninguna sintaxis; eso se dejaba a criterio de los
93
implementadores. Los primeros desarrollos efectuados se hicieron en UN-EDIFACT, y los mas

recientes en XML.
Aspectos de inters en los modelos del CEN son los siguientes:
Modelo de Casos de Uso. El nfasis de CEN/TC251 est en las comunicaciones entre sistemas
dbilmente acoplados, es decir diferentes organizaciones (p.ej primaria y especializada), por lo que
tienen limitada importancia los eventos 'disparo' y no es obligado a la identificacin de los eventos
'disparo' para todos los flujos de mensajes.
Modelo de Informacin. En esta metodologa, la mayor parte de la informacin est en los modelos de
informacin del dominio (DIM). CEN/TC251 prcticamente no usa diagramas de estados. Debera
adoptarlos, aunque slo se aplicaran en muy contadas situaciones.
Modelo de Interaccin. Describe las partes que intercambian mensajes, y las interacciones. Una
interaccin define una instancia especfica de intercambio de informacin:
Evento de 'disparo'
Roles involucrados
Interaccin (soportada por una descripcin jerrquica del mensaje)
Secuencia
CEN/TC251 describe los escenarios a base de diagramas de secuencias.
Modelo de Diseo de Mensajes. Se denominan Modelo de Informacin de Mensaje (MIM),
anteriormente conocidos como Descripcin General del Mensaje (GMD).
A partir de 2001 en CEN/TC251 todos los GMDs, ahora llamados Modelos de Informacin de
Mensaje (MIMs) se construyen con los denominados Componentes de Informacin de Propsito
General (GPICs) [14822]. La documentacin de sus clases, estructura interior, atributos, etc. se
encuentra en la documentacin de los propios GPICs. En este trabajo se seguir esta metodologa
actualizada.
4.4.2 Mtodos y herramientas para construccin de arquetipos

No existe en la actuaUdad una metodologa o procedimiento mas o menos consensuado de cmo
construir un arquetipo. Hay razones que explican suficientemente la situacin.
Ha transcurrido demasiado poco tiempo desde la adopcin del paradigma de doble modelo que se ha
dado por bueno en este trabajo, como para que en estos momentos, estuviera adoptado un nico (y
optimizado) procedimiento desarrollador de arquetipos. Baste decir que se estn produciendo ahora
las primeras reuniones conjuntas de los grupos WGI y WGII, para establecer las bases de
colaboracin sobre arquetipos.
Adems, es bastante obvio que las ventajas del doble modelo se centran sobre todo en la
simplificacin del modelo de referencia, lo que implicar sin duda un software del sistema de
94
informacin mas sencillo y robusto, y la posibilidad cada vez mas cercana de utilizar herramientas,
p.ej Together [Toge], aunque tambin lenguajes, p.ej Eiffel [Eiff], Python [Pyth], partiendo de
especificaciones en UML de los servicios 'middleware' involucrados. Hay actualmente en este campo
una cierta analoga a la situacin que gener la aparicin de los lenguajes de alto nivel en el mundo de
desarrolladores de software en lenguajes ensamblador.
Tambin est claro el 'modus operandi' de este nuevo tipo de sistemas de informacin basados en el
doble modelo, en el momento de crear objetos (instancias de las clases del modelo de referencia) al
ejecutar software. Cuestin totalmente fuera de los lmites del presente trabajo.
Sin embargo, queda todo un camino de aos por delante en los que no estar claro cmo optimizar la
construccin de arquetipos, situacin que dar lugar a trabajos como el presente. Construir
actualmente arquetipos es ciertamente difcil puesto que supone, entre otras muchas dificultades,
representar conocimiento mediante la declaracin de restricciones sobre instancias de clases de
modelos que se estn todava definiendo, adems de la dificultad inherente a decidir en muchos casos
qu entidad es un concepto del dominio y cual no lo es.
Se dispone del material descrito en los dos apartados anteriores, el lenguaje en el que expresar
arquetipos y los modelos de referencia de los dos servicios involucrados. Sin embargo, se est en una
situacin en la que se puede afirmar que los arquetipos es necesario "escribirlos a mano". En el
momento de escribir este trabajo ni CEN, ni openEHR han proporcionado oficialmente una
herramienta de edicin. El autor ha dispuesto de xma versin pre-beta que openEHR puso a
disposicin de los miembros del grupo de trabajo EHRcom que no ha podido utilizar por los
numerosos errores que la hacan impracticable.
Por lo tanto, al no disponer de (verdaderas) herramientas de edicin, es obvio que en la actuahdad, no
se puede escribir un arquetipo sin conocer en profundidad el modelo de referencia y las posibles
instancias sobre las que sea de inters especificar restricciones.
El mtodo general de aproximacin a la construccin de arquetipos consiste en una manifestacin de
principios y niveles de acuerdo, que se han tenido en cuenta para realizar el desarrollo en este trabajo.
Los aspectos especficos del caso concreto de este trabajo se incluyen en el captulo 4.
4.4.2.1
Principios de los arquetipos
Al iniciar su construccin es necesario saber con claridad qu es un arquetipo. Un listado de los

principios en los que se basan los arquetipos son los siguientes:
Los arquetipos definen conceptos, es decir entidades del dominio, completos y distintos.
Los arquetipos describen la estructura de instancias de un modelo de referencia.
Los arquetipos expresan restricciones sobre instancias de un modelo de referencia.
La combinacin de estructura y expresin de restricciones, significa que numerosas variaciones de
una instancia del modelo de referencia (datos) pueden ser conformes a un mismo arquetipo.
95
La granularidad de un arquetipo se corresponde con la granularidad del concepto en el modelo de

referencia.
Si un modelo de referencia tiene Secciones tipo 'SECTION' y Entradas tipo 'ENTRY', habr
arquetipos para secciones y entradas.
Puesto que cada concepto del dominio se encuentra en un nivel ontolgico, los arquetipos
pertenecen a uno u otro nivel ontolgico.
Puede haber composicin entre arquetipos dentro de un nivel ontolgico, o entre niveles
adyacentes.
Un arquetipo puede ser la especializacin de otro arquetipo.
Otras afirmaciones que son verdad en la casi totalidad de casos reales son las siguientes:
Los arquetipos tienen una estructura composicional jerrquica.
Los arquetipos_nodos, tanto el raz como las hojas, son identificados por nombres estandarizados
('meanings'), que son unvocos en cualquier nodo, y que se denominan nombres en tiempo de
diseo.
Los datos generados desde un arquetipo (pueden ser varios del mismo arquetipo) tienen tambin
una estructura composicional, en la que los nodos tienen nombres unvocos; se denominan
nombres en tiempo de ejecucin.
Los diferentes idiomas son tratados va el medio usual de traducciones a travs de terminologas
codificadas, lo que permite, tanto a los arquetipos en tiempo de diseo, como a los datos en
tiempo de ejecucin, aparecer en el idioma del usuario local.
4.4.2.2
Niveles de acuerdo
Dejando al margen los niveles de acuerdo sobre los metadatos necesarios en la seccin de descripcin
del arquetipo, que sern de gran inters para su manejo en repositorios y acceso on-line, pero de
escaso inters respecto a las semnticas de los contenidos, se describen a continuacin los niveles de
acuerdo que es necesario manejar durante la construccin de un arquetipo.
Nivel 0. Principios. Acuerdo sobre la distincin y complettud de los conceptos (entidades) definidas.
Si no se tiene en cuenta, aparecern solapamientos entre conceptos y se producir (mas pronto que
tarde) una explosin de complejidad.
Nivel 1. Estructura bsica. Acuerdo sobre la estructura semntica del arquetipo: Identificacin,
estructura jerrquica de cada uno de los conceptos involucrados, nombres ('meanings'), cardinalidad
de las invariantes, restricciones sobre los tipos en los nodos_hoja (aunque no sobre valores u otras
restricciones detalladas).
Este nivel permite acordar los modelos (conceptos) del dominio, pero no dice nada de cmo
relacionarlos con los modelos de referencia, excepto del uso de tipos de datos.
96
Nivel 2. Relaciones entre arquetipos. Acuerdo sobre los tipos de arquetipos, es decir, su relacin con
el modelo de referencia. Acuerdo en la semntica de las restricciones sobre: composicin,
especializacin, y versiones de los arquetipos.
Nivel 3. Restricciones sobre contenido. Acuerdo sobre los tipos de nodo que no son raz ni hojas, es
decir, encontrar un significado comn de los conceptos del modelo de referencia usados en el
arquetipo. Acuerdo sobre la especificacin formal de los tipos de datos, incluyendo acuerdo o
equivalencia entre los nombres de los atributos.
Nivel 4. Equivalencia formal. Las invariantes expresan relaciones formales referidas a propiedades
(atributo, relacin) de cualquier elemento estructural del modelo. Es obligado que arquetipo y modelo
de referencia compartan su significado.
Los niveles de acuerdo se pueden resumir en lo siguiente:
Compartir significado modelo y arquetipo.
La relacin entre arquetipos se ha de producir en dos niveles: ontolgico (semntica) y terminolgico
(lxico).
4.4.3 Proceso de edicin en ADL

Cuando se escribieron los arquetipos que constityen parte de las tareas de desarrollo objeto de este
trabajo de tesis, y en particular los que figuran en el captulo de resultados, no se dispona de ninguna
herramienta de edicin, por lo que fueron escritos a mano. En la actualidad el autor utiliza una
herramienta [soys] muy sencilla, aimque en propiedad no puede llamarse editor, dado que las
facilidades que proporciona son mnimas.
4.4.4 Proceso de anlisis de ADL

En la figura 4.8 puede verse una ilustracin grfica del proceso de anlisis de ADL.
El fichero ADL es convertido por el analizador de ADL en un rbol ADL. Este rbol es una
representacin en memoria (estructura de objetos) de la semntica del arquetipo, hecha de una forma
conveniente para ser procesada posteriormente.
El rbol es independiente de los modelos de referencia involucrados, y necesita procesamiento
adicional, realizado por im "constructor de arquetipos", para crear un arquetipo en forma de modelo
de objetos que pueda ser usado en tiempo de ejecucin por los sistemas de informacin. El constructor
de arquetipos necesita como entrada la especificacin del modelo de referencia, es decir, tener acceso
en tiempo de ejecucin al modelo real de informacin cuyas instancias formarn los datos del sistema
97
de informacin. Esto podr realizarse via herramientas tipo CASE, via XMI (lenguaje de intercambio
de modelos descritos en ficheros XML), o lenguajes de programacin adecuados p.ej tipo Eiffel.
-raz
defiiiciii
onlologa
Especificacin
del modelo de
informacin
Clave:
^ B Nodo objeto
(
Restriccin terminolgica
j Nodo objeto primitivo ^ ^ Uso de arquetipo
witj Nodo de uso
Nodo de relacin
Figura 4.8 Estructura anlisis ADL.

El rbol ADL resultante del anlisis de un fichero ADL se ve en la parte derecha de la figura 3.8.
Consiste en niveles con nodos que contienen objetos que se alternan con niveles con nodos que
contienen propiedades; cada nivel es contenedor de los siguientes niveles. La lista completa de los
diferentes tipos de nodos es:
Nodo_objeto. Un nodo interior que representa una restriccin sobre instancias de algn tipo del
modelo (p.ej SECTION, ENTRY, etc).
Nodo_propiedad. Un nodo interior que representa una propiedad (atributo o relacin) de un tipo del
modelo.
Nodo_objetoJoja. Un nodo_objeto que representa una restriccin sobre tipos bsicos (STRING,
INTEGER, etc).
Nodoreferenciaobjeto
('use_node'). Un nodo que referencia a otro nodo_objeto ya definido. La
referencia se realiza usando un camino ('path').

Nodo_referencia_restriccin_texto. Un nodo que referencia un nodo_objeto que define una
restriccin sobre un texto o entidad 'codedterm', el cual aparece en la seccin 'constraint_binding'
del arquetipo. La referencia se realiza usando un cdigo [acNNNN].
Referencia_arquetipo. Un nodo cuya especificacin define una restriccin sobre otros arquetipos a los
cuales les est permitido aparecer en ese punto del arquetipo (ver Composicin de arquetipos en el
apartado anterior).
98
4.4.5 Herramienta de 'debug' ADL

La herramienta ADL Workbench, de Ocean Informatics es la utilizada para validar la correccin tanto
sintctica como semntica de los arquetipos desarrollados en este trabajo, y para serializarlos en html.
Esta herramienta es de libre distribucin y est en una fase temprana de su desarrollo, por lo que
carece de ciertas facilidades exigibles a un producto comercial, p.ej los arquetipos han de ser editados
a mano, no realiza comprobaciones contra el modelo de referencia en el que se basan los arquetipos
(si bien ya est programada su implementacin), etc. Sin embargo, al haber sido desarrollada por el
mismo equipo que produjo las especificaciones del lenguaje ADL, la herramienta resulta muy potente
en sus anlisis sintctico y semntico.
El primer paso para su uso consiste en la creacin del arquetipo en lenguaje ADL. Esto se puede
realizar de forma externa y cargando posteriormente el fichero de texto en la herramienta, o bien
escribindolo directamente en el editor proporcionado por la misma, que el usuario puede configurar
para utilizar el de su preferencia.
A continuacin, pulsando el botn 'Parse' se realiza el anlisis del arquetipo, informando de los
errores que se encuentren. Si todo ha ido bien se puede guardar el arquetipo en disco, mediante el
botn 'Save', siendo posible elegir el formato del mismo (ADL o HTML).
Una vez realizado el anlisis y no habiendo encontrado ningn error de sintaxis o de semntica, se
ponen a disposicin del usuario las herramientas para la navegacin. En la misma ventana en la que
aparece el cdigo fuente del arquetipo se puede elegir: ver un mapa de los nodos que componen el
mismo, o una relacin de los caminos ('paths') encontrados, tanto fsicos como lgicos.
La vista grfica est organizada en forma jerrquica, representado la disposicin de los nodos dentro
del arquetipo: Los nodos siempre comienzan con el nombre del tipo (de la instancia que restringen) y
un smbolo que expresa de forma grfica las caracterstica del nodo (de objeto, de uso, de restriccin
sobre terminologa, de primitiva o de uso de otro arquetipo), se incluye tambin la cardinalidad del
mismo y, entre corchetes, su nombre que sirve para identificarlo en los caminos y en las secciones de
terminologa y definiciones. En el siguiente nivel de la jerarqua (que se puede abrir y cerrar) aparecen
las restricciones sobre las propiedades del tipo padre. A su vez, en cada una de las propiedades se
pueden abrir nuevas secciones, repitindose en ellas la estructura de tipo y propiedades, continuando
con la jerarqua hasta que sea necesario. En esta vista se puede navegar y expandir o encoger cada uno
de los nodos (o del arquetipo entero) mediante los correspondientes botones, para facilitar la lectura.
Otra ayuda de la que dispone el usuario para mejorar la legibilidad de la vista de nodos es la
posibilidad de elegir entre un formato enfocado en el dominio y otro ms tcnico. Mientras que en el
99
Captulo 5. Integracin de la teleconsulta
5.
Integracin de la teleconsulta en la actividad asistencial
5.1 Aspectos bsicos del diseo de integracin

La teleconsulta entre profesionales sanitarios es un concepto de gran extensin dado que, bajo el
mismo trmino en la prctica asistencial se pueden presentar mltiples casos de uso y muy distintos y
complejos sistemas soportando los servicios telemticos y/o de otras caractersticas que constituyen el
servicio asistencial.
Aunque la adopcin del paradigma de doble modelo permite sin duda trabajar con modelos de
informacin (referencia) razonablemente pequeos; p.ej en este caso intervienen los modelos de
EHR_Extract, de RIM-GPICs y uno desarrollado en el marco de este trabajo para la continuidad
asistencial (ver aptdo 5.4), inspirado en un modelo de trabajo colaborativo sntesis de varios existentes
en la literatura [Elli][Fari][PICN], que no no son muy grandes; el nmero y la complejidad de los
conceptos clnicos (incluidos los estrictamente ligados a la teleconsulta) del dominio pueden ser
elevados. Es obvio que en este caso lo son.
Desde una perspectiva RIM-GPICs es como decir que las posibles instancias de actores, roles,
participaciones, y actividades que pueden verse involucrados son muy numerosas, pudiendo adems
adoptarse un gran nmero de relaciones entre ellas.
Anlogamente, desde la perspectiva del sistema de conceptos para la continuidad asistencial es como
decir que el contexto en el que se libra un servicio asistencial definido por:
Tema de salud (o tema de salud enhebrado, si se conoce)
Plan de atencin (o programa de atencin, si se conoce)
Episodio de atencin (o episodio de atencin acumulado, si se conoce)
Protocolo (si se conoce)
101
Gua clnica (si se conoce)

y el procedimiento propiamente dicho en el que tiene lugar una teleconsulta entre profesionales
sanitarios, es algo que puede ser ciertamente complejo y de difcil normalizacin, aun en el supuesto
(como de hecho se supone en este trabajo) de una situacin de estandarizacin generalizada.
El establecimiento o intento de adopcin de una posible metodologa nica de integracin de la
teleconsulta en el proceso asistencial no viene al caso, puesto que habra supuesto incluir (al menos)
en el material de trabajo la norma CEN prEN 12967 Health Informatics Service Architecture Part 1:
Enterprise viewpoint [12967-1] y Part 2: Information viewpoint [12967-2], y estar disponible su
armonizacin con el sistema de conceptos de continuidad asistencial CEN prEN13940 [13940],
cuestin que solo ha empezado a considerarse muy recientemente en el seno del 'Task Forc HISA'
[Hisa].
Una vez analizado el estado general de los documentos de estandarizacin en la poca en que se
afront este trabajo, se tomaron las siguientes decisiones de diseo, que una vez puestas en prctica
condujeron a los objetivos de desarrollo especificados en el captulo 2, (aptdo 2.2.2):
Respecto a los estndares:
Adoptar un doble "paraguas": CEN/TC251 y openEHR, que luego se ha revelado acertado tras las
publicaciones de las primeras revisiones de CEN prENV13606 por EHRCom.
Centrar los esfuerzos de desarrollo en el nivel de conocimiento del modelo universal (ver fig.
3.6): trminos de referencia (13606-2:1999), GPICs, arquetipos, templates y conceptos de mas
alto nivel. Esto implicaba no intentar elaborar un modelo de referencia propio para el tema de
trabajo.
Apostar por el uso de los GPICs como constituyentes estructurales de mensajes y arquetipos.
(cuestin que empieza a asumirse en la actualidad, pero n cuando comenz este trabajo y se
adoptaron las decisiones).
Aceptar desde el comienzo de las tareas de diseo, que la teleconsulta es un concepto
excesivamente extenso para ser susceptible de ser arquetipado por un nico arquetipo, aunque ste
fuera una gran encadenado de arquetipos primarios y/o organizativos. A primera vista parece
mucho mas orientado a templates (posiblemente tampoco nico) que encadenen arquetipos.
A la hora de especificar los arquetipos, adoptar los tipos de datos del CEN/TC251 [14796] aunque
en el momento de realizar el trabajo, y todava hoy, no se corresponden en muchos casos con el
contenido de los doumentos de los GPICs [14822], que estn tomados directamente de HL7-RIM
1.18.
'Respecto a la propia teleconsulta:
Considerar la teleconsulta entre partes sanitarias, aunque luego se restrinja a profesionales y
organizaciones en lo relativo a actores, en sentido amplio, pudiendo considerarse teleconsultas
102
gran parte de las peticiones de pruebas, procedimientos y observaciones realizadas en la prctica

asistencal cotidiana.
Aunque en la actualidad, quizs por su excesiva adhesin al servicio telemtico, se suele tenerla
asociada a peticiones relativas a productos de estudio y/o sujeto de atencin, no existe ningn
inconveniente y s muchas ventajas en lo que respecta a la modelizacin de procedimientos, en
considerar tambin teleconsulta cuando sta est asociada a peticiones relativas a especmenes y
especmenes manufacturados.
En este trabajo son considerados tambin como teleconsulta aquellos casos en los que el servicio
asistencial implica el traslado del sujeto de atencin o sujeto de prueba.
Los distintos tipos de teleconsulta obviamente tienen gran repercusin sobre el sistema que
soporta el servicio telemtico involucrado, pero poca en el proceso global de integracin; solo
afectan a la parte del contenido del mensaje de peticin en la que la parte solicitante del servicio
hace saber a la parte receptora del mismo, el tipo de teleconsulta prevista e informacin
contextual ad-hoc que se considere necesaria.
Respecto al diseo de integracin y a las actuaciones de desarrollo:
Comprobar si los atributos de los GPICs clnicos y no-clnicos existentes, y sus interrelaciones
proporcionaban informacin contextual y/o informacin de contenido suficiente para que el
binomio de mensajes de peticin de/informe sobre servicio fuera suficiente para soportar todo tipo
de interacciones (evento de disparo, roles involucrados, interaccin soportada por la descripcin
jerrquica del mensaje, posible secuencia, etc)
Desarrollar los mensajes de peticin de servicio/teleconsxdta asistencial e informe sobre
servicio/teleconsulta asistencial basados nicamente en los GPICs existentes.
Comprobar cuantos arquetipos y qu lvel de complejidad tendran, sera necesario tener en el
(hipottico) repositorio de arquetipos que usara el (hipottico) sistema de informacin que
manejara instancias de EHR_Extract.
Desarrollar dos arquetipos directamente relacionados con la solicitud de teleconsulta e informe
sobre la misma, as como un ejemplo de arquetipo de resultados de un servicio solicitado y
realizado.
Estudiar las posibilidades de formalizar los conceptos de continuidad asistencial en base a GPICs,
iniciar el desarrollo de im modelo de referencia e iniciar el diseo de arquetipos en ese campo.
En los siguientes apartados se describen ciertos aspectos (no incluidos en el captulo de material y
mtodos) relativos a mensajes y arquetipos, ambos basados en GPICs que ayudan a comprender lo
expuesto en el siguiente captulo de resultados, as como el trabajo realizado en el rea de conceptos
de continuidad asistencial.
103
5.2 Los mensajes en la integracin

5,2.1 Tipos de mensajes utilizados
Los mensaje_peticin_de_servicio y mensajeJnforme_sobre_servicio son los mensajes relativos a
pruebas o procedimientos llevados a cabo sobre un sujeto de atencin por uno o varios proveedores de
servicios sanitarios, los cuales emiten un informe sobre los resultados una vez realizado el servicio, el
cual envan al solicitante del servicio.
Un mensaje peticin de servicio es enviado por una parte asistencial (persona u organizacin) en el rol
de solicitante, a otra parte asistencial en el rol de proveedor, y en ciertos casos a otras partes
relacionadas (copias). Un mensaje informe sobre servicio es enviado por una parte asistencial
(persona u organizacin) en el rol de proveedor, a otra parte asistencial en el rol de solicitante, y en
ciertos casos a otras partes relacionadas (copias).
Ambos permiten la transmisin del contenido semntico definido en las descripciones jerrquicas de
los respectivos mensajes (HMDs).
Son independientes de la especialidad de las partes, y por tanto aplicables a:
Servicios de laboratorio (p.ej bioqumica clnica, microbiologa, hematologa, etc)
Servicios diagnsticos (p.ej radiodiagnstico, anatoma patolgica, medicina nuclear, etc)
Servicios de especialista, tales como mensajes d derivacin y de alta.
Otros servicios, ya definidos y aceptados o por definir (p.ej teleconsulta entre profesionales como
servicio asistencial propiamente dicho)
En general el mensaje peticin de servicio es apUcable en una gran variedad de escenarios:
Tanto a la solicitud de nuevas pruebas/procedimientos,
como a modificaciones
de
pruebas/procedimientos previamente sohcitados.

Tanto si la muestra/producto de estudio (ver aptdo 4.2.1.3) estn en el lugar del solicitante del
servicio y son enviados al lugar del proveedor, como si es necesario que el proveedor obtenga la
muestra y/o producto de estudio.
y tambin lo es el mensaje informe sobre servicio:
Tanto
al
informe
de
pruebas/procedimientos
nuevos,
como
modificaciones
de
pruebas/procedimientos previamente informados.

Permite cuatro formas de informar: cuando todos los resultados de las pruebas estn disponibles;
segn se van obteniendo; enviar nuevos resultados como parte de un informe acumulativo; y
enviar resultados parciales.
Los resultados pueden incluir valores numricos, rangos, porcentajes, informacin codificada,
texto libre, y objetos binarios (informacin multimedia).
Cada intercambio de informacin (interaccin) implica la existencia de:
Un remitente del mensaje
104
Un evento que inicia la interaccin

Un tipo de mensaje especfico
Un receptor del mensaje
Responsabilidades del receptor (acciones que el remitente espera sean realizadas por el receptor
en respuesta a recibir un mensaje especfico)
Se consideran los siguientes tipos de mensajes:
Mensaje_pettcin_nuevo_servicio, para solicitar un nuevo servicio, sin relacin con ningn servicio
previo solicitado al mismo proveedor.
Mensaje_peticin_modificacin_de_servicio, para modificar informacin sobre la totalidad de una
solicitud previa.
Mensaje_peticin_modificacin_pruebas_de_servicio, para modificar informacin sobre uno o varios
de los procedimientos/pruebas solicitados; la mayora de la informacin puede no haber cambiado.
Mensaje_peticin_pruebas_adicionales_al_servicio,
para
aadir
una
o mas
solicitudes
de
procedimientos/pruebas adicionales; la informacin relativa a la solicitud original no ha cambiado.

Mensaje_informe_nuevo_servicio, para informar sobre un servicio no reportado previamente.
Mensaje_mfomte_modiflcacin_de_servicio,
para modificar informacin sobre la totalidad de un
informe previo.
MensajeJnformejnodificacin_pruebas_de_servicio,
para modificar informacin sobre uno o mas
procedimientos/pruebas ya informados previamente.

Mensaje_informe_pruebas_adicionales_al_servicio,
para
aadir
un
o mas
informes
sobre
procedimientos/pruebas adicionales; la informacin del informe original no ha cambiado.

Mensaje_cancelacin, para cancelar una peticin de servicio o un informe.
Mensajej-espuesta, para reconocer haber recibido una peticin de servicio o un informe.
5.2.2 Ejemplos de uso de mensajes peticin/informe servicio

5.2.2.1
Escenarios de peticin de servicio
Los requerimientos comunes a todos los tipos de mensaje peticin son los siguientes:
Servicio socitado
Fecha-hora de solicitud
Urgencia de la peticin
Identificacin de otra informacin relevante acerca del sujeto de atencin, incluyendo
informacin clnica relevante
Diagnstico provisional, para ser confirmado o refutado por el servicio solicitado
Identificacin y otros detalles relevantes acerca de la parte solicitante del servicio
Identificacin y otros detalles relevantes acerca de la parte solicitada para proveer el servicio
105

(Posible) indicacin relacionada con aspectos relativos al pago del servicio
5.2.2.1.1
Escenarios de peticin con requerimientos especficos
Lx)s diferentes escenarios que siguen tienen requerimientos especficos que son listados a
continuacin:
Servicios para ser realizados sobre especmenes (ver aptdo 4.2.1.3) suministrados por el solicitante
Identificadores del espcimen
Naturaleza del espcimen
Fecha-hora en que el espcimen fue obtenido
Servicios que requieren agenda, antes de recibir la muestra/producto de estudio recogido por el
solicitante
Fecha-hora en que el solicitante intenta obtener la muestra
Localizacin en la que el solicitante obtendr la muestra
Solicitud de notificacin de aceptacin de la peticin
Servicios realizados sobre muestras/productos de estudio recogidos por el proveedor del servicio
Fecha-hora a las que debera tomarse la muestra
Localizacin del sujeto de atencin para permitir al proveedor del servicio proceder a la toma de
la muestra/producto de estudio
Servicios en los cuales el sujeto de atencin es examinado por el proveedor del servicio
Localizacin en la que se realiza el estudio
-
Ubicacin temporal del estudio (p.ej preoperativo, o requerido antes de consulta)

Lugar desde el que ir el sujeto de atencin
Manera en la que el sujeto de atencin ser notificado
Mtodo por el que el paciente alcanzar el lugar donde se provee el servicio
Lugar al que ha de ser enviado el paciente despus de realizar el servicio (por defecto, el de
procedencia)
Servicios que implican evaluacin de existente muestra/producto_de_estudio

Copia de, o referencia al informe original existente
Referencia a la muestra/producto de estudio
Nota de la razn de una segunda opinin
Modificacin de una peticin previa, que sigue a cualquiera de los anteriores escenarios
Se utiliza un mensaje peticin modificacin de servicio, o bien un mensaje peticin modificacin
pruebas de servicio, o un mensaje peticin pruebas adicionales al servicio. Los requerimientos
especficos son:
Referencia al mensaje peticin nuevo servicio original.
Referencia a la informacin que ha de ser modificada
Detalles del tipo de modificacin
106
Captulo 5. Integradn de la telecnsulta
Cancelacin de una peticin previa, que sigue a cualquiera de los anteriores escenarios. Afecta a toda
la peticin de servicio; si solo es parcial se utiliza modificacin. Los requerimientos especficos son:
Referencia al mensaje peticin nuevo servicio original
Referencia al o los servicios que han de ser cancelados
Razn de la cancelacin.
5.2.2.2
Escenarios de informe sobre servicio
Los requerimientos comunes a todos los tipos de mensajes informe son los siguientes:
Referencia al mensaje peticin nuevo servicio original, y a cualquier mensaje peticin
modificacin
Fecha-hora a la que comenz el servicio solicitado
Fecha-hora a la que comenz el informe
Identidad y posiblemente otros detalles del proveedor del servicio responsable del informe
Referencia a las muestras o productos_de_estudio
Resultados del servicio, comprendiendo informacin dependiente del tipo de servicio y del estilo
del informe.
No existe una relacin uno-a-uno entre mensajes peticin y mensajes informe:
Un solo informe puede corresponder a dos o mas peticiones
Un solo informe puede corresponder a toda una serie de peticiones
El informe corresponde a una peticin hecha fuera del sistema (p.ej formulario papel)
El informe es un verdadero informe de alta.
El informe puede contener resultados de pruebas no pedidas por el solicitante, pero que el
proveedor del servicio consider necesarias.
5.2.2.2.1
Escenarios de informe con requerimientos especficos
Informes provisionales
Se usa el mensaje informe nuevo servicio para resultados preUminares, y los mensaje informe
modificacin para los siguientes informes. Los requerimientos especficos son:
Indicacin del estado del resultado (p.ej provisional, suplementario, completo, etc)
Indicacin de los servicios solicitados que no han sido completados
Indicacin de cuando es probable que est disponible el siguiente informe
Referencia a los informes previos.
Ejemplos de este tipo son:
Informe preliminar (y solo sobre ciertos aspectos) emitido por el propio tcnico de Rx que obtuvo las
imgenes; stas son posteriormente revisadas por el radilogo, que emite el informe formal.
107
Una biopsia es estudiada rpidamente (durante un procedimiento quirrgico) y un informe con:q)leto

sigue al estudio posterior (y en profundidad) de la muestra.
Otros informes
A veces los mensaje informe nuevo servicio son contestados mediante verdaderos mensaje informe de
alta, sin haberse producido im mensaje de derivacin.
Suelen darse en casos de peticiones (p.ej exmenes endoscpicos, pruebas de esfuerzo ECG, etc) en
las que se producen incidencias y el proveedor de servicio considera mas apropiado emitir un informe
de alta, dado que al paciente se le han proporcionado otros servicios.
Correcciones o actualizaciones en los informes
Se utiliza un mensaje informe modificacin de servicio, o bien un mensaje informe modificacin
pruebas de servicio, o un mensaje informe pruebas adicionales al servicio. Los requerimientos
especficos son:
Una referencia al mensaje informe nuevo servicio original
Referencias a la informacin que ha de ser modificada
Detalles del tipo de modificacin.
Cancelacin de informes
Afecta a todo el informe sobre servicio; si solo es parcial se utiliza modificacin. Los requerimientos
especficos son:
Referencia al mensaje informe nuevo servicio original
Referencia al o los items de resultados que han de ser cancelados
Razn de la cancelacia
5.2.3 Otros aspectos relevantes

5.2.3.1
Tipos de datos en un informe
Los informes pueden incluir distintos tipos de datos, necesitando en cada caso diferente informacin
adicional.
Informes incluyendo un conjunto discreto de valores numricos.
Varias instancias de un valor numrico, rango o porcentaje
Informacin cualificando el valor numrico, rango o porcentaje (p.ej el objeto, o parte del objeto
al que se aplica la medida, la cantidad medida, unidades, feha, hora, periodo, valores de
referencia, incertidumbre, etc)
Informes incluyendo una serie o array de valores numricos
Informes incluyendo grficos, imgenes o seales
108
Indicacin del formato en el que la informacin es almacenada

Identificador del sistema y/o aplicacin en la que est almacenada la informacin referenciada
Identificador um'voco de la informacin referenciada
Identificador de un puntero, almacenado dentro o asociado al formato, que indica una parte o rea
concreta de la seal o la imagen.
Informes incluyendo resultados en forma codificada y/o texto
Identificacin del esquema de codificacin
Indicacin de la divisin en una serie de secciones lgicas de: texto libre, codificado, y datos
numricos
Identificacin textual o codificada de las cabeceras de las diferentes secciones de texto
Identificador del profesional responsable de cada seccin, o de un conjunto de varias secciones
relacionadas.
Informes incluyendo propuestas de acciones (plan_de_accin); suelen incluir recomendaciones de
otras pruebas.
5.2.3.2
Tipos de sujeto de prueba
Pueden existir distintos tipos de sujeto prueba:

Sujeto de atencin. Normalmente el paciente, aunque la prueba sea realizada sobre algo derivado
del paciente (p.ej muestra de sangre, espcimen de tejido, imagen de Rx, ECG, etc)
Sujeto de atencin relacionado (p.ej donante, feto, etc)
Animal, o grupo de animales.
Material. El sujeto de prueba puede ser un item de material, que no est relacionado con persona o
animal (p.ej muestra de agua, mancha en un vestido, etc)
5.2.3.3
Tipos de partes implicadas
Las principales partes implicadas en un escenario de peticin/informe de servicio son:

El sujeto de atencin, sujeto de atencin relacionado, y/o otras partes relacionadas (p.ej parientes)
El solicitante del servicio, iniciador de la peticin (persona u organizacin)
El proveedor del servicio (persona, organizacin, u otras partes relacionadas con la provisin del
servicio)
Destinos de copias, tanto de la peticin como del informe que, por las razones que sean, han de
ser informadas.
Estos ltimos necesitarn informacin adicional:
Mensajes de peticin de servicio
Detalles de la parte asistencial a la que ha de enviarse una copia
Indicacin de que el solicitante no requiere una copia del informe que se genere.
109

En algunos casos pueden requerirse resultados previos para poder detectar cambios.
Mensajes de informe sobre servicio
Detalles de la parte asistencial a la que ha de enviarse una copia
Un identificador del paciente que sea reconocible donde va la copia
Informacin relevante que contena la peticin de servicio.
5.2.3.4
Contenido del mensaje
Un mensaje peticin de servicio o un mensaje informe sobre servicio contendr obligatoriamente una
instancia de cada una de las siguientes clases:
SujetoDePrueba (GPIC_ID = 2.032), la cual puede ser uno o varios ObjetoAnalizable (GPICJD =
3.001), o puede ser un SujetoDeAtencin (GPICJD = 2.017).
El sujeto_de_prueba puede contener instancias opcionales de las clases:
-
InformacinClnica (GPICJD = 3.017), y
ObjetoAnalizableRelacionado (GPIC_ID = 3.004)
Si
el
SujetoDeAtencin
es
una
persona,
puede
haber
tambin
uno
varios
SujetoDeAtencinRelacionado (GPICJD = 2.023) con el paciente (p.ej madre, hijo, donante, etc)
InformacinClnica (GPICJD = 3.017), la cual puede especializarse en uno de los siguientes tipos:
-
ObservacinClnica (GPICJD = 3.023)
PeticinPrueba (GPICJD = 3.030)
ResultadoPrueba (GPICJD = 3.032)
Consejo (GPICJD = 3.028)
TratamientoConMedicamento (GPICJD = 3.040)
ProcedimientoClnico (GPICJD = 3.025)
InformacinClnicaNoClasificada (GPICJD = 3.029)
Una InformacinClnica puede contener una o mas instancias opcionales de cada una de las siguientes
clases:
-
InformacinClnicaRelacionada (GPICJD = 3.022)
ReceptorServicioAsistencial (GPIC_ID = 2.031)
AgenteSanitarioParticipante (GPICJD = 2.054)
Un mensaje peticin de servicio o un mensaje informe sobre servicio contendr opcionalmente una
instancia de cada una de las siguientes clases:
Partes asistenciales involucradas
Mensajes solicitud de servicio relacionados
Mensajes informe de servicio relacionados
Encuentro asistencial relacionado, el cual puede contener una o mas instancias opcionales de cada
una de las siguientes clases:
110
Captulos. Integracin de la teleconsulta
- informacin_clnica
- receptor_servicio_asistencial
- partes_asistenciales_partcipantes
- localizaciones_asistenciales_particpantes
En este apartado de aspectos bsicos se ha intentado resumir la enorme cantidad de posibilidades que
existen en la prctica asistencia! diaria, en cuanto a mensajes peticin/informe servicio se refiere. No
obstante es evidente la dificultad de abarcarlas todas y sobre todo la difcil comprensin del texto al
no incorporar la descripcin de los correspondientes GPICs.
5.3
Los arquetipos en la integracin
Tal y como se apunt en el aptdo 4.4.2, todava no estn claros muchos de los aspectos relacionados
con la construccin de arquetipos. Las dudas llegan en muchos casos incluso a tener dificultad en
decidir qu conceptos sern arquetipados y cuales no.
Para poder abarcar dos tipos muy distintos de arquetipos se decidi incluir en el captulo de resultados
arquetipos que estuvieran basados en dos modelos de referencia distintos: los arquetipos basados en
GPICs, y por tanto en el modelo de referencia RIM, y el arquetipo de hallazgos en el servicio
solicitado (p.ej estudio electrofisiolgico) basado en el modelo de referencia de EHR_Extract
En este apartado se describen los modelos de referencia, o parte de ellos, sobre los que estn basados
los arquetipos del siguiente captulo.
5.3.1 Arquetipos basados en GPICs

En las figuras 5.1, 5.2, 5.3, 5.4 y 5.5 pueden verse algunos de los modelos de los GPICs.sobre los que
estn basados los arquetipos especificados en los apartados 6.3 y 6.4. Las figuras permiten apreciar
sus posibilidades de estructura interior y de asociacin con otros GPICs.
Peticin de servicio asistencial. Es una especializacin de ComplejoDeInformacinClnica

(GPIC_ID = 3.018) [A] que contiene un conjunto de informacin relativa a la peticin de uno o varios
servicios asistenciales para un sujeto de atencin.
111
Interfaz Externo
GPIC Core
Peticin Deservicio
Asistencia I
ReceptorServicioAsis
tendal
GPIC 2.031
ParteSan i taria Pa rti ci
pante
GPIC 2.053
TransporteSujetoVivo
Relacionado
GPIC 2.057
cdigociase: CS
cdigomodo: CS
cdgoestado: CS
CdigoiCD
id; SET<II>
tiempoactividad;TS
cdigoprioridaci:CV
texto; ED
ProvisinServicioAsis
tencial
GPIC 3.060
InformacinCinicaRe
lacionada
GPIC 3 . 0 2 2
o..*
Peticin DeServicioRel
acionado
GPIC 3.055
ObjetoAnalizableUsa
do
GPIC 3 . 0 0 2
InformeScbreServicio
Relacionado
GPIC 3.057
Figura 5.1 GPIC_ID = 3.054 Peticin de Servicio Asistencial.

Informe sobre servicio asistencial. Es una especializacin de ComplejoDeInformacinClnica
(GPIC_ID = 3.018) [A] que contiene el conjunto de informacin contenida en un informe sobre uno o
varios servicios asistencial es.
Interfaz Externo
A
GPIC Core
ReceptorServicioAsis
tencial
GPIC 2.031
ParteSanitariaPartici
pante
I n f o r m e Sobre
Servicio
Asistencial
cdigoClase: CS
cdigomodo: CS
cdigoesado: CS
Cdgo:CD
id: SET<n>
GPIC 2 . 0 5 3
ProvisinServicioAsis
tencial
GPIC 3 . 0 6 0
InformacinCinicaRe
lacionada
GPIC 3.022
tiempoactividadiTS
cdigoprioridad:CV
texto :ED
EnuentroRelacionado
GPIC 3 . 0 5 9
O..*
PeticinDeServicioR
elacionado
GPIC 3 . 0 5 5
o..*
InformeSobreServici
oRelacion!
GPIC 3 . 0 5 7
ObjetoAnalizableUsa
do
GPIC 3.002
Sujeto De Prueba
GPIC 2 . 0 3 2
Figura 5.2 GPIC_ID = 3.056 Informe sobre servicio asistencial.
112
Objeto analizable. Informacin acerca de algo derivado del sujeto de atencin, o lugar fsico, o parte
de una prueba diagnstica.
Punto d e e n t r a d a
^ GPIC Core
RoiObjetoAnalizable
Caracterstica DeObj eto

(OPIC 3 . 0 1 0 )
=^
AdquisicinObjetoAnaliz
able (GPIC 3.013)
cdigoClase; CS
nmeroPosicin: I N I
cdigo: CV
Trata miento Espci men R

elacionado
(GPIC 3 . 0 0 7 )
ObjetoAnalizable
Objeto Anal iza bleRelacionado

(GPIC 3.004)
Espcimen
ProductoDeEstudio
(GPIC 3 . 0 0 3 )
(GPIC 3 . 0 0 9 )
Figura 5.3 GPICJD = 3.001 Objeto analizable.

Espcimen. Una o mas partes tomadas de un sistema (o subsistema) para proveer informacin sobre
ese sistema, o proporcionar una base para la toma de decisiones
Puntode entrada
A
M a t e r i a l Preservacin
(GPIC 3.001)
GPIC Core
Espcimen
0..*
1
LugarNoAsistenciai
(GPIC 2.064)
0..1
1
CdigoClase: CS
cdigoDeterminador: CS
id; S E T < I I >
cdigo: CV
desc: ED
cantidad: PQ
cdigoExistencia: I\/L<TS>
cdigolvlanejo: SET<CV>
cdigoRiesgo: SET<CV>
Figura 5.4. GPICJD = 3.003 Espcimen..

Producto de estudio. Registro de informacin procedente de un paciente, como parte de un servicio de
diagnstico; puede tomar la forma de un objeto fsico, o puede consistir en informacin digital en un
sistema de informacin.
113

Interfaz Externo
ReferenciaInformacnExt
erna
GPIC
ProductoDeEstudio
0..*
1
cdigoClase: CS
cdigoDeterminador: CS
id: SET<II>
cdigo: CV
desc: ED
Dispositivo
Relacionado
GPIC
0..*
1
Figura 5.5. GPICJD = 3.009 Producto de estudio.
Para comprender las posibilidades y restricciones existentes en las relaciones entre GPICs, es
necesario recordar el modelo de referencia del RIM (aptdo 4.1.2) y el cdigo de colores de las
diferentes clases del modelo (fig. 4.3), y tener en cuenta las siguientes condiciones de diseo:
Una Entidad no puede asociarse directamente con una Actividad, sino que obligatoriamente ha de
hacerlo a travs de un Rol y una Participacin.
Una Entidad puede jugar varios Roles, relacionados dos a dos por una clase Enlace de Roles.
Una entidad puede participar simultneamente en mas de una actividad.
Una Actividad no puede asociarse directamente con otra, necesariamente ha de hacerlo a travs de
una clase Relacin entre Actividades.
Otras caractersticas importantes de los GPICs son:
Pueden usarse para llevar informacin actualizable.
Todos tienen un punto de entrada (clase raz) que puede ser de cualquier clase: Actividad, Rol,
Enlace de roles. Entidad, Participacin y Relacin entre Actividades. Un GPIC se une al exterior a
travs de esa clase raz.
Un GPIC puede usar otros GPICs en su interior (p.ej. especializaciones de clases abstractas). Un
diseador puede decidir qu componentes utilizar en una ocasin determinada.
Pueden tener un punto de salida al que otros GPICs pueden unirse a travs de sus clase raz, para
formar GPICs mas grandes y complejos.
Los GPICs no incluyen formalmente el concepto de jerarqua y la sustitucin de un componente
general por otro mas especfico.
114
Captulos. Integracin de la teleconsulta
5.3.2 Arquetipos basados en Extract

Los resultados del servicio asistencial solicitado se estructurarn conforme a un extracto que ser
incluido en el cuerpo del mensaje de informe sobre servicio asistencial; cuando la parte solicitante de
la teleconsulta reciba este mensaje informe, almacenar esta parte en la HCE del sujeto de atencin.
ENTRY
nombre[1]:TEXT
proveedorjnfo [O..!]: FUNCT10NAL_R0LE
anotaciones [O..!]: SET <CS_ANNOTATION>
id_act [0..1]:String
estadQ_act[0..1]: CV
ite/fts
TEM
partes
Q..*
nfasis [0..1]: CV
tiempo_obs [O..!]: 1VL<TS>
categorajtem [0.1]: CS_ITEM_CAT
^ ^ ^ ' - ' ^ -
CLUSTER
ELEMENT
notnbre[1]:TEXT
tipo_estructura[0..11:CS_STRUCTURA_TIP
nombre[1]: TEXTO
valor
0..1
Herencia CEN
Los tipos de datos
van aqu
DATA VALU
nuil flavor: CS NULL FLAV
P^
Figura 5.6, Parte del modelo EHR_Extract involucrado en el arquetipo
En la figura se han incluido atributos heredados por la clase Entry de clases superiores.
Aunque los desarrollos realizados en este trabajo de tesis permitiran presentar un elevado nmero de
posibles arquetipos basados en el modelo de referencia EHR__Extract factibles de ser usados en el
contexto de la teleconsulta entre profesionales, se ha considerado por razones de espacio presentar
nicamente un ejemplo (Cap. 6; aptdo 6.5 de arquetipo tipo Entry para describir los resultados
encontrados en un estudio electrofisiolgico, como uno de tantos posibles ejemplos de hallazgos
clnicos obtenidos en una prueba o procedimiento constitutivos de un servicio asistencial solicitado.
115
RESULTADOS
6.
Resultados
Este captulo contiene los resultados obtenidos en las dos reas que el autor entiende mas
concluyentes en el proceso de integracin de la teleconsulta entre profesionales sanitarios en el
proceso asistencial en un marco de continuidad: los mensajes de peticin e informe, y los arquetipos
relacionados mas directamente con ambos mensajes.
En los apartados 6.1 y 6.2 se describen los mensajes de peticin de servicio asistencial e informe
sobre servicio asistencial, desde una perspectiva amplia: la teleconsulta se considera parte de un
servicio asistencial mas amplio. De esta forma, el trabajo de modelizadn realizado valdr en
muchsimas mas situaciones reales, que si solamente se hubiera considerado la teleconsulta como
componente nico del servicio asistencial.
En los apartados 6.3 y 6.4 se describen los arquetipos que pueden soportar los modelos de peticin e
informe adoptados en los apartados anteriores.
En el apartado 6.5 se describe, a modo de ejemplo, un arquetipo que formar parte del contenido del
mensaje de informe, que muestra los hallazgos encontrados al realizar un servicio asistencial
solicitado.
6.1 Especificacin del mensaje de peticin de teleconsulta

Siguiendo el actual marco metodolgico de desarrollo de mensajes vigente en CEN/TC251, se
presentan los resultados del trabajo de desarrollo del mensaje de peticin de teleconsulta entre dos
partes sanitarias (aunque luego se restrinja a profesionales y organizaciones).
El trabajo se presenta en tres partes:
117
Descripcin general del mensaje con los GPICs involucrados, las clases que los componen y los
diagramas de clases de los mas significativos.
Modelo de Informacin del Mensaje (MIM); incluyendo xm diagrama de clases del mensaje y la
Descripcin Jerrquica del Mensaje (DJM) utilizando la forma grfica usada en CEN/TC251.
6.1.1 Descripcin general del mensaje de peticin de teleconsulta

6.1.1.1
TransmisinMensaje
Es el envoltorio en el que se coloca el mensaje de peticin (de cualquier mensaje; esta parte es
anloga en el caso del mensaje informe). Es el componente que figura a la cabeza del mensaje; no
tiene un interfaz de clase raz como un GPIC normal, sino que se utiliza la clase EventoDeControl
como enlace al contenido del mensaje, el cual es obligatorio que comience con una clase tipo ACT, o
una de sus especializaciones.
#Se compone de:
- TransmisinMensaje. Informacin acerca del mensaje como un todo.
#Atributos:
tiempoCreacin
TS
Fecha/hora en la que el sistema remitente cre la
id
II
Identificador nico de la transmisin
seguridad
ST
Para ciertas aplicaciones que quieran implementar
transmisin.
aspectos de seguridad (no contemplados aqu)

cdigoAceptRecon
CS
Ejemplos: AL(siempre), ER(solo error), NE(nunca),
INT
Para identificar mensaje en envos por lotes (no
ST
Para analizar por el sistema receptor y mejorar
SU(solo xito)
nmerosecuencia
considerados aquQ
nmeroVersin
identificacin
- ParteComunicante. Informacin acerca de las partes que estn conectadas, enviando o
recibiendo, en una comunicacin.
#Se compone de:
- FuncinComunicacin. Informacin acerca del rol que juega la parte comuicante en la
comunicacin.
#Atributos:
cdigoTpo
CS
SND(remitente), RCV(receptor), RSP(respuesta a;
entidad a la que debe enviarse cualquier respuesta)

telecom
telecom
118
- ParteComunicante. Informacin acerca de la persona, organizacin o dispositivo que est

actuando como parte comunicante.
#Es una de las siguientes especializaciones:
- Persona (GPIC_ID = 2.006) [E]. Identifica demogrficamente una persona que est
actuando como remitente o receptor en la comunicacin.
#Se compone de una sola clase: Persona [E]
#Atributos:
cdigoClase
CS
PSN (persona; ver Anexo 3)
cdigoDeterminador
CS
INST (instancia de; ver Anexo 4)
id
II
Identificador nico de la persona ^^^
nombre
SET<NombreEntidad>Uno o mas nombres que
pueden ser usados para confirmar la identidad de la persona

direccin
SET<dirpostal>Una o mas direcciones postales (o
partes de direcciones) asociadas con la persona

telecom
SET<telecom> Una
mas
direcciones
de
telecomunicaciones (o partes de direcciones) asociadas con la persona

cdigoAdminGnero
CS
(hombre, mujer, inter, desconocido)
tiempoNacimiento
TS
Fecha y hora del nacimiento
^^^ Con problemtica muy conocida y sin todava clara solucin; a acordar entre las partes comunicantes.
#Se puede asociar con:
0..* LenguajeDeComunicacin (GPIC_ID = 2.007). Informacin acerca de la capacidad
y competencia de lenguajes de comunicacin de la persona.
- Organizacin (GPIC_ID = 2.008) [E]. Identifica una organizacin que est actuando como
remitente o receptor en la comunicacin. Aunque la teleconsulta se realiza entre
profesionales, en muchos casos desde un punto de vista institucional (y tambin por
cuestiones administrativas) figura la organizacin como parte comunicante.
#Se compone de una sola clase: Organizacin [E]
#Atributos:
cdigoClase
CS
ORG (organizacin; ver Anexo 3)
cdigoDeterminador
CS
INST(instancia de); KIND(tipo); ver Anexo 4
nombre
ST
Nombre descriptor organizacin
id
SET<II>
cdigo
CV
Especialidad de la organizacin
desc
ST
Descripcin texto libre organiz.
direccin
SET<dir_postal>
Uno o mas identifcadores
Una
mas
direcciones
postales (o partes de direcciones) asociadas con la persona

telecom
SET<telecom> Una
mas
direcciones
de
telecomunicaciones (o partes de direcciones) asociadas con la persona

119
# Se puede asociar con:

- 0..* JerarquaOrganizacin (GPIC_ID = 2.010) [R]. Descripcin de un conjunto
anidado de organizaciones identificadas.
- 0..* Lengua]eDeComunicacin (GPIC_ID = 2.007). Informacin acerca del lenguaje,
modo de comunicacin y competencia de la organizacin en este modo de comunicacin.
- 0..* PersonaDeContacto (GPIC_ID = 2.012) [R]. Detalles acerca de una persona que
puede ser usada como un punto de contacto en una organizacin y el rol jugado por esa
persona de contacto.
- Dispositivo (GPIC_ID = 2.055) [E]. Identifica un dispositivo que est actuando como
remitente o receptor en la comunicacin. No ha sido incluida en este trabajo.
Conceptualmente no supone ningn problema incluir esta clase especializacin de
ParteComunicante, y su presencia en los tipos de teleconsulta basados en servicios en
diferido, es mas que previsible cuando se implanten herramientas de automatizacin del
flujo de trabajo.
- RolDeParteComunicante. Informacin acerca del tipo de rol de parte sanitaria jugado por la
parte comunicante. P.ej. Especialista consultor, etc
#Atributos:
cdigoClase
CS
PROV(proveedor; ver Anexo 5)
cd
CV
cdigo que representa la especialidad mdica
cdigoPuestoTrabajo
CV
Posicin o naturaleza trabajo
cdigoTtuloPuestoTrabajo
CV
Ttulo del puesto de trabajo
- EventoDeControl. Informacin acerca de la naturaleza del contenido del mensaje, para ser usada
por el receptor p.ej "nueva teleconsulta", "nueva derivacin", "pregunta sobre un servicio (o
teleconsulta) anterior"; es decir informacin clnico asistencial, no de tipo tcnica de
comunicaciones.
#Atributos:
idTipoEstructura
II
identifcador del tipo de contenido del mensaje
tomado de un catlogo de interacciones ^^^

cdigoRespuesta
CS
C(completo),
D(detalle),
E(excq)cin),
F(confirmacin), R(modificacin), X(ninguna).

cdigoLenguaje
CV
lenguaje principal en el contenido
' ' Las partes que se comunican han aceptado previamente im catlogo de tipos de interacciones, e identifican sin
problemas este identifcador.

0..* MensajeRelacionado (GPIC_ID =) []. Informacin acerca de otros mensajes que tienen
alguna relacin y significan algo en el presente mensaje.
6.1.1.1.1
MensajeRelacionado
120
Referencia a otro mensaje con algn significado para el mensaje actual. Ejemplos: peticin previa,
peticin relacionada (referenciada por un mensaje informe)
#Se compone de:
- EventoDeControlRelacionado. Informacin acerca del tipo del mensaje previo.
#Atributos:
idTipoEstructura
II
identifcador del tipo de contenido del mensaje
tomado de un catlogo de interacciones

- MensajeRelacionado. Informacin acerca del mensaje relacionado.
#Atributos:
tiempoCreacin
TS
Fecha/hora en la que el sistema remitente cre la
II
Identificad nico de la transmisin
transmisin.
id
6.1.1.2
Es una especializacin de ComplejoDeInformacinClnica (GPIC_ID = 3.018) [A] que contiene un

conjunto de informacin relativa a la peticin de uno o varios servicios asistenciales para im sujeto de
atencin. En la descripcin textual que sigue se mantendr lo mas posible que sea vlida para los dos
casos posibles: a) la teleconsulta forma parte de un servicio asistencial mas complejo, y b) la
teleconsulta es el servicio asistencial solicitado. En aquellos casos que no sea posible, se considerar
estar describiendo solamente el caso b).
#Se compone de una sola clase:
- PeticinDeServicioAsistencial [A]
#Atributos
cdigoClase
cdigoMood
cdigoEstado
Elegido de Anexo 10.
es
es
es
cdigo
eD
Identificacin unvoca tipo servicio solicitado
id
SET<II>
Uno o mas identifcadores para la instancia de
tienq)oActividad O
0
IVL<TS>
Ventana de tiempo en la que la peticin debe tratarse
cdigoPrioridad 0O
ev
P.ej Alta prioridad, urgente, rutina
ED
comentario adjunto a la peticin
emo interpretar la informacin (ver Anexo 11)

Estado de la peticin (ver Anexo 12)
peticin
texto
0..1 ReceptorServicioAsistencial
(GPIC_ID = 2.031) [P]. Informacin acerca de una persona,
generalmente el paciente, -pero tambin podra ser animal o grupo de animales- que es el sujeto de
atencin en la peticin del servicio/teleconsulta asistencial.
121
0..1 SujetoDePrueba (GPIC_ID = 3.032) [P]. Conjunto de informacin relativa a una persona,
animal, u objeto analizable que es el sujeto de una prueba.
0..* ParteSanitariaParticipante (GPIC_ID = 2.053) [P]. Informacin relativa a la implicacin de
un profesional sanitario, u organizacin, o combinacin de ambos, en la peticin del
servicio/teleconsulta asistencial,
0..* PeticinDeServicioRelacionada (GPIC_ID = 3.055) [AR]. Conjunto de informacin relativa
a una peticin de uno o mas servicios que puede estar relacionada a otra actividad. Usada para
enlazar una instancia de PeticinDeServicioAsistencial a otra actividad, la cual incluye a su vez
otra peticin de servicio.
0..*O/etoAna/i2flj/e7sado (GPIC_ID = 3.002) [P].
Un ObjetoAnalizable con un interfaz
participacin que le permite ser asociado con una actividad.

0..* ProvisinServicioAsistencial (GPIC_ID = 3.060) [AR]. Informacin relativa a la provisin
del servicio/teleconsulta asistencial.
0..* InformacinClnicaRelacionada (GPIC_ID = 3.022) [AR]. Informacin relativa a un item o
coleccin de informacin clnica con alguna relacin a alguna actividad.
0..* InformeSobreServicioRelacionado
(GPIC_ID = 3.057) [AR].
Conjunto de informacin
relativa a un informe sobre uno o mas servicios que puede estar relacionado a otra actividad.
Usado para enlazar una instancia de InformeSobreServicioAsistencial a otra actividad, la cual
incluye otro informe sobre servicio.
0..* EncuentroRelacionado
(GPIC_ID = 3.059) [AR]. Conjunto de informacin relativa a un
encuentro que est relacionado a alguna actividad.

0..* TransporteSujetoVivoRelacionado (GPIC_ID = 2.067) [AR]. Informacin sobre el transporte
de sujetos de atencin, tal y como se describe en TransporteSujetoVivo (GPIC_ID = 2.065) [A],
que est relacionado a otra actividad.
6.1.1.2.1
ReceptorServicioAsistencial ( G P I C J D = 2.031) [P]
Informacin acerca de una persona, generalmente el paciente (pero tambin podra ser animal o grupo
de animales), que es el sujeto de atencin en la peticin del servicio/teleconsulta asistencial. Ver
Figura 6.1.
#Es una de la siguientes especializaciones:
- SujetoDeAtencinReferenciado (GPIC_ID = 2.025) [P]. Una referencia al sujeto de atencin que
es implicado en una actividad. Se utiliza para el caso en que puede ser identificado por un
identifcador.
No
es necesario
especificar
la naturaleza
de su participacin
en
el
servicio/teleconsulta o en su solicitud.
#Se compone de:
- ParticipacinDelSujetoReferenciado [P]. Enlaza el sujeto de atencin referenciado a una
actividad.
122
#Atributos:
cdigoTipo
es
PATSBJ (sujeto paciente; ver Anexo 6)
- RolDelSujetoReferenciado [R]. Enlaza la participacin del paciente a la informacin del

paciente.
#Atributos:
cdigoClase
CS
IDENT (rol entidad identificado; ver Anexo 5)
- SujetoVivoIdentificado (GPIC_ID = 2.014) [E]. Informacin de identificacin relativa a un

sujeto (persona o animal).
#Atributos:
cdigoClase
CS
LIV (sujeto vivo; ver Anexo 3)
cdigoD ter minador M
CS
id
II
Identificador nico sujeto
nombre
SET<NombreEntidad>Uno o mas nombres que pueden ser
usados para confirmar la identidad del sujeto
ReceptotDeSeividoAsistercal
GPIC 2.031
PaitlcipacicnDelSujelaRefefenciado
(de GPIC 2.025)
PartJcipacinPePason^MDSanilsra
(de GPIC 2.028)
R oIDelSuj ettJ efererKado

(de GPIC 2.035)
RolDelSiijefoDeAlenclDnPersona
(de GRC Z02fl)
1
PaitiapacnDelSujeloDeAtenan
(de GPIC 2.026)
ParteRelaoionada
(de GPIC 2,029)
.I1
PartcfiadnDePersanaNoSanitara
[deGPIC2.027)
(de GPIC 2.029)

1
RolDelSujetcOe Alee ion

(deGPIC2026)
l | '
SujelaVruoldentifioado
(de GPfC 2.014)
PatcipacinDePersanôSanitara
ffencion
GPIC 2.017
RolDeLsParteRel ademada
(deGPICZ024)
1
Lenguaje
GPIC 2.00
SiietcOeAtencinArimal
jUJeloDeAtenoinGrupoArima
GPIC Z021
SlljetoDeAtencinPefsonE
GPICZ013
TT"
^TMi
InformacinEstrtdarPaoiente
GPIC 2 020
GRC 2019
1 Organliacin
GPIC2.00B
^.
0..*
lnformacinExtendidaPaeime
ParleRelacionadaCor
SiijetoDeAtencin
GPIC Z024
^1
ParteSanaria
GPIC 2.039
JerarqiiaOrganlacin
GPICZ010
0*
LugarDe Asistencia
GPICZ033
PersonaDeCotitarto
GPICZ012
0,.*
Figura 6.1
SujetaDeAtencin
Relacionado
GPIC 2.023
Receptor de servicio asistencial y GPICs asociados.
- SujetoDeAtencinParicipante (GPIC_ID = 2.026) [P]. Asocia un sujeto de atencin (persona,

animal o grupo de animales) con una actividad, pero no dando ninguna informacin especfica
acerca de la naturaleza de esa participacin. Se utiliza para el caso en que es necesario incluir
algunos detalles, p.ej nombre, direccin, fecha de nacimiento, sexo, etc, pero no es necesario
especificar la naturaleza de su participacin en el servicio o en su solicitud.
123
#Se compone de:

- ParticipacinDelSujetoDeAtencin [P]. Significa la participacin de un sujeto de atencin en
una actividad.
#Atributos:
cdigoTpo
es
PATSBJ (sujeto paciente; ver Anexo 6)
- RolDelSujetoDeAtencin [R]. Enlaza la participacin del sujeto de atencin en una actividad

a la informacin sobre el propio sujeto de atencin)
#Atributos:
cdigoClase
CS
- SujetoDeAtencin (GPIC_ID = 2.017) [E]. Es una generalizacin de los GPICs usados para
proporcionar informacin acerca de un sujeto de atencin humano y no-humano. En nuestro
caso solamente se usar para identificar y proporcionar informacin acerca de personas.
# Es una de la siguientes especializaciones:
- SujetoDeAtencinAnimal (GPIC_ID = 2.021) [E] (*No se considera*)
- SujetoDeAtencinGrupoAnimal (GPIC_ID = 2.022) [E] (*No se considera*)
- SujetoDeAtencinPersona (GPIC_ID = 2.018) [E]. Conjunto de informacin relativa a
una persona que est recibiendo, o va a recibir, uno o mas, de los servicios asistenciales
solicitados.
- InformacinEstndarDePaciente (GPIC_ID = 2.019) [E]. Informacin acerca de un
sujeto persona usando un conjunto estndar de informacin demogrfica.
#Atributos:
cdigoClase
CS
cdigoDeterminador
CS
II
id
nombre
Identifcador nico sujeto
SET<NombreEntidad>Uno o mas nombres que
pueden ser usados para confirmar la identidad del sujeto

direccin
SET<dirpostal>Una o mas direcciones postales (o
partes de direcciones) asociadas con el paciente

telecom
SET<telecom> Una
mas
direcciones
de
telecomunicaciones (o partes de direcciones) asociadas con el paciente

cdigoAdminGnero
tiempoNacimiento
CS
(hombre, mujer, inter, desconocido)
TS
cdigoEstadoMarital
CV
(casado, separado, etc)
cdigoHabitat
CV
descripcin lugar de dnde viene
cdigoRiesgo
CV
Riesgo
asociado
la
persona
(p.ej
embarazada, inmunodeprimida, etc)

124
cdigoGrupoEtnico
CV
- InformacinExtendidaDePaciente (GPIC_ID = 2.020) [E]. dem los anteriores, mas:

#Atributos:
nmeroOrdenNacim
INT
Orden nacimiento en parto mltiple
cdigodiscapacidad
CV
Deficiencias en p.ej vista, odo, etc
cdigoNacionalidad
SET<CV>
indicadorMuerte
BL
Indicacin de que el sujeto ha muerto
tiempoMuerte
TS
Fecha y hora del bito
cdigoEstadoEmpleo
CV
(empleado, autnomo, desempleado,..
- SujetoVivoIdentificado (GPICJD = 2.014) [E] (*Ya descrito anteriormente*)

Informacin de identificacin relativa a un sujeto (persona o animal).
# Puede asociarse con:
- 0..* Lengua]eDeComunicacin (GPIC_ID = 2007). Informacin acerca del lenguaje,
modo de comunicacin y competencia de la persona en este modo de comunicacin.
- 0..* ParteRelacionadaConSujetoDeAtencin (GPICJD = 2.024) [R].
Informacin
acerca de una parte -persona, organizacin o ambas- no-sanitaria que tiene relacin con
el paciente.
- 0..* ParteSanitaria (GPIC_ID = 2.039) [R]. Informacin acerca de una parte -persona,
organizacin o ambas- sanitaria que tiene relacin con el paciente.
- 0..* LugarDeAsistencia (GPIC_ID = 2.062) [R]. Informacin acerca de un lugar que
est asociado con la asistencia.
- 0..* SujetoDeAtencinRelacionado (GPIC_ID = 2.023) [R]. Informacin acerca de otro
sujeto de atencin que tiene relacin con el paciente.
- PacienteParticipanteldentificado (GPICJD = 2.028) [P]. Es un GPIC SujetoVivoIdentiflcado
con un interfaz participacin. Se utiliza para el caso en que puede ser identificado por un
identificador,
y s es necesario especificar
la naturaleza de su participacin en el
servicio/teleconsulta o en su solicitud.
#Se compone de:
- ParticipacinDePersonaNoSanitaria [P].
Informacin relativa a la participacin de un
paciente en una actividad.

#Atributos:
cdigoTipo
es
Casi siempre PATSBJ (sujeto paciente; ver Anexo 6)
- RolDelSujetoDeAtencinPersona [R]. Enlaza la participacin del paciente en una actividad a

la informacin sobre el propio paciente.
#Atributos:
cdigoClase M
CS
- SujetoVivoIdentificado (GPICJD = 2.014) [E] (*Ya descrito antes*)

125
- PacienteParticipante (GPIC_ID = 2.027) [P]. Es un GPIC InformacinEstndarDePaciente con

un interfaz participacin. Se utiliza para el caso en que es necesario incluir algunos detalles, p.ej
nombre, direccin, fecha de nacimiento, sexo, etc, y s es necesario especificar la naturaleza de su
participacin en el servicio/teleconsulta o en su solicitud.
#Se compone de:
-ParticipacinDePersonaNoSanitaria [P]. (*Ya descrito antes*)
- RolDelSujetoDeAtencinPersona [R]. (*Ya descrito antes*)
- InformacinEstndarDePaciente (GPICJD = 2.019) [E] (*Ya descrito antes*).
-
ParteRelacionadaConPacienteParticipante
(GPICJD
2.029)
[P].
Es
un
GPIC
ParteRelacionadaConSujetoDeAtencin con un interfaz participacin, que provee informacin

acerca de la implicacin de las partes relacionadas en alguna actividad o servicio.
#Se compone de:
-ParticipacinDePersonaNoSanitaria [?]. (*Ya descrito antes*)
- ParteRelacionadaConSujetoDeAtencin
(GPIC_ID = 2.024) [R]. Proporciona informacin
acerca de la parte relacionada con el sujeto de atencin y la naturaleza de esa relacin.

#Se compone de:
- RolDeLaParteRelacionada [R]. Enlaza con el exterior y permite la descripcin del tipo de
relacin.
#Atributos:
cdigoClase
GUARD(guardin),
CS
RESP(responsable),
Ejemplos^ NOK(pariente prximo), FAM(familiar),

NEI(vecino),
FRE(amigo),
CON(contacto),
GUAR(responsable), EMP(empleado), MIL(contacto militar), SCH(escuela), etc)

id
II
Identificador por el cual la parte relacionada conoce
al sujeto de atencin
- ParteRelacionada [E].
- Persona (GPIC_ID = 2.006) [E]. Informacin acerca de una persona actuando como
sujeto de atencin o parte relacionada, pero informacin general relativa solamente
acerca de aspectos personales, no del rol. Si la persona est en el rol de paciente, se usa
InformacinEstndarDePaciente, o InformacinExtendidaDePaciente como parte del
GPIC SujetoDeAtencinPersona. Si la persona est en el rol de paciente y la necesidad es
solamente proveer informacin que pueda usarse para identificar la historia del paciente
se usa SujetoVivoIdentificado o IdentificacinSujetoDeAtencinPersona.
#Atributos:
(*Ya descritos antes en aptdo 5.1.1.1*)
Estos valores no son conformes a RIM.
126
- 0..*LenguajeDeComunicacin (GPIC_ID = 2007). (*Ya descrito antes*).
- Organizacin
(GPIC_ID = 2.008) [E]. Informacin acerca de una organizacin
actuando como sujeto de atencin o parte relacionada.

#Atributos:
(*Ya descritos antes en aptdo 5.1.1.1*)
- 0..* JerarquaOrganizacin (GPIC_ID = 2.010) [R]. Descripcin de un conjunto
anidado de organizaciones identificadas.
- 0..*LenguajeDeComunicacin (GPIC_ID = 2.007). (*Ya descrito antes*).
- 0..* PersonaDeContacto (GPIC_ID = 2.012) [R]. Detalles acerca de una persona
que puede ser usada como un punto de contacto en una organizacin y el rol jugado
por esa persona de contacto.
6.1.1.2.2
SujetoDePrueba ( G P I C J D = 2.032) [P]
Conjunto de informacin relativa a una persona, animal, u objeto analizable que es el sujeto de una
prueba. Ver figura 6.2.
ParticipacinDelSuj eto DePrueba
(de GPIC 2.032)
0^
RolDelSujetoDePrueba
(de GPIC 2,032)
SujetoDePrueba
SujetoVivoldentificado
GPIC 2.014
Figura 6.2
SujetoDeAtencin
GPIC 2,017
Espcimen
GPIC 3,003
Espcimen Manufacturado
GPIC 3.005
Sujeto de prueba y GPICs asociados
# Se conpone de:
- ParticipacinDelSujetoDePrueba [P]. Informacin acerca de la participacin en alguna prueba real o potencial- del sujeto de la prueba.
# Atributos:
cdigoTipo
es
SBJ (sujeto; ver Anexo 6)
notaTexto
ST
Cualquier anotacin en texto libre; puede usarse para
CS
Estado la participacin (ver Anexo 7)
especificar disponibilidad
cdigoEstado
127
- RolDelSujetoDePrueba [R]. Enlaza la informacin sobre la participacin del sujeto con la

informacin sobre la identificacin del sujeto.
# Atributos:
cdigoClase
CS
ROL (rol; ver Anexo 5)
- SujetoDePrueba [E]. Informacin acerca del sujeto de la prueba.

- SujetoVivoIdentificado (GPIC_ID = 2.014) [E]. (*Ya descrito anteriormente*)
Informacin de identificacin relativa a un sujeto (persona o animal).
- SujetoDeAtencin (GPIC_ID = 2.017) [E]. (*Ya descrito anteriormente*)
Solo se considera aqu la especializacin SujetoDeAtencinPersona.
-Espcimen (GPICJD = 3.003) [E]. (*Ya descrito anteriormente*)
Una o mas partes tomadas de un sistema (o subsistema), o que van a ser tomadas, para proveer
informacin sobre ese sistema (o subsistema), o proveer una base para la toma de decisiones.
- EspcimenManufacturado (GPIC_ID = 3.005) [R]. Informacin acerca de una muesti-a de
material que es una parte representativa de una sustancia manufacturada.
# Se compone de:
- RolDelObjetoManufacturado [R]. Interfaz rol del GPIC
# Atributos:
cdigoClase
CS
MANU (producto manufacturado; ver Anexo 5)
- EspcimenManufacturado [E]. Informacin acerca de un espcimen manufacturado.

# Atributos:
cdigoClase
CS
MMAT (material manufacturado; ver Anexo 3)
cdigodeterminador
CS
INST, KIND (ver Anexo 4)
id
0/M
SET<II>
cdigo
CV
naturaleza del espcimen manufacturado
cantidad
PQ
cantidad de especmenes manufacturados
tempoExistencia
TS
fecha-hora de finalizacin proceso manufacturacin
cdigoManejo
SET<CV>
nombreLote
ST
Identificacin lote de material manufacturado
tiempoCaducidad
TS
Fecha caducidad
Uno o mas identificadores del espcimen
manufacturado
Instrucciones almacenamiento y manejo

- 0..* OrganizacinRelacionada (GPIC_ID = 2.011) [R]. Informacin acerca del fabricante
o suministrador del espcimen (objeto-material) manufacturado.
6.1.1.2.3
ParteSanitariaParticipante ( G P I C J D = 2.053) [P]
128
Informacin relativa a la implicacin de un profesional sanitario, u organizacin, o combinacin de

ambos, en la peticin del servicioTeleconsulta asistencial. Ver figura 6.3.
ParleSanllaraPsrticjpaniB
me 2053
..
P artdpacinPmtesJDnalSanitaro
GPIC 2.002
PattldpaclnPrDfesiDnsISaiiaHo
GPIC 2.002
ProfsionalSanilarD
Relacionada
GPIC 2.035
Al
RolDeProfeaonldentilicado
(de GPIC Z034)
RolDelProfesionalSanilario 1
(de GPIC 2,033)
_L
t OrganizacinSanitaria
^^
Relacionada
GPIC Z03E
i^
Figura 6.3
0-'
Persona
GPIC 2.008
OrganizdnSa^taria
GPIC 2.036
ParoipacinOrgatiszadnSanilaria
GPIC 2.003
O'
O'
RolOrganizadnSanilaria
(de GPIC 2.036)
1
1
(de GPIC 2 0 3 ^
Participad nOrgani^sQnSsnilaria
GPIC 2.003
RolOiârizadr^dertilicada
de GPIC 2.037)
1
Organizaci6nlderific:ada
(de GPIC 2037)
Orgartzacin
GPIC 2008
Parte sanitaria participante y GPICs asociados.

- ProfesionalSanitarioParticipante (GPIC_ID = 2.049) [P]. Detalles del profesional sanitario e
informacin acerca de la parte jugada en alguna actividad.
# Se compone de:
- ParticipacinProfesionalSanitario (GPIC_ID = 2.002) [P]. Detalles de la naturaleza de la
participacin del profesional sanitario en uno o mas aspectos de la provisin del
servicio/teleconsulta asistencial.
# Atributos:
cdigoTipo
cdigoControlContexto
cdigoFuncin
cdigoModo
es
es
ev
es
tiempo
IVL
notaTexto
ED
Comentarios adicionales
cdigoEstado
Estado de la participacin (ver Anexo 7)
cdigoFirma
es
es
ED
rbrica con la que el profesional sanitario
Tipo de participacin (ver Anexo 6)

Si hereda contexto de actividad (ver Anexo 9)
Ampla la descripcin de la participacin
Elegido de Anexo 8; p.ej presente, por
telfono, comunicacin escrita,...)

S>
INT
Intervalo de la participacin
(pensada),
SGN
(firmada),
REQ
(requerida)
textoFirma
endosa su participacin
- ProfesionalSanuario (GPIC_ID = 2.033) [R]. Persona actuando en un rol como profesional
sanitario, es decir, implicada en la provisin del servicio/teleconsulta asistencial.
# Se compone de:
- RolDelProfesionalSanitario [R]. Describe el rol jugado por la persona como profesional
sanitario.
129
# Atributos:
cdigoClase
es
PROV (proveedor; ver Anexo 5)
cdigo
CV
Especialidad del proveedor
SET<II>
Uno o mas identificadores
cdigoTrabajo
CV
Naturaleza del puesto de trabajo.
CdigoTtuloTrabajo
CV
Ttulo del trabajo
id
- Persona (GPICJD = 2006) [E]. (*Ya descrito antes*).

0..* ProfesionalSanitarioRelacionado (GPIC_ID = 2.035) [RL]. Informacin acerca de otro
profesional sanitario que tiene alguna relacin con el profesional sanitario sujeto de la
instancia.
0..* OrganizacinSanitariaRelacionada (GPIC_ID = 2.038) [RL]. Informacin acerca de
una organizacin sanitaria que tiene alguna relacin con el profesional sanitario sujeto de la
instancia.
0..* OrganizacinSanitaria (GPIC_ID = 2.036) [R].
Informacin acerca de una
organizacin sanitaria que tiene relacin de alcance al rol del profesional sanitario sujeto de
la instancia.
- ProfesionalParticipanteldenflcado (GPIC_ID = 2.050) [P]. Informacin acerca de la parte
jugada en alguna actividad por un profesional el cual es referenciado para detalles de
identificacin.
# Se compone de:
- ParticipacinProfesionalSanitario (GPIC_ID = 2.002) [P] (*Ya descrito antes*)
- ProfesionalSanitarioIdentificado (GPIC_ID = 2.034) [R].
Proporciona un medio de
referenciar a un profesional sanitario identificado.

#Se compone de:
- RolDelProfesionalldentificado [R]. Un interfaz tipo rol.
# Atributos:
cdigoClase
CS
PROV (proveedor servicio; ver Anexo 5)
- Profesionalldenficado [E]. Informacin de identificacin del profesional sanitario

# Atributos:
cdigoClase
CS
cdigoDeterminador
CS
id
II
Identificador profesional
nombre
NombreEntidad
Nombre
nombres
que
pueden ser usados para confirmar la identidad del profesional
130
- OrganizacinSanitaaParticipante (GPIC_ID = 2.051) [P]. Informacin acerca de la parte

jugada en alguna actividad por una organizacin que es referenciada para detalles de
identificacin.
# Se compone de:
- ParticipacinOrganizacinSanitaria (GPIC_ID = 2.003) [P]. Detalles de la participacin en
una actividad de una organizacin sanitaria identificada.
- OrganizacinSanitaa (GPIC_ID = 2.036) [R]. Informacin que identifica y proporciona una
descripcin de las propiedades de la organizacin sanitaria.
# Se compone de:
- RolOrganizacinSanitaria [R]. Enlaza con la informacin sobre la organizacin.
# Ati-ibutos:
cdigoClase
CS
cdigo
CV
Organizacin (GPICJD = 2.008) [E] (*Ya descrito antes*).

- 0..* ProfesionalSanitarioRelacionado (GPIC_ID = 2.035) [RL]. Enlaza informacin
acerca de un profesional sanitario a la informacin acerca de la organizacin sanitaria objeto
de la instancia.
- 0..* OrganizacinSanitariaRelacionada (GPIC_ID = 2.038) [RL]. Enlaza informacin
acerca de una organizacin sanitaria a la informacin acerca de la organizacin sanitaria
objeto de la instancia.
- OrganizacinParticipanteldentificada (GPIC_ID = 2.052) [P]. Iirformacin acerca de la parte
jugada en alguna actividad por una organizacin cuyos detalles son incluidos.
# Se compone de:
- ParticipacinOrganizacinSa [P]. (*Ya descrita antes*)
- OrganizacinSanitarialdentificada (GPIC_ID = 2.037) [R]. Informacin de identificacin de
la organizacin sanitaria.
# Se compone de:
- RolOrganizacinIdentificada [R]. Interfaz.
# Atributos:
cdigoClase
CS
- Organizacinidentificada [E]. Informacin de identificacin de la organizacin.

# Atributos:
cdigoClase
CS
ORG (organizacin; ver Anexo 3)
cdigoD eterminador
CS
id
II
Identificador organizacin
nombre
ST
Nombre conocido de la organizacin.

131
6.1.1.2.4
PeticinDeServicioRelacionada ( G P I C J D = 3.055) [AR]
Conjunto de informacin relativa a una peticin de uno o mas servicios que puede estar relacionada a
otra actividad. Usada para enlazar una instancia de PeticinDeServicioAsistencial a otra actividad,
incluyendo otra peticin de servicio)
# Se compone de:
- PeticinDeServicioRelacionada [AR]
# Atributos:
cdigoTipo
es
El tipo de relacin (ver Anexo 13).
ntimeroSecuencia
INT
Especifica orden cronolgico
cdigoControlContexto O
CS
Si hereda contexto de la actividad (ver Anexo 14)
- PeticinDeServicioAsistencial (GPICJD = 3.054) [A] (*Ya descrito antes*).
6.1.1.2.5
ObjetoAnalizableUsado ( G P I C J D = 3.002) [P]
Un ObjetoAnalizable con un interfaz participacin que le permite ser asociado con una actividad. Ver
figura 6.4.
PartidpadnObjeloAnizable
(de GPIC 3.002)
1^
.^;.;LobjetoAnalizableRGlacionado
GPIC 3.004
CaracteristJcaDdObjeto
GPIC 3.010
RdObjetoAnalizable
{de GPIC 3.001)
Q -
AdquisicinObjetoAnalizate
GPIC 3.013
TratamientoEspecimenRela
cionacio. GPIC 3.007
ObjetoAnalizable
4^
0..'
Material Preservacin
GPIC 3.011
0..' ReferenclalnformadnExtema
GPIC 3.016
Espcimen
GPIC 3.003
ProductoDeEstudio
GPIC 3.009
0.,1
LugarNoAsislendal
GPIC 2.064
Figura 6.4
0..*
DispositivoReladonado
GPIC 2.057
Objeto Analizable Usado y GPICs asociados
# Se compone de:
- ParticipacinObjetoAnalizable [P]. Enlaza ei objeto analizable usado con una actividad.
# Atributos:
cdigoTipo '
CS
SPC (espcimen; ver Anexo 6)
CS
Si hereda contexto de la actividad (ver Anexo 9).
cdigoFuncin
CV
Cdigo par funcin o propsito
132
cdigoModo
CV
p.ej. local o remoto
nmeroSecuencia
INT
tiempo
IVL<TS>
notaTexto
ED
informacin adicional
- ObjetoAnalizable GPIC_ID = 3.001) [R]. Informacin acerca del objeto analizable asociado:
algo derivado del sujeto vivo de atencin, o un lugar fsico, como parte de una prueba diagnstica
o de laboratorio.
# Se compone de:
- RolObjetoAnalizable [R]. Enlaza la informacin sobre el objeto analizable a un modelo
mayor y proporciona su contexto cuando se juntan varios.
# Atributos:
cdigoClase
CS
INST (instancia; ver Anexo 5)
nmeroPosicin
INT
Cronologa en el orden de varios
CV
cdigo
proporciona contexto al rol del objeto
- ObjetoAnalizable [E].
- Espcimen (GPIC_ID = 3.003) [E].
Una o mas partes tomadas de un sistema (o
subsistema), o que van a ser tomadas, para proveer informacin sobre ese sistema (o
subsistema), o proveer una base para la toma de decisiones.
# Atributos:
cdigoClase
CS
ENT (entidad; ver Anexo 3)
cdigodeterminador
CS
id
SET<II>
Uno o mas identifcadores del espcimen
cdigo
CV
naturaleza espcimen
desc
ED
PQ
nmero de objetos
cantidad
0/M
cdigoExistencia O
IVL<TS>
fecha-hora o periodo de tiempo de creacin
del espcimen
cdigoManejo
SET<CV>
cdigoRiesgo
SET<CV>
Instrucciones manejo

- 0..* MaterialPreservacin (GPIC_ID = 3.011) [R]. Informacin acerca de cualquier
reactivo o material usado para almacenar y/o preservar el espcimen
- 0..1 LugarNoAsistencial (GPIC_ID = 2.064) [R]. Informacin acerca de un lugar
geogrfico asociado con el espcimen.
- ProductodeEstudio (GPIC_ID = 3.009) [E]. Identificable registro de informacin procedente
de un paciente, como parte de un servicio de diagnstico. Puede tomar la forma de un objetofsico,o
puede consistir en informacin digital en un sistema de informacin electrnico.
133
# Atributos:
cdigoClase
CS
ENT (entidad; ver Anexo 3)
cdigodeterminador
CS
id
0/M
SET<II>
cdigo
CV
naturaleza producto estudio
desc
ED
cantidad
PQ
nmero de objetos
tiempoExistencia
rVL<TS>
Uno
mas
identificadores
del
producto de estudio
fecha-hora o periodo de tiempo de
creacin del producto de estudio

- 0..* ReferenciaInformacinExterna (GPICJD = 3.016) [R].
Referencia a una
informacin externa que soporta o constituye un producto de estudio, y que est

almacenado en forma digital.
- 0..* DispositivoRelacionado (GPIC_ID = 2.057) [R].
Informacin acerca de un
dispositivo u otro equipamiento usado en el proceso de adquisicin del producto de

estudio.
- 0..* CaractersticaDelObjeto (GPIC_ID = 3.010) [P].
Informacin acerca de una
caracterstica o parmetro de medida de un objeto analizable.

- 0..1 AdquisicinObjetoAnalizable (GPIC_ID = 3.013) [P].
Informacin acerca de la
adquisicin del objeto analizable.

- 0..* TratamientoEspcimenRelacionado (GPIC_ID = 3.007) [P]. Informacin acerca de
cualquier tratamiento fsico o qumico del espcimen.
- 0..* ObjetoAnalizableRelacionado (GPIC_ID = 3.004) [RL]. Informa acerca de otro objeto
analizable y de su relacin con ste descrito en la instancia.
6.1.1.2.6
ProvisinServicioAsistencial ( G P I C J D = 3.060) [AR]
Informacin relativa a la provisin del servicio asistencial. Ver figura 6.5.

# Se compone de:
- EnlaceProvisinServicio [AR].
Enlaza detalles de la provisin del servicio con entidades
extemas.
# Atributos:
cdigoTipo
CS
INST (instancia; ver Anexo 13)
CS
Si hereda contexto de la actividad (ver Anexo 14)
- ProvisinServicio [A]. Identificacin del tipo de procedimiento, tratamiento, prueba u otro

servicio.
134
EnlacePrevisinSeivicio
GPIC 3.060
DispositivoUsado
GPIC 2.059
PravisinServicio
RutaTratamiento
GPIC 3,052
^ ^
^
ProcedimientoDePreparacion O '
Paciente GPIC 3.026
ProcedimJenoClnico
GPIC 3.025
^
^ ^
Tratam i entoConMedicam ento

GPIC 3.040
J
SuministroMedicamento
GPIC 3.041
Consejo
GPIC 3-028
^0^
_a,'
0..1
lnformacinCnicaRelacionada_0^
GPIC 3,022
i
PacientePartcipantel dentifi
cado GPIC 2.028
ParteRe ac onadaConPacien te
Participante GPIC 2.029
SujetoDePrueba
GP!C 2.032
0,.1
^-<o%
<;^
PeticinPrueba
GPIC 3.030
<j|
^
1A
1A
LugarDeAsislenciaUsado
GPIC 2 063
Retid nDePruebaRelacio nadaA

GPIC 3.031
^^-
ResultadoDePruebaRelacio O,,'
nado GPIC 3,033
O,.*
TransporteSujetoVivoRelacio
nado GPiC 2.067
ObjetoAnalizableAdquifido
GPIC 3.012
Figura 6.5
Provisin del servicio asislencial y GPICs asociados

- ProcedimientoClnico (GPIC_ID = 3.025) [A]. Especializacin de ItemDelnformacinClnica
(GPIC_ID = 3.021) [A] que proporciona una descripcin general de un procedimiento clnico.
# Atributos:
cdigoease
es
PROC (ver Anexo 10
cdigoMood
es
Cmo interpretar la informacin (ver Anexo 11)
cdigoEstado
es
Estado actual de la actividad (ver Anexo 12)
id
SET<II>
cdigo
eO
Identificacin tipo de procedimiento
texto
o
o
o
o
o
o
ED
Detalles sobre tipo procedimiento
cdigoMtodo
cdigoSitio
tiempoActividad
tiempoEfectivo
cdigoPrioridad
SET<CV>
mtodos del procedimiento
SET<CD>
lugar foco procedimiento
IVL<TS>
Ventana tiempo procedimient
IVL<TS>
Ventana tiempo ocurrencia
eV
P.ej Alta prior, urgente, rutina

135
- 0..* InformacinClnicaRelacionada (GPIC_ID = 3.022) [AR]. Informacin relativa a un

tem o coleccin de informacin clnica con alguna relacin al procedimiento clnico.
- 0..* DispositivoUsado (GPIC_ID = 2.059) [P]. Informacin acerca de un equipo o
dispositivo que est siendo usado en la provisin del servicio asistencial.
- 0..* RutaTratamiento (GPIC_ID = 3.052) [AR]. Informacin acerca de la va por donde se
administra el tartamiento.
- 0..* ProcedimientodePreparacinPaciente (GPIC_ID = 3.026) [AR]. (Informa acerca de
condiciones aplicadas o sustancias administradas al paciente, antes o durante el
procedimiento.
- PetcinPrueba (GPIC_ID = 3.030) [A].
Especializacin de ItemDelnformacinClnica
(GPIC_ID = 3.021) [A] que proporciona un conjunto de informacin que puede ser usada para
definir una prueba especfica de laboratorio.
# Atributos:
cdigoClase
CS
PROC (procedimiento; ver Anexo 10)
cdigoMood
CS
Elegido de Anexo 11; ORD, INT (INT, APT, ARQ,
CS
Elegido de Anexo 12; si ORD (nuevo, activo,
PRP, RMD), EVN

cdigoEstado
suspendido, modificado, cancelado, completado); si INT (notificado, suspendido, cancelado,

completado); si EVN (completado)
tiempoActividad
TS
Hora a la que la prueba fue realizada
tiempoEfectivo
rVL<TS>
cdigo
CD
cdigoMtodo
SET<CV>
Mtodos de la prueba
id
SET<II>
Uno o mas indicadores de la instancia de la
cdigoPrioridad
CV
nmeroRepeticin
IVL<INT>
texto
ED
prueba solicitada
Mximo y mnimo repet.
Detalles adicionales sobre la prueba

- 0..1 SujetoDePrueba (GPIC_ID = 2.032) [P]. (Informacin acerca de la entidad que es
sujeto de la peticin de prueba, incluyendo detalles de su identificacin.
- 0..* PeticinDePruebaRelacionada
(GPIC_ID = 3.031) [AR]. Enlaza la peticin de
prueba con otra peticin de prueba, -conq)onente de la prueba o previa-.

- 0..* ResultadoDePruebaRelacionado (GPIC_ID = 3.033) [AR]. Informacin acerca de un
resultado o conjunto de resultados que son directamente asociados con la peticin de prueba.
- 0..* ObjetoAnalizableAdquirido (GPIC_ID = 3.012) [P].
espcimen o producto de estudio asociados con la peticin de prueba.

136
- 0..* InformacinCUnicaRelacionada (GPIC_ID = 3.022) [AR]. tems o grupos de items de

informacin clnica que son relevantes a la peticin de prueba.
- 0..* TransporteSujetoVivoRelacionado (GPIC_ID = 2.067) [AR]. Informacin acerca de
los requerimientos para el transporte del sujeto de atencin al o del sitio donde se realizar la
prueba.
- 0..* LugarDeAsistenciaUsado (GPIC_ID = 2.063) [?]. Informacin acerca del lugar
donde tendr lugar la prueba solicitada.
- Consejo (GPICJD = 3.028) [A]. Especializacin de ItemDelnformacinClnica (GPIC_ID =
3.021) [A] que provee informacin detallada relativa al consejo o la advertencia dados al
paciente o persona/profesional relacionados, que estn asociados a la provisin del servicio.
# Atributos:
cdigoClase
CS
ACT (actividad; ver Anexo 10)
cdigoMood
CS
Cmointerpretar lainform(ver Anexo 11)
cdigoEstado
CS
Actual estado (ver Anexo 12)
cdigo
CV
Identificacin tipo de consejo
texto
ED
Resumen o transcripcin del consejo
tiempoActividad
IVL<TS>
cdigoConfidencialidad
SET<CV>
Ocurrencia del consejo

- 0..1 PacienteParticipanteldentificado (GPIC_ID = 2.028) [P]. Informacin acerca de la
participacin del paciente en el consejo.
- 0..* ParteRelacionadaConPacienteParttcipante
(GPIC_ID=2.029) [P].
Informacin
acerca de la participacin de una persona no-sanitaria, u organizacin, o ambos, con

respecto al consejo.
- 0..* InformacinCUnicaRelacionada (GPIC_ID = 3.022) [AR]. tems o grupos de items de
informacin clnica que son relevantes al consejo.
- TratamientoConMedicamento (GPIC_ID = 3.040) [A]. (*No objeto de estudio aqu*).
- SuministroMedicamento (GPIC_ID = 3.041) [A]. (*No objeto de estudio aqu*).
6.1.1.2.7
InformacinClnicaRelacionada ( G P I C J D = 3.022) [AR]
Informacin relativa a un item o coleccin de informacin clnica con alguna relacin a alguna
actividad. Ver figura 6.6.
# Se compone de:
- EnlacelnformacinRelacionada [AR]. Enlaza el conjunto de informacin clnica con la actividad
relacionada.
137
EnlacelnformacinRelacionada
GPIC 3,022
1I
1
InfomiaeinClinica
~2sr
Cornple]oDelntormadnClinica_
ComplejoDeInformacin
ItemDeInfonnacinCllnica
Relacionado GPIC 3,020
Clninica GPIC 3.018
GPIC 3,021
AgrupacinDelnformadn
Observacinairica
ProcetmientoClnico
anicaGPIC3.019
GPIC 3.023
GPIC 3.025
InformadrClricaRelacio
nada GPIC 3,022
PeticinDeSefvici oAsi slencj al
Peticin Prueba
GPIC 3.054
GPIC 3.030
ReferenciaNorrralidad
GPIC 3.034
O,.*
InfomieSobreServIcio
Consejo
ObjeloAnalIzableUsado
Aslstencial GPIC 3 056
GPIC 3,002
GPIC 3,028
O,,'
&icuenlro
Resultado Prueba
, TratamientoConmedicamento
GPIC 3 032
GPIC 3,040
GPIC 3.068
Re3ultadoPmebaRelacionado_0
GPIC 3.033
'
O'
SuministroUedi cemento
0..1
GPIC 3.041
Especificacin Prueba
GPIC 3,03e
Figura 6.6
Informacin clnica relacionada y GPICs asociados
# Atributos:
cdigoTipo
es
cdigoControl Contexto O
CS
- nformacinClnica (GPIC_ID = 3.017) [A]. Descripcin genrica de los items o complejos

(contenedores) de informacin clnica.
- ComplejoDelnformacinCUnica (GPIC_ID = 3.018) [A]
#Es una de la siguientes especializaciones:
- AgrupacinDelnformacinClnica (GPIC_ID = 3.019) [A].
Proporciona un contexto
compartido para el contenido de la informacin dentro del complejo.

# Atributos:
cdigoClase
CS
Clase contenido (ver Anexo 10)
cdigoMood
CS
Cmo interpretar (ver Anexo 11)
cdigoEstado
CS
cdigoNivel
CV
Nivel que ocupa en la jerarqua estructura
cdigoLenguaje
CV
cdigo
CD
id
SET<II>
Identificacin cabecera
Uno o mas identifcadores de esta agrupacin
de informacin
138
tiempoActividad
tiempoEfectivo
TS
Fecha y hora de creacin
IVL<TS>
ED
Ventana de tiempo en el que ha
estado en este estado

texto
- PeticinDeServicioAsistencial (GPIC_ID = 3.054) [A].
predefinido de peticin -o derivacin-, para uno o mas servicios asistenciales.

- InformeSobreServicioAsistencial (GPIC_ID = 3.056) [A].
predefinido de informe sobre provisin, para uno o mas servicios asistenciales.

- Encuentro (GPIC_ID = 3.058) [A]. Proporciona un contexto predefinido de informe sobre
un encuentro entre agente sanitario y receptor del servicio asistencial.
- 0..* InformacinClnicaRelacionada (GPIC_ID = 3.022) [AR]. Informacin acerca de un
tem de informacin clnica que en un cierto contexto es considerado indivisible.
- 0..* ComplejoDelnformacinClnicaRelacionado (GPIC_ID = 3.020) [AR]. Informacin
acerca de un complejo de informacin clnica que est contenido en el complejo
(contenedor) objeto de este GPIC o su especializacin.
- ItemDelnformacinClnica (GPIC_ID = 3.021) [A].
Informacin acerca de un tem de
informacin clnica que en un cierto contexto es considerado indivisible.

ObservacinClnica
(GPIC_ID
3.023)
[A].
Especializacin
de
ItemDelnformacinClnica (GPIC_ID = 3.021) [A] que proporciona una descripcin general

de una observacin clnica.
# Atributos:
cdigoClase
CS
OBS (observacin; ver Anexo 10)
cdigoMood
CS
cdigoEstado
CS
cdigo
CD
Tipo de observacin
texto
ED
Detalles adicionales
id
II
Identificador nico instancia
cdigoMtodo
SET<CV>
Mtodo usado prueba
cdigoSitio
SET<CV>
Lugar foco
tiempoEfectivo
IVL<TS>
Ventana
ANY
tiempo
en
el
que
la
observacin estuvo activa

valor
P.ej: ST (cadena), PQ (cantidad fsica), TS
(punto en el tiempo), CD (cdigo descriptor), CV (cdigo valor), IVL<PQ> (rango de cantidades

fsicas), LIST<PQ> (lista de cantidades fsicas), IVL<TS> (periodo de tiempo), LIST<TS> (lista de
puntos en el tiempo)
139
cdigolnterpretacin
CV
(p.ej 'anormal')

- 0..* InformacinClnicaRelacionada (GPICJD = 3.022) [AR]. Informacin acerca de
un tem o grupos de items de informacin clnica relavantes para la observacin.
- ProcedimimtoClnico (GPICJD = 3.025) [A] (*Ya descrito antes*)
- PeticinPrueba (GPICJD = 3.030) [A] (*Ya descrito antes*)
- Consejo (GPIC_ID = 3.028) [A] (*Ya descrito antes*)
- TratamientoConMedicamento (GPICJD = 3.040) [A]. (*No objeto de estudio aqu*)
- SuministroMedicamento (GPIC_ID = 3.041) [A]. (*No objeto de estudio aqu*)
- ResultadoPrueba (GPICJD = 3.032) [A]. Especializacin de ItemDelnformacinClnica
(GPICJD = 3.021) [A] que proporciona un conjunto de informacin incluyendo todo lo
esencial o til, relevante al resultado de la prueba clnica.
# Atributos:
cdigoClase
CS
Naturaleza result (ver Anexo 10)
cdigoMood
CS
cdigoEstado
CS
cdigo
CD
Tipo de prueba
id
SET<II>
Uno o mas identifcadores para la instancia
tiempoActividad
IVL<TS>
Tiempo total en el que ocurri la prueba
tiempoEfectivo
IVL<TS>
Ventana tiempo en el que se obtuvo
valor
ANY
del resultado de la prueba
P.ej: ST (cadena), PQ (cantidad fsica), TS (punto en
el tiempo), CD (cdigo descriptor), CV (cdigo valor), IVL<PQ> (rango de cantidades fsicas),

LIST<PQ> (lista de cantidades fsicas), IVL<TS> (periodo de tiempo), LIST<TS> (lista de puntos en
el tiempo)
cdigoInterpretacinO
CV
(p.ej 'anormal')
indlndependiente O
BL
Si puede ser independiente
cdigoInterpretacinO
CV
"Normalidad" resultado
cdigoMtodo
SET<CV>
texto
ED
Mtodo usado para interpretar el resultado
Detalles adicionales o inform. multimedia adjunta

- 0..* ReferenciaNormalidad (GPICJD = 3.034) [AR]. Descripcin de un rango de
normalidad, expresado como un rango de medidas numricas o en forma textual. Los
lmites pueden aplicarse a una poblacin particular y pueden ser de un tipo especificado.
- 0..* ObjetoAnalizableUsado (GPICJD = 3.002) [P].
Informacin acerca de, o
referencia a, un objeto analizable que est asociado con este resultado.
140
- 0..* ResultadoPruebaRelacionado (GPIC_ID = 3.033) [AR]. Informacin acerca de

otro resultado que tiene alguna relacin con este resultado.
- 0..* PeticinPruebaRelacionada (GPIC_ID = 3.031) [AR]. Informacin acerca de
peticiones que tienen alguan relacin con este resultado.
- 0..1 EspecificacinPrueba (GPIC_ID = 3.036) [AR]. Detalles acerca de cmo ha sido
llevada a cabo la prueba.
- InformacinClnicaNoClasificada
(GPIC_ID = 3.029)
[A].
Especializacin de
ItemDelnformacinClnica (GPIC_ID = 3.021) [A] que proporciona una descripcin de

informacin clnica que no ha sido categorizada como una observacin, procedimiento,
prueba -peticin o informe-, consejo o medicacin -tratamiento o suministro-.
# Atributos:
cdigoClase
CS
Naturaleza informacin (ver Anexo 10); el
cdigoMood
CS
cdigoEstado
CS
cdigo
CD
Tipo de la informacin
texto
ED
defecto es ACT
id
Identificador instancia
cdigoMtodo
SET<CV>
Mtodo asociado
tiempoEfectivo
IVL<TS>
Ventana
ANY
tiempo
en
la
que
la
informacin est activa

valor
P.ej: ST (cadena), PQ (cantidad fsica), TS
(punto en el tiempo), CD (cdigo descriptor), CV (cdigo valor), IVL<PQ> (rango de cantidades

fsicas), LIST<PQ> (Usta de cantidades fsicas), IVL<TS> (periodo de tiempo), LIST<TS> (Usta de
puntos en el tiempo)
- 0..* InformacinClnicaRelacionada (GPIC_ID = 3.022) [AR]. Informacin acerca de
un tem o grupos de tems de informacin clnica relavantes para la observacin.
- CondicinDelPacienteRelacionada (GPIC_ID = 3.024) [AR]. Informacin acerca de
cualquier condicin o dolencia del paciente.
6.1.1.2.8
InformeSobreServicioRelacionado ( G P I C J D = 3.057) [AR]
Conjunto de informacin relativa a un informe sobre uno o mas servicios que puede estar relacionado
a otra actividad. Usada para enlazar una instancia de InformeSobreServicioAsistencial a otra
actividad, incluyendo otro informe sobre servicio)
# Se compone de:
141
- InformeSobreServicioRelacionado [AR]
# Atributos:
cdigoTipo
es
nmeros ecuencia
INT
CS
Si hereda contexto de la actividad adjunta (ver Anexo
14)
- InformeSobreServicioAsistencial (GPIC_ID = 3.056) [A] (*Se describir posteriormente*).
6.1.1.2.9
EncuentroRelacionado ( G P I C J D = 3.059) [AR]
Conjunto de informacin relativa a un encuentro que est relacionado a alguna actividad.

# Se compone de:
- EncuentroAsistencialRelacionado [AR]
# Atributos:
cdigoTipo
CS
nmeros ecuencia
INT
Especifica orden cronolgico de encuentros
CS
- Encuentro (GPIC_ID = 3.058) [A].
Especializacin de ComplejoDelnformacinClnica
(GPIC_ID = 3.018) [A] que proporciona un conjunto de informacin acerca de un encuentro con
un paciente.
# Atributos:
cdigoClase
CS
ENC (encuentro; ver Anexo 10)
cdigoMood
CS
cdigoEstado
CS
cdigo
CD
Tipo de servicio en el encuentro
id
II
Identificador instancia encuentro
tiempoActividad
IVL
S>
Fecha-hora comienzo
tiempoEfectivo
IVL
S>
Duracin encuentro
escenarioPrctica
CV
Tipo de entorno del encuentro
texto
ED

- 0..* ReceptorServicioAsistencial (GPIC_ID = 2.031) [P]. Informacin acerca del paciente casi siempre-, el cual es el receptor del servicio asistencial en el encuentro.
- 0..* AgenteSanitarioParticipante (GPIC_ID = 2.054) [P].
profesional, orgaizacin o dispositivo, el cual est asociado con el encuentro, y la naturaleza

de su participacin.
- 0..* LugarDeAsistenciaUsado (GPIC_ID = 2.063) [P]. Informacin acerca de un lugar
asociado con el encuentro.'
142
- 0..* ProvisinServicioAsistencial (GPIC_ID = 3.060) [AR].
Informacin acerca de la
naturaleza del servicio asistencial que se provee al paciente o en representacin de l, durante el

encuentro.
- 0..* PeticinDeServicioRelacionada (GPIC_ID = 3.055) [AR]. Informacin acerca de una
peticin de servicio que est relacionada con el encuentro.
- 0..* InformeSobreServicioRelacionado (GPIC_ID = 3.057) [AR]. Informacin acerca de un
informe sobre servicio asistencial que est asociado al encuentro.
- 0..* EncuentroRelacionado (GPIC_ID = 3.059) [AR]. Informacin acerca de otro encuentro
que est relacionado con ste.
- 0..* TransporteSujetoVivoRelacionado (GPIC_ID = 2.067) [AR]. Informacin acerca de los
preparativos o responsabilidad del transporte del paciente u otras personas.
6.1.1.2.10
Informacin
TransporteSujetoVivoRelacionado ( G P I C J D = 2.067) [AR]

sobre el transporte de sujetos
de atencin,
tal y como se describe en
TransporteSujetoVivo (GPIC_ID = 2.065) [A], que est relacionado a otra actividad.

# Se compone de:
- TransporteRelacionado [AR]. Enlaza la informacin sobre el sujeto vivo con los detalles del
transporte.
- TransporteSujetoVivo (GPIC_ID = 2.065) [A]. Informacin acerca de la actividad de transportar
una o mas personas - o animales-.
# Se compone de:
- TransporteSujeto [A]
# Atributos:
cdigoClase
CS
ENC (encuentro; ver Anexo 10)
cdigoMood
CS
EVN (evento), ORD (orden), INT (intento; dos
subtipos: PRP (propuesto), RMD (recomendado); (interacta con cdigoEstado; ver Anexo 12)
cdigoEstado
CS
Si EVN (completado, abortado); si ORD (nuevo,
activo, suspendido, cancelado, completado); si INT (notificado, suspendido, cancelado, completado)

cdigo
cv
Tipo de transporte
cdigoNivelGravedad 0
cv
Agudeza, nivel complejidad
tiempoActividad
TS
Fecha y hora comienzo transporte
ide
Identificador nico
texto
ED
Detalles adicionales sobre el transporte
cdigo_prioridad
cv

- 0..* LugarDeAsistenciaUsado (GPIC_ID = 2.063) [P]. Informacin acerca de un lugar donde
se administran los servicios asistenciales
143
- 0..* ParteSanitariaParticipante (GPICJD = 2.053) [P]. Detalles o identificacin de una

parte sanitaria -profesional, organizacin o ambos- y su participacin en el transporte.
- 0..* ParteRdacionadaConPacienteParticipante (GPIC_ID = 2.029) [P]. Informacin acerca
de una persona no-sanitaria implicada en el transporte del sujeto vivo.
6.1.2 Modelo de informacin del mensaje (MIM) de peticin de teleconsulta

En la figura 6.7 puede verse el modelo de informacin del mensaje de peticin de teleconsulta. Se ha
elaborado lo suficientemente general como para que valga para los cuatro tipos de teleconsulta:
Teleconsulta a un especialista, teleconsulta en entorno cooperativo, teleconsulta con telepresencia, y
sesin clnica distribuida.
Penaa
Msnsaffl
Relacionado
1 \,.paiiiCiimuonte
FundAn
Comunicacin
M1
Encuontro
GPIC 3.058 _ J l
' GHCzaoe j j
OrganEadAriV
" GPICiOOS' '
RolDePartflC cmunicante
iJ Ertcu&nlroAsislaicialRelacEDnadD
I
(de GPtC 3.059)
~
SijtleAteneiSn <c
(de GPIC 2.026) 1
OrdenDEMonsaje
RolProfesional
Identificada
;do GPIC 2.034;
Participacin
PtofesionalSanItaria
<S^C2002
PeticinDoSBivicio
As$tendalGPIC 3.054
1 To.-i
^ KolDalSujetoDe
Atencin
(da GPIC 2,026
^-^
0..1
Participseiin
1 |OcgaiaAnSiiiitaia
GPIC 2003
"-^Y
EnlacsPiDUisln
Deservicio
(de GPIC 3,060]
RolProfesional
Sanildro
de GPIC 2.033;
''': Piifeslonal
IdedtJlicado
fda GPIC 2.034)
Persona
GPIC 2006
|_ iolOrgsniiaclir
Identicada 1 ^ Identificada
fe GPIC 2 0 3 7 ' to GPIC 2.337
1 ldOrt|ani;a{!0r
Sanilara
Kde GPIC 2.036
PnnisinSenicio
SujetoDeA tencin
Pstsona
GPIC 2,018
SljeteDeAtenpir / ] _
' f f l c 2:017
N
I rfaimacl6nG^nda
DePaaente
GPIC 2.019
InFarmacinBdendida
DsPadenTe
GPIC 2.020
Sujeto WvD
Idsntifieailo
0rgaii2aciSn
GPIC 2,0OB
ItemDa
InformacinCUnica
GPIC 3,021
OtesrvacinCIInlca
GPIC 3 023
InormeSLAireSeiHcio
Aastsncial
GPIC 3.056
] InfmmoSobreSi
- O
Relacionado
(ds GPIC 3.057)
~r
AgnipactnDe
IfiroimacinCirnrca
GPIC 3.019
ProcedrnientEiCIInlcii.,
GPIC 3.025
PeticinDePfijoba
GPIC 3.030
ResuHadoPiueba
GPIC 3.032
Figura 6.7
Consojo
GPIC 3,028
MIM mensaje de peticin de teleconsulta
Anlogamente al apartado anterior, en la descripcin que sigue se intenta que sea vlida para los dos
casos posibles: a) la teleconsulta forma parte de un servicio asistencial mas complejo, y b) la
teleconsulta es el servicio asistencial solicitado. En aquellos casos que no sea posible, se considerar
estar describiendo solamente el caso b).
1
TransmsinMensê
144
Mensaje
tiempoCreacin (M)
Fecha/hora en la que el sistema remitente cre la transmisin,
id
(M)
Identifcador nico de la transmisin
0..*
MensgeRelaconiado
EventoDeControlRelacionado
idTipoEstructura (O)
Identifcador del tipo de contenido del mensaje relacionado
Mensaj eRelacionado
tiempoCreacin (M)
Fecha/hora en la que el sistema remitente cre la transmisin,
id
(M)
Identifcador nico de la transmisin
2..*
ParteComunicante
FuncinComunicacin
cdigoTipo
(M)
P.ej SND(remitente), RCV(receptor), RSP(respuesta a)
telecom
(O)
telecom
ParteComunicante.
- Persona (GPIC_ID = 2.006) [E]
cdigoClase
(M)
Elegido de Anexo 3; p.ej PSN (persona)
cdigoDeterminador(M)Elegido de Anexo 4; p.ej INST (instancia de)
id
(M)
Identifcador nico de la persona
nombre
(O)
Uno o mas nombres para confirmar la identidad de la persona
direccin
(O)
Una o mas direcciones postales (o partes)
telecom
(O)
Una o mas direcciones de telecomunicaciones (o partes)
0..* LenguajeDeComunicacin (GPICJD = 2.007).
- Organizacin (GPICJD = 2.008) [E]
cdigoClase
(M)
Elegido de Anexo 3; p.ej ORG (organizacin)
cdigoDeterminador(M)Elegido de Anexo 4; p.ej INST (instancia de); KIND (tipo)
nombre
(O)
id
(O)
cdigo
(O)
desc
(O)
direccin
(O)
telecom
(O)
0..* JerarquaOrganizacin (GPICJD = 2.010) [R]
0..* LenguajeDeComunicacin (GPIC_ID = 2.007)
0..* PersonaDeContacto (GPICJD = 2.012) [R]
- Dispositivo (GPICJD = 2.055) (No incluido)
RolDeParteComunicante
cdigoClase
(M)
Elegido de Anexo 5; p.ej PROV(proveedor)
cd
(O)
Cdigo que representa la especialidad mdica
cdigoPuestoTrabajo(O)
cdigoTtuloPuestoTrabajo(O) Ttulo del puesto de trabajo
0.1
EventoDeControl
idTipoEstructura(O)
Identifcador del tipo de contenido del mensaje tomado de un
catlogo de interacciones
cdigoRespuesta(O)
P.ej C(completo), D(detalle), E(exc^cin), F(confirmacin),
R(modifcacin), X(mnguna).
CdigoLenguaje(O)
Lenguaje principal en el contenido
1
PetciiiDeServicio
1
cdigoClase
(M)
Elegido de Anexo 10; p.ej OBS(observacin), LIST (lista de
trabajos), ENC (encuentro), Proc(procedimiento), REFR(derivacin),
cdigoMood (M)
Elegido de Anexo 11; p.ej DEF(defnicin), ORD(orden),
CNF(confirmacin, INT(intento), PRP(propuesta), etc
cdigoEstado (O)
Elegido de Anexo 12; p.ej
nuevo, normal, abortado,
cancelado, completado, suspendido, etc.
cdigo
(O)
Identificacin unvoca tipo servicio solicitado
145
id
(O)
Uno o mas identifcadores para la instancia de peticin
tiempoActividad(0)
Ventana de tiempo en la que la peticin debe tratarse
cdigoPrioridad(O)
texto
(O)
Comentario adjunto a la peticin
0..1 ReceptorServicio
0..1 ReceptorServicioAsistencial (GPICJD = 2.031) [P]
- SujetoDeAtencinParticipante (GPICJD = 2.026) [P]
PartcipacinDelSujetoDeAtencin[P]
cdigoTipo
(M)
Elegido de Anexo 6; p.ej PATSBJ(sujeto paciente)
RolDelSujetoDeAtencin [R].
cdigoClase
(M)
Elegido de Anexo 5; p.ej IDENT (rol identificado entidad)
SujetoDeAtencin (GPICJD = 2.017) [E]
- SujetoDeAtencinPersona (GPIC_ID = 2.018) [E].
- InformacinEstndarDePaciente (GPICJD = 2.019) [E]
cdigoClase
(M)
id
(M)
nombre
(O)
Uno o mas nombres para confirmar identidad sujeto
direccin
(O)
telecom
(O)
Una o mas direcciones telecomunicaciones (o partes)
cdigoAdminGnero(O) P.ej hombre, mujer, inter, desconocido
tiempoNacimiento(O)
cdigoEstadoMarital(O) P.ej casado, separado, etc
cdigoHabitat (O)
Descripcin lugar de dnde viene
cdigoRiesgo
(O)
Riesgo asociado (embarazada, imnunodeprimida, etc)
cdigoGrupoEtnico(O)
- InformacinExtendidaDePaciente (GPIC_ID = 2.020) [E]
nmeroOrdenNacim
(O)
Orden nacimiento en parto mltiple
cdigodiscapacidad
(O)
Deficiencias en p.ej vista, odo, etc
cdigoNacionalidad
(O)
indicadorMuerte
(O)
Indicacin de que el sujeto ha muerto
tempoMuerte
(O)
Fecha y hora del bito
cdigoEstadoEmpleo
(O)
P.ej empleado, autnomo, desempleado,..
- SujetoVivoldentifcado (GPICJD = 2.014) [E]
cdigoClase
(M)
Elegido de Anexo 3; p.ej LIV (sujeto vivo)
cdigoDeterminador(M) Elegido de Anexo 4; p.ej INST (instancia de)
id
(M)
Identificador ico del sujeto
nombre
(O)
0..* LenguajeDeComunicacin (GPIC_ID = 2007)
0..* ParteRelacionadaConSujetoDeAtencin (GPICJD = 2.024) [R]
0..* ParteSanitaria (GPICJD = 2.039) [R]
0..* LugarDeAsistencia (GPICJD = 2.062) [R]
0..* SujetoDeAtencinRelacionado (GPICJD = 2.023) [R]
0..1 SujetoDePrueba (GPIC_ID = 2.032) [P]
ParticipacinDelSujetoDePrueba [P]
cdigoTipo
(M)
Elegido de Anexo 6; p.ej SBJ (sujeto)
notaTexto
(O)
Cualquier anotacin en texto libre; puede usarse para
especificar disponibilidad
cdigoEstado
(O)
Elegido de Anexo 7; p.ej activo, cancelado, etc
RolDelSujetoDePrueba [R]
cdigoClase
(M)
Elegido de Anexo 5; p.ej ROL (rol)
SujetoDePrueba [E].
- Sujeto Vivoldentifcado (GPICJD = 2.014) [E]
- SujetoDeAtencin (GPICJD = 2.017) [E]. Solo se considera SujetoDeAtencinPersona.
- Espcimen (GPIC_ID = 3.003) [E]
- EspcimenManufacturado (GPICJD = 3.005) [R]
146
RolDelObjetoManufacturado [R].
cdigoClase
(M)
Elegido de Anexo 5; p.ej MANU (producto manufacturado)
EspcimenManufacturado [E]
cdigoClase
(M)
Elegido de Anexo 3; p.ej MMAT (material manufacturado)
cdigodeterminador(M)Elegido de Anexo 4; p.ej INST, KIND
id
(O)
Uno o mas identifcadores del espcimen manufacturado
cdigo
(M)
Naturaleza del espcimen manufacturado
cantidad
(O)
Cantidad de especmenes manufacturados
tienq)oExistencia(O) Fecha-hora de finalizacin proceso manufacturacin
cdigoManejo (O)
Instrucciones almacenamiento y manejo
nombreLote
(O)
Identificacin lote de material manufacturado
tienpoCaducidad(0) Fecha caducidad
0.. * OrganizacinRelacionada (GPIC_ID = 2.011) [R]
0..* PartePartcipante
0..* ParteSanitariaParttdpante (GPIC_ID = 2.053) [P]
- ProfesionalSanitarioParticipante (GPIC_ID = 2.049) [P]
ParticipacinProfesionalSanitario (GPICJD = 2.002) [P]
cdigoTipp
(M)
Elegido de Anexo 6; p.ej CON(consultor),
PRF(reaUzador, ASS(asistente), etc
cdigoControlContexto(O) Elegido de Anexo 9; p.ej I(hereda), N(no hereda)
cdigoFuncin
(O)
Ampla la descripcin de la participacin
cdigoModo
(O)
Elegido de Anexo 8; p.ej VIDEOCONF
(videoconferencia), FACE(cara a cara), PONE(por telfono), etc
tiempo
(O)
cdigoEstado
(O)
Elegido de Anexo 7; p.ej pendiente
cdigoFirma
(O)
P.ej SGN (firmada), REQ (requerida)
textoFirma
(O)
Rbrica del profesional
ProfesionalSanitario (GPICJD = 2.033) [R].
RoIDelProfesionalSanitario [R].
cdigoClase
(M)
Elegido de Anexo 5; p.ej PROV (proveedor)
cdigo
(O)
id
(O)
Uno o mas identificadores del rol
cdigoTrabajo (O)
Naturaleza del puesto de trabajo.
CdigoTtuloTrabajo(O) Ttulo del trabajo
Persona (GPICJD = 2006) [E]
0..* ProfesionalSanitaroRelacionado (GPICJD = 2.035) [RL]
0..* OrganizacinSanitariaRelacionada (GPICJD = 2.038) [RL]
0..* OrganizacinSanitaria (GPICJD = 2.036) [R]
- ProfesionalParticipanteldentificado (GPICJD = 2.050) [P]
ProfesionalSanitarioIdentificado (GPIC_ID = 2.034) [R]
RolDelProfesionalIdentificado [R]
cdigoClase
(M)
Profesionalldentificado [E]
cdigoClase
(M)
cdigoDeterniinador(M) Elegido de Anexo 4; p.ej INST (instancia)
id
(M)
Identifcador del profesional
nombre
(O)
Nombre(s) para confirmar identidad del profesional
- OrganizacinSanitariaParticipante (GPIC_ID = 2.051) [P]
ParticipacinOrganizacinSanitaria (GPICJD = 2.003) [P]
OrganizacinSanitaria (GPICJD = 2.036) [R]
RolOrganizacinSanitaria [R]
cdigoClase
(M)
cdigo
(O)
Organizacin (GPICJD = 2.008) [E]
0.. * ProfesionalSanitarioRelacionado (GPICJD = 2.035) [RL]
147
0..* OrganizacinSanitariaRelacionada (GPICJD = 2.038) [RL]

- OrganizacinParticipanteldentificada (GPICJD = 2.052) [P]
ParticipacinOrganizacinSanitaria [P]
OrganizacinSanitarialdentificada (GPICJD = 2.037) [R]
RolOrganizacinldentificada [R]
cdigoClase
(M)
Organizacinidentificada [E]
cdigoClase
(M)
cdigoDeterminador(M) Elegido de Anexo 4; p.ej INST (instancia de)
id
(M)
nombre
(O)
Nombre por el que se conoce la organizacin
0..* PetconesRelacionadas
0..* PeticinDeServicioRelacionada (GPIC_ID = 3.055) [AR]
PeticinDeServicioRelacionada [AR]
cdigoTipo
(M)
Elegido de Anexo 13; p.ej CAUS(es causa de), PREV(tiene
instada previa), RPLC(reemplaza), SUCC(se aade), etc
nmeroSecuencia (O)
cdigoControlContexto(O) Elegido de Anexo 14.
0..* ObjetoAnalizable
0..* ObjetoAnalizableUsado (GPICJD = 3.002) [P]
ParticipacinObjetoAnalizable [P]
cdigoTipo
(M)
Elegido de Anexo 6; p.ej SPC (espcimen)
cdigoControlContexto(O)Elegido de Anexo 9; p.ej I(hereda)
cdigoFuncin
(O)
Cdigo par funcin o propsito
cdigoModo
(O)
P.ej. local o remoto
nmeroSecuencia (O)
tiempo
(O)
notaTexto
(O)
Informacin adicional
ObjetoAnalizable GPICJD = 3.001) [R]
RolObjetoAnalizable [R]
cdigoClase
(M)
Elegido de Anexo 5; p.ej INST (instancia)
nmeroPosicin(0)
Cronologa en el orden de varios
cdigo
(O)
Proporciona contexto al rol del objeto
ObjetoAnalizable [E]
cdigoClase
(M)
Elegido de Anexo 3; p.ej ENT (entidad)
cdigodeterminador (M)
Elegido de Anexo 4; p.ej KIND (tipo)
id
(O)
Uno o mas identifcadores del espcimen
cdigo
(M)
Naturaleza espcimen
desc
(O)
cantidad
(O)
Nmero de objetos
cdigoExistencia
(O)
Fecha-hora (o periodo) creacin del espcimen
cdigoManejo
(O)
Instrucciones manejo
cdigoRiesgo
(O)
0..* MaterialPreservacin (GPICJD = 3.011) [R]
0..1 LugarNoAsistencial (GPIC_ID = 2.064) [R]
- ProductodeEstudio (GPICJD = 3.009) [E]
cdigoClase
(M)
Elegido de Anexo 3; ENT (entidad)
Elegido de Anexo 4; p.ej INST, KIND
id
(O)
Uno o mas identifcadores del producto de estudio
cdigo
(M)
Naturaleza producto estudio
desc
(O)
cantidad
(O)
Nmero de objetos
tiempoExistencia
(O)
Fecha-hora (o periodo) creacin producto de estudio
0..* ReferencialnformacinExtema (GPICJD = 3.016) [R]
148
0..* DispositivoRelacionado (GPICJD = 2.057) [R]

0..* CaractersticaDelObjeto (GPICJD = 3.010) [P]
0..1 AdquisicinObjetoAnalizable (GPICJD = 3.013) [P]
0..* ObjetoAnalizableRelacionado (GPIC_ID = 3.004) [RL]
0..* ProyisinServicio
0..* ProvisinServicioAsistencial (GPICJD = 3.060) [AR]
EnlaceProvisinServicio [AR]
cdigoTipo
(M)
cdigoControlContexto(O) Elegido de Anexo 14; p.ej N(no hereda)
ProvisinServicio [A].
- ProcedimientoClnico (GPICJD = 3.025) [A]
cdigoClase
(M)
Elegido de Anexo 10; p.ej PROC(procedimiento)
cdigoMood (M)
Elegido de Anexo 11; p.ej APT(compromiso)
cdigoEstado (O)
Elegido de Anexo 12; p.ej ACT(activo)
id
(O)
Identificadores del procedimiento
cdigo
(O)
texto
(O)
cdigoMtodo (O)
Mtodos del procedimiento
cdigoSitio
(O)
Lugar procedimiento
tiempoActividad(0)
Ventana tiempo procedimiento
tiempoEfectivo (O)
cdigoPrioridad(0)
P.ej Alta prior, urgente, rutina
0..* InformacinClnicaRelacionada (GPICJD = 3.022) [AR]
0..* DispositivoUsado (GPIC_ID = 2.059) [P]
0..* ProcedimientodePrq)aracinPaciente (GPICJD = 3.026) [AR]
- PeticinPrueba (GPICJD = 3.030) [A]
cdigoClase
(M)
Elegido de Anexo 10; PROC (procedimiento)
CdigoMood (M)
Elegido de Anexo 11; ORD, INT (INT, APT, ARQ, PRP,
RMD), EVN
cdigoEstado (O)
Elegido de Anexo 12; si ORD (nuevo, activo, suspendido,
modificado, cancelado, completado); si INT (notificado, suspendido, cancelado, completado); si EVN
(completado)
tiempoActividad(0)
Hora a la que la prueba fue realizada
tiempoEfectivo (O)
cdigo
(O)
cdigoMtodo (O)
Mtodos de la prueba
id
(O)
Uno o mas indicadores de la instancia de la prueba solicitada
cdigoPrioridad(0)
nmeroRepeticin(0) Mximo y mnimo de repeticiones
texto
(O)
Detalles adicionales sobre la prueba
0.. 1 SujetoD ePrueba (GPIC_ID = 2.032) [P]
0..* PeticinDePruebaRelacionada (GPICJD = 3.031) [AR]
0..* ResultadoDePruebaRelacionado (GPICJD = 3.033) [AR]
0..* ObjetoAnalizableAdquirido (GPICJD = 3.012) [P]
0..* TransporteSujetoVivoRelacionado (GPIC_ID = 2.067) [AR]
0..* LugarDeAsistenciaUsado (GPICJD = 2.063) [P]
- Consejo (GPICJD = 3.028) [A]
cdigoClase
(M)
Elegido de Anexo 10; p.ej ACT
cdigoMood (M)
Elegido de Anexo 11; p.ej RMD(recomendacin)
cdigoEstado (O)
cdigo
(O)
Identificacin tipo de consejo
texto
(O)
Resumen o transcripcin del consejo
tiempoActividad(0)
Ocurrencia del consejo
cdigoConfidencialidad
0.. 1 PadenteParticipanteldentificado (GPIC_ID = 2.028) [P].
149
0..* ParteRelacionadaConPacienteParticipante(GPIC_ID=2.029) [P]

0..* InfonnacinClnica
0..* InformacinClnicaRelacionada (GPIC_ID = 3.022) [AR]
EnlacelnformacinRelacionada [AR]
cdigoTipo
(M)
Elegido de Anexo 13; p.ej REFR(se refiere a)
cdigoControlContexto(O)
Elegido de Anexo 14; p.ej I(hereda)
InformacinClnica (GPICJD = 3.017) [A].
- ComplejoDeInformacinClnica (GPICJD = 3.018) [A]
- AgrupacinDelnformacinClnica (GPICJD = 3.019) [A]
cdigoClase
(M)
Elegido de Anexo 10; p.ej DOCCLIN(documento clnico)
cdigoMood (M)
Elegido de Anexo 11); p.ej DEF(definicin servicio)
cdigoEstado (O)
Elegido de Anexo 12; p.ej SUS(suspendido)
cdigoNivel
(O)
Nivel que ocupa en la jerarqua de la estructura
cdigoLenguaj e(0)
cdigo
(O)
id
(O)
Uno o mas identifcadores de esta agrupacin de informacin
tiempoActividad(0)
tiempoEfectivo Ô)
Ventana tiempo en el que ha estado en este estado
texto
(O)
0..* ComplejoDelnformacinClnicaRelacionado (GPIC_ID = 3.020) [AR]
- ItemDelnformacinClnica (GPICJD = 3.021) [A]
- ObservacinClnica (GPICJD = 3.023) [A]
cdigoClase
(M)
Elegido de Anexo 10; p.ej OBS (observacin)
cdigoMood (M)
Elegido de Anexo 11; EVN(evento)
cdigoEstado (O)
Elegido de Anexo 12; ACT(activo)
cdigo
(O)
Tipo de observacin
texto
(O)
id
(O)
Identificador nico instancia
cdigoMtodo (O)
Mtodo usado prueba
cdigoSitio
(O)
Lugar foco
tiempoEfectivo (O)
Ventana tiempo en el que la observacin estuvo activa
valor
(O)
P.ej: ST (cadena), PQ (cantidad fsica), TS (punto en el
tiempo), CD (cdigo descriptor), CV (cdigo valor), IVL<PQ> (rango de cantidades fsicas),
el tiempo)
cdigoInterpretacin(0)P.ej anormal
0..* InformacinClnicaRelacionada (GPIC_ID = 3.022) [AR]
- ProcedimientoClnico (GPIC_ID = 3.025) [A]
- ResultadoPrueba (GPICJD = 3.032) [A]
cdigoClase
(M)
Elegido de Anexo 10; p.ej OBS(observacin)
cdigoMood (M)
Elegido de Anexo 11; p.ej RMD(recomendacin)
cdigoEstado (O)
Elegido de Anexo 12; p.ej CMP(completado)
cdigo
(O)
Tipo de prueba
id
(M)
Uno o mas identifcadores de la instancia del resultado
tiempoActividad(0)
tiempoEfectivo (O)
Ventana tiempo en el que se obtuvo el resultado
valor
(O)
P.ej: ST (cadena), PQ (cantidad fi'sica), TS (punto en el
el tiempo)
cdigoInterpretacin(0)
P.ej anormal
indlndependiente(0) Si puede ser independiente
150
cdigoInterpretaciii(0)
Normalidad del resultado
cdigoMtodo (O)
texto
(O)
Detalles adicionales o adjuntar multimedia informacin
0..* ReferenciaNormalidad (GPICJD = 3.034) [AR]
0..* ObjetoAnalizableUsado (GPICJD = 3.002) [P]
0..* ResultadoPruebaRelacionado (GPICJD = 3.033) [AR]
0..* PeticinPruebaRelacionada (GPICJD = 3.031) [AR]
0..1 EspecifcacinPrueba (GPICJD = 3.036) [AR]
- InformacinClnicaNoClasifcada (GPICJD = 3.029) [A]
cdigoClase
(M)
Elegido de Anexo 10; por defecto es ACT
cdigoMood (M)
Elegido de Anexo 11; p.ej DEF(defnicin)
cdigoEstado (O)
Elegido de Anexo 12; NRM(normal)
cdigo
(O)
Tipo de la informacin
texto
(O)
id
(M)
Identificador instancia
cdigoMtodo (O)
Mtodo asociado
tiempoEfectivo (O)
Ventana tiempo en la que la informacin est activa
valor
(O)
el tiempo)
0..* CondicinDelPacienteRelacionada (GPICJD = 3.024) [AR]
0..* InformeSobreServcio
0..* InformeSobreServicioRelacionado (GPICJD = 3.057) [AR]
- Informes obreServicioRelacionado [AR]
cdigoTipo
(M)
Elegido de Anexo 13; p.ej SEQL(secuela)
nmeroSecuencia (O)
cdigoControlContexto(0)Elegido de Anexo 14; p.ej l(hereda)
- InformeSobreServicioAsistencial (GPICJD = 3.056) [A]
0..* Encuentro
0..* EncuentroRelacionado (GPICJD = 3.059) [AR]
EncuentroAsistencialRelacionado [AR]
cdigoTipo
(M)
Elegido de Anexo 13; p.ej DRIV(derivado de)
nmeroSecuencia (O)
Encuentro (GPICJD = 3.058) [A]
cdigoClase
(M)
Elegido de Anexo 10; p.ej ENC (encuentro)
cdigoMood
(M)
Elegido de Anexo 11; APT(cita, compromiso)
cdigoEstado
(O)
Elegido de Anexo 12; CMP(completado)
cdigo
(O)
id
(O)
tiempoActividad (O)
Fecha-hora comienzo
tiempoEfectivo
(O)
Duracin encuentro
escenarioPrctica (O)
texto
(O)
0..* LugarDeAsistenciaUsado (GPIC_ID = 2.063) [P]
0..* TransporteSujetoVivoRelacionado (GPICJD = 2.067) [AR]
0..* Transporte
0..* TransporteSujetoVivoRelacionado (GPICJD = 2.067) [AR]
TransporteRelacionado [AR]
TransporteSujetoVivo (GPICJD = 2.065) [A]
TransporteSujeto [A]
cdigoClase
(M)
Elegido de Anexo 10; TRNS(transporte)
151
cdigoMood (M)
Elegido de Anexo 11; p.ej EVN (evento), ORD (orden), INT
(intento; dos subtipos: PRP (propuesto), RMD (recomendado); (interacta con cdigoEstado)
cdigoEstado (M)
Si EVN (completado, abortado); si ORD (nuevo, activo,
suspendido, cancelado, completado); si INT (notificado, suspendido, cancelado, completado)
cdigo
(O)
Tipo de transporte
cdigoNivelGravedad(0)
Agudeza, nivel complejidad
tiempoActividad(0)
Fecha y hora comienzo transporte
id
(O)
Identificador nico
texto
(O)
Detalles adicionales sobre el transporte
cdigo_prioridad(0) P.ej Alta prioridad, urgente, rutina
0..* ParteSanitariaParticipante (GPICJD = 2.053) [P]
0..* ParteRelacionadaConPacienteParticipante (GPICJD = 2.029) [P]
152
6.13 Descripcin jerrquica del mensaje (DJM) de peticin de eleconsulta

La descripcin jerrquica del mensaje de peticin de teieconsulta es la siguiente:
Ocurminmax
1
0..*
2-*
r '
.,: ., .,
,fl
-'
l..^^
1
EventoDeControI
PeticinDeServicio
Usado para
Cabecera mensaje peticin
teleconsulta
MensêRelacionado
Mens aj eRelacionado
0..*
0..1
0..1
GPIC ID
TransmisiiiMeiisîe
ParteComunicante
FuncinComunicacin
ParteComunicante.
Persona
Organizacin
Lenguaj eD eCbmunicacin
r^lj^^:
Nombre GPIC o clase
Tipo de contenido
Identificar otros mensajes
relacionados
2.006
2.008
2.007
PeticinDeServicioAsistencial
3.054
ReceptorServicio
Receptor ServicioAsistencial
2.031
Remitente, receptor, respuesta a

Solo una de las dos especializacones
para cada parte
Informacin demogrfica del
profesional sanitario
Identificar la organizacin del
profesional
Especialidad mdica, puesto de
trabajo
Lenguaje principal profesionales
Peticin de teleconsulta o de servicio
asistencial que la incluye
Naturaleza del servicio
Identificacin tipo servicio
Tiempo Actividad
Prioridad
Comentarios
Solo se considera persona. No se da

ninguna informacin especfica
acerca de la naturaleza de la
participacin
153
SujetoDeAtencinParticipante
ParticipacinDelSujetoDeAtencin
RolD elSuj etoDeAtencin
SujetoDeA tencin
SujetoDeAtencinPersona
InformacinEstndarDePaciente
Infor macinExtendi daD eP aciente
Suj eto Vivol dentificado
2.026
2.019
2.020
2.014
Cuando el sujeto de atencin (no

necesariamente el paciente, pero s
persona) participa en la teleconsulta.
En la gran mayora de los casos:
Paciente. En cada caso concreto solo
se usa una de las tres
esp ecializaciones
En la gran mayora de los casos
Cuando se necesita informacin
adicional
Solo se necesita (correcta)
identificacin
0..*
0..=
LenguajeDeComuncacin
ParteRelacionadaConSuj etoDeAtencin
2007
2.024
0./
ParteSanitaria
2.039
0..=
O-*
LugarDeAsstencia
Suj etoD eAtencinRelaciona do
2.062
0..1
SujetoDePrueba
2.032
ParticipacinDelSujetoDePrueba
SujetoDePrueba
Suj eto Vi voldentificado
Suj etoDeAtencin
Espcimen
EspcimenManufacturado
2.014
2.017
3.003
3.005
0./
OrganizacinRelacionada
2.011
0..*
ParteParticipante
2.023
Lenguaje principal paciente

Parte no-sanitaria relacionada con
paciente
Parte sanitaria relacionada con
paciente
Lugar relacionado con la asistencia
Otro sujeto de atencin relacionado
con el paciente
Para aquellos casos en que el sujeto
de atencin no participa en la
teleconsulta
En cada caso concreto solo se usa una
de las cuatro especializaciones
Solo se necesita identificacin
Solo se considera sujeto de atencin
persona
En la gran mayora de los casos de
s ervici os=prueb as
Espcimen elaborado, casi siempre
auxiliar
Organizacin fabricante del
espcimen manufacturado
154
0..*
arteSanitariaParticipante
2.053
0..*
ProfesionalSanitarioParticipante
ParticipacinProf es ionalS anitario
ProfesionalSanitario
RolD elProfesionalS anitario
Persona
ProfesionalSanitarioRelacionado
OrganizacinSanitariaRelacionada
OrganzacinSanitaria
2.049
2.002
2.033
ProfesionalParticipanteldentifcado
ParticipacinProf esionalS anitario
Profes ionalS anitariol dentifica do
RolDelProfesionalIdentificado
Profes ionall dentificado
OrganizacinS anitariaP articipante
ParticipacinOrganizacinSanitaria
OrganizacinS anitaria
RolOrganizacinS anitaria
Organizacin
2.050
2.002
2.034
H^
i|p
'
0..*
0..*
0..*
0..*
1
C
0..*
n
D
Wr
2006
2.035
2.038
2.036
0..*
0..*
0..*
0..*
0..*
ProfesionalSanitarioRelacionado
OrganizacinS anitariaRelacionada
OrganizacinParticipanteldentificada
ParticipacinOrganizacinS anitaria
OrganizacinS anitarialdentificada
RolOrganizacinl dentificada
Organizacin! dentificada
PeticionesRelacionadas
PeticinDeServicioRelacionada
2.051
2.003
2.036
2.008
2.035
2.038
2.052

de las cuatro especializaciones
(ProfesionalSanitarioParticipante,
ProfesionalParticipanteldentifcado,
OrganizacinS anitariaP articipante,
OrganizacinParticipanteldentificada
)
Detalles del profesional y de la
naturaleza de su participacin en uno
o mas aspectos de la provisin del
Otro profesional sanitario relacionado
Organizacin relacionada
Otros aspectos adicionales de la
propia organizacin
Solo referenciado para detalles de
identificacin
Detalles de la organizacin y de la
naturaleza de su participacin en uno
0 mas aspectos de la provisin del
Profesional relacionado
Otra organizacin relacionada
Solo referenciada para detalles de
identificacin
2.037
3.055
Enlazar una instancia de peticin de

servicio a otra actividad, que incluye
155
^^MHII
0..*
ObJetoAnalizable
ObjetoAnalizableUsado
ParticipacinObjeto Analizable
ObJetoAnalizable
RolOb jeto Analizable
ObJetoAnalizable
Espcimen
3.054
otra peticin de servicio
3.002
Cuando el verdadero tema de la

teleconsulta no es persona sino
espcimen o producto de estudio. En
cada caso concreto solo se usa una de
las dos especializaciones (espcimen,
producto de estudio).
3.001
3.003
P.ej biopsia, sangre, orina, etc

0..*
0..1
MateriaiPreservacin
LugarNoAsistencial
Producto deEstu dio
3.011
2.064
3.009
o..^^
ReferenciaInformacinExterna
3.016
0..*
DispositivoRelacionado
2.057
0..*
CaractersticaDelObjeto
3.010
0..1
AdquisicinObjetoAnalizable
3.013
0..*
0..*
0..*
ObjetoAnalizableRelacionado
ProvisinServicio
ProvisinServicioAsistencial
EnlaceProvisinServicio
ProvisinServicio
ProcedimientoCinico
3.004
Pa
H ^H
A
3.060
3.025
0..*
InformacinClnicaRelacionada
3.022
0..*
DispositivoUsado
2.059
Cualquier reactivo o similar

Lugar (no sanitario) relacionado con
el espcimen
P.ej estudios Rx, TAC, RMN, eco,
ECG, etc
Referencia a un componente del
Extract que se enva al consultor
cuando se solicita la teleconsulta
Usado en la adquisicin del producto
de estudio
Parmetros de medida u otras
caractersticas
Informacin sobre el proceso de
adquisicin
Otro objeto relacionado
de las tres especializaciones
(procedimiento, prueba, consejo)
Enlaza detalles de la provisin del
servicio con entidades externas.
Informacin relativa al procedimiento
0 referencia a tems de informacin
relacionada
Equipo usado en el procedimiento
156
0..*
ProcedimientodePreparacinPaciente
3.026
0..1
PeticinPrueba
SujetoDePrueba
3.030
2.032
0..*
PeticinDePruebaRelacionada
3.031
0..*
ResultadoDePruebaRelacionado
3.033
0..*
0..*
Objeto AnalizableAdquirido
3.012
3.022
0..*
TransporteSujetoVivoRelacionado
2.067
0..*
0..1
LugarDeAsistenciaUsado
Consejo
PacienteP articipanteldentifica do
2.063
3.028
2.028
0..*
ParteRelacionadaConPacientePartcipante
2.029
0..*
3.022
0..*
0..*
InformacinClmca
InformacinClmca
ComplejoDelnformacinCUnica
AgrupacinD einfor macinClnica
B
m
'f"fp'--
'
C
1^1
3.022
3.019
Condiciones aplicadas o sustancias

administradas al paciente
Informacin sobre la entidad que es
sujeto de la prueba
Otra peticin de prueba (componente
o previa).
Otros resultados de prueba
relacionados
Espcimen o producto de estudio
tems 0 agrupaciones relevantes a la
prueba o referencia a items de
informacin relacionada
Requerimientos transporte del sujeto
de atencin o del sitio donde se
realiza la prueba
Lugar donde se realiza la prueba
Participacin del paciente en el
consejo
Participacin de persona no-sanitaria
u organizacin en el consejo
tems o agrupaciones relevantes al
cornejo o referencia a items de
informacin relacionada
Un tem o complejo de informacin
clnica con alguna relacin al
servicio/teleconsulta. En cada caso
concreto solo se usa una de las dos
esp ecializaciones.
Proporcionar un contexto compartido
para el contenido de la informacin
dentro del complejo
0..*
3.022
Otros items de inters relacionados

con la agrupacin
157
Captulo 6, Resultados
0..*
B
0..*
<
3.023
3.022
3.025
3.030
3.028
3.032
0..*
0..*
ReferenciaNormalidad
ObjetoAnalizableUsado
3.034
3.002
0..*
0..*
ResultadoPruebaRelacionado
PeticinPruebaRelacionada
3.033
3.031
0..1
EspecificacinPrueba
3.036
0..*
Infor macinClnicaNoClasifica da
3.029
3.022
0..*
CondicinDelPacienteReacionada
3.024
0..*
0..*
0..*
InformeSobreServicio
Informes obreServicioRelacionado
InformeSobreServicioAsistencial
Encuentro
EncuentroRelacionado
Encuentro As istencialRelacionado
Encuentro
3.058
2.063
0..*
EncuentroRelacionado
3.059
0..*
0..*
M I
3.020
ItetnDelnformacinClnica
Ob servacinClnica
Procedimi entoCInico
PeticinPrueba
Consejo
ResultadoPrueba
ComplejoDeInformacinClnicaRelacionado
3.057
3.056
3.059
Otra agrupacin dentro del mismo

complejo
Contexto considerado indivisible.
Descripcin
general
de
una
observacin clnica
Otros tems de inters relacionados
con la observacin
Descripcin general de un
procedimiento.
Descripcin general de una prueba.
Descripcin general de un consejo.
Descripcin general de resultados de
una prueba
Establecimiento lmites rango vlido
Referencia a otro objeto asociado con
el resultado
Otro resultado relacionado
Otras peticiones de prueba
relacionadas
Detalles sobre cmo se ha llevado a
cabo la prueba
Otros tems de inters relacionados
con la informacin no clasificada
Informacin adicional (dolencia)
sobre el paciente
un informe sobre otro servicio
un encuentro relacionado
Informacin adicional sobre el lugar
asociado al encuentro
Otro encuentro relacionado con ste
158
HLJ
0..*
0..*
0..*
Transporte
TransporteRelacionado
TransporteSuj eto Vivo
TransporteSuj eto
2.067
Informacin sobre preparativos o

responsabilidad asociados al
encuentro
2.067

un un transporte.
Enlaza la informacin sobre el sujeto
vivo con los detalles del transporte.
Profesional sanitario relacionado con
el transporte
Persona no sanitaria u organizacin
relacionada con el transporte
2.065
0..*
ParteSanitariaParticipante
2.053
0..*
ParteRelacionadaConPacienteParticipante
2.029
159
6.2 Especificacin del mensaje de informe sobre teleconsulta

6.2.1 Descripcin general del mensaje de informe sobre teleconsulta
6.2.1.1
TransmisinMensaje
Es el envoltorio en el que se coloca el mensaje de informe; esta parte es anloga a la descrita en el

apartado 6.1.1.1 del mensaje de peticin. Tambin puede tener mensajes relacionados.
6.2.1.2
Es una especializacin de ComplejoDelnformacinClnica
(GPIC_ID = 3.018) [A] que contiene el
conjunto de informacin contenida en un informe sobre uno o varios servicios asistenciales. En la

descripcin textual que sigue se mantiene lo mas posible que sea vlida para los dos casos posibles: a)
la teleconsulta forma parte de un servicio asistencial mas complejo, y b) la teleconsulta es el servicio
asstencal solicitado. En aquellos casos que no sea posible, se considerar estar describiendo
solamente el caso b).
# Se compone de una sola clase:
- InformeSobreServicioAsistencial [A]
# Atributos:
cdigoClase
CS
cdigoMood
CS
Cmo interpretar la informacin (ver Anexo 11)
cdigoEstado
CS
Estado del informe (ver Anexo 12)
cdigo
CD
Identificacin tipo de servicio informado
id
SET<II>
Uno o mas identifcadores instancia informe
tiempoActividad O
TS
Fecha y hora en que el informe finaliz
cdigo_prioridad O
CV
texto
ED
comentario adjunto al informe

- 0..1 ReceptorServicioAsistencial (GPIC_ID = 2.031) [P]. Informacin acerca de una persona generalmente el paciente- que es el sujeto de atencin en el informe sobre el servicio asistencial.
- 1 SujetoDePrueba (GPIC_ID = 3.032) [P]. Conjunto de informacin relativa a una persona,
animal, u objeto analizable que es el sujeto de una prueba.
- 0..* ParteSanitariaParttcipante (GPIC_ID = 2.053) [P]. Informacin relativa a la implicacin de
un profesional sanitario, u organizacin, o combinacin de ambos, en el informe sobre el servicio
asistencial.
- 0..* InformeSobreServicioRelacionado (GPIC_ID = 3.057) [AR]. Conjunto de informacin
relativa a un informe sobre uno o mas servicios que puede estar relacionado a otra actividad.
160
Usado para enlazar una instancia de InformeSobreServicioAsistencial a otra actividad, incluyendo

otro informe sobre servicio.
- 0..* PeticindeServicioRelacionada (GPIC_ID = 3.056) [AR]. Conjunto de informacin relativa
a una peticin de uno o mas servicios que puede estar relacionada a otra actividad. Usada para
enlazar una instancia de PeticinDeServicioAsistencial a otra actividad, incluyendo otra peticin
de servicio.
- 0..* EncuentroRelacionado (GPIC_ID = 3.059) [AR]. Conjunto de informacin relativa a un
encuentro que est relacionado a alguna actividad.
- 0..* ProvisinServicioAsistencial (GPIC_ID = 3.060) [AR]. Informacin relativa al servicio
asistencial.
- 0..* InformacinClnicaRelacionada (GPIC_ID = 3.022) [AR]. Informacin relativa a un item o
coleccin de informacin clnica con alguna relacin a alguna actividad.
- 0..* ObjetoAnalizableUsado (GPIC_ID = 3.002) [P]. Un ObjetoAnalizable con un interfaz
participacin que le permite ser asociado con una actividad.
6.2.1.2.1
ReceptorServicioAsistencial (GPICJD = 2.031) [P]
Iirformacin acerca de una persona, generalmente el paciente (pero tambin animal o grupo de
animales), que es el sujeto de atencin en el informe sobre el servicio asistencial. (*Ya descrito en
aptdo 6.1.1.2.1*).
- SujetodeAtencinReferenciado (GPIC_ID = 2.025) [P]. Se utiliza cuando puede ser identificado
por un identifcador, y no es necesario especificar la naturaleza de su participacin en el servicio o
en su solicitud.
- SujetodeAtencinParticipante (GPIC_ID = 2.026) [P]. Se utiliza cuando es necesario incluir
algunos detalles, p.ej nombre, direccin, fecha de nacimiento, sexo, etc, y no es necesario
especificar la naturaleza de su participacin en el servicio o en su solicitud.
- PacienteParticipanteldentiflcado (GPIC_ID = 2.028) [P]. Se utiliza cuando puede ser
identificado por un identifcador, y s es necesario especificar la naturaleza de su participacin en
el servicio o en su solicitud.)
- PacienteParticipante (GPIC_ID = 2.027) [P]. Se utiliza cuando es necesario incluir algunos
detalles, p.ej nombre, direccin, fecha de nacimiento, sexo, etc, y s es necesario especificar la
naturaleza de su participacin en el servicio o en su solicitud.
- ParteRelacionadaConPacienteParticipante (GPIC_ID = 2.029) [P]. Es un GPIC
ParteReladonadaConSujetoDeAtencin con un interfaz participacin, que provee informacin
acerca de la implicacin de las partes relacionadas en alguna actividad o servicio.
161
En la prctica totalidad de los casos, en el mensaje de informe sobre servicio/teleconsulta puede -y es

suficiente- ser utilizado el GPIC PacienteParticipante.
Es un GPIC InformacinEstndarDePaciente con un interfaz participacin. Se utiliza para el caso en
que es necesario incluir algunos detalles, p.ej nombre, direccin, fecha de nacimiento, sexo, etc, y s
es necesario especificar en el informe la naturaleza de su participacin en el servicio/teleconsulta.
#Se compone de:
- ParticipacinDePersonaNoSanitaria [P]. Informacin relativa a la participacin de un paciente
en una actividad.
- RolDelSujetoDeAtencinPersona [R]. Enlaza la participacin del paciente en una actividad a la
informacin sobre el propio paciente.
- InformacinEstndarDePaciente (GPIC_ID = 2.019) [E]. Informacin acerca de un sujeto
persona usando un conjunto estndar de informacin demogrfica.
En algunos casos excepcionales el GPIC ParteRelacionadaConPacienteParticipante podra ser
necesario utilizarlo. Por simplicidad, no se incluye en el MIM de informe (aptdo 6.2.2).
Es un GPIC ParteRelacionadaConSujetoDeAtencin con un interfaz participacin, que provee
informacin acerca de la implicacin de las partes relacionadas en alguna actividad o servicio.
#Se compone de:
- ParticipacinDePersonaNoSanitaria [P].
- ParteRelacionadaConSujetoDeAtencin (GPICJD = 2.024) [R].
#Se compone de:
- RolDeLaParteRelacionada [R].
- ParteRelacionada [E].
- Persona (GPICJD = 2.006) [E].
- Organizacin (GPICJD = 2.008) [E].
- 0..* JerarquaOrganizacin (GPICJD = 2.010) [R].
- O.MenguajeDeComunicacin (GPICJD = 2.007).
- 0..* PersonaDeContacto (GPIC_ID = 2.012) [R].
6.2.1.2.2
SujetoDePrueba ( G P I C J D = 2.032) [P]
Conjunto de informacin relativa a una persona, animal, u objeto analizable que es el sujeto de una
prueba. (*Ya descrito en aptdo 6.1.1.2.2*).
# Se compone de:
- ParticipacinDelSujetoDePrueba [P]. Informacin acerca de la participacin en alguna prueba real o potencial- del sujeto de la prueba.
162
- RolDelSujetoDePrueba [R]. Enlaza la informacin sobre la participacin del sujeto con la

informacin sobre la identificacin del sujeto.
- SujetoDePrueba [E]. Informacin acerca del sujeto de la prueba.
- SujetoVivoIdentificado (GPIC_ID = 2.014) [E]. Informacin de identificacin relativa a un sujeto
(persona o animal).
- SujetoDeAtencin (GPIC_ID = 2.017) [E]. Informacin acerca de un sujeto de atencin humano
y no-humano. Solo se considera aqu la especializacin SujetoDeAtencinPersona.
- Espcimen (GPIC_ID = 3.003) [E]. Una o mas partes tomadas de un sistema (o subsistema), o
que van a ser tomadas, para proveer informacin sobre ese sistema (o subsistema), o proveer una
base para la toma de decisiones.
- EspdmenManufacturado (GPIC_ID = 3.005) [R]. Informacin acerca de una muestra de
material que es una parte representativa de una sustancia manufacturada.
# Se compone de:
- RolDelObjetoManufacturado [R]. Interfaz rol del GPIC
- EspdmenManufacturado [E]. Informacin acerca de un espcimen manufacturado.
- 0..* OrganizadnReladonada (GPIC_ID = 2.011) [R]. Informacin acerca del fabricante
o suministrador del espcimen (objeto-material) manufacturado.
6.2.1.2.3
ParteSanitariaParticipante ( G P I C J D = 2.053) [P]
Informacin relativa a la implicacin de un profesional sanitario, u organizacin, o combinacin de

ambos, en el informe sobre el servicio asistencial. (*Ya descrito en aptdo 6.1.1.2.3*).
- ProfesionalSanitarioPartidpante (GPIC_ID = 2.049) [P]. Informacin acerca de la parte jugada
en alguna actividad por un profesional cuyos detalles son incluidos.
- ProfesionalPartidpanteldentificado
(GPIC_ID = 2.050) [P]. Informacin acerca de la parte
jugada en alguna actividad por un profesional el cual es referenciado para detalles de

identificacin.
- OrganizadnSanitariaParttdpante
jugada en alguna actividad por una organizacin que es referenciada para detalles de
identificacin.
- OrganizadnPartidpanteldentificada
jugada en alguna actividad por una organizacin cuyos detalles son incluidos.
En el mensaje de informe sobre servicio/teleconsulta en la gran mayora de los casos basta con utilizar
los GPICs participacin en los que solo son necesarias referencias en la identificacin. Son:
163
- ProfesionalParticipanteldentificado (GPICJD = 2.050) [P].

# Se compone de:
- ParttcipacinProfesionalSanitario (GPIC_ID = 2.002) [P]. Detalles de la naturaleza de la
participacin del profesional sanitario en uno o mas aspectos de la provisin del
- ProfesionalSanitarioIdenttflcado (GPIC_ID = 2.034) [R].
Proporciona un medio de
referenciar a un profesional sanitario identificado.

#Se compone de:
- RolDelProfesionalldentificado [R]. Un interfaz tipo rol.
- Profesionalldentiflcado [E]. Informacin de identificacin del profesional sanitario.
- OrganizacinParticipanteldentificada (GPIC_ID = 2.052) [P].
# Se compone de:
- ParticipacinOrganizacinSanitaria [P]. Detalles de la participacin en una actividad de una
organizacin sanitaria identificada.
- OrganizacinSanitarialdentificada (GPIC_ID = 2.037) [R]. Informacin de identificacin de la
organizacin sanitaria.
# Se compone de:
- RolOrganizacinIdentiflcada [R]. Interfaz tipo rol.
- Organizacinidentificada [E]. Informacin de identificacin de la organizacin.
La utilizacin de una u otra especializacin vendr determinada en ltima instancia por
requerimientos locales de los usuarios.
6.2.1.2.4
Conjunto de informacin relativa a un informe sobre uno o mas servicios que puede estar relacionado
a otra actividad. Usada para enlazar una instancia de informe sobre servicio asistencial a otra
actividad, incluyendo otro informe sobre servicio. (*Ya descrito en aptdo 6.1.1.2.8*).
# Se compone de:
- InformeSobreServicioRelacionado [AR].
- InformeSobreServicioAsistencial (GPIC_ID = 3.056) [A].
6.2.1.2.5
PeticindeServicioRelacionada (GPICJD = 3.055) [AR]
Conjunto de informacin relativa a una peticin de uno o mas servicios que puede estar relacionada a
otra actividad. Usada para enlazar una instancia de PeticinDeServicioAsistencial a otra actividad,
incluyendo otra peticin de servicio. (*Ya descrito en aptdo 6.1.1.2.4*).
# Se compone de:
- PeticinDeServicioRelacionada [AR].
164
- PeticinDeServicioAsistencial (GPIC_ID = 3.054) [A].
6.2.1.2.6
EncuentroRelacionado ( G P I C J D = 3.059) [AR]
Conjunto de informacin relativa a un encuentro que est relacionado a alguna actividad. (*Ya
descrito parcialmente en el aptdo 6.1.1.2.9*)
# Se compone de:
- EncuentroAsistencialRelacionado [AR]
- Encuentro (GPIC_ID = 3.058) [A].
Especializacin de ComplejoDelnformacinClnica
(GPIC_ID = 3.018) [A] que proporciona un conjunto de informacin acerca de un encuentro con
un paciente.
- 0..* LugarDeAsistenciaUsado (GPIC_ID = 2.063) [P]. Informacin acerca de un lugar donde los
servicios asistenciales son administrados asociado con el encuentro; generalmente limitada a un
solo lugar, sin embargo se permiten mltiples localizaciones, para permitir la transferencia del
sujeto de atencin durante el encuentro o situaciones de telemedicina.
# Se compone de:
- LugarParticipante [P]. Detalles de la naturaleza de la participacin del lugar.
# Atributos:
cdigoTipo
es
LOC (lugar; ver Anexo 6)
cdigoFimcin
CV
Descripcin de la funcin del lugar
tiempo
IVL<TS>
notaTexto
ED
cdigoEstado
es
Estado actual de la participacin del lugar:
Duracin uso del lugar
ACT(actvo), CAN(cancelado), COM(completado), PEN(pendiente), PLN(planeado),

REQ(solicitado)
- LugarDeAsistencia (GPIC_ID = 2.062) [R]. Informacin acerca de un lugar asistencial que
engloba el lugar anterior.
# Se compone de dos clases:
-RolDelLugar[R]
#Atributos:
cdigoClase
CS
ROL (rol; ver Anexo 5)
CS
PLC (lugar fsico; ver Anexo 3)
cdigoDeterminer M
CS
nombre
ST
Lugar representado por una cadena
id
SET<II>
- LugarDeAsistencia [E]
#Atributos:
cdigoClase
Identifcador lugar
165
6.2.1.2.7
cdigo
CV
Tipo de lugar (p.ej cuidados intensivos)
direccin
Dir.Postal
telecom
SET<telecom>
ProvisinServicioAsistencial ( G P I C J D = 3.060) [AR]
Informacin relativa a la provisin del servicio asistencial. (*Ya descrito parcialmente en aptdo
6.1.1.2.6*).
# Se compone de:
- EnlaceProvisinServicio [AR]. Enlaza detalles de la provisin del servicio con entidades
externas.
- ProvisinServicio [A]. Identificacin del tipo de procedimiento, tratamiento, prueba u otro
servicio.
- ProcedimientoClnico (GPIC_ID = 3.025) [A]. Especializacin de ItemDelnformacinClnica
(GPIC_ID = 3.021) [A] que proporciona una descripcin general de un procedimiento clnico.
- 0..* ProcedimientodePreparacinPaciente (GPIC_ID = 3.026) [AR]. Informa acerca de
condiciones aplicadas o sustancias administradas al paciente, antes o durante el
procedimiento.
- 0..* InformacinCUnicaRelacionada (GPIC_ID = 3.022) [AR]. Informacin relativa a un
tem o coleccin de informacin clnica con alguna relacin al procedimiento clnico.
- 0..* DispositivoUsado (GPIC_ID = 2.059) [P]. Informacin acerca de un equipo o
dispositivo que est siendo usado en la provisin del servicio asistencial.
# Se compone de:
- ParticipacinDispositivo (GPIC_ID = 2.004) [P]. Detalles de la participacin de un
dispositivo en la provisin del servicio/teleconsulta asistencial.
# Atributos:
cdigoTipo
M
cdigoControlContexto 0
es
DEV (dispositivo; ver Anexo 6)
es
Si hereda contexto actividad (ver Anexo 9).
cdigoFuncin
CV
Cdigo para propsito del dispositivo
tiempo
IVL<TS>
cdigoEstado
es
Estado participacin (ver Anexo 7)
id
II
Identificador participacin dispositivo
notaTexto
ED
Intervalo de tiempo de uso
- DispositivoRelacionado (GPIC_ID = 2.057) [R]. Informacin acerca de un dispositivo

o parte de uno, en un rol particular.
#Se compone de:
166
- RolDispositivo [R]. Enlaza la informacin sobre el dispositivo con modelos

externos, en este caso con la participacin en la provisin del servicio/teleconsulta
asistencial.
- Dispositivo (GPIC_ID = 2.055) [E]. Descripcin del dispositivo, o parte de un
equipo mayor.
#Atributos:
cdigoClase
CS
DEV (dispositivo; ver Anexo 3)
cdigodeterminador M
CS
cdigo
CV
Tipo de dispositivo
desc
ST
nombreModeloFabr O
ST
Nombre del modelo
id
II
Nmero de serie del dispositivo
cantidad
PQ
nmero de objetos
tiempoUltimaCal
TS
fecha-hora de la ltima calibracin
- PettcinPrueba (GPIC_ID = 3.030) [A]. Especiahzacin de ItemDelnformacinClnica

(GPIC_ID = 3.021) [A] que proporciona un conjunto de informacin que puede ser usada para
definir una prueba especfica de laboratorio.
6.2.1.2.8
InformacinClnicaRelacionada (GPICJD = 3.022) [AR]
Informacin relativa a un item o coleccin de informacin clica con alguna relacin a alguna
actividad.
# Se compone de:
- EnlacelnformacinRelacionada [AR]. Enlaza el conjunto de informacin clnica con la actividad
relacionada.
- InformacinClnica (GPIC_ID = 3.017) [A]. Descripcin genrica de los items o complejos
(contenedores) de informacin clnica.
- ComplejoDeInformacinClnica (GPICJD = 3.018) [A].
- AgrupacinDelnformacinClnica
(GPIC_ID = 3.019) [A]. Proporciona un contexto
compartido para el contenido de la informacin dentro del complejo.

- ItemDelnformacinClnica (GPIC_ID = 3.021) [A]. Informacin acerca de un item de
informacin clnica que en un cierto contexto es considerado indivisible.
ObservacinClnica
(GPIC_ID
3.023)
[A].
Especializacin
de
ItemDelnformacinClnica que proporciona una descripcin general de una observacin

clnica.
167
ProcedimientoClnico
(GPIC_ID
3.025)
[A].
Especializacin
de
ItemDelnformacinClnica que proporciona una descripcin general de un procedimiento

clnico.
- PeticinPrueba (GPIC_ID = 3.030) [A]. Especializacin de ItemDelnformacinClnica
que proporciona un conjunto de informacin que puede ser usada para definir una prueba
especfica (p.ej de laboratorio).
- Consejo (GPIC_ID = 3.028) [A]. Especializacin de ItemDelirformacinClnica que
provee informacin detallada relativa al consejo o la advertencia dados al paciente o
persona/profesional relacionados, que estn asociados a la provisin del servicio.
- 0..1 PacienteParticipanteldentiflcado (GPIC_ID = 2.028) [P]. Informacin acerca de la
participacin del paciente en el consejo.
- 0..* ParteRelacionadaConPacienteParticipante (GPIC_ID=2.029) [P].
Informacin
acerca de la participacin de una persona no-sanitaria, u organizacin, o ambos, con

respecto al consejo.
- 0..* InformacinClnicaRelacionada (GPIC_ID = 3.022) [AR]. tems o grupos de
tems de informacin clnica que son relevantes al consejo.
- ResultadoPrueba (GPIC_ID = 3.032) [A]. Especializacin de ItemDelnformacinClnica
que proporciona un conjunto de informacin incluyendo todo lo esencial o titil, relevante al
resultado de la prueba clnica.
# Atributos:
cdigoClase
CS
Naturaleza resultado (ver Anexo 10)
cdigoMood
CS
cdigoEstado
CS
cdigo
CD
Tipo de prueba
id
SET<II>
Uno o mas identifcadores para la instancia
tiempoActividad
IVL<TS>
tiempoEfectivo
IVL<TS>
Ventana tiempo en el que se obtuvo el
valor
ANY
del resultado de la prueba
resultado
P.ej: ST (cadena), PQ (cantidad fsica), TS (punto en
el tiempo), CD (cdigo descriptor), CV (cdigo valor), IVL<PQ> (rango de cantidades fsicas),

el tiempo)
cdigolnterpretacin
CV
(p.ej 'anormal')
indlndependiente O
BL
Si puede ser independiente
cdigolnterpretacin
CV
"Normalidad" resultado
168
cdigoMtodo
SET<CV>
texto
ED
Detalles
adicionales
adjuntar
multimedia
informacin
- 0..* ReferenciaNormalidad (GPIC_ID = 3.034) [AR]. Descripcin de un rango de
normalidad, expresado como un rango de medidas numricas o en forma textual. Lxs
lmites pueden aplicarse a una poblacin particular y pueden ser de un tipo especificado.
- 0..* ResultadoPruebaRelacionado (GPIC_ID = 3.033) [AR]. Informacin acerca de
otro resultado que tiene alguna relacin con este resultado.
- 0..* PeticinPruebaRelacionada (GPIC_ID = 3.031) [AR]. Informacin acerca de
peticiones que tienen alguan relacin con este resultado.
- 0..1 EspecificacinPrueba (GPIC_ID = 3.036) [AR]. Detalles acerca de cmo ha sido
llevada a cabo la prueba.
- 0..* ObjetoAmlizableUsado
(GPICJD = 3.002) [P].
Informacin acerca de, o
referencia a, un objeto analizable con un interfaz participacin que le permite ser

asociado con xma actividad y que est asociado con este resultado.
# Se compone de:
- ParticipacinObjetoAnalizable [?]. Enlaza el objeto analizable usado con una
actividad.
- RolObjetoAnalizable [R]. Enlaza la informacin sobre el objeto analizable a un
modelo mayor y proporciona su contexto cuando se juntan varios.
- ObjetoAnalizable [E].
-Espcimen (GPICJD = 3.003) [E].
- ProductodeEstudio (GPICJD = 3.009) [E].
169
6.2.2 Modelo de informacin del mensaje (MIM) de informe sobre teleconsulta

En la figura 6.8 puede verse el modelo de informacin del mensaje de informe sobre teleconsulta.
Persona
GPIC ZUm
Organizacin
GPIC 2006
EncuentD
GPIC 3.056
SujeloVua
Idsnbcado
J^ SujsloDfPruBba
GPIC !,Q14
SujebDeAtetcln
GPIC 1017
Espcimen
QPIC 3,003
EspecImenManifattu
rado GPIC 3.005
PctcinSenio
A$isteflcial
QPIC 3 054
ProceifiiileiitQprepaiadin
Paciente GPIC 3.026
ItonnacinCInicaRe
lacionnia GPIC 3.022
AgnjpacifnDe
InfonlaciilnCllnica
GPIC 3.019
InfonnadnCUnica
Reiadortada
GPIC 3.022
Paite RelaonadaCon
RolObietaAniJizable
GPIC 3.001
PaciertePaiticipanie
(GPIC 2.029)
ObsefvacinClinica
ResultadoPrueba
GPIC 3.023
j RefeienciaNDiraalldad
-iol
GPIC 3.032
PaiticipadnO IjetnMali
z a b k (de GPIC 3.002)
GPIC 3.034
specficacinPiueba
GPIC 3.031
Figura 6.8 MIM mensaje de informe sobre teleconsulta

1
1
TransimsinMens^je
Mensaje
tiempoCreacin (M)
Fecha/hora en la que el sistema remitente cre la transmisin.
id
(M)
O..*"
Mens^jeRelacionado
Identificador del tipo de contenido del mensaje relacionado
idTipoEstructura (O)
Mens aj eRelacionado
tiempoCreacin (M)
Fecha/hora en la que el sistema remitente cre la transmisin.
id
(M)
2..*
ParteComimicante
FuncinComunicacin
cdigoTipo
(M)
P.ej SND(remitente), RCV(receptor), RSP(respuesta a)
telecom
(O)
telecom
ParteComunican te.
- Persona (GPIC J D = 2.006) [E]
cdigoClase
(M)
id
(M)
Identificador nico de la persona
nombre
(O)
Uno o mas nombres para confirmar la identidad de la persona
direccin
(O)
170
telecom
(O)
0..* LenguajeDeComunicacin (GPIC_ID = 2.007).
- Organizacin (GPICJD = 2.008) [E]
cdigoClase
(M)
cdigoDeterminador(M)Elegido de Anexo 4; p.ej INST (instancia de); KIND (tipo)
nombre
(O)
id
(O)
cdigo
(O)
desc
(O)
direccin
(O)
telecom
(O)
0..* JerarquaOrganizacin (GPICJD = 2.010) [R]
0.. * LenguajeDeComunicacin (GPICJD = 2.007)
0..* PersonaDeContacto (GPICJD = 2.012) [R]
- Dispositivo (GPIC_ID = 2.055) (No incluido)
cdigoClase
(M)
Elegido de Anexo 5; p.ej PROV(proveedor)
cd
(O)
Cdigo que representa la especialidad mdica
cdigoPuestoTrabajo(O)
cdigoTtuloPuestoTrabajo(O) Ttulo del puesto de trabajo
0.1
EventoDeControl
idTipoEstructura(O)
Identificador del tipo de contenido del mensaje tomado de un
catlogo de interacciones
cdigoRespuesta(O)
P.ej C(completo), D(detalle), E(excepcin), F(confirmacin),
R(modifcacin), X(ninguna).
CdigoLenguaje(O)
Lenguaje principal en el contenido
1 InfonneSobreServieio
1 InformeSobreServicioAsistencial (GPICJD = 3.056) [A]
cdigoClase
(M)
Elegido de Anexo 10; p.ej DOCCLIN(documento clnico),
DOCSECr(seccin de un documento CDA), etc.
cdigoMood
(M)
Elegido de Anexo 11; DEF(definicin del servicio)
cdigoEstado
(O)
Elegido de Anexo 12; p.ej nuevo, normal, etc
cdigo
(O)
Identificacin tipo de servicio informado
id
(O)
Uno o mas identifcadores para la instancia de informe
tiempoActividad (O)
Fecha y hora en que el informe finaliz
cdigo_prioridad(0)
texto
(O)
Comentario adjunto al informe
0..1 ReceptorServicio
0..1 ReceptorServicioAsistencial (GPIC_ID = 2.031) [P]
- PacienteParticipante (GPIC_ID = 2.027) [P]
ParticipacinDePersonaNoSanitaria [P].
cdigoTipo M
es
Casi siempre PATSBJ (sujeto paciente; ver Anexo 6)
RolDelSujetoDeAtencinPersona [R].
cdigoClase M
CS
InformacinEstndarDePaciente (GPICJD = 2.019) [E]
cdigoClase (M)
id
(M)
nombre
(O)
direccin
(O)
telecom
(O)
Una o mas direcciones telecomunicaciones (o partes)
cdigoAdminGnero(O)
P.ej hombre, mujer, inter, desconocido
tiempoNaciniiento(O) Fecha y hora del nacimiento
cdigoEstadoMarital(O)
P.ej casado, separado, etc
cdigoHabitat(O)
Descripcin lugar de dnde viene
cdigoRiesgo (O)
Riesgo asociado (embarazada, inmunodeprimida, etc)
171
cciigoGrupoEtnico(O)
0..1 SujetoDePrueba (GPIC_ID = 2.032) [P]
ParticipacinDelSujetoDePrueba [P]
cdigoTipo (M)
Elegido de Anexo 6; p.ej SBJ (sujeto)
notaTexto
(O)
Anotacin en texto libre; puede usarse para especificar disponibilidad
cdigoEstado (O)
RolDelSujetoDePrueba [R]
cdigoClase (M)
SujetoDePrueba [E].
- SujetoVivoIdentifcado (GPIC_ID = 2.014) [E]
- SujetoDeAtencin (GPIC_ID = 2.017) [E]. Solo se considera SujetoDeAtencinPersona.
- Espcimen (GPICJD = 3.003) [E]
- EspcimenManufacturado (GPICJD = 3.005) [R]
0..* OrganizacinRelacionada (GPICJD = 2.011) [R]
0..* ParteParticipante
0..* ParteSanitariaParticipante (GPICJD = 2.053) [P]
- ProfesionalParticipanteldentificado (GPICJD = 2.050) [P]
ProfesionalSanitarioIdentificado (GPIC_ID = 2.034) [R]
RolDelProfesionalIdentificado [R]
cdigoClase (M)
Profesionalldentificado [E]
cdigoClase (M)
cdigoDeterminador(M)
id
(M)
Identificador del profesional
nombre
(O)
Nombre(s) para confirmar identidad del profesional
- OrganizacinParticipanteldentificada (GPICJD = 2.052) [P]
ParticipacinOrganizacinSanitaria [P]
OrganizacinSanitarialdentificada (GPICJD = 2.037) [R]
RolOrganizacinldentificada [R]
cdigoClase (M)
Organizacinldentificada [E]
cdigoClase (M)
cdigoDeterminador(M)
Elegido de Anexo 4; p.ej INST (instancia de)
id
(M)
nombre
(O)
Nombre por el que se conoce la organizacin
0..* InformesRelacionados
0..* InformeSobreServicioRelacionado (GPICJD = 3.057) [AR]
InformeSobreServicioRelacionado [AR]
cdigoTipo
(M)
Elegido de Anexo 13; p.ej SEQL(secuela)
nmeroSecuencia (O)
O..* PeticinDeServico
0..* PeticinDeServicioRelacionada (GPICJD = 3.055) [AR]
PeticinDeServicioRelacionada [AR]
cdigoTipo
(M)
Elegido de Anexo 13; p.ej CAUS(es causa de), PREV(tiene
instada previa), RPLC(reemplaza), SUCC(se aade), etc
nmeroSecuencia (O)
cdigoControlContexto(O) Elegido de Anexo 14.
0..* Encuentro
EncuentroAsistencialRelacionado [AR]
cdigoTipo
(M)
Elegido de Anexo 13; p.ej DRIV(derivado de)
nmeroSecuencia (O)
172
cdigoControlContexto(O) Elegido de Anexo 14; p.ej I(hereda)

Encuentro (GPICJD = 3.058) [A]
Elegido de Anexo 10; p.ej ENC (encuentro)
cdigoClase
(M)
Elegido de Anexo 11; APT(cita, compromiso)
cdigoMood
(M)
Elegido de Anexo 12; CMP(conq)letado)
cdigoEstado
(O)
cdigo
(O)
id
(O)
Fecha-hora comienzo
tiempoActividad (O)
Duracin encuentro
tiempoEfectivo
(O)
lugarDeAtencin (O)
texto
(O)
0. * LugarDeAsistenciaUsado (GPICJD = 2.063) [P]
LugarParticipante [P].
Elegido de Anexo 6; p.ej LOC (lugar)
cdigoTipo
(M)
Descripcin de la funcin del lugar
cdigoFuncin (O)
Duracin uso del lugar
tiempo
(O)
notaTexto
(O)
Estado actual de la participacin del lugar: ACT(activo),
cdigoEstado (O)
CAN(cancelado), COM(completado), PEN(pendiente), PLN(planeado), REQ(solicitado)
LugarDeAsistencia (GPICJD = 2.062) [R]
RolDelLugar [R]
cdigoClase (M)
LugarDeAsistencia [E]
cdigoClase
(M)
Elegido de Anexo 3; p.ej PLC (lugar fsico)
cdigoDeterminer (M)
Elegido de Anexo 4; p.ej INST (instancia de)
nombre
(O)
Lugar representado por una cadena
id
(O)
Identificador lugar
(O)
Tipo de lugar (p.ej cuidados intensivos)
cdigo
direccin
(O)
Direccin postal
(O)
Direccin electrnica
telecom
0..* ProvisinServico
0..* ProvisinServicioAsistencial (GPICJD = 3.060) [AR]
EnlaceProvisinServicio [AR]
cdigoTipo
(M)
cdigoControlContexto(0)Elegido de Anexo 14; p.ej N(no hereda)
ProvisitiServicio [A].
cdigoClase
(M)
Elegido de Anexo 10; p.ej PROC(procedimiento)
cdigoMood (M)
Elegido de Anexo 11; p.ej APT(compromiso)
cdigoEstado (O)
id
Identificadores del procedimiento
(O)
cdigo
Identificacin
tipo de procedimiento
(O)
texto
(O)
Mtodos del procedimiento
cdigoMtodo (O)
Lugar procedimiento
cdigoSitio
(O)
Ventana tiempo procedimiento
tiempoActividad(0)
tiempoEfectivo (O)
P.ej
Alta prior, urgente, rutina
cdigoPrioridad(0)
0.. InformacinClnicaRelacionada (GPICJD = 3.022) [AR]
0.. ProcedimientodePreparacinPaciente (GPIC_ID = 3.026) [AR]
0.. DispositivoUsado (GPIC_ID = 2.059) [P]
ParticipacinDispositivo (GPICJD = 2.004) [P]
cdigoTipo
(M)
Elegido de Anexo 6; p.ej DEV (dispositivo)
cdigoControlContexto(0)Elegido de Anexo 9; p.ej l(hereda).
cdigoFuncin (O)
Cdigo para propsito del dispositivo
tiempo
(O)
Intervalo de tiempo de uso
173
cdigoEstado
(O)
id
(O)
Identificador participacin dispositivo
notaTexto
(O)
DispositivoRelacionado (GPICJD = 2.057) [R]
RolDispositivo [R].
Dispositivo (GPICJD = 2.055) [E]
cdigoClase
(M)
Elegido de Anexo 3; p.ej DEV (dispositivo)
Elegido de Anexo 4; p.ej INST, KIND
cdigo
(M)
Tipo de dispositivo
desc
(O)
nombreModeloFabr (O)
Nombre del modelo
id
(O)
Nmero de serie del dispositivo
cantidad
(O)
nmero de objetos
tiempoUltimaCal
(O)
fecha-hora de la ltima calibracin
O..* InformaciiiCliiica
EnlacelnformacinRelacionada [AR]
cdigoTipo
(M)
Elegido de Anexo 13; p.ej REFR(se refiere a)
cdigoControlContexto(O) Elegido de Anexo 14; p.ej I(hereda)
InformacinClnica (GPICJD = 3.017) [A].
- ComplejoDelnformacinClnica (GPICJD = 3.018) [A]
- AgrupacinDelnformacinClnica (GPICJD = 3.019) [A]
cdigoClase
(M)
Elegido de Anexo 10; p.ej DOCCLIN(documento clnico)
cdigoMood (M)
Elegido de Anexo 11); p.ej DEF(definicin servicio)
cdigoEstado (O)
Elegido de Anexo 12; p.ej SUS(suspendido)
cdigoNivel
(O)
Nivel que ocupa en la jerarqua de la estructura
cdigoLenguaj e(0)
cdigo
(O)
id
(O)
Uno o mas identifcadores de esta agrupacin de informacin
tiempoActividad(0)
tiempoEfectivo (O)
Ventana tiempo en el que ha estado en este estado
texto
(O)
0..* ComplejoDelnformacinClnicaRelacionado (GPICJD = 3.020) [AR]
- ItemDelnformacinClnica (GPICJD = 3.021) [A]
- ObservacinClnica (GPICJD = 3.023) [A]
- PeticinPrueba (GPIC_ID = 3.030) [A]
cdigoClase
(M)
Elegido de Anexo 10; p.ej CONS (consentimiento informado)
cdigoMood (M)
cdigoEstado (O)
cdigo
(O)
Identificacin tipo de consentimiento
texto
(O)
Resumen o transcripcin del consentimiento
tiempoActividad(0)
Ocurrencia del consentimiento
cdigoConfidencialidad(O)
0..1 PacienteParticipanteldentifcado (GPICJD = 2.028) [P]
0..* ParteRelacionadaConPacienteParticipante(GPICJD=2.029) [P]
- ResultadoPrueba (GPIC_ID = 3.032) [A]
cdigoClase
(M)
Elegido de Anexo 10; p.ej TBLCOLGP(grupo colum tabla)
cdigoMood (M)
cdigoEstado (O)
cdigo
(O)
Tipo de prueba
id
(M)
Uno o mas identifcadores de la instancia del resultado
174
tempoActividad(0)
tiempoEfectivo (O)
Ventana tiempo en el que se obtuvo el resultado
valor
(O)
tienq)o), CD (cdigo descriptor), CV (cdigo valor), IVL<PQ> (rango de cantidades fsicas),
el tiempo)
P.ej anormal
indlndq)endiente(0) Si puede ser independiente
Normalidad del resultado
cdigoMtodo (O)
texto
(O)
Detalles adicionales o adjuntar multimedia informacin
0..* ReferenciaNormalidad (GPICJD = 3.034) [AR]
0..* ResultadoPruebaRelacionado (GPIC_ID = 3.033) [AR]
0..* PeticinPruebaRelacionada (GPICJD = 3.031) [AR]
0..1 EspecificacinPrueba (GPICJD = 3.036) [AR]
0..* ObjetoAnalizableUsado (GPIC_ID = 3.002) [P]
ParticipacinObjetoAnalizable [P]
cdigoTipo
(M)
Elegido de Anexo 6; p.ej CON (consultor)
cdigoControlContexto(O)
Elegido de Anexo 9; p.ej N(no hereda)
cdigoFuncin (O)
Cdigo para funcin o propsito
cdigoModo
(O)
P.ej. local o remoto
tiempo
(O)
notaTexto
(O)
ObjetoAnalizable GPICJD = 3.001) [R]
RolObjetoAnalizable [R]
cdigoClase (M)
nmeroPosicin(0) Cronologa en el orden de varios
cdigo
(O)
Proporciona contexto al rol del objeto
ObjetoAnalizable [E]
- ProductodeEstiidio (GPICJD = 3.009) [E]
175
6.2.3 Descripcin jerrquica del mensaje (DJM) de informe sobre teleconsulta
'
_.
im^^:
r! l
g,...
1H
1 1
h^
b:.,,-^.
f T ilTiIrtBfl'ril ^ * ' - * * * ^ ' - ^ ' - -
Ocur min Nombre GPIC o clase

max
TransimsinMensîe
l
1
0..*
MensîeRelaconado
Mensa] eRelacionado
2..*
ParteComunicante
FuncinComunicacin
ParteComunicante.
Persona
Organizacin
RolD eP arteComunicante
Lenguaj eD eComunicacin
0..*
.
GPIC ID
1..*
1
Cabecera mensaje peticin teleconsulta

Tipo de contenido
Identificar otros mensajes relacionados
2.006
2.008
2.007
EventoDeCoDtFol
InformeSobreServicio
InformeSobreServicioAsstencal
3.056
0..1
0..1
ReceptorServicio
ReceptorServicioAsistencial
PacienteParticipante
ParticipacinDePersonaNoSanitaria
RolDelSujetoDeAtencinPersona
InformacinEstndarDePaciente
Usado para
2.031
2.027
2.019
Remitente, receptor, respuesta a

Solo una de las dos especializaciones para cada parte
Informacin demogrfica del profesional sanitario
Identificar la organizacin del profesional
Especialidad mdica, puesto de trabajo
Lenguaje principal profesionales
Describir el informe que un profesional u organizacin
sanitaria emite sobre el servicio/teleconsulta asistencia!
que ha llevado a cabo
Naturaleza del servicio
Estado del informe (preliminar, final)
Identificacin tipo de informe
Tiempo Actividad
Prioridad del informe
Comentarios
Casi todos los casos. En algunas excepciones puede

usarse ParteRelacionadaConPacienteParticipante (no se
incluye en el modelo).
Incluir algunos detalles sobre el receptor y especificar
en el informe la naturaleza de su participacin en el
servicio/teleconsulta.
176
0..1
:
'
.
^
:
OH^^B
B
SujetoDePrueba
PartcipacinD elSuj etoD ePru eb a
SujetoDePrueba
Suj eto Vivoldentifica do
Suj etoD eAtencin
Espcimen
EspcimenManufacturado
2.014
2.017
3.003
3.005
Para aquellos casos en que el sujeto de atencin no ha

participado en la teleconsulla.
En cada caso concreto solo se usa una de las cuatro
especializad ones
Solo se necesita identificacin
Solo se considera sujeto de atencin persona
En la gran mayora de los casos de servicios=pruebas
Espcimen elaborado, casi siempre auxiliar
2.032
0..*
0..*
0..*
OrganizacinRelacionada
ParteParticipante
ParteSanitariaPa rticipante
2.011
Organizacin fabricante del espcimen manufacturado
2.053
0..*
ProfesionalParticipanteldentifcado
ParticipacinProfesionalSanitario
ProfesionalS anitariol dentifica do
RolDelProfesionalIdentificado
Profesionalldentifcado
OrganizacinParticipantel dentificada
ParticipacinOrganizacinS ailara
OrganizacinS ailar ialdentificada
RolOrganizacinl dentif ica da
Organizacinl dentificada
InformesRelacionados
Informes obreS er vicio As istencial
PeticinDeServicio
Encuentro
Encu entroR elacionado
Encu entro AsistencialR el acionado
Encuentro
2.050
2.002
2.034
En la gran mayora de los casos solo son necesarias

referencias en la identificacin. Una de las dos
especializaciones (Profesional?articipanteldentifcado,
OrganizacinParticipanteldentificada)
Profesional solo referenciado para detalles de
identificacin
1^^^H
0..*
0*
0..*
"
0..*
0..*
^^^
0..*
0..*
2.052
Profesional solo referenciada para detalles de

identificacin
2.037
3.057
Enlazar una instancia de informe sobre servicio a otra

actividad, que incluye un informe sobre otro servicio
3.056
3.055

actividad, que incluye una peticin de servicio
3.054
3.059

activida4 que incluye un encuentro relacionado
3.058
177
Capiulo 6. Resultados
^^
H^^
0..*
0..*
0..*
3.060
0..*
LugarParticipante
LugarDe Asistencia
RolDelLugar
LugarDe Asistencia
ProvisinServicio
ProvisinServicioAsistencial
EnlaceProvisinS ervicio
ProvisinServicio
ProcedimientoClnico
0..*
ProcedimientodePreparacinPaciente
3.026
0..*
DispositivoUsado
ParticipacinD ispos itivo
DispositivoRelacionado
RolDispositivo
Dispositivo
PeticinPrueba
InformacinClnica
InformacinClnica
ComplejoDelnformacinClnica
AgrupacinD einformacinClni
ca
ComplejoDeInformacinClnicaRelacio
nado
ItemDelnformacin Clnica
ObservacinClnica
ProcedimientoClnico
PeticinPrueba
Consejo
2.059
2.004
2.057
',
JH^
..riiuiEi^
0..*
0..*
^H
î9
0..*
0..*
'.
2.063
Informacin adicional sobre el lugar asociado al

encuentro que sea relevante para la teleconsulta
2.062
3.025
3.022
Considerar la teleconsulta como un procedimiento.

Incluye tambin alguna peticin de prueba relacionada.
Enlaza detalles de la provisin del servicio con
entidades externas.
Informacin relativa al procedimiento o referencia a
tems de informacin relacionada
Condiciones aplicadas o sustancias administradas al
paciente
Descripcin del equipo o una parte de l, usado en el
procedimiento
2.055
3.030
3.022
Un tem o complejo de informacin clnica con alguna

relacin al servicio/teleconsulta. En cada caso concreto
solo se usa una de las dos especializaciones.
3.019
3.022
3.020
Proporcionar un contexto compartido para el contenido

de la informacin dentro del complejo
Otros tems de inters relacionados con la agrupacin
Otra agrupacin dentro del mismo complejo
3.023
3.025
3.030
3.028
Contexto considerado indivisible.

Descripcin general de una observacin clnica
Descripcin general de un procedimiento.
Descripcin general de una prueba.
Descripcin general de un consejo.
178
1
1K
V'
tmatUK
0..1
0..*
0..*
0..*
0..*
0..*
0..1
0..*
PacienteParticipanteldentificado
ParteRelacionadaConPacienteParticipan
te
InformacinClni caRelacionada
2.028
2.029
ResultadoPrueba
ReferenciaNormalidad
ResultadoPruebaRelacionado
PeticinPruebaRelacionada
EspecificacinPrueba
Objeto AnalizableUsado
P articipacinOb j eto Analizabl e
RolObj eto Analizable
ObjetoAnalizable
Espcimen
ProductoDeEstudio
3.032
3.034
3.033
3.031
3.036
3.002
3.022
Participacin del paciente en el consejo

Participacin de persona no-sanitaria u organizacin en
el consejo
tems 0 agrupaciones relevantes al consejo o referencia
a tems de informacin relacionada
Descripcin general de resultados de una prueba
Establecimiento lmites rango vlido
Otro resultado relacionado
Otras peticiones de prueba relacionadas
Detalles sobre cmo se ha llevado a cabo la prueba
Descripcin del objeto usado en la prueba asociado con
el resultado de la misma.
3.003
3.009
179
6.3 Arquetipo peticin de teleconsulta

En este apartado se especifica en ADL vO.9 el arquetipo peticin de servicio basado en el GPIC_ID =
3.054 y otros GPICs relacionados, teniendo como modelo de referencia el subconjunto de RIM sobre
el que estn basados los GPICs.
Con nimo demostrador se han especificado y restringido tambin los tipos de datos, cosa infrecuente
normalmente, pero como se advirti en el captulo anterior, se han utilizado los tipos de datos del
CEN, lo que haca necesario una mayor concreccin para una mayor claridad.
archetype
cen-gpics-CareServiceRequest.core_CareServiceRequest.v01
concept
[atOOOO]
~ Peticin de servicio (teleconsulta)
description
author = <"Carlos H. Salvador">
submission = <
organisation = <"LBT-HUPH">
date = <2004-03-10>
>
versin = <"version 1.0">
status = <"draft">
description("es") = <
purpose = <"Describe la peticin de una teleconsulta como servicio asistencial">
use = <"">
misuse = <"">
>
adl_version = <"0.9">
rights = <"">
defnition
PeticinDeServcioAsistencial[atOOOO] matches {
-Peticin de servido (teleconsulta)
cdigoClase matches {
- Clase de servicio
CS_ITEM_CAT[at0001] matches {
nombreEsquemaCdigo matches {"CENrltemCategory"}
versinEsquemaCdigo matdies {/.*/}
valorCdigo matdies {"PROC"}
~ Elegido de Anexo 10
}
}
cdigoMood matches {
~ Interpretacin del servicio
CS_nEM_CAT[at0002] matches {
nombreEsquemaCdigo matches {"CEN:ItemCategory"}
versinEsquemaCdigo matches {/.*/}
valorCdigo matches {"ORD" | "APT'}
~ Elegidos de Anexo 11
}
}
cdigoEstado existence matches {0..1} matches {
- Estado de la actividad
CS_ITEM_CAT[at0003] matches {
nombreEsquemaCdigo matches {"CEN:ItemCategory"}
versinEsquemaCdigo matches {/.*/}
valorCdigo matches {"NEW"}
- Elegido de Anexo 12
}
}
cdigo existence matdies {0..1} matches {
~ Cdigo de la actividad
CD[at0004] matches!
nombreDisplay matches{
[acOOOl,
~ estudio electrofisiolgico
ac0002]
~ ablacin
}
valorCdigo matches {
[local::
atlOOO,
~ estudio
atlOOl]
- ablacin
}
}
180
}
id existence matches {0..1} cardinality matches {0..* ; unique} matches { Identificacin

II[at0005] matches{
Identificacin unvoca
raz matches {
OID[at0006] matdies {
Identificador nico ODD de la
od matches {/([0-9]*\.)*/}
peticin
}
}
- nico dentro del
extensin existence matches {0..1} matches {/.*/}
espacio de nombres de la autoridad de asignacin
nombreAutoridadAsignadn existence matches {0..1} matches {1*1} Entendible por humano
tiempoValided existence matdies{0}
- Valido siempre
}
}
tiempoActividad existence matches {0..1} matchesj

IVL[TS][at0007] matches{
duracin matches{P7d0h0m0s}
Plazo comienzo
Atencin de peticin antes de una semana (ejemplo)
}
Prioridad
cdigoPrioridad existence matches {0..1} matches {
CV[at0008] matches{
nombreDisplay matches{
[acOOlO,
maxma urgenaa
acOOll,
urgente
ac0012]
rutina
}
valorCdigo matches {
[local::
-alta
atlOlO,
media
atlOll,
baja
atl012]
}
}
}
Descripcin auxiliar
texto existence matches {0..1} matches {
ED[at0009] matdies {
- Slo texto
tipoMedia matches {"text/plain"}
}
}
receptor matches{
use_ardietype ReceptorServidoAsistendal matches {
identifier matches {"cen-gpics-entity.care_service_recipient.*"}
}
}
professional cardinality matches {1..*; unique} matches {
use_archetype ParteSanitariaPartidpante matches{
identifier matches {"cen-gpics-participation.participating_healthcare_professional. *"}
}
}
servidos existence matches {0..1} cardinality matches {0..*; unique} matches {
use_archetype PetidnDeServidoReladonado matches{
identifier matches {"cen-gpics-actsrelation.related_service_request.*"}
}
}
objeto existence matches {0..1} cardinality matdies {0..*; unique} matches {
use_archetype ObjetoAnalizableUsado matches{
identifier matches {"cen-gpics-partidpation.analysable_object_in_use.*"}
}
}
provisin existence matches {0..1} cardinality matches {0..*; unique} matches {
use_archetype ProvisinServidoAsistendal matdies{
identifier matches {"cen-gpics-actsrelation.care_service_delivery.*"}
}
}
informadn existence matches {0..1} cardinality matdies {0..*; unique} matches {
use_archetype ProcedimientoClnico matdiesj
identifier matches {"cen-gpics-act.clinical_procedure.*"}
}
181
}
informes existence matches {0..1} cardinality matches {0..*; umque} matches {
use_archetype InfonneSobreServidoRelacionado matches{
identifier matches {"cen-gpics-actsrelation.related_service_report.*"}
}
}
encuentro existence matdies {0..1} cardinahty matdies {0..*; unique} matches {
use_ardietype EncuentroAsistendalReladonado matches{
identifier matches {"cen-gpics-actsrelation.related_care_encounter.*"}
}
}
}
ontology
primary_language = <"es">
term_definitions("es") = <
items("atO0OO") = ctext = <"Peticin servicio teleconsulta">; description = <"Ejemplo peticin de
servicio para teleconsulta"
items("at0001") = <text = <"aase de servicio">;description = <"CEN CS_ITEM_CAT: Tipo de
actividad"
items("at0002") = <text = <"Interpretacin del servicio">; description = <"CEN CS_ITEM_CAT:
Interpretacin tipo de actividad"
items("at0003") = ctext = <"Estado de la actividad">; description = <"CEN CS_rrEM_CAT: Estado de
la actividad"
items("at0004") = <text = <"Cdigo de la actividad">; description = <"CEN CD: Identificacin del
servicio solicitado"
items("at0005") = <text = <"Identficacin">; description = <"CEN II: Identificacin de teleconsulta"
items("at0006") = ctext = <"Identificacn unvoca">; description = <"CEN OD: Identificador OD
unvoco de la peticin"
items("at0007") = ctext = <"Plazo comienzo">; description = <"CEN rVL<TS>: Inetervalo de comienzo
de la actividad"
items("at0008") = ctext = <"Prioridad">; description = <"CEN CV: Indicador prioridad peticin"
items("at0009") = ctext = <"Descripcin auxiliar">; description = <"CEN ED: Descripcin auxiliar "
items("atlOOO") = <text = <"Estudio">; description = <"Cdigo tipo de estudio solicitado"
items("atlCI01") = ctext = <"Ablacin">; description = <"Cdigo tipo de estudio solicitado"
items("atl010") = ctext = <"Alta">; description = <"Nivel de urgencia de la peticin"
items("atl011") = ctext = <"Media">; description = <" Nivel de urgencia de la peticin "
items("atl012") = <text = <"Baja">; desaiption = <" Nivel de urgencia de la peticin "
>
constraint_defimtions("es") = <
items("ac0001") = <text = <"Estudio elctrofisiolgico">; description = <"Nombre visual del tipo de
estudio solicitado"
items("ac0002") = ctext = <"AbIadn">; description = <" Nombre visual del tipo de estudio solicitado
"
items("ac0010") = <text = <"Mxima urgencia">; description = <"Descripcin visual del nivel de
prioridad"
items("ac0011") = <text = <"Urgente">; description = <" Descripcin visual del nivel de prioridad "
items("ac0012") = <text = <"Rutina">; description = <" Descripcin visual del nivel de prioridad "
>
6.4 Arquetipo informe sobre teleconsulta

En este apartado se especifica en ADL vO.9 el arquetipo informe sobre servicio basado en el GPIC_ID
= 3.056 y otros GPICs relacionados, teniendo como modelo de referencia el subconjunto de RIM
sobre el que estn basados los GPICs.
Con nimo demostrador de las distintas (solo en apariencia) formas de editar arquetipos se han
especificado las restricciones sobre los atributos de la clase principal de forma diferente al caso
anterior.
arcietype
cen-gpics-CareServiceReport.core_CareServiceReport.v01
concept
182
[atOOOO]
- Informe sobre servicio (teleconsulta)
desCTption
author = <"Carlos H. Salvador">
submission = <
date = <2004-03-10>
>
status = <"dra">
purpose = <"DesCTbe el informe sobre ima teleconsulta considerada como servicio">
use = <"">
misuse = <"">
>
rights = <"">
definition
InformeSobreServicioAsistencial[atOO(X)] matches {
-- Informe sobre servicio (teleconsulta)
cdigoClase matches {
~ Clase de servicio
CS_ITEM_CAT matches {[acOOOl]}
-- DOCCLIN (elegido de anexo 10)
}
cdigoMood matches {
- Interpretacin del servicio
CS_ITEM_CAT matches {[ac0002]}
-- DEF (elegido de anexo 11)
}
cdigoEstado existence matches {0..1} matches {
~ Estado de la actividad
CS_rrEM_CAT matches {[ac0003]}
-- NORM (elegido de anexo 12)
}
cdigo existence matches {0..1} matches {
- Cdigo de la actividad
CD matedles {
[ac0004,
- SNOMED CT - cdigo XX de estudio
electrofisiolgico
acOOOS]}
- SNOMED CT-cdigo XX de estudio
electrofisiolgico con ablacin
}
id existence matches {0..1} cardinality matches {0..* ; unique} matches {
- Identificacin
II [atOOlO] matches{
laz matdies {
Identificacin unvoca
OID[at0011] matches {
oid matches {/([0-9]*\.)*/}
- Identificador nico OD del
informe
}
}
extensin existence matches {0..1} matches {/.*/}
nico dentro del espacio de
nombres de la autoridad de asignacin
nombreAutoridadAsignadn existence matches {0..1} matches {/.*/}-- Entendible por humano
tiempoValided existence matches{0}
- Valido siempre
}
}
tiempoActividad existence matdies {0..1} matciies{
- Fecha y hora de fijiazadn del informe
TS matches!""}
}
cdigoPrioridad existence matches {0..1} matches {
- Prioridad
CV matches{
[acOOlO,
mxima urgenda
acOOll,
urgente
ac0012]
- rutina
}
}
sujeto matches {
use_archetype SujetoDePrueba matdies {
identifier matches {"cen-gpics-partidpation.subject_of investigation.*"}
}
}
profesional cardinality matches {1..*; unique} matches {
use_archetype ParteSanitariaPartidpante matdies {
identifier matches {"cen-gpics-partidpation.partidpating_healthcare_profesional. *"}
}
}
183
informes existence matches {0..1} cardinality matches {0..*; unique} matches {
use_ardietype InformeSobreServidoReladonado matches {
identifer matches {"cen-gpics-actsrelationj'elated_service_report.*"}
}
}
servidos existence matches {0..1} cardinality matches {0..*; unique} matches {
use_archetype PetidonDeServidoReladonado matches {
identifier matches {"cen-gpics-actsrelation.related_service_request.*"}
}
}
encuentro existence matches {0..1} cardinality matdies {0..*; unique} matches {
use_archetype EncuentroAsistendalReladonado matches {
identifier matdies {"cen-gpics-actsrelation.related_care_encounter.*"}
}
}
provisin cardinality matches {1..*; unique} matches {
use_archetype ProvisionServidoAsistendal matdies {
identifier matches {"cen-gpics-actsrelation.care_service_deUvery.*"}
}
}
informadon cardinality matches {1..*} matches {
use_ardietype InformadnClnica matdies {
identifier matches {"cen-gpics-actrelation.clinical_information.*"}
}
}
ontology
priinary_language = <"es">
terminologies_available = <"SNOMED_CT">
term_defnitions("es") = <
items("atO0OO") = <text = <"Informe servido teleconsulta">; description = <"Ejemplo informe sobre
servido de teleconsulta"
items("at0010") = <text = <"Identifcadn">; desaiption = <"CEN D: Identification de la
teleconsulta"
items("at0011") = <text = <"Identificadn unvoca">; description = <"CEN OD: Identificador OD
unvoco del informe"
>
constraint_definitions("es") = <
items("ac0001") = <text = <"CEN:ItemCategory: DOCCLIN">; description = <"Tipo de actividad
elegido del anexo 10 (informe)"
items("ac0002") = <text = <"CEN:ItemCategory: DEF">; desaiption = <"Interpretadn, elegido del
anexo 11 (definidn)"
items("ac0003") = <text = <"CEN:ItemCategory: NORM">; description = <"Estado, elegido del anexo
12 (normal)"
items("ac0004") = <text = <"Estudio ElectrofisioIgico">; desaiption = <" Nombre del tipo de estudio
realizado "
items("ac0005") = <text = <"Abladn">; desaiption = <" Nombre del tipo de estudio realizado "
items("ac0010") = <text = <"Mxima urgenda">; description = <"Desaipdn visual del nivel de
prioridad"
items("ac0011") = <text = <"Urgente">; description = <" Desaipdn visual del nivel de prioridad "
items("ac0012") = <text = <"Rutina">; description = <" Desaipdn visual del nivel de prioridad "
>
term_binding ("SNOMED Cr')=< >
constraint_binding ("SNOMED CV) = <
items("ac0004") = <query("tenninology", "terminology_id = snomed_ct; synonym_of [ ]
items("ac0005") = <queiy("tenninology", "tenmnology_id = snomed_ct; synonym_of [ ]
>
184
6.5 Arquetipo informe estudio electrofsiolgico.

En este apartado se especifica en ADL vO.9 el arquetipo "Informe estudio electrofsiolgico"
archetype
CEN-EHR-ENTRY.informe_estudio_electrofisiologico.vl
concept
[atOOOO]
Informe sobre servicio (teleconsulta)
description
authoi = <"Carlos H. Salvador">
submssion = <
date = <2004-03-10>
>
status = <"draft">
purpose = <"Describe el informe de un servicio (teleconsulta) sobre un estudio electrofsiolgico">
use = <"">
misuse = <"">
>
rights = <"">
defnition
ENTRY[atOOOO] matches{
ame matches {[acOOOO]}
tems cardinaty matches {3} matches{
ELEMENT[at0001] matches{
ame matches{[aclOOO]}
valu matches{
CX)DED_TEXT matches {
codeValue matdies{
[local::
atlOOl,
atl002,
atlOOS,
atl004,
atlOOS,
atiooe,
atl007]
}
}
}
ame matches{[acl001]}
valu matches{
INTEGER matches {
Tipo ENTRY para informe sobre servicio de teleconsulta

Informe EEF
Cardiopata
No cardiopata
~ Isqumica-IAM
~ Dilatada Idioptica
Hipertrfica
~ Valvular
Displasia AVD
Congnita
Fraccin de eyeccin ventricular
185
valu matches {0..100}
}
Porcentaje?
}
}
CLUSTER[at0003] matches{
ame matches {[acl002]}
Procedimiento
parts cardinality matches {1-2} matches{
CLUSTER[at2000] matches{
ame matches {[ac2000]}
Estudio electrofsiolgico
parts cardinality matches {3} matches{
- Tipo estudio
valu matches{
CODED_TEXT matches {
codeValue matches{
[local::
at2101, Conduccin
at2102, - Sncope
at2103] -- Induccin TV
}
}
}
CLUSTER [at2200] matdies{

Tcnica empleada
ELEMENT [at2210] matches{
-Sedacin
valu matches{
CODEDTEXT matches {
codeValue matches{
[local::
at2211, - - Ninguna
at2212, - - Superficial
at2213] - - Anestesia general
}
}
}

Anticoagulacin
valu matches{
CODEDTEXT matches {
codeValue matches{
[local::
at2221, - Ninguna
at2222, - Hep Na IV segn TTPa
at2223, - Hep Na empirica
at2224] - Hep bajo peso molecular
186
}
}
}
}
ELEMENT [at2230] matdies{
- Nmero catteres diagnstico
valu matches{
INTEGER matdies{
valu matdies{1..7}
}
}
}
CLUSTER [at2240] matches{
ame matches{[ac2240]}
- Va de abordaje
parts cardinaljty matches {1..3} matches{
ELEMENT [at2241] matches{ -- Yugular
ame matdies {[ac2241]}
valu matches{
INTEGER matches{
valu matches{0..2}
}
}
}
ELEMENT [at2242]raatches{-- Femoral
valu matches{
INTEGER matches{
valu matches{0..5}
}
}
}
ELEMENT [at2243] matches{ -- Subclavia
valu matches{
INTEGER matches{
valu matches{0..2}
}
}
}
}
}
}
}
Parmetros electro fisiolgicos
parts cardinality matches {4} matches {
ame matdies{[ac2400]}
Bsales - electrocardiograma
187
Electrocardiograma
parts caidinality matdies {4} matches{
namematches{[ac2411]} -ritmo
valu matches{
CODEDTEXT matches{
CodeValu matches{
[local::
at2412, -sin.
at2413, -FA
at2414, -flut.
at2415] -TV
}
}
}
}
ame matches {[ac2420]} frec.
valu matches{
PHYSICAL_QUANTITY matches{
units matches {"Ipm"}
}
}
}
ame matches {[a<430]}
parts cardinality matches {1..2} matches{
valu matches {"s","no"}
}
ELEMENT [at2432] occurrences matches {0..1} matches{
valu matches{1..3}
}
}
}
ame matches {[ac2441]}~PR
valu matdies{
PHYSICAL_QUANTrrY matches{
units matches {"ms"}
valu matches{60..400}
}
}
188
}
namematdies {[ac2442]}-QRS
valu matches {
}
}
}
ame matches {[ac2443]}--QT
valu matches{
}
}
}
ame matches {[ac2444]}-QTc
valu matches{
PHYS1CAL_QUANTITY matdies{
}
}
}
}
}
}
}
CLUSTER [at2450] matdies{
- Bsales
parts caidinality matches {4} matches{
ame matches {[ac2451]}--LC
valu matches{
}
}
}
ame matches {[ac2452]}--PA
valu matches{
189
061
{
{[t70523B]}s3ipjBui soiea
OUOJBJSIHI sosedEDiBii^ }s3ij3)eiii [tÔSZl^] XMHNSia
{
{OU^/IS} S3I]3;BUI 3n|BA
{[0SZ3B]}S3ipjBUI 3UIBU
IBijjBouts o a n b o i a -
}s3q3jBUi [0531^] X N a W H i a
{
{ou'is} ssqojBiu anjBA
{[20g30B]}s3Ha(BUI SUIBU
[Bsnuis BsnBj-}s3qoiBUi [ZOSZI] XNaiMHia
{
{
{
{sui} ssqo^BU s}iun
}s9qO)Bui AXIJLNVnO"'T5'OISAHd
}s9lp|BUI SnjBA
aOl--
{ [ T O S Z ? " ] } S9ipiBUI 9UIBU

}s3q3jBni [xoszie] x N a w a i a
}s3ip}BUI {g} S3q3)Bm X)IIBUlplB3 S)lBd
[Bsnuis uoraunj {[00ZOB]}s3qoiEUi auiBU
}saqojBui [OOSJJB] âxsaao
{
{
{
{
{
{
{
{|0SX"0H}^M3"i 3niA
{,^siu} saqojBHi sjiun
}s3q3iBui AXIXNVnO~TVDISAHd
}s3qO}BUI 9n[BA
AH-{[t'St'Z3B]} saqoBui auiBU
}s9ipjBui [t^stzJB] XMawaia

{
{
{
{OOfOssipiBui snjBA
{sni} saqojBHi sjiun
}s3ipjBui AUJNVnO~TV3ISAHd[
}s9qajBui 3n[BA
HV-{[SPZ^^]} saqojBUi 9UIBU
}s9iFHBHi [5f tB] xNajMaia
{
{
{
{O0Z"Ol}s3ipiE'a sniEA
sopBip9H 9 opqxdB3
ELEMENT [at2505] matches{ --Tiempo recuperacin sinusal
valu matches{
}
}
}
ELEMENT [at2506] matdies{ Tiempo recuperacin sinoatrial
valu matches{
}
}
}
ELEMENT [at2507] matches{ Respuesta a la atropina
valu matdies{
}
}
}
ELEMENT [at2508] matches{ Ritmo sinusal intrnseco
valu matches {
}
}
}
}
}
- Conduccin AV
parts cardinaty matches {2} matches{
ame matches {[ac2601]} -Punto de Wenckebach
valu matches {
PHYSICAL_QUANTrrY match6s{
}
}
}
ame matches {[ac2602]} -Periodo re&actario del nodo AV
valu matches {
191
unuioo IX-- 'ZZ8ZIB

V X - 'X38ZJB
"IOl]
}s9ipieui anjBA^poD
jssipjEm xxax~aHac
Enmure ap odix~{[038ZP^]}^1^l^ SUIEU
}s9ip)Bui [OZSZIB] XNawaia
{
{
{
{
{
{
DS~ [XSZl"
IV~ '918ZIB
Sffl- 'S1831B
av-- 't'isziB
::iBDOi]
}saq3iEui anjBAspoo
}s3ip}Bui xxax~aaacxD
n9pB[nuips3 ojund {[^XSZP^D^'PIBI' auiEU
}saipiBui [eisziB] XNawaia

{
{i7--X}s3ip}Em dn[BA
sopiuijisaBiixa
Sp OMUinjvI - {[2X8t3B]}s3ll3}EUI 3UIBU
}s9q3}Bm [ZXSZIB] usiawaia

{
{^X}s9q3jBm aniBA
9SBq
9p s o p p 3p oMuinfj ~ {[xx8Z?B]}s3qo}Eiu SUIBU
}s3qo}Bui [XXSZE] xNawaia
}saip}Bui {{:} ssipiBui XjfiBurpJEO sjred
uopBjnuirisa 9po[ooo}oid{[0X8Z3B]}s3qo}Bui3mBU
}s9ipiBui OXSZJE] aaxsmD
}sSip)BUI {c} S3q3)BUI XlIJBUipiBO SJBd
s3re[noii|U3AEidns SBipiBombBX- {[008Z^^]}s3il3jBm 3UIBU
}s9ii3jBui {x"0} saipjBui saouajinooo [ooSD^] a a X S f n D
}s3ip}Bui {z"o} saqojBui XiiiBuipiBo sired
SBini)UJB ap upioonpui -
{[00Z3B]}S3I1'IBUI SUIBU
}s3ip)Eui [OO3)B] aaxsnD

{
{
{
{
{
{sui} ssqajBUi sjinn
s o p E j p s a a '9 oxnjxdEo
at2823, -TI no comn
at2824, -Reentrada por va accesoria
ortodrmica
at2825, -Reentrada por va accesoria
antdrmica
at2826, -Flutfer auricular tsmico
horario
at2827, -Flutter auricular tsmico
antihorario
at2828, -Flutter auricular no tsmico
at2829] -Fibrilacin auricular
}
}
}

ame matches{[ac2850]}~Finalzacin
valu matches {
CODED_TEXT matches{
codeValue matches{
[local:;
at2851, -Espontnea
at2852, -Sobreestimulacin
at2853, -Frmaco: Adenosina
at2854, -Frmaco: Verapamil
at2855, -Frmaco: LJncafna
at2856, -Frmaco: Procanamida
at2857, -Frmaco: Amiodarona
at2858] -Cardioversin
}
}
}
CLUSTER [at2900] occurrences matches {0..1} matches{

ame matches{[ac2900]} Taquicardias ventriculares
Protocolo de estimulacin
parts cardinality matdies {3} matches{
ame matches{[ac2911]} - Nmero de ciclos de
base
valu matches{1..4}
}
ame matdies{[ac2912]} - Nmero de
extraes tmulos
193
AV opN -{ [ 0 X I 3 E ] } saqojBUi auiBU

}s9ipiBiu {x"o} ssipjBUi sMuajinoDo [oTTOBlHHXSmO
}s3H3}Bui {"l} saipjEH XjijBnipjBO sired
{[OOTC^]} saqcnBui SUIBU
uoiOBiqB odfx }saq3}BUi [ o o i o e ] H a X S m O
} S3ip}BUI {} SaqOJBlU XjtJBUtpjBD SJlBCl
uopBjqv -{[OOOPB]} saipjBUi amBU
}saipiBui {x"0} saqoBUi SMuaunoao [oOOeiBlaaXSmD
{
{
{
{
{
{
{
{
uopBZitBuij/[oe83B]s}d/[o083lB]sJBd/[ooZ1E]sjiBd/[oOZJB]sWBd/[oooZB]sviBd/[0001B]so"31/[00001B]
jjsiaiMaia 9pou~3sn
{
{
{
{
iBjnoujuaA u o p B i u q i j - [Z6tlB
Bjioffljiod AX-- 'Zt6tlB
Bjjomououi AX-- 'XZtJB
::iBOoi]
}S3H0}BU1 9njB/\9p03
}s3ip}Bui x x a x ~ a H a c o
BIUIIJIIE 3p odtX~{[0Z6t3B]}s9ip}BUI 9UIBU
}s9qojBui [ottiB] x N a w a i a
{
{
{
{
{
{
OASX-- [9X6tlB
IA-- 'SI6ZIB
QA- 'n6Z\'B
"IBOOl]
}s9q3}Bni 3n\v\spQO
}s3ipjEm xxai~aaaoD
}s3qo}BUi antBA
HopBjnmr|S9 ojund- {[x6Z3B]}s3ipiBiu SIUBU
}s9q3}Bm [ei63iB] x N a w a i s
{
{^X}ssip}Bui anjBA
sopBjpisay 9 opqj'lB3
parts cardinality matches {2} matdies{
ELEMENT [at3111] matches {
- Objetivo
ame matdies {[ac3111]}
valu matches{
CXJDEDTEXT matches{
codeValue matdies{
[local::
at3112, -- Ablacin
at3113] --Modulacin
}
}
}
}
-Tipo arritmia
valu cardinality matdies{1..3} matches{
CODED_TEXT matches{
codeValue matches {
[local::
at3115, - Fib. auricular
at3116,-Flutter
at3117] -Taq. auricular
}
}
}
}
}
}
- Taquicardia intranodal
ELEMENT [at3121] matches { -Tipo
valu matches{
CX)DED_TEXT matches{
codeValue matches{
[local::
at3122, -Comn
at3123] -Incomn
}
}
}
}
ELEMENT [at3124] matches { -Abordaje
valu matches{
CODEDTEXT matches{
codeValue matches{
[local::
195
96T
}s3qO)BUI {t"X}s9ip}BUI XjIJBUrplBa 3n[BA
{[TSXPB]} saipiBn SUIBU
uppBZiBOoi--
} S91I0JBUI [isieiB] INaj^HlH

} s 3 i p i B U I { x } SaipjBlU XjIJBUrpiBO S}IBd
[B30J jEinounB -bBX{[OST?^]} saqaiBiu SIUBU
}s9ipiBHI {X"0} S3H31BUI S33U3JinCK)0 [ 0 5 X 0 ^ ] 3 X 8 1 1 1 3
{
{
{
{
{
{
IBld9S013}IIV - [tt^XeiB
JSp IBI3JB1 -- 'Xt-IOB
J3p l o j i a i s o j - 'OI'ICIB
[B}d3SOJ9}soj - '6XJB
bzi J01J3JS0J -- 'geXO^
bzi JB19JB1 - ' t i e i B
"[BOOl]
}S3q3}Bm 9n[B/\SpOD
}s9ip}Bni xxax~aaaco
}s9H3iBUi {9"x}saqojBui XjiiBuipiBa 9n[BA
{[9X{?B]} saipjBui suiBU
U9roBzi[Bacri
} s3ijo}Bui [9ex}B] x N a w a a a
{
{
{
{
3}U31IUIJ9}UI
rarequBjv
IB)U9UI9J33Q -- 'eexcJE
}U3:H - 'ZXJE
"IBOOl]
}s3q3jEUi aniBâpco
}s9q3iBui x ) H x " " a a a ( X )
}s3qO)BUI {t7"x}s3q3}BUI XjflBUipJBD 3njBA
{[XEXEOB]} saqojEui 9IIIBU
BU0S330B BJA o d l X ~
} saqojBui [XEXEie] X N H W a a a
}s9ip)Bui {3} saqojBUi XjtiBuipjBO sjred
BUOS33DB BJA "
{ [ O E X ? B ] } S3q3)BUI 3UIBU
}s3q3jBui { X - Q } saipjBui saouaurewo [oeXEie] a X S m D
{
{
{
{
{
BptdBI BIy\
Bjuaj BJA
sopB)xns3H '9 oiaijtlB3
{
[9ZXIE
'SZXCB
CODED_TEXT matches{
codeValue matches{
[local::
at3152, -- Aurcula der.
at3153, ~ Aurcula izq.
at3154, - Septal
at3155] - Venas pulmonares
}
}
}
CLUSTER [at3160] occurrences matdies {0..1} matches{

-Flutter
parts caidinality matches {2} matches{
--Tipo de flutter
valu cardinaUty matches{1..5} matches{
CX)DED_TEXT matches{
codeValue matches{
[local
at3162, - tsmico Hor.
at3163, - tsmico Anti.
at3164, - Cicatridal
at3165, - Izquierdo
at3166] - Vena cava inf.
}
}
}
- Objetivo
valu matches{
CODEDTEXT matches{
codeValue matches{
[local::
at3168, --Bloqueo del itsmo
at3169] -No indudblidad
}
}
}

Fibrilacin auricular
- Objetivo
197
valu matches{
CODED_TEXT matches{
codeValue matches{
[local::
at3172, -- Focal.
at3173, - Lineal.
at3174] - - Aislamiento VVPP.
}
}
}
CLUSTER [atalSO] occurrences matches {0..1} matches{

--Taquicardia ventricular
~ Tipo
valu matches{
CODED_TEXT matches{
codeValue matches{
[local:;
at3182, --Tracto salida VD.
at3183, --TV fascicular.
at3184, -TV rama-rama.
at3185, --TV isqumica.
at3186, -TV miocardiopata.
at3187] -TV displasia VD.
}
}
}

valu matches{
CODEDTEXT matches{
valu matches{
[local::
at3211,
at3212,
at3213.
-Tcnica
Acceso
- Venoso
- Foramen oval
- Transeptal
198
at3214,
at3215]
}
~ Retroartico
~ Seno coronario
}
}
}
valu matches{
C O D E D T E X T matches{
valu matches{
[local::
at3221.
at3222.
at3223,
at3224.
at3225.
at3226]
~ Catter ablacin
--4 mm
8 mm
- Punta irrigada
- Crioablacin
- Ultrasonidos
- Otro
}
}
}
}
valu matches {
CDDED_TEXT matches{
valu matches{
[local::
at3231.
at3232,
at3233.
at3234.
at3235]
}
Sistema navegacin
- Ninguno
-- CARTO
- LOCALISA
-- ENSITE
-Otro
}
}
Resultado del prcedimiento
- Resultado
valu matches{
CODED_TEXT matches{
valu matches {
[local::
at3311. - xito
199
at3312,
at3313]
}
Fracaso
Recuirencia precoz
}
}
}
valu matches{
CODED_TEXT matches{
valu matdies{
[local::
at3321.
at3322.
at3323.
at3324.
at3325.
at3326]
}
ontology
Complicaciones
Muerte
--BAV
- Vascular
-- ACVA/AIT
--IAM
-ICC
}
primary_language = <"es">
languages_avalable = <"es">
term_defnitions("es")= <
items("atOOOO") = < text = <"Informe sobre servicio (teleconsulta)">; description = <"E1 nombre del arquetipo de tipo ENTRY"
items("at0001") = < text = <"Cardiopata">; desaiption = <"Elemento: Cardiopata"
items("at0002") = < text = <"FEVI">; description = <"Elemento: Fracdn Eyeccin Ventrculo Izquierdo"
items("at0003") = < text = <"Procedimiento">; description = <"CLUSTER: contenedor de los distintos tipos de procedimiento"
items("atl001") = < text = <"No cardiopata">; description = <"Cardiopata: no "> >
tems("atl002") = < text = <"Isqumica-IAM">; descxiption = <"Cardiopata: Isqumica-IAM"
iteras("atl003") = < text = <"Dilatada Idioptica">; description = <"Cardiopata: Dilatada Idioptica"
items("atl004") = < text = <"Hipertrflca">; desaiption = <"Cardiopata: Hipertrflca"
items("atl005") = < text = <"Valvular">; description = <"Cardiopata: Valvular"
items("atl006") = < text = <"Displasia AVD">; description = <"Cardiopata: Displasia AVD"
items("atl007") = < text = <"Congmta">; description = <"Cardiopata: Congnita"
items("at2000") = < text = <"Estudio electrofisiolgico">; description = <"CLUSTER: Contenedor datos del estudio"
items("at2100") = < text = <"Tipo estudio">; description = <"Element: tipo del estudio realizado"
items("at2101") = < text = <"Conduccin">; description = <"Tipo estudio electrofisiolgico: conduccin"
items("at2102") = < text = <"Sncope">; description = <"Tipo estudio electrofisiolgico: sncope"
200
iteins("at2103") = < text = <"Induccn TV">; description = <"Tipo estudio electroflsiolgico: induccin taquicardia ventricular"
itenis("at2200") = < text = <"Tcnca empleada">; desaiption = <"CLUSTER: contenedor para la informacin de la tcnica empleada"
items("at2210") = < text = <" Sedacin">; description = <"ELEMENT : Tipo de sedadn empleado"
items("at2211") = < text = <" Nnguna">; description = <"Sedacn: No se ha empleado"
items("at2212") = < text = <" Superfdar>; description = <"Sedacin: Se ha empleado anestesia superflcial"
itenis("at2213") = < text = <" Anestesia general">; desaiption = <"Sedadn: Se ha empleado anestesia general"
items("at2220") = < text = <" Anticoag:uladn">; description = <"ELEMENT : Tipo de anticoagulacin empleado"
items("at2221") = < text = <"Ning;una">; description = <"Anticoaguladn: No se ha empleado ninguna"
items("at2222") = < text = <" Hep Na IV segn TTPa ">; description = <"Anticoagulacin: Heparina sdica segn tiempo protrombina"
itenis("at2223") = < text = <" Hep Na emprica ">; desaiption = <"Anticoagulacin: Heparina sdica segn peso"
items("at2224") = < text = <" Hep bajo peso molecular ">; description = <"Anticoagulacin: Heparina de bajo peso molecular"
items("at2230") = < text = <"Catteres de diagnstco">; description = <"Element: nmero de catteres usados en diagnstico"
items("at2240") = < text = <"Va de abordaje">; description = <"Cluster: nmero de vas de abordaje empleadas"
items("at2241") = < text = <"Yugular">; description = <"Element: nmero de vas de abordaje en )rugular"
items("at2242") = < text = <"Femoral">; description = <"Element: nmero de vas de abordaje en femoral"
items("at2243") = < text = <"Subclavia">; desaiption = <"Element: nmero de vas de abordaje en subdavia"
items("at2300") = < text = <"Parmetros electrofisiolgicos">; desaiption = <"CLUSTER: contenedor para los parmetros electroflsiolgicos"
items("at2400") = < text = <"Basales - electrocardiograma">; desaiption = <"CLUSTER: contenedor para los parmetros bsales - electrocardiograma"
items("at2410") = < text = <"Electrocardiograma">; desaiption = <"CLUSTER: contenedor para los parmetros de electrocardiograma"
items("at2411") = < text = <"Ritmo cardiaeo">; description = <"ELEMENT: ritmo cardiaco"
items("at2412") = < text = <"Sinusal">; desaiption = <"Ritmo cardiaco"
items("at2413") = < text = <"Fibrilacin auricular">; desaiption = <"Rtmo cardiaco"
items("at2414") = < text = <"Flutter">; desaiption = <"Ritmo cardiaco"
items("at2415") = < text = <"Taquicardia ventricular">; desaiption = <"Rtmo cardiaco"
items("at2420") = < text = <"Frecuencia cardiaca">; desaiption = <"ELEMENT:fi-ecuenciacardiaca"
items("at2430") = < text = <"Bloqueo AV">; desaiption = <"CLUSTER: bloqueo aunculo ventricular"
items("at2431") = < text = <"Bloqueo">; desaiption = <"ELEMENT: existe bloqueo AV?"
items("at2432") = < text = <"grado de bloqueo">; desaiption = <"ELEMENT: grado del bloqueo AV detectado"
items("at2440") = < text = <"Intervalos">; desaiption = <"CLUSTER: intervalos medidos"
items("at2441") = < text = <"Intervalo PR">; desaiption = <"ELEMENT: Intervalo P R "
items("at2442") = < text = <"Intervalo QRS">; desaiption = <"ELEMENT: Intervalo QRS"
items("at2443") = < text = <"Intervalo QT">; desaiption = <"ELEMENT: Intervalo Q T "
items("at2444") = < text = <"Intervalo QTc">; desaiption = <"ELEMENT: Intervalo QTc"
items("at2450") = < text = <"Basales">; description = <"CLUSTER: contenedor para los parmetros bsales medidos"
items("at2451") = < text = <"Longitud de ddo">; desaiption = <"ELEMENT: Longitud de d c l o "
items("at2452") = < text = <"Intervalo PA">; desaiption = <"ELEMENT: Intervalo P A "
items("at2453") = < text = <"Intervalo AH">; desaiption = <"ELEMENT: Intervalo A H "
items("at2454") = < text = <"Intervalo HV">; desaiption = <"ELEMENT: Intervalo H V "
items("at2500") = < text = <"Funcin sinusal">; desaiption = <"CLUSTER: contenedor para los parmetros de funcin sinusal"
items("at2501") = < text = <"Longitud de cido basal">; desaiption = <"ELEMENT: Longitud de ciclo basal"
items("at2502") = < text = <"Pausa sinusal">; desaiption = <"ELEMENT: Pausa sinusal"
items("at2503") = < text = <"Bloqueo sinoatriar>; desaiption = <"ELEMENT; Bloqueo sinoatrial"
tems("at2504") = < text = <"Marcapasos migratorio">; desaiption = <"ELEMENT: Marcapasos migratorio"
items("at2505") = < text = <"Tiempo de recuperacin sinusal">; desaiption = <"ELEMENT: Tiempo de recuperadn sinusal"
tems("at2506") = < text = <"Tiempo de conducdn sinoatrial">; desaiption = <"ELEMENT: Tiempo de conduccin sinoatrial"
items("at2507") = < text = <"Respuesta a la atropina">; desaiption = <"ELEMENT: Respuesta a la atropina"
items("at2508") = < text = <"Ritmo sinusal intrfnseco">; desaiption = <"ELEMENT: Ritmo sinusal intrnseco"
items("at2600") = < text = <"Conduccin AV">; desaiption = <"C1.USTER: contenedor para los parmetros de conduccin A V "
items("at2601") = < text = <"Punto de Wendcebach">; desaiption = <"ELEMENT: Punto de Wendcebadi"
201
items("at2602") = < text = <"Periodo re&actario del nodo AV">; desctiption = <"ELEMENT: Periodo refractario del nodo A V "
items("at2700") = < text = <"Induccin de arritmias">; description = <"CLUSTER: contenedor para los parmetros de induccin de arritmias"
items("at2800") = < text = <"Taquicardias supraventriculares">; description = <"CLUSTER: contenedor para los parmetros de induccin de taquicardias supraventriculares"
items("at2810") = < text = <"Protocolo de estimulacin">; description = <"CLUSTER: contenedor para los parmetros del protocolo de estimulacin"
iteins("at2811") = < text = <"Nmero de ciclos de base">; description = <"ELEMENT: nmero de ciclos de base"
items("at2812") = < text = <"Nmero de extraestmulos">; description = <"ELEMENT: nmero de extraestmulos"
items("at2813") = < text = <"Punto de estimulacin">; desaiption = <"ELEMENT: punto de estimulacin"
items("at2814") = < text = <"Aurcula derecha">; desaiption = <"Punto de estimulacin"
items("at2815") = < text = <"His">; description = <"Punto de estimulacin"
items("at2816") = < text = <"Aurcula izquierda">; desaiption = <"Punto de estimulacin"
items("at2817") = < text = <"Seno coronario">; description = <"Punto de estimulacin"
items("at2820") = < text = <"Tipo de arritmia inducida">; description = <"ELEMENT: contenedor para el tipo de arritmia inducida"
items("at2821") = < text = <"Taquicardia auricular">; description = <"Tipo de arritmia inducida"
items("at2822") = < text = <"Taquicardia intranodal comn">; description = <"Tipo de arritmia inducida"
items("at2823") = < text = <"Taquicardia intranodal incomin">; description = <"Tipo de arritmia inducida"
items("at2824") = < text = <"Reentrada por va accesoria ortodrmica">; desaiption = <"Tipo de arritmia inducida"
items(''at2825") = < text = <"Reentrada por va accesoria antidrmica">; desaiption = <"Tipo de arritmia inducida"
items("at2826") = < text = <"Flutter auricular tsmico horario">; desaiption = <"Tipo de arritmia inducida"
items("at2827") = < text = <"Flutt6r auricular tsmico antihorario">; description = <"Tipo de arritmia inducida"
items("at2828") = < text = <"Flutter auricular no tsmico">; desaiption = <"Tpo de arritmia inducida"
items("at2829") = < text = <"Fibrilacin auricular">; desaiption = <"Tipo de arritmia inducida"
items("at2850") = < text = <"Finalizacin">; desaiption = <"ELEMENT: contenedor para la finalizacin"
items("at2851") = < text = <"Espontnea">; description = <"Finalizacin de la arritmia"
items("at2852") = < text = <"Sobreestimuladn">; desaiption = <"Finaliza(3n de la arritmia"
items("at2853") = < text = <"Frmaco: Adenosina">; desaiption = <"Finalizacin de la arritmia"
items("at2854") = < text = <"Frmaco: Verapamil">; desaiption = <"Finalizacin de la arritmia"
items("at2855") = < text = <"Frmaco: Lincana">; desaiption = <"Finalizaci6n de la arritmia"
items("at2856") = < text = <"Frmaco: Procainamida">; desaiption = <"Finalizacin de la arritmia"
items("at2857") = < text = <"Frmaco: Amiodarona">; desaiption = <"Finalizacin de la arritmia"
items("at2858") = < text = <"Cardioversi6n">; desaiption = <"Finalizacin de la arritmia"
items("at2900") = < text = <"Taquicardias ventriculares">; desaiption = <"CLUSTER: contenedor para los parmetros de induccin de taquicardias ventriculares"
items("at2910") = < text = <"Protocolo de estimulacin">; desaiption = <"CLUSTER: contenedor para los parmetros del protocolo de estimulacin"
items("at2911") = < text = <"Nmero de ciclos de base">; desaiption = <"ELEMENT: nmero de ciclos de base"
items("at2912") = < text = <"Nmero de extraestmulos">; desaiption = <"ELEMENT: nmero de extraestmulos"
items("at2913") = < text = <"Punto de estimulacin">; desaiption = <"ELEMENT: punto de estimulacin"
items("at2914") = < text = <"Ventrculo derecho">; desaiption = <"Punto de estimulacin"
items("at2915") = < text = <"Ventrculo Izquierdo">; desaiption = <"Punto de estimulacin"
it6ms("at2916") = < text = <"Tracto salida ventrculo derecho">; desaiption = <"Punto de estimulacin"
items("at2920") = < text = <"Tipo de arritmia inducida">; desaiption = <"CLUSTER: contenedor para el tipo de arritmia inducida"
items("at2921") = < text = <"Taquicardia ventricular monomorfa">; desaiption = <"Tipo de arritmia inducida"
items("at2922") = < text = <"Taqucardia ventricular polimorfas">; desaiption = <"Tpo de arritmia inducida"
items("at2923") = < text = <"Fibrilaci6n ventricular">; desaiption = <"Tipo de arritmia inducida"
items("at3000") = < text = <" Ablacin">; desaiption = <"CLUSTER: Contenedor datos de la ablacin"
items("at3100") = < text = <"Tipo ablacin">; desaiption = <"CLUSTER: Contenedor para los tipos ablacin"
items("atJ110") = < text = <"Nodo AV">; desaiption = <"CLUSTER: Contenedor para el tipo: Nodo aurculo ventricular"
items("at3111") = < text = <"Objetivo">; desaiption = <"ELEMENT: Objetivo de la ablacin practicada"
items("at3112") = < text = <"Ablacin">; desaiption = <"Objetivo de la ablacin practicada: Ablacin"
items("at3113") = < text = <"Modulacin">; desaiption = <"Objetivo de la ablacin practicada: Modulacin"
items("atJ114") = < text = <"Tipo de arritmia">; desaiption = <"ELEMENT: Tipo de arritmia del nodo A V "
202
it6ms("at3115") = < text = <"Fibrilacin auticular">; desaiption = <"Tipo de aiiitmia del nodo A V "
items("at3116") = < text = <"Flutter atpco">; desaiption = <"Tipo de arritmia del nodo A V "
items("at3117") = < text = <"Taqucarda auricular">; descrption = <"Tipo de arritmia del nodo A V "
iteins("at3120") = < text = <"Taquicarda intranodal">; descrption = <"CLUSTER: Contenedor para el tipo: Taquicardia intranodal"
items("at3121") = < text = <"Tipo">; desaiption = <"ELEMENT: Tipo de taquicardia intranodal"
items("at3122") = < text = <"Comn">; description = <"Tipo de taquicardia intranodal"
items("at3123") = < text = <"Incomn">; desaiption = <"Tipo de taquicardia intranodal"
items("aB124") = < text = <"Tipo abordaje">; desaiption = <"ELEMENT: Tipo de abordaje"
items("at3125") = < text = <"Va lenta">; desaiption = <"Tipo de abordaje"
items("at3126") = < text = <"Va rpida">; desaiption = <"Tipo de abordaje"
items("at3130") = < text = <"Va accesoria">; desaiption = <"CLUSTER: Contenedor para el tipo: Va accesoria"
items("at3131") = < text = <"Tipo">; desaiption = <"ELEMEhJT: Tipo de va accesoria"
items("at3132") = < text = <"Kent">; desaiption = <"Tipo de va accesoria"
items("at3133") = < text = <"Deaemental">; desaiption = <"Tipo de va accesoria"
iteins("at3134") = < text = <"Manhaim">; desaiption = <"Tipo de va accesoria"
items("at3135") = < text = <"Intermitente">; desaiption = <"Tipo de va accesoria"
items("at3136") = < text = <"Localizacin">; desaiption = <"ELEMENT: Localizadn de va accesoria"
items("at3137") = < text = <"Lat6ral izquierda">; desaiption = <"Localizadn de va accesoria"
items("at3138") = < text = <"Posterior izquierda">; desaiption = <"Localizadn de va accesoria"
items("at3139") = < text = <"Posteroseptal">; desaiption = <"Localizacin de va accesoria"
items("at3140") = < text = <"Posterior derecha">; desaiption = <"Localizadn de va accesoria"
items("a0141") = < text = <"LateraI derecha">; desaiption = <"Localizadn de va accesoria"
items("at3142") = < text = <"Anteroseptal">; desaiption = <"Localizadn de va accesoria"
items("at3150") = < text = <"Taquicardia auricular focar>; desaiption = <"CLUSTER: Contenedor para el tipo: Taquicardia auricular focal"
it6ms("at3151") = < text = <"Localizacin">; desaiption = <"ELEMENT: Localizadn de la taquicardia auricular focal"
items("at3152") = < text = <"AurcuIa derecha">; desaiption = <"Localizadn de taquicardia auricular focal"
items("at3153") = < text = <"Aurcula izquierda">; desaiption = <"Localizadn de taquicardia auricular focal"
items("at3154") = < text = <"Septal">; desaiption = <"Localizacin de taquicardia auricular focal"
items("at3155") = < text = <"Venas pulmonares">; desaiption = <"lx)calizadn de taquicardia auricular focal"
items("at3160") = < text = <"Flutter">; desaiption = <"CLUSTER: Contenedor para el tipo: Flutter"
items("at3161") = < text = <"Tipo">; desaiption = <"ELEMENT: Tipo de flutter"
items("at3162") = < text = <"tsmico horario">; desaiption = <"Tipo de fluttter"
items("at3163") = < text = <"tsmico antihorario">; desaiption = <"Tpo de fluttter"
items("at3164") = < text = <"Cicatricial">; desaiption = <"Tipo de fluttter"
items("at3165") = < text = <"fzquierdo">; desaiption = <'Tipo de fluttter"
items("at3166") = < text = <"Vena cava inferior">; desaiption = <"Tipo de fluttter"
items("at3167") = < text = <"Objetivo">; desaiption = <"ELEMENT: Objetivo de la ablacin"
items("at3168") = < text = <"Bloqueo del itsmo">; desaiption = <"Objetivo"
it6nis("at3169") = < text = <"No inducibilidad">; desaiption = <"Objetivo"
itenis("at3170") = < text = <"Fibrilacin auricular">; desaiption = <"CLUSTER: Contenedor para el tipo: Fibrilacin auricular"
items("at3171") = < text = <"Tipo de abordaje">; desaiption = <"ELEMENT: tipo de abordaje de la ablacin"
items("at3172") = < text = <"Focar>; desaiption = <"Tipo de abordaje de la ablacin"
items("at3173") = < text = <"Linear'>; desaiption = <"Tipo de abordaje de la ablacin"
items("atl74") = < text = <"Aislamiento de venas pulmonares">; description = <"Tipo de abordaje de la ablacin"
items("at3180") = < text = <"Taquicardia ventricular">; desaiption = <"CLUSTER; Contenedor para el tipo: Taquicardia ventricular"
items("at3181") = < text = <"Tipo de TV">; desaiption = <"ELEMENT: tipo de taquicardia ventricular"
iteras("at3182") = < text = <"Tracto de salida del ventrculo derecho">; desaiption = <"Tipo de taquicardia ventricular"
items("at3183") = < text = <"TV fascicular">; desaiption = <"Tipo de taquicardia ventricular"
itenis("at3184") = < text = <"TV rama-rama">; desaiption = <"Tipo de taquicardia ventricular"
203
items("at3185
tems("at3186
items("at3187";
tems("at3200"^
tems("at3210'
tems("at3211'
items("at3212'
tems("at3213'
tems("at3214"
tems("at3215"'
tems("at3220'
items("at3221":
items("at3222'
tems("at3223":
items("at3224
tems("at3225
tems("at3226"
items("at3230'
tems("at3231'
items("at3232"
,t6ms("at3233'
items("at3234
tems("at3235
iteras("at3300
items("at3310
tems("at3311""
items("at3312
tems("at3313
tems("at3320""
tems("at3321
tems("at3322";
tems("at3323":
tems{"at3324
tems("at3325";
items("at3326"'
: < text = <"TV isqumica">; description = <"Tipo de taquicardia ventricular"

< text = <"TV por miocardiopata dilatada">; description = <"Tipo de taquicardia ventricular"
: < text = <"TV displasia del ventrculo derecho">; description = <"Tipo de taquicardia ventricular"
: < text = <" Tcnica">; description = <"CLUSTER : Tcnica empleada en la ablacin"
: < text = <" Acceso">; description = <"ELEMENT : Tipo de acceso empleado"
: < text = <"Venoso">; description = <"Acceso: Venoso"
: < text = <" Foramen oval">; description = <"Acceso: Foramen oval"
: < text = <" Transeptal">; description = <"Acceso: Transeptal"
: < text = <" Retroartico">; description = <"Acceso: Retroartico"
: < text = <" Seno coronario">; description = <"Acceso: Seno coronario"
: < text = <"Tpo catter ablacin">; description = <"ELEMENT: tipo catter ablacin empleado"
: < text = <"4 mm ">; description = <"Catter ablacin: 4 mm "
: < text = <"8 mm ">; description = <"Catter ablacin: 8 mm "
: < text = <" Punta irrigada ">; description = <"Catter abladn: Punta irrigada "
: < text = <" Crioablacin ">; description = <"Catter ablacin: Crioablacin "
: < text = <" Ultrasonidos ">; description = <"Catter ablacin: Ultrasonidos "
: < text = <" Otro ">; description = <"Catter ablacin: Otro "
: < text = < "Sistema de navegadn">; description = <"Element: sistema de navegacin empleado"
< text = <" Ninguno ">; description = <"Sistema de navegacin: Ninguno "
: < text = <" CARTO ">; description = <"Sistema de navegacin: CARTO "
: < text = <" LOCALISA ">; description = <"Sistema de navegacin: LOCALISA"
: < text = <" ENSITE ">; description = <"Sistema de navegacin: ENSITE "
: < text = <"Otro">; description = <"Sistema de navegacin: Otro"
: < text = <"Resultado del procedimiento">; description = <"CLUSTER: Resultado del procedimiento"
: < text = <"Resultado">; descaîption = <"ELEMENT: Resultado"
: < text = <"xito">; description = <"Resultado del procedimiento"
: < text = <"Fracaso">; description = <"Resultado del procedimiento"
: < text = <"Recurrencia precoz">; description = <"Resultado del procedimiento"
: < text = <"Complicacones">; description = <"ELEMENT: Complicaciones"
: < text = <"Muerte">; description = <"Complica(ones del procedimiento"
: < text = <"Bloqueo AV">; description = <"Complicacones del procedimiento"
: < text = <"Vascular">; description = <"Complicaciones del procedimiento"
: < text = <"Accidente cerebrovascular agudo/Arr">; description = <"Complicaciones del procedimiento">>
: < text = <"Infrto agudo de miocardio">; description = <"Complicaciones del procedimiento"
: < text = <"Insuf(encia cardiaca congestiva">; description = <"Complicaciones del procedimiento"
constraint_definitions("es") = <
items("acOOOO") = < text = <"Informe sobre EEF (teleconsulta)">; description = <"Informe del estudio electrofsiolgic realizado"
items("aclOOO") = < text = <"Cardiopata">; description = <"Elemento: cardiopata del paciente"
items("acl001") = < text = <"FEVr'>; description = <"Elemento: Fracxin de Eyecxn del Ventrculo Izquierdo"
items("acl002") = < text = <"Procedimiento">; description = <"Clust6r: contenedor procedimientos"
items("ac2000") = < text = <"Estudio elecrofsiolgic">; descaription = <"Cluster: contenedor informacin del estudio elecrofsiolgico"
items("ac2100") = < text = <"Tipo de estudio realizado">; description = <"Element: tipo del estudio realizado"
items("ac2200") = < text = <"Tcnica empleada">; descaiption = <"Cluster: informacin de la tcnica empleada en el estudio"
items("ac2210") = < text = <"Sedacin">; description = <"Element: sedacin empleada"
items("ac2220") = < text = <"Anticoagulacin">; description = <"Element: anticx)agulacin empleada"
items("ac2230") = < text = <"Catteres diagnstico">; description = <"Element: nmero de catteres de diagnstico"
items("ac2240") = < text = <"Va de abordaje">; description = <"Cluster: nmero de vas de abordaje empleadas"
items("ac2241") = < text = <"Yugular">; description = <"Element: nmero de vas de abordaje en yugular"
204
items("ac2242") = < text = <"Femoral">; descripton = <"Element: nmero de vas de abordaje en femoral"
items("ac2243") = < text = <"Subclavia">; descaription = <"Element: nmero de vas de abordaje en subclavia"
tems("ac2300") = < text = <"Parmetros electrofsolgicos">; description = <"Clust6r: contenedor para los parmetros electrofisiolgicos"
items("ac2400") = < text = <"Basales - electrocardograma">; descripton = <"Cluster: contenedor para los parmetros bsales - electrocardiograma"
items("ac2410") = < text = <"Electrocardiograma">; descripton = <"Cluster: contenedor para los parmetros de electrocardiograma"
tems("ac2411") = < text = <"Rtmo cardiaco">; description = <"Element: ritmo cardiaco"
items("ac2420") = < text = <"Frecuencia cardiaca">; descxiption = <"Element:fi-ecuenciacardiaca"
items("ac2430") = < text = <"Bloqueo AV">; desdiption = <"Cluster: bloqueo aurculo-ventricular"
items("ac2431") = < text = <"Bloqueo">; description = <"Element: existe bloqueo AV?"
items("ac2432") = < text = <"grado de bloqueo">; description = <"Element: grado del bloqueo AV detectado"
items("ac2440") = < text = <"Intervalos">; description = <"Cluster: intervalos medidos"
items("ac2441") = < text = <"Intervalo PR">; description = <"Element: Intervalo P R "
items("ac2442") = < text = <"Intervalo QRS">; description = <"Element: Intervalo QRS"
items("ac2443") = < text = <"Intervalo QT">; description = <"Element: Intervalo Q T "
items("ac2444") = < text = <"Intervalo QTc">; description = <"Element: Intervalo QTc"
items("ac2450") = < text = <"Basales">; description = <"Clust6r: contenedor para los parmetros bsales medidos"
items("ac2451") = < text = <"Longitud de ciclo">; description = <"Element: Longitud de c i d o "
items("ac2452") = < text = <"Intervalo PA">; description = <"Element: Intervalo P A "
items("ac2453") = < text = <"Intervalo AH">; description = <"Element: Intervalo AH"
items("ac2454") = < text = <"Intervalo HV">; description = <"Element: Intervalo H V "
items("ac2500") = < text = <"Funcin sinusal">; description = <"Cluster: contenedor para los parmetros de funcin sinusal"
items("ac2501") = < text = <"Longitud de ciclo basal">; description = <"Element: Longitud de ciclo basal"
items("ac2502") = < text = <"Pausa snusal">; description = <"Element: Pausa sinusal"
t6ms("ac2503") = < text = <"Bloqueo sinoatrial">; description = <"Element: Bloqueo sinoatrial"
items("ac2504") = < text = <"Marcapasos migratorio">; description = <"Element: Marcapasos migratorio"
items("ac2505") = < text = <"Tiempo de recuperacin sinusal">; description = <"Element: Tiempo de recuperacin sinusal"
items("ac2506") = < text = <"Tiempo de conduccin sinoatrial">; description = <"Element: Tiempo de conduccin sinoatrial"
tems("ac2507") = < text = <"Respuesta a la atropna">; description = <"Element: Respuesta a la atropina"
items("ac2508") = < text = <"Ritmo sinusal intrnseco">; desaiption = <"Element: Ritmo sinusal intrnseco"
items("ac2600") = < text = <"Conduccin AV">; description = <"Cluster: contenedor para los parmetros de conduccin A V "
items("ac2601") = < text = <"Punto de Wenckebach">; description = <"Element: Punto de Wenckebach"
items("ac2602") = < text = <"Periodo refractario del nodo AV">; description = <"Element:Periodo refractario del nodo A V "
tems("ac2700") = < text = <"Induccin de arritmias">; description = <"Cluster: contenedor para los parmetros de induccin de arritmias"
items("ac2800") = < text = <"Taquicardias supraventriculares">; description = <"Cluster: contenedor para los parmetros de induccin de taquicardias supraventriculares"
items("ac2810") = < text = <"Protooolo de estimulacin">; desaiption = <"Cluster: contenedor para los parmetros del protocolo de estimulacin"
items("ac2811") = < text = <"Nmero de ciclos de base">; description = <"Element: nmero de cidos de base"
items("ac2812") = < text = <"Nmero de extraestmulos">; description = <"Element: nmero de extraestmulos"
items("ac2813") = < text = <"Punto de estimulacin">; description = <"Element: punto de estimulacin"
items("ac2820") = < text = <"Tipo de arritmia nducida">; description = <"Element: contenedor para el tipo de arritmia inducida"
items("ac2850") = < text = <"Finalizacin">; description = <"Element: contenedor para la finalizacin"
items("ac2900") = < text = <"Taquicardias ventriculares">; descxiption = <"Cluster: contenedor para los parmetros de induccin de taquicardias ventriculares"
tems("ac2910") = < text = <"Protocolo de estimulacin">; description = <"Cluster: contenedor para los parmetros del protocolo de estimulacin"
items("ac2911") = < text = <"Nmero de cidos de base">; desaiption = <"Element: nmero de ciclos de base"
items("ac2912") = < text = <"Nmero de extraestmulos">; description = <"Element: nmero de extraestmulos"
items("ac2913") = < text = <"Punto de estimulacin">; description = <"Element: punto de estimulacin"
items("ac2920") = < text = <"Tipo de arritmia inducida">; description = <"Cluster: contenedor para el tipo de arritmia indudda"
items("ac3000") = < text = <"Ablacin">; description = <"Cluster: contenedor informacin de la abladn practicada"
items("ac3100") = < text = <"Tipo abladn">; description = <"Cluster: contenedor informacin del tipo de ablacin practicada"
items("ac3110") = < text = <"Nodo AV">; description = <"Cluster: Contenedor para el tipo: Nodo aurculo ventricular"
205
it6ms("ac3111") = < text
items("ac3114") = < text
items("ac3120'') = < text
items("ac3121 ) = < text
it6ms("ac3124")) = < text
tems("ac3130 ') = < text
items("ac3131 ') = < text
items("ac3136";') = < text
tems("ac3150"') = < text
tems("ac3160";') = < text
it6ms("ac3180 ') = < text
items("ac3300"') = < text
") = < text
items("ac3320")
: <"Objetivo">; description = <"Element: Objetivo de la ablacin practicada"

: <"Tipo de arritma">; description = <"Element: Tipo de arritmia del nodo A V "
: <"Taquicardia intranodal">; description = <"Cluster: Contenedor para el tipo: Taquicardia intranodal"
; <"Tipo">; description = <"Element: Tipo de taquicardia intranodal"
: <"Tipo abordaje">; description = <"Element: Tipo de abordaje"
: <"Va accesoria">; description = <"Cluster: Contenedor para el tipo: Va accesoria"
: <"Tipo">; description = <"Element: Tipo de va accesoria"
: <"Localizacin">; description = <"Element: Localizacin de va accesoria"
; <"Taquicardia auricular focal">; description = <"Cluster: Contenedor para el tipo: Taquicardia auricular focal"
: <"Localizacin">; description = <"Element: Idealizacin de la taquicardia auricular focal"
: <"Flutter">; description = <"Cluster: Contenedor para el tipo: Flutter"
: <"Tipo">; description = <"Element: Tipo de flutter"
: <"Objetivo">; description = <"Element: Objetivo de la ablacin"
: <"Fibrilacin auricular">; description = <"Cluster: Contenedor para el tipo: Fibriladn auricular"
; <"Tipo de abordaje">; description = <"Element: tipo de abordaje de la ablacin"
: <"Taquicardia ventricular">; description = <"Cluster: Contenedor para el tipo: Taquicardia ventricular"
: <"Tipo de TV">; description = <"Element: tpo de taquicardia ventricular"
: <"Tcnica">; description = <"Cluster: contenedor informacin tcnica empleada"
: <"Acceso">; description = <"Element: tipo de acceso empleado"
: <"Tipo catter ablacin">; description = <"El6ment: tipo de catter de ablacin empleado"
: <"Sistema de navegacin">; description = <"Element: sistema de navegacin empleado"
: <"Resultado del procedimiento">; description = <"Cluster: Resultado del procedimiento"
: <"Resultado">; description = <"Element: Resultado"
: <"Complcadones">; description = <"Element: Complicaciones"
206
CONCLUSIONES
Captulo 7. Conclusiones
7.
Conclusiones
Los resultados obtenidos cumplen en su totalidad los objetivos que se definieron en este trabajo de
tesis, exponindose a continuacin un resumen de las aportaciones realizadas.
Aportacin 1. Elaboracin de una estrategia global de integracin de la teleconsulta entre
profesionales sanitarios en el proceso asistencial.
Se estableci el contexto actual de estandarizacin de la HCE con aportaciones de CENTTC251 y
openEHR, que adopta una metodoga de elaboracin de normas cuyas caractersticas mas importantes
son: la existencia de un doble modelo (referencia y conocimiento), y el desarrollo controlado de los
conceptos del dominio.
Se analizaron los escenarios de actividad mas frecuentes en los que la teleconsulta puede darse en el
marco de una asistencia continuada, que son: Transferencia de responsabilidad iniciada por cualquiera
de las partes, provisin de servicio temporal sin transferencia de responsabilidad y con/sin peticin
previa de la parte solicitante, provisin de servicio continuo por dos o mas partes, comunicacin
indirecta iniciada por cualquiera de las partes, confirmacin de identidad de un solicitante de
informacin, y confirmacin de autenticidad de una fuente de informacin.
Se propuso como idea fuerza en la estrategia de integracin, considerar la teleconsulta como un
servicio asistencial mas o una parte de un servicio, ambos casos como actividad del proceso
asistencial, y se ha propuso una integracin basada en la actuacin en tres campos del nivel de
conocimiento del dominio: Componentes de informacin de propsito general (GPICs),
arquetipos/templates, y sistema de conceptos de continuidad asistencial.
Considera el autor que estas actuaciones de bajo nivel de abstraccin, sern mucho mas efectivas en el
proceso de integracin, que abordar un modelo de referencia genrico de la teleconsulta en el
escenario de continuidad asistencial de, probablemente, dudosa aplicabilidad.
Aportacin 2. Especificacin de los mensajes de peticin de servicio e informe sobre servicio.
Se han desarrollado los modelos de informacin de mensaje (MIM) y las descripciones jerrquicas de
mensaje (DJM) de los mensajes de peticin de teleconsulta e informe sobre teleconsulta, basados en
GPICs y siguiendo la metodologa actualizada del CEN/TC251. Dichos mensajes son las herramientas
bsicas de integracin de la teleconsulta en el proceso asistencial considerada como una actividad de
trabajo colaborativo en la agenda de unos profesionales sanitarios.
Se ha comprobado que los atributos de los GPICs clnicos y no-clnicos utilizados proporcionan
informacin contextual suficiente y/o referencia a informacin de contenido (p.ej. Extractos) para que
el binomio de mensajes de peticin/informe servicio sea suficiente para soportar todo tipo de
interacciones (evento de disparo, roles involucrados, interaccin soportada por la descripcin
jerrquica del mensaje, posible secuencia de mensajes relacionados, etc)
Aportacin 3. Especificacin de arquetipos relacionados con la teleconsulta.
La teleconsulta es un concepto excesivamente extenso para ser susceptible de ser arquetipado por un
nico arquetipo. Las aportaciones de mayor inters prctico que pueden hacerse en este campo son:
las que se refieren a arquetipos usados en la construccin de los mensajes de peticin e informe de
servicio, y los que se refieren a los extractos que salen de (peticin) o entran en (informe) la HCE del
paciente. Por razones de espacio, de estos ltimos solo se ha incluido uno en el captulo de resultados.
Se han especificado en lenguaje ADL vO.9 los dos arquetipos directamente relacionados con la
solicitud de teleconsulta e informe sobre la misma, teniendo como modelo de referencia la parte del
RIM en el que estn basados los GPICs. Se han utilizado los tipos de datos del CEN/TC251 [14796]
aunque en buen nmero de casos no se corresponden con el contenido de los doumentos de los GPICs
[14822], que estn tomados directamente de HL7-RIM 1.18.
Tambin se ha especificado un arquetipo de resultados (hallazgos) de un servicio que fue previamente
solicitado (se ha escogido como ejemplo el estudio electrofsiolgico), que tiene como modelo de
referencia el de EHR_Extract 13606:2003. Ha sido escogido a propsito, ya que es un caso de
servicio asistencial que no suele asociarse a la teleconsulta por implicar el traslado del sujeto de
prueba.
El arquetipo "Estudio electrofsiolgico" se ha aportado como especificacin que sirva como ejemplo
para los muy numerosos casos prcticos de solicitud de un profesional a otro, del informe sobre un
producto de estudio determinado, que siempre quedar almacenado en la HCE del sujeto de atencin.
Aportacin 4. Formalizacin del sistema de conceptos de continuidad asistencial
Se han estudiado las posibilidades de formalizar los conceptos de continuidad asistencial en base a
GPICs y/o arquetipos tanto primarios como organizativos basados en el modelo de referencia
EHR_Extract y tipos de datos CEN/TC251.
Se ha iniciado el desarrollo de un modelo de referencia del escenario de continuidad asistencial
inspirado en un modelo de trabajo colaborativo sntesis de varios existentes en la literatura.
208
Captulo?. Conclusiones
Se ha realizado un mapa de referencias cruzadas entre los conceptos de continuidad asistencial, los
GPICs existentes, y los nombres de clases y atributos del modelo de referencia de EHR_Extract.
Dado que muchos de los conceptos de continuidad asistencial son de muy alto nivel, y no estn
todava especificados los arquetipos previsiblemente involucrados, es una tarea que claramente
excede los lmites de este trabajo, y sin duda conformar una de las lneas futuras de trabajo.
7.1 Trabajo futuro

Aceptado como marco general la particin del universo del dominio en servicios (responsabilidades);
aceptado que para cada servicio definido en el dominio haya una familia de modelos (referencia,
conocimiento y servicio) (ver fig 3.4), y aceptada la separacin entre niveles de informacin y
conocimiento, el trabajo futuro necesariamente caer en uno de estos dos lados. Dependiendo del lado
elegido, el trabajo es bien diferente.
Si es en el nivel de informacin, el trabajo futuro estar en completar la definicin del servicio
EHR_Extract y servicios asociados (p.ej demogrfico, terminologa, mensajes, etc) hasta que se
terminen de especificar los tres modelos (ver fig. 3.6). Dentro de este nivel pueden vislumbrarse las
siguientes lneas de trabajo:
- Tareas de comprobacin de la validez de las aportaciones que han implicado tareas de desarrollo
(aportaciones 2, 3, 4).
El Laboratorio de Bioingeniera y Telemedicina del Hospital Universitario Puerta de Hierro de
Madrid, est involucrado (proyecto FIS RG03/117) en el desarrollo de varios servicios middleware
compatibles con el escenario de estandarizacin descrito en este trabajo de tesis. En un futuro
prximo se podr contar con la capacidad de conprobar la validez de las aportaciones realizadas:
El servicio de mensajera podr comprobar la vaUdez de la especificacin de los mensajes de
peticin/informe de teleconsulta.
El servicio EHR_Extract conjuntamente con el repositorio de arquetipos permitir comprobar la
validez del arquetipo de hallazgos de un estudio electrofsiolgico a la hora de introducir o extraer
informacin en el registro.
El resto de servicios que se estn desarrollando (p.ej demogrfico) junto con otros existentes (p.ej
terminologa) permitirn trabajar con el sistema de conceptos de continuidad asistencial formalizado y
comprobar, de forma experimental, su idoneidad en el trabajo clnico habitual.
- Tareas en la definicin de modelos de referencia, conocimiento y servicio en el servicio Guas
clnicas, Protocolos y Vas de asistencia.
Las herramientas que automatizan el flujo de trabajo como ayuda y soporte a los procesos
asistenciales, solo alcanzarn altos niveles de efectividad cuando "grandes bloques" de la actividad
209
Captulo?. Conclusiones
asistencial descansen sobre guas, protocolos y vias de asistencia. Asumir el trabajo colaborativo
como la forma habitual de trabajar que supone la continuidad asistencial, implicar un paso adelante
en ese sentido.
Considerar la teleconsulta entre profesionales sanitarios un servicio constituyente de cualquier plan de
atencin posibilita toda una lnea de trabajo tendente a su integracin en los modelos que definan el
servicio.
Si es en el nivel de conocimiento, la adopcin del desarrollo controlado de los conceptos del
dominio como una de las bases en las que se apoya actualmente el proceso de estandarizacin, hace
vislumbrar varias vas de trabajo. Como continuacin a este trabajo de tesis las mas cercanas a su
filosofa seran:
- Tareas en el interfaz entre terminologa de referencia y tipos de datos usados en GPICs y
arquetipos.
En la estandarizacin de la HCE queda una ingente tarea por hacer para rellenar el 'gap' entre los
conceptos de menor nivel del dominio, denominados trminos de referencia (p.ej los que contienen
SNOMED CT, LOINC, etc) y los vocabularios controlados (utilizando terminologa de HL7) que
constituyen los valores que pueden tomar los tipos de datos de los atributos de las clases de los
modelos de referencia. Trabajos parciales en este nivel, como puede ser abarcar los GPICs, arquetipos
directamente relacionados y conceptos de continuidad asistencial involucrados en la peticin de /
informe sobre servicios asistenciales, seguro que son bienvenidos y ampliamente reconocidos.
- Especificacin de arquetipos.
Para que funcionen los futuros sistemas de informacin, que veremos como gestionadores de
instancias de clases de los modelos de referencia, ser necesaria la existencia de repositorios de
arquetipos que estn basados en esas mismas instancias. Contribuciones consistentes en la
especificacin de nuevos arquetipos son absolutamente necesarias, si bien conviene tener claro desde
el inicio en este campo de trabajo, en qu marco (local, regional, europeo) se quiere jugar, y en qu
nivel de complejidad se puede hacerlo. Sera muy deseable que reuniones conjuntas de CEN/TC251
grupos WGl y WG2 delinearan lo antes posible, las normas de juego.
- Tareas de armonizacin de los conceptos de continuidad asistencial.
En primer lugar es necesario realizar tareas de armonizacin del sistema de conceptos de continuidad
asistencial respecto a otras normas ya aprobadas o en vas de serlo prximamente. La forma mas
correcta de afrontar este trabajo sera incorporarse al grupo 'Task Forc HISA' de revisin del
estndar CEN prEN12967 Health Informatics Service Architecture Part 1: Enterprise viewpoint, Part
2: Information viewpoint, Part-3: Computational viewpoint, que ha comenzado a realizar este trabajo
parcialmente, en los aspectos que interesan a la norma revisada.
- Tareas de formalizacin de los conceptos de continuidad asistencial.
210
Una vez armonizados con el resto de las normas, ser posible afrontar cx)n posibilidades de xito la
formalizacin de los cxinceptos de continuidad asistencial, a base de conceptos de menor nivel de
complejidad, GPICs y arquetipos.
El trabajo habr de orientarse fundamentalmente en el sentido de especificar arquetipos, basados lo
mas posible en los GPICs existentes o modificaciones de los mismos que el autor o autores de estos
trabajos consideren convenientes.
211
BIBUOGRAFIA
Captulo 8..Bibliografa
8.
Bibliografa
[12226]
CEN/TC251AVG1 prENV12226:1995 Medical informatics - Categorial structures of

systems of concepts - Model for representation of semantics.
[12539]
CEN/TC251/WG1 ENV 12539:1997 Medical Informatics - Request and report

messages for diagnostc service departinents.
[12587]
CEN Report: 1996. Medical Informatics - Methodology for ie development of

healthcare messages.
[12967-1]
CEN/TC251 prEN12967-l:2003 Health Informatics -Service architecture -Part 1:

Enterprise viewpoint.
[12967-2]
CEN/TC251 prEN12967-2:2003 prEN12967-2 Health informatics -Service

architecture -Part 2: Information viewpoint
[13606:1999]
CEN/TC251AVG1 prENV13606:1999 Health informatics - Electronic record

communication Parts 1-4
[13606-1:2003] CEN/TC251/WG1 prENV13606-1:2003 Health informatics - Electronic record

communication - Part 1: Reference Model
[13606-2:2003] CEN/TC251AVG1 prENV13606-2:2003 Heali informatics - Electronic record
communication - Part 2: Archetype interchange specificaton
[13606-3:2003] CEN/TC251AVG1 prENVI3606-3:2003 Health informatics - Electronic record
communication - Part 3: Reference archetypes and term list
[13606-5:2003] CEN/TC251AVG1 prENV13606-5:2003 Healti informatics - Electronic record
communication - Part 5: Exchange models
[13940]
CEN/TC251/WGl prENV13940:2000 Health informatics - System of concepts to

support continuity of care
[14720]
CEN/TC251AVG1 prENV 14720 Healtii informatics - Service request and report

messages - Part 1: Basic services including referral and discharge
[14796]
CEN/TC251AVG1 CEN/TS 14796:2003 Health Informatics - Data types
[14822]
CEN/TC251AVG1 prENV 14822:2003 Healtii informatics - General purpose

information components - GPIC. Parts 1-3
213
[18303]
ISO/TS 18303:2004 Health informatics - Requirements for an electronic health

record architecture
[Aaml]
Aarnio P, Rudenberg H, EUonen M, Jaatinen P. User satsfaction with

teleconsultations for surgery. Journal ofTelemedicine and Telecare 2000;6(4):237-41
[Aarn2]
Aarnio P, Jaatinen P, Hakkari K, Halin N. A new method for surgical consultations

with videoconference. Annales Chirurgiae et Gynaecologiae Fenniae
2000;89(4):336-40
[ACC]
American College of Cardiology (http://www.acc.org')
[ACR]
American College of Radiology (http://www. acr.org^
[Balb]
T, Sussmann H, Jansen T, Allescher HD, Horsch A Teleconsultation for endoscopic

diagnosis of gastrointestinal diseases-concepts and architecture of the service
ENDOTEL. StudHealth TechnolInform. 1999;68:234-7
[Balch]
Balch DC, Tichenor JM. Telemedicine expanding the scope of health care
information. JAm Med Inform Assoc. 1997;4(l):l-5
[Baru]
Baruffaldi F, Gualdrini G, Toni A Comparison of asynchronous and realtime

teleconsulting for orthopaedic second opinions. J Telemed Telecare 2002;8(5):297301
[Batt]
Battmann A, Knitza R, Janzen S, et al. Telemedicine: application of telepathologyremote microscopy for intraoperative diagnoses on frozen sections. Studies in Health
Technology and Informatics 2000;77:1127-30.
[Beall]
Beale T. Design principies for the EHR. OpenEHR Foundation. 2002

(http://www.openehr.org/Doc_html/Principles/design_principles.htm)
[Beal2]
Beale T. The health model universe. Ocean Informatics P/L.

(http://www.deepthought.com.auA
[Beal3]
Beale T. Archetypes: Constraints-based domain models for future-proof information

systems. 2002. (http://www.openehr.org/archetypes_technical.htm)
[Beal4]
Beale T. Archetype definition language (ADL). Ocean Informatics. 2003.

(http://www.oceaninformatics.biz/adl.html)
[BealeS]
Beale T, Heard S. Archetype Definition Language (ADL). Rev 0.9. 2003.

(http://www.oceaninformatics.biz/adl.html)
214
[Brah]
Brahams D. The medicolegal implications of teleconsulting in the UK. J Telemed

Telecare. 1995;1(4): 196-201
[Bruu]
Bruun-Rasmussen M, Bemstein K, Chronaki C. Collaboration~a new IT-service in

the next generation of regional health care networks. Int J Med Inf. 2003;70(2-3):20514
[Bui]
Bui AA, Taira RK, Goldman D, Dionisio JD, Aberle DR, El-Saden S, et al. Effect of
an imaging-based streamlined electronic healthcare process on quality and costs. Acad
Radiol. 2004;ll(l):13-20.
[Burg]
Burgiss S, Sprang R, Tracy J. Telehealth tchnology guidelines.

(http://telehealth.hrsa.gov/pubs/tech/techhome.htm)
[Cell]
Celler BG, Lovell NH, Basilakis J. Using information technology to improve the
management of chronic disease. MedJAust. 2003 Sep l;179(5):242-6
[CEN]
Comit Europeo de Normalizacin (http://www.centc251.org/)
[CDA]
HL7. The CUnical Document Architecture:2000.

(http://www.hl7.Org/library/standards_nonl.htm#CDA)
[Chan]
Chan FY, Soong B, Lessing K, et al. Clinical valu of real-time tertiary fetal
ultrasound consultation by telemedicine: preliminary evaluation. Telemedicine
Journal 2000;6(2):237-42
[Chro]
Chronaki CE, Lelis P, Demou C, Tsiknakis M, Orphanoudakis SC. An HL7/CDA

framework for the design and development of telemedicine services. In Proc EMBC
2001, 23rd Annual International Conference of the IEEE Engineering in Medicine
and Biology Society, 25-28 Oct. 2001, 2001 Instambul, Turkey
[Consorti]
Consorti F, Lalle C, Ricci FL, Rossi-Mori A. Relevance of mandates, notifications

and threads in the management of continuity of care. Stud Health Technol Inform.
2000;77:1035-9
[daSi]
da Silva VD. A remote second-look teleconsultation protocol on breast

cytopathology. Pathologica. 1998;90(6):824-5
[Dem]
Demartines N, Mutter D, Vix M, Leroy J, Glatz D, Rosel F, et al. Assessment of

telemedicine in surgical education and patient care. Annals of Surgery
2000;231(2):282-91.
215
Captulo S.-Bibliografa
[DSTC]
Tun, Z., Bird, L., and Goodchild, A. Validating Electronic Health Records Using
Archetypes and XML. Technical Report.
((http://titanium. dstc. edu. au/papers/acsc2002.pdf)')
[Ecch]
Eccher C, Berloffa F, Galligioni E, Larcher B, Forti S. Experience in designing and

evaluating a teleconsultation system supporting shared cate of oncological patients.
ProcAMIA Symp. 2003; :835
[Eiff]
EiffelStudio (http://www. eiffel.com/)
[EHCRSupA] UE-Telematics Applications Programme. European Healthcare Record Support

Action -EHCR SupA (http://www.chime.ucl.ac.uk/work-areas/ehrs/EHCR-SupAy)
[Elk]
Elkin P, Kemberg M, Rossi-Mori A Health Level 7- Templates SIG.

(http://www.hl7.org/library/committees/dss/minutes/elkin-presentation-10-2001.ppt')
[EUis]
Ellis C, Wainer J. A conceptual model of Groupware. In Proc. ACM Conf. On

Computer Supported Cooperative Work (CSCW'94), 1994:79-88
[Ette]
Etter M, Feussner H, Siewert JR. Guidelines for teleconsultation in surgery. The

Germn experience. Surg Endose. 1999;13(12):1254-5
[Fari]
Parias CRG, Pires LF, Sinderen M van. Conceptual frameworks for the development
of CSCW sysems. Technical Report CTIT 99-07, University of Twente, 1999
[FdP]
Pozo F, Gmez EJ, Hernando ME. Telemedicine: Teleconsultation between medical

professionals. Cap.Libro. Wiley Encyclopedia of BME
[Fraz]
Frazier P, Rossi-Mori A, Dolin RH, Alschuler L, Huff SM. The creation of an

ontology of clinical document ames. Medinfo. 2001;10(Pt l):94-8
[G8]
Nerlich M, Balas EA, Schall T, Stieghtz SP, Filzmaier R, Asbach P, Dierks C,

Lacroix A, Watanabe M, Sanders JH, Doarn CR, Merrell RC; G8 Global Health
^plications Subproject 4. Teleconsultation practice guidelines: report from G8
Global Health i^plications Subproject 4. Telemed J E Health. 2002; 8(4):411-8
[GeAul]
Distributed Systems Technology Centre. Good Electronic Health Record Project

(http://titanium. dstc. edu.au/gehr/)
[GeAu2]
Beale T. The Good Electronic Health Record. An EHR architecture for archetyped
health information systems. (http ://www.health.tno.nl/htmlmail/2001/epd/gehr.ppt^
216
[Gehrl]
CE-Advanced Informatics in Medicine Prograimne. Good European Health Record

Project - GEHR (http://www.chime.ucl.ac.uk/work-areas/ehrs/GEHR/)
[Gehr2]
Good European Health Record, (http://www.chime.ucl.ac.uk/workareas/ehrs/GEHR/Deliverables.htm)
[Gelh]
XML-Schema Archetypes Examples

(www, deepthou ght.com. au/it/archetvpes/output/man. html)
[Gilb]
Gilbert BK, Mitchell MP, BengaU AR, Khandheria BK. NASA/DARPA advanced
Communications technology satellite project for evaluation of telemedicine outreach
using next-generation Communications satellite technology: Mayo Foundation
participation. Mayo Clin Proc. 1999;74(8):753-7.
[Glou]
Glouberman S, Mintzberg H. Managing the care of health and the cure of diseasePart II: Integration. Health Care Manage Rev. 2001;26(l):70-84
[Gm]
Gmez EJ, del Pozo F, Ortiz EJ, Malpica N, Rahms H. A broadband multimedia
collaboratve system for advanced teleradiology and medical imaging diagnosis. IEEE
Trans Inf Technol Biomed. 1998;2(3): 146-55.
[Gran]
Granlund H, Thoden CJ, Carlson C, Hamo K. Realtime teleconsultations versus faceto-face consultations in dermatology: immediate and six-month outcome. J Telemed
Telecare. 2003;9(4):204-9
[Guil]
Guilfoyle C, Perry L, Lord B, Buckle K, Mathews J, Wootton R. Developing a

protocol for the use of telenursing in community health in AustraUa. J Telemed
Telecare. 2002;8 Suppl 2:33-6
[Harn]
Harno K, Arajarvi E, Paavola T, Carlson C, Viikinkoski P. Clinical effectiveness and

cost analysis of patient referral by videoconferencing in orthopaedics. J Telemed
Telecare. 2001;7(4):219-25.
[Heard]
Heard S, Beale T, Freriks G, Rosi-Mori A, Pishev O. Templates and archetypes: how

do we know what we are talking about?.
(http://www.openehr.org/repositories/repositories.html)
[Heij]
van Heijningen RI, Mannaerts GH, Steffens LF. Medicolegal aspects of international
teleconsultancy. Lancet. 2000;355(9205):757-8
[Hell]
Helleso R, Ruland CM. Developing a module for nursing documentation integrated in

the electronic patient record. J Clin Nurs. 2001 Nov;10(6):799-805
217
Captulo 8..Bibliografla
[Hisa]
Task Forc HISA. Revisin of ENV 12967: Health informatics - Service architecture
Parts 1-3. (http://www.centc251 .orgAVitems/Tflist.htm)
[HL7]
High Level 7 rhttp://www.hl7.orgA
[HL7 RIM-RM]
HL7 Reference Information Model (www.hl7.org/librarv/data-
model/RIM/modelpage_mem. htm^
[Hors]
Horsch A, tala T, Mikola T, Leonhardt P, Tobman M, Ntscher C, Sussmann H.

CDA-based integration of a teleconsultaion service into a regional electronic patient
record system. (www.iinse.med.tu-muenchen.de/ini/endotel/
veroefe/mie2003/horsch.pdf)
[Hustl]
Huston JL. A telemedical record model. J Telemed Telecare. 1997;3 Suppl 1:86-8
[Hust2]
Huston JL. Telemedical record documentation. Top Health InfManage.

1999;19(3):59-65
pCD]
World Health Organisation. ICD-10. The International Statistical Classifcation of

Diseases and Related Health Problems, tenth revisin,
(http ://www. who. int/whosis/icdlO/)
[ICPC]
WONCA. International classifcation of primary cate (ICPC) (second revisin)

(http://www.ulb.ac.be/esp/wicc/icpc2.html)
pSO]
International Organization for Standardization
(http://isotc.iso.ch/livelink/livelink. exe?func=ll&objId=529136&objAction=browse&sort=name)
[IsRM]
ISO/IEC 10746-2:1996. Information Technology. Open distributed processing.

Reference Model. Part 2: Foundations
[Jaat]
Jaatinen PT, Forsstrom J, Loula P. Teleconsultations: who uses them and how? /
Telemed Telecare 2002;8(6):319-24
[Jack]
Jacklin PB, Roberts JA, Wallace P, Haines A, Harrison R, Barber JA, et al; Virtual
Outreach Project Group. Virtual outreach: economic evaluation of joint
teleconsultations for patients referred by their general practitioner for a specialist
opinin. BMJ. 2003;327(7406):84.
(http://bmj.bmjjournals.com/cgi/content/full/327/7406/84V
[JoU]
Jollife VM, Harris DW, Whittaker SJ. Can we savely diagnose pigmented lesions
from stored video images? A diagnostic comparison between clinical examination and
218
stored video images of pigmented lesions removed for histology. Clinical and
Experimental Dermatology 2001 Jan;26(l):84-7
[Kays]
Kayser K. Interdisciplinary telecommunication and expert teleconsultaton in

diagnostic pathology: present status and future prospects. J Telemed Telecare
2002;8(6):325-30
[KIF]
Knowledge Interchange Format (KIF). DARPA Project.

(http://logc.stanford.edu/ki^kif.htnil)
[Lam]
Lamminen H, Lamminen J, Ruohonen K, Uusitalo H. A cost study of teleconsultation

for primary-care ophthalmology and dermatology. Journal ofTelemedicine and
Telecare 2001;7(3):167-73
[Lam2]
Lamminen H, Voipio V, Ruohonen K, Uusitalo H. Telemedicine in ophthalmology.

Acta Ophthalmol Scand 2003;81(2):105-9
[Lamb]
Lambrecht CJ, Canham WD, Gattey PH, McKenzie GM. Telemedicine and
orthopaedic care. A review of 2 years of experience. Clinical Orthopaedics and
Related Research 1998;348:228-32
[Larc]
Larcher B, Arisi E, Berloffa F, Demichelis F, Eccher C, Galligioni E, et al. Analysis

of user-satisfaction with the use of a teleconsultation system in oncology. Med Inform
InternetMed. 2003;28(2):73-84.
[Lee]
Lee JS, Tsai CT, Pen CU, Lu HC. A real time collaboration system for teleradiology
consultation. IntJMedlnf.
[Lian]
2003;72(l-3):73-9
Lian P, Chong K, Zhai X, Ning Y. The quality of medical records in teleconsultation.

J Telemed Telecare. 2003;9(1):35-41
[Lloy]
Lloyd J, Davies GP, Harris M., Integration between GPs and hospitals: lessons from a
divisin-hospital ^ros^&m. Ai^t Health Rev. 2000;23(4): 134-41
[Loan]
Loane MA, Bloomer SE, Corbett R, et al. A randomized controlled trial assessing the
health economics of realtime teledermatology compared with conventional care: an
urban versus rural perspective. Journal ofTelemedicine and Telecare 2001;7(2):10818
[Maier]
Maier M. Architecting principies for systems-of-systems. Technical Report.

University of Alabama. Himtsville 2000.
(http://www.infoed.com/Open/PAPERS/svstems.htm)
219
[Mair]
Mair F, Whitten P. Systematic review of studies of patient satisfaction with

telemedicine. British MedicalJournal 2000 Jun;320(7248):1517-20
[Mari]
Marley T. CENTC251 Message development armonisation with HL7. CEN/TC251

N04-005. (http://www.centc251.org/TCMeet/doclst/doclist2004.htm^
[May]
May C, Harrison R, MacFarlane A, Williams T, Mair F, Wallace P. Why do

telemedicine systems fail to normalize as stable models of service delivery? /
Telemed Telecare. 2003;9 Suppl l:S25-6
[McCo]
McComiell ME, Steed RD, Tichenor JM, Hannon DW. Interactive telecardiology for
the evaluation of heart murmurs in children. Telemedicine Journal 1999;5(2):157-61
[McCu]
McCue MJ, Hampton CL, Malloy W, Fisk KJ, Dixon L, Neece A. Financial analysis
of telecardiology used in a correctional setting. Telemedicine Journal andE-Health
2000;6(4):385-91
[McLa]
McLaren P, Ahlbom J, Riley A, Mohammedali A, Denis M. The North Lewisham

telepsychiatry project: beyond the pilot phase. / Telemed Telecare. 2002; 8 Suppl
2:98-100
[Meck]
Meck JM, Munshi G, Plempel J, Amato S, Macedonia C. Cytogenetic analysis using

telemedicine consultation: an improved means of providing expert cross-coverage.
Genetics in Medicine 1999 Nov-Dec;l(7):328-31
[Meij]
Meijer WJ, Vermeij DJ. A comprehensive model of cooperation between caregivers

related to quality of care. IntJ Qual Health Care. 1997;9(l):23-33
[Mili]
Millman DS, Klesel AB. Telecardiology: legal issues and new developments.
Telemed Today. 1999;7(3):27-9
[Mykk]
Mykkanen J, Tikkanen T, Rannanheimo J, Eerola A, Korpela M. Specifcation levis

and coUaborative definition for the integration of health Information systems. Stud
Health Technol Inform. 2003;95:304-9
[Nhsh]
NHS Headings Project (http://www.nhsia.nhs.uk/headings/pages/default.asp)
[Oacis]
OACIS-GEHR transformation process

(titanium. dstc. edu. au/papers/GPCG_Proj ect2_01 .pdf)
[Oakl]
Oakley AM, Kerr P, DuffiU M, et al, Patient cost-benefits of realtime teledermatology

- a comparison of data from Northern Ireland and New Zealand. Journal of
Telemedicine and Telecare 2000;6(2):97-101
220
Captulo 8..BibKografa
[OMG]
OMG Healthcare Domain Taskforce (HDTF) rhttp://healthcare.omg.orgA
[OMG-OCL]
UML 2 OCL
(http://www.omg.Org/technologv/documents/modeling_spec_catalog.htm#UML)
[openEHR]
Open Electronic Health Records Foundation (http://www.openehr.org/)
[OWL]
W3C Web Ontology Language 1.0 Reference (www.w3.org/2001/sw/WebOnty)
[PagJ]
Page-Jones M. Fundamentis of object oriented dessing. Addison Wesley, 2000
[Paiv]
Paiva T, Coelho H, Araujo MT et al. Neurological teleconsultation for general

practitioners. Journal ofTelemedicine and Telecare 2001;7(3):149-54
[Pall]
Pallawala PM, Lun KC. EMR based telegeriatric system. Int J Med Inf. 2001;61(23):229-34.
[Pap]
Pap SA, Lach E, Upton J. Telemedicine in plstic surgery: E-consult the attending
surgeon. Plast Reconstr Surg. 2002;110(2):452-6
[Phil]
Philips CM, Balch D, Schanz S, Branigan A. Teledermatology: Issues in remote

diagnosis and management of cutaneous disease. Current Problems in Dermatology
2002;14(1): 7-38.
[PICN]
Professionals and citizens network for integrated care -PICNIC IST-1999-10345.

D4.1 Collaboration Service IT-response. Description of the Selected Service,
(www. medcom. dk/picnic/deliver ables/ D4.2-Collaboration-vl -7. doc)
[Pine]
Pinelle D, Gutwin C. Supporting collaboration in multidisciplinary home care teams.

In Proc AMIA Symp. 2002;617-21
[Plin]
Plinkert PK, Plinkert B, Zenner HP. Telemedicine in otorhinolaryngology. Basic

principies and possible applications. HNO 2000 Sep;48(9):639-44
[Protege]
The Protege Ontology Editor and Knowledge Acquisition System

(protege, stanford. edu/index. shtml)
[Pyth]
P}ôn programming language (http://www.pvthon.org/)
[Rectl]
Rector AL. CUnical terminology: why is it so hard? Methods Inf Med. 1999;38(45):239-52
[Rect2]
Rector AL. The interface between Information, terminology, and inference models.
Medinfo. 2001;10(Pt l):246-50
221
[RosMl]
Rossi Mor A, Consorti F. Structures of clinical information in patient records. In

ProcAMIA Symp. 1999;: 132-6
[RosM2]
Rossi Mor A, Consorti F. Structuring clinical information in healthcare records. Stud

Health Technol Inform. 1999;68:862-5
[RosMoS]
Rossi-Mori A, De Simone M, Lalle C, Ricci FL. A model for structured description of

healthcare activities and related data. In C. Gordon, JP Christensen Eds: Health
telematics for clinical guidelines and protocols. IOS Press, pp 185-198,1995
[Sabl]
Sable C, Roca T, Gold J, Gutirrez A, Gulotta E, Culpepper W. Live transmission of

neonatal echocardiograms from underserved reas: accuracy, patient care, and cost.
Telemedicine Journal 1999;5(4):339-47
[Salv]
Salvador CH, Gonzlez MA, Muoz A, Pascual M. Teleradiology from primary care:
comparison of user activity in two different scenarios. J Telemed Telecare.
2002;8(3):178-82.
[Saw]
Sawyer MA, Lim RB, Wong SY, Cirangle PT, Birkmire-Peters D. Telementored
laparoscopic cholecystectomy: a pilot study. Studies in Health Technology and
Informatics 2000;70:302-8
[Scha]
Schanz SJ. A queston in desperate need of an answer: where does a teleconsultation

occur? Telemed Today. 1998;6(6):17, 32
[Shum]
Shum SB. Representing hard-to-formalise, contextualised, multidisciplinary,

organisational knowledge. Knowledge Media Institute. The Open University Milton
Keynes. (http://kmi.open. ac.uk/~simonb/)
[Sico]
Sicotte C, Lehoux P. Teleconsultation: rejected and emerging uses. Methods InfMed.

2003;42(4):451-7
[SmAC]
Smith AC, Williams M, Van der Westhuyzen J, McCrossin R, Isles A, Wootton R. A

comparison of telepaediatric activity at two regional hospitals in Queensland. J
Telemed Telecare 2002;8 Suppl 3:S3:58-62
[SmRS]
Smith RS. Telemedicine and trauma care. Soutiiern Medical Journal 2001; 94(8):8259
[Smyt]
Smythe J, Yolton RL, Leroy A, et al. Use of teleoptometry to evalate acceptability

of a rigid gas-permeable contact lens. Optometry 2001;72(l):13-8
222
[Snom]
NHS Information Authority. SNOMED Clinical Terms (SNOMED CT).

(http ://www. nhsia.nhs .uk/snomed/pa ges/default. asp)
[soys]
Soysal E. ADL Editor.

http://soysal.com/modules.php?op=modJoad&name=Downloads&fle=index&req=v
ewdownload&cid=2
[Stan]
Stanberry B. The legal and ethical aspects of telemedicine. 4: Product liability and
jurisdictional problems. J Telemed Telecare. 1998;4(3): 132-9
[Suth]
Sutherland L, Igras E, Ulmer R, Sargious P. A laboratory for testing the

interoperability of telehealth systems. J Telemed Telecare. 2000;6 Suppl 2:S74-5
[Synx]
UE-Telematics i^plicatons Programme. Synergy on the Extranet Project - SynEx

(http://www.chime.ucl.ac.uk/work-areas/ehrs/SynEx/)
[Tachl]
Tachakra S, HoUingdale J, Uche CU. Evaluation of telemedical orthopaedic speciality

support to a minor accident and treatment service. Journal of Telemedicine and
Telecare 2001;7(1):27-31
(Tach2]
Tachakra S, Sivakumar A, Hayes J, Dawood M. A protocol for telemedical

consultaton. J Telemed Telecare. 1997;3(3): 163-8
[Thor]
Thorley PJ, Beacock DJ, Trickett CA, Sivananthan UM. 18FDG SPECT to assess
myocardial viability: inital experience at a hospital remote from a cyclotron. Nuclear
Medicine Communications 2000;21(8):715-8
[Toge]
Together ControlCenter (http://www.borland.com/together/)
[Wagn]
Wagner A, Undt G, Schicho K, Wanschitz F, Watzinger F, Murakami K, et al.

Interactive stereotaxic teleassistance of remote experts during arthroscopic
procedures. Arthroscopy 2002;18(9):1034-9
[WaUl]
Wallace P, Haines A, Harrison R, Barber J, Thompson S, Jacklin P, et al. Joint

teleconsultations (virtual outreach) versas standard outpatient appointments for
patents referred by their general practtoner for a specialist opinin: a randomised
trial. Lancet. 2002 Jun8;359(9322):1961-8
[Wall2]
Wallace P, Haines A, Harrison R, Barber JA, Thompson S, Roberts J, Jacklin PB,

Lewis L, Wainwright P; Virtual Outreach Project Group. Design and performance of
a multi-center randomized controUed trial and economic evaluation of joint teleconsultations. BMCFamPract. 2002;3(1):1 (http://www.biomedcentral.com/14712296/3/1')
223
Captulo 8..BibUografla
[Weer]
Weerakkody G, Ray P. CSCW-based system development methodology for healthcare information systetns. TelemedJE Health. 2003 Fall;9(3):273-82
[Whit]
Whitten PS, Mair FS, Haycox A, May CR, Williams TL, Hellmich S. Systematic
review of cost effectiveness studies of telemedicine interventions. BMJ. 2002 Jun
15;324(7351):1434-7.
224
ANEXOS
Captulo 9. Anexos
Anexo 1. GPICs No-Clnicos

GPIC_ID = 2.001 p
GPIC_ID = 2.002 p
GPIC_ID = 2.003 p
GPICJD = 2.004 p
GPICJD = 2.005 p
GPICJD = 2.006 E
GPIC_ID = 2.007
GPIC_ID = 2.008 E
GPICJD = 2.009 E
GPICJD = 2.010 R
GPICJD = 2.011 R
GPICJD = 2.012 R
GPICJD = 2.013 E
GPICJD = 2.014 E
GPIC_ID = 2.015 E
GPIC_ID = 2.016 E
GPICJD = 2.017 E
GPICJD = 2.018 E
GPICJD = 2.019 E
GPICJD = 2.020 E
GPICJD = 2.021 E
GPICJD = 2.022 E
GPICJD = 2.023 R
GPICJD = 2.024 R
GPIC_ID = 2.025 P
GPICJD = 2.026 P
GPICJD = 2.027 P
GPICJD = 2.028 P
GPICJD = 2.029 P
GPICJD = 2.030 P
GPICJD = 2.031 P
GPICJD : 2.032 P
GPIC_ID = 2.033 R
GPIC_ID = 2.034 R
GPIC ID = 2.035 RL
GPIC~ID = 2.036 R
GPICJD = 2.037 R
GPICJD: = 2.038 RL
GPIC_ID = 2.039 R
GPICJD = 2.040 R
GPICJD: = 2.041 R
GPICJD: = 2.042 R
GPICJD = 2.043 RL
GPICJD = 2.044 P
GPICJD = 2.045 P
GPIC_ID = 2.046 P
GPIC_ID: : 2.047 P
GPICJD: : 2.048 P
GPICJD: : 2.049 P
GPIC_ID: : 2.050 P
GPICJD: : 2.051 P
GPICJD: : 2.052 P
GPICJD : : 2.053 P
GPICJD : : 2.054 P
GPICJD : : 2.055 E
GPICJD : : 2.056 E
GPICJD : = 2.057 R
GPICJD : = 2.058 R
GPICJD : = 2.059 P
GPICJD : = 2.060 P
GPICJD : = 2.061 P
GPICJD : = 2.062 R
GPICJD : = 2.063 P
GPIC ID : = 2.064 R
ParticipacnPersonaNoSamtaria(NonHealthcarePersonPartcipation)
PartidpadnProfesionalSamtario(HealthcareProfessionalParticipaton)
ParticipacnOrganizacinSanitaria(HealthcareOrganisatonParticipaton)
PartidpacinDispositvo (DevicePartidpation)
PartidpadnAgenteSanitario(HealthcareAgentPartdpaton)
Persona (Person)
Lenguaje (LanguageCommunication)
Organizadn (Organisaton)
OrgaDzadnldentfcada(IdentiedQrganisation)
JerarquaOrganizadn (OrganisatonHierardiy)
OrganzadnReladonada(RelatedOrganisation)
PersonaDeContacto (ContactPerson)
IdentficadnSujetoDeAtendn(SubjectOfCareldentficaton)
SujetoVivoIdentifcado(IdentifedLivingSubjed)
IdentficadnSujetoDeAtendnPersona(SubjectOfCarePersonIdentfication)
IdentificadnSujetoDeAtendnAnimal(SubjedOfCareAniinalIdentfcation)
SujetoDeAtendn (SubjectOfCare)
SujetoDeAtendnPersona(SubjectOfCarePerson)
InformadnEstndarDePadente(PatentStandardlnformation)
InfonnadnExtendidaDePadente(PatientExtendedlnformation)
SujetoDeAtendnAnimal (SubjectOfCareAnimal)
SujetoDeAtendnGnipoAnimal (SubjectOfCareAnimal Group)
SujetoDeAtendnReladonado(RelatedSubjectOfCare)
ParteReladonadaConSujetoDeAtendn(SubjectOfCareRelatedParty)
SujetoDeAtendnReferendado(ReferencedSubjectOfCare)
SujetoDeAendnPartidpante(PartidpatmgSubjectOfCare)
PadentePartidpante (PartdpatingPatient)
PadentePartidpanteldentificado(IdentifiedPartidpatingPatient)
ParteReladonadaConPadentePartidpante(PartidpatingPatientRelatedParty)
SujetoDeAtendnReladonadoPartidpante(PartdpatmgRelatedSubjectOfCare
ReceptorServidoAsistendal(CareServiceRedpient)
SujetoDePrueba(SubjectOfInvestigation)
ProfesionalSanitario (HealthcareProfessional)
ProfesionalSaiiitarioIdentficado(IdentifiedHealthcareProfessional)
ProfesionalSanitarioReladonado(RelatedHealthcareProfessional)
OrganizadnSanltara (HealthcareOrganisation)
OrgaDzadnSanitarialdentifcada(IdentiedHealthcareOrgamsation)
OrganizadnSanitariaReladonada(RelatedHealthcareOrgaiiisation)
ParteSanitaria (HealthcareParty)
ParteSanitarialdentificada(IdentifedHealthcareParty)
AgenteSanitario (HealthcareAgent)
AgenteSanitarioIdentificada(IdentfiedHealthcareAgent)
AgenteSanitarioReladonado(RelatedHealthcareAgent)
ProfesionalSanitarioReferendado(ReferencedHealthcareProfessional)
OrganizadnSantariaReferendada(ReferencedHealthcareOrganisation)
DispositvoSanitarioReferendado(ReferencedHealthcareDevice)
ParteSanitariaReferendada(ReferencedHealthcareParty)
AgenteSaiiitarioReferendado(ReferencedHealthcareAgent)
ProfesionalSanitarioPartdpante(PartidpatmgHealthcareProfessonal)
ProfesionalPartidpanteldentficado(IdentfiedPartdpatingProfessional)
OrganzadnSanitariaPartidpante(PartdpatingHealthcareOrganisaton)
Organ2adnPartidpanteIdentfcada(IdentfiedPartdpatingOrganisaton)
ParteSanitariaPartdpante(PartdpatingHealthcareParty)
AgenteSamtaroPartdpante(PartdpatmgHealthcareAgent)
Dispositivo (Device)
Dispositivoldentificado (IdentifiedDevice)
DispositivoReladonado (RelatedDevice)
DispositivoReladonadoIdentificado(RelatedldentifiedDevice)
DispositivoUsado (DevicelnUse)
DispositivoUsadoIdentificado(IdentifiedDevicelnUse)
ParmetroDispositivo (DeviceParameter)
LugarDeAsistenda (CareLocation)
Lugar DeAsistendaUsado (CareLocationlnUse)
LugarNoAsistendal (GeographicLocation)
225
Captulo 9. Anexos
GPICJD:
GPICJD:
GPICJD:
GPICJD:
GPICJD:
GPICJD :
GPIC ID :
2.065
2.066
2.067
2.068
2.069
2.070
2.071
A
A
AR
AR
AR
AR
AR
TransporteSujetoVivo (livingSubjectTransportation)
TransporteSujetoNoVivo(NonIivingEntityTraiisportaton)
TraiisporteSujetoVivoRelacionado(RelatedlivingSubjectTransportation)
TransporteSujetoNoVivoRelacionado(RelatedNonLivingEntityTransportaton)
CosteAsistencial (CareCost)
Autorizacin (Authorisation)
AcuerdoSobreServido (ServiceAgreement)
Anexo 2. GPICs Clnicos

GPICJD = 3.001
GPICJD = 3.002
GPIC_ID = 3.003
GPIC_ID = 3.004
GPIC_ID = 3.005
GPICJD = 3.006
GPICJD = 3.007
GPICJD = 3.008
GPICJD = 3.009
GPIC_ID = 3.010
GPICJD = 3.011
GPICJD = 3.012
GPICJD = 3.013
GPICJD = 3.014
GPICJD = 3.015
GPIC_ID = 3.016
GPICJD = 3.017
GPICJD = 3.018
GPICJD = 3.019
GPIC_ID = 3.020
GPICJD = 3.021
GPICJD = 3.022
GPICJD = 3.023
GPICJD = 3.024
GPICJD = 3.025
GPICJD = 3.026
GPICJD = 3.027
GPIC_ID = 3.028
GPICJD = 3.029
GPIC_ID = 3.030
GPIC_ID = 3.031
GPICJD = 3.032
GPICJD = 3.033
GPICJD = 3.034
GPICJD = 3.035
GPICJD = 3.036
GPICJD = 3.037
GPICJD = 3.038
GPIC_ID = 3.039
GPIC_ID = 3.040
GPICJD = 3.041
GPIC_ID = 3.042
GPIC_ID = 3.043
GPIC_ID = 3.044
GPIC_ID = 3.045
GPIC_ID = 3.046
GPIC_ID = 3.047
GPIC_ID = 3.048
GPICJD = 3.049
GPICJD = 3.050
GPICJD = 3.051
GPICJD = 3.052
GPICJD = 3.053
GPICJD = 3.054
R
P
E
RL
R
A
P
AR
E
P
R
P
P
R
A
R
A
A
A
AR
A
AR
A
AR
A
AR
AR
A
A
A
AR
A
AR
AR
AR
AR
P
R
AR
A
A
R
R
P
R
E
R
P
AR
A
AR
AR
P
A
ObjetoAnalizable (AnalysableObject)
ObjetoAnalizableUsado (AnalysableObjectlnUse)
Espcimen (Spedmen)
ObjetoAnalizableReladonado (RelatedAnalysableObjert)
EspcimenManufacturado (ManufacturedSpedmen)
TratamientoEspcimen (SpedmenTreatment)
TratamientoEspdmenReladonado (RelatedSpedmenTrearment)
TratamientoEspdmenAsodado (AssodatedSpedmenTreatment)
ProductoDeEstudio (StudyProdua)
CaractersticaDelObjeto (ObjectCharacteristic)
MaterialPreservadn (PreservationMaterial)
ObjetoAnalizableAdquirido (AcquredAnalysableObjea)
AdquisidnObjetoAnalizable (AnalysableObjectAcquisition)
AdquisidnObjetoReladonada (RelatedObjectAcquisition)
ProcedimientoAdquisidn (AcquisitionProcedure)
ReferendalnformadnExtema (ExternalDataReference)
InformadnClmca(ClinicalInformation)
ComplejoDeInformadnClnica (ClimcaUnformationComplex)
AgrupadnDelnfonnadnClnica (ClinicalInformationContext)
ComplejoDelnformadnClnicaReladonado (RelatedClinicalInformationComplex)
ItemDelnformadnClnica (ainicallnformationltem)
InfonnadnClncaReladonada (RelatedClinicalInformation)
ObservadnClnica(ClinicalObservation)
CondidnDelPadenteReladonada (RelatedPatientCondition)
Procedimientoanico(ainicalProcedure)
ProcedimientoDePreparadnPadente (PatientPreparationProcedure)
SustandaDePreparadnPadente (PatientPreparationSubstance)
Consejo (Counselling)
InformadnClnicaNoCIasifcada (UnclassfedCIimcalInfonnation)
PetidnPrueba(InvestigationRequest)
PetidnPruebaReladonada (RelatedlnvestigationRequest)
ResultadoPrueba (InvestigationResultItem)
ResultadoPruebaReladonado (RelatedlnvestigationResult)
ReferendaNormalidad(ReferencelJimt)
ReferendaPobladonal (ReferencePopulation)
EspedficadnPnieba(IhvestigationSpedficaton)
Sistema/Componente (BodySystem)
Sistema/ComponenteReladonado (RelatedBodySystem)
ProcedimientoMedida(MeasurementProcedure)
TratamientoConMedicamento (MedicationTreatment)
SuministroMedicamento (MedicationSupply)
Medicamento (MedidnalProduct)
IngredienteMedicamento(Ingredient)
MedicamentoUsado(MedicinalProduaInUse)
PaqueteMedicamento (MedidnalProductPack)
PaqueteMedicamentoUsado (MedidnalProductPackInUse)
AplicadnMedicamento (MedicationAppliance)
AplicadnMedicamentoUsado(MedicationAppliancelnUse)
RgimenTratamientoConMedicamento (MedicationTreatmentRegimen)
DosisAdministradnMedicamento (DoseAdministration)
CondidnTratamientoConMedicamento (MedicatonTreatmentCondition)
RutaTratamiento (RoutingOption)
DispositivoRuta (RoutingDevice)
PetidnDeServidoAsistental (CareServiceRequest)
226
Captulo 9. Anexos
GPIC_ID = 3.055
GPIC_ID = 3.056
GPIC_ID = 3.057
GPIC_ID = 3.058
GPIC_ID = 3.059
GPIC_ID = 3.060
GPIC_ID = 3.061
AR
A
AR
A
AR
AR
AR
PetidnDeServidoReladonada (RelatedServiceRequest)
InformeSobreServidoAsistendal (CareServiceReport)
InformeSobreServidoReladonado (RelatedServiceReport)
Encuentro (CareEncounter)
EncuentroReladonado (RelatedCareEncounter)
ProvisinServidoAsistendal (CareServiceDelivery)
ActividadPreviaReladonada (PreviousRelatedActivity)
Anexo 3. Clases de Entidades

Mnemnico
Nombre de Impresin
Descripcin
ENT
ORG
PUB
Entidad
Entidad Organizadn
Institudn Pblica
ESTADO
Estado
PSN
HCE
EntidadPersona
Entidad esquema sanitario
UV
EntidadSujetoVivo
Corresponde a la clase Entidad.

Una estructura sodal o legal formada por seres himianos.
Una agenda del pueblo de un estado frecuentemente asumiendo alguna
autoridad sobre im asvinto concreto. Incluye gobierno, agendas
gubernamentales, asodadones.
Un cuerpo de personas organizado polticamente unido por territorio,
cultura 0 etnia, teniendo soberana (hasta un derto punto) otorgada por
otros estados (estados rodeantes o vecinos). Esto incluye pjises
(nadones), provindas (p. ej., uno de los Estados Unidos de Amrica o un
departamento francs), condados o munidpios. Refinar usando, p. ej.,
cdigos de pas ISO, cdigos de estado FIPS-PUB, etc.
Un sujeto vivo de la espeda Homo sapiens.
Un esquema sanitario incluido para servir como entidad de recepdn de
documentos en el manejo de historias mdicas.
Cualquier cosa que esendaknente tiene la propiedad de vida
independientemente de su estado actual (un cadver humano continua
siendo esendahnente un sujeto vivo).
NLIV
ANM
MIC
EntidadSuietoPersonaNoViva
Animal
Microorganismo
PDsrr
PSN
MAX
Planta
EntidadPersona
EntidadMaterial
MMAT
CONT
HOLD
EntdadMateralManufacturado
EntidadContenedor
Poseedor
DEV
CER
EntidadDispositivo
Representadn de Certificado
MODDV
EntidadModaldadlmagen
CHEM
Sustanda qiimica
FOOD
Comida
ORG
PUB
EntidadOrganizadn
Institudn Pblica
PLC
EntidadLugar
CITY
COUNTRY
COUNTY
Ciudad 0 pueblo
Pas
Condado o parroquia
PROVINCIA
Estado 0 provinda
Un sujeto vivo del reino animal.

Todo organismo vivo unicelular induyendo protozoos, bacteria,
levadura, virus, etc.
Un sujeto vivo del orden de las plantas.
Un sujeto vivo de la espeda Homo sapiens.
Cualquier cosa que tenga extensin en espado y masa, puede ser de
origen vivo o no vivo.
Corresponde a la clase MaterialManufacturado.
Un contenedor de otras entidades.
Un tipo de contenedor que puede poseer ottos contenedores u otros
poseedores.
Un artefecto fsico que almacena informadn sobre el otorgamiento de
autorizadn.
Clase para contener atributos singulares de equipos de diagnstico por
imagen.
Una sustanda que se define plenamente por una frmula qumica
orgnica o no orgnica, incluye mezclas de otras sustandas qumicas.
Refnar usando, p. ej., cdigos lUPAC.
Entidades ocurriendo en la naturaleza, procesadas o manufacturadas que
se emplean prindpalmente como comida para seres humanos y einimales.
Una estructura sodal o legal formada por seres hiunanos.
Una agenda de las personas de un estado frecuentemente asumiendo
alguna autoridad sobre un asunto concreto. Incluye gobierno, agendas
gubernamentales, asodadones.
Un lugar o sitio fsico con su estructura conteniente. Puede ser natural o
hecho por el hombre. La posidn geogrfica de un lugar puede o no ser
constante.
El territorio de una dudad, pueblo u otro munidpio.
El territorio de ima nadn soberana.
El territorio de un condado, parroquia u otra divisin de un estado o
provinda.
El territorio de un estado, provinda, departamento u otra divisin de un
227
Captulo 9. Anexos
RGRP
pas soberano.
Una agrupacin de recursos (personal, material o lugares) para ser
empleado para cuestiones de agenda. Puede ser una agrupacin de
recursos similares, un equipo o una combinacin de personal, material y
lugares.
Grupo
Anexo 4. Cdigo Determinador de Entidades

Mnemnico
Nombre de
Impresin
Descripcin
KIND
desCTito
QUANTIFIED_KIN
D
descrito
cuan tincado
INSTANCE
especfico
El determinante descrito se emplea para indicar el hecho de que la Entidad en

cuestin se toma como una desCTipdn general de \m tipo de cosa que se puede
tomar en su integridad, en parte o por mltiples.
El determinante cuantificado descrito indica que la Entidad en cuestin se toma
como una desaripdn general de una cantidad especfica de una cosa. Por ejemplo,
QUANTIFED KIND (tipo cuantificado) de una jeringuilla (cantidad = 3)
representa exactamente tres jeringuillas.
El determinante especfico indica que la Entidad en cuestin se toma como un caso
de una cosa especfica. Por ejemplo, un CASO humano (cantidad = 1) representa
exactamente im ser humano.
Anexo 5. Clases de Roles

Mnemnico
Nombre de Impresin
Descripcin
ROL
PAYEE
Rol
Portador
PAYOR
Pagador de la factura
COVPTY
Parte cubierta
POLHOLD
Titular de la pliza
SPNSR
Patrocinador
Corresponde a la clase de rol

Rol de una organ2acin o individuo designado para recibir el pago
por xma reclamacin contra una cobertura en particular. La entidad
evaluadora es la organizacin que remite la factura en cuestin.
Rol de una organizacin que se compromete a aceptar facturas de
reclamaciones, evaluar la cobertura o pagos deudores de esas facturas
y pagar las facturas a los cobradores designados. Este rol puede ser o
la aseguradora o una tercera organizacin autorizada por la
aseguradora. La entidad evaluadora es la organizacin que asegura la
cobertura reclamada.
Una clase de rol realizado por una persona que recibe cobertura de
beneficio bajo los trminos de una pliza de seguros en particular. La
aseguradora es la entidad evaluadora. La parte cubierta recibe
cobertura por alguna relacin contractual o de otro tipo con el titular
de la pliza. Este motivo de cobertura est capturado en 'Role.Code'
y un enlace Rol con cdigo tipo de autoridad indirecta debe incluirse
usando el rol del titular de la pliza como fuente, y el rol de la parte
cubierta como diana. Se hace hincapi en el hecho de que una pliza
en particular puede cubrir varios individuos, uno de los cuales puede
ser, pero no necesariamente es, el titular de la pliza. As que la
nocin de la parte cubierta es un rol distinto del rol del titular de la
pliza.
Un rol realizado por una entidad, generalmente un individuo que tiene
una pliza de seguros. La aseguradora de esa pliza es la entidad
evaluadora. Titular de la pliza y suscritor son trminos equivalentes.
El identificador de la pliza se captura en 'Role.id' cuando el Rol es
titular de una pliza. Una pliza en particular puede cubrir varios
individuos, uno de los cuajes puede ser, pero no necesariamente es, el
titular de la pliza. As que la nocin de la parte cubierta es un rol
distinto del rol del titular de la pliza.
Un rol realizado por una entidad, generalmente una organizacin que
es el patrocinador de un plan de seguros. La aseguradora de ese plan
es la entidad evaluadora. Ejemplos incluyen el caso en el cual una
228
Captulo 9. Anexos
UNDWRT
Aseguradora
CRED
Entidad con credenciales
CERT
RolEntidadCertificada
PROV
RolProveedorAsistendaSanitaria
UC
Entidad Autorizada
HCFAC
Centro sanitario
PROV
RolProveedorAsistendaSanitaria
ASSIGNED
RolEntidadDesignada
QUAL
Entidad cualificada
GEN
Tiene generalizadn
GRIC
Tiene genrico
PART
Parte
INGR
Ingrediente
ADTV
Aditivo
COLR
Aditivo colorante
FLVR
Sabor
PRSV
Conservante
STBL
Estabilizador
Acri
Ingrediente activo
BASE
Base
corporadn en particular puede patrocinar un plan para sus

empleados, pero las plizas individuales son una obligadn
contractual entre los empleados y la aseguradora. En general, el rol
del patrocinador es negodar y establecer los trminos del plan y
calificar individuos quienes pueden llegar a ser titulares de una pUza
bajo el plan.
Un rol realizado por una organizadn que asegura o acepta
responsabilidad fiscal por planes de seguros y las plizas que se crean
bajo esos planes.
Un rol realizado por una entidad que redbe aredendales de la entidad
evaluadora.
Este concepto ha sido desaprobado. Utilice en su lugar
RolEntidadAutorizada. Este cambio se adopt demasiado tarde para
permitir que el material del Ballot#3 fiera reesaito. Este concepto se
omitir del vocabulario en agosto de 2002. Una reladn en que la
entidad evaluadora autoriza al actor a llevar a cabo dertas actividades
que caen bajo la jurisdicdn de la evaluadora (p. ej., una autoridad
sanitaria que emite Ucendas a proveedores de asistenda sanitaria, una
autoridad de trfico emitiendo carns a conductores, etc.).
Una Entidad (actor) autorizada a proveer servidos de asistenda
sanitaria por alguna agenda autorizadora (evaluadora).
Una reladn en que la evaluadora autoriza al actor a llevar a cabo
dertas actividades que caen bajo la jurisdicdn de la evaluadora (p.
ej., una autoridad sanitaria que emite Ucendas a proveedores de
asistenda sanitaria, una autoridad de trifco emitiendo carns a
conductores, etc.).
Un lugar (actor) que est autorizado a albergar la provisin de
servidos de asistenda sfinitaria. La evaluadora es la agenda pblica
autorizadora.
Una Entidad (actor) que est autorizada a proveer servidos de
asistenda sanitaria por alguna agenda autorizadora (evaluadora).
Un rol de agente en el que el agente es una Entidad actuando bajo el
empleo de una organizadn. El enfoque est en el papel fundonal en
nombre de la organizadn, no como el rol de Empleado en donde el
enfoque est en la relacin de "Recursos Humanos" entre el empleado
y la organizadn.
Una Entidad (actor) al que se le reconoce derla
formadn/experienda u otras caractersticas que haran a dicha
entidad im actor apropiado para derta actividad. La evaluadora es una
organizadn que educa o cuaUfca entidades.
Reladona un concepto material espedalizado (actor) con su
generalizadn (evaluadora).
Un enlace espedal entre farmacuticos indicando que la
obietivo(evaluadora) es un genrico para la fuente (actor).
Reladona vm todo (evaluadora) con sus partes (actor). Una parte
puede ser un ingrediente no separable del todo o una parte discreta
que puede ser identificado por separado y puede, en prindpio, ser
desmontado de la parte, (no sera del "todo"?)
Reladona un componente (actor) con una mezcla (evaluadora). Por
ejemplo. Glucosa y Agua son ingredientes de D5W; ltex puede ser
un ingrediente de un tubo traqueal.
Un ingrediente (actor) que se aade a una base (evaluadora), que llega
a constituir una parte menor de la mezcla global.
Una sustancia (actor) que influye el aspecto ptico de un material
(evaluadora).
Una sustancia (actor) que se iade a una mezcla (evaluadora) para
que sepa de una derta manera. En los alimentos, el uso es obvio; en
los farmacuticos, los sabores pueden encubrir el gusto repugnante
del ingrediente activo (importante en los tratamientos peditricos).
Una sustanda (actor) que se aade a una mezcla (evaluadora) para
impedir que microorganismos (hongos, bacteria) estropeen la mezcla.
Un estabilizador (actor) que se aade a una mezda (evaluadora) para
impedir la desintegradn molecular de la sustanda prindpal.
Un ingrediente teraputicamente activo (actor) en ima mezcla
(evaluadora), donde la mezcla es tpicamente un farmacutico
manufacturado.
Un ingrediente base (actor) es lo que comprende la parte prindpal de
una mezcla (evaluadora). Por ejemplo, el agua en la mayora de las
229
Captulo 9. Anexos
MBR
RolMiembro
PRSN
Tiene presencia
DEPO
Tiene almacn
LOCE
Entidad localizada
BIRTHPL
Lugar de nacimiento
STOR
Entidad almacenada
CONT
Contenido
INST
Instancia
AGNT
Agente
ASSIGNED
RolEntidadDesignada
CON
RolContacto
GUARD
SGNOFF
Guardin
Autoridad u oficial firmante
GUAR
RolGarante
IDENT
RolEntidadIdentificada
DST
Material distribuido
RET
Material vendido al por menor
HLD
Entidad tenido
MNT
Entidad mantenida
OWN
Entidad en propiedad
WRTE
Producto garantizado
soluciones i.v. o vaselina en las pomadas. Entre todos los ingredientes

de un material, debe haber tan slo una base que, por su parte, puede
ser una mezcla.
Un rol realizado por una entidad que es miembro de un grupo. El
grupo sirve de evaluadora para este rol.
Este concepto ha sido desaprobado. Utilice en su lugar
EntidadLocalizadaClaseRol. Este cambio se adopt demasiado tarde
para permitir que el material del Ballot#3 (Papeleta n 3) fuera
reescrito. Este concepto se omitir del vocabulario en agosto de 2002.
Relaciona una entidad (actor) con una localizadn (evaluadora) en la
cual est presente de alguna manera. Esta presencia puede ser limitada
en cuanto al tiempo.
Este concepto ha sido desaprobado. Utihce en su lugar "entidad
almacenada". Este cambio se adopt demasiado tarde para permitir
que el material del Ballot#3 (Papeleta n 3) fuera reescrito. Este
concepto se omitir del vocabulario en agosto de 2002. Relaciona un
material (actor) (p. ej. un dispositivo) con una locaUzadn
(evaluadora) en la cual se encuentra normalmente o en donde se
almacena cuando no se est usando.
Relaciona una entidad (actor) con una localizadn (evaluadora) en la
cual est presente de alguna manera. Esta presenta puede ser limitada
en cuanto al tiempo.
Reladona im sujeto vivo (actor) con una localizadn (evaluadora) en
donde nad.
Reladona un material (actor) (p. ej. un dispositivo) con una
localizadn (evaluadora) en la cual se encuentra normalmente o en
donde se almacena cuando no se est usando.
Reladona \m material como contenido (actor) con un continente
(evaluadora). A diferenda de los ingredientes, el contenido y el
continente permanecen separados (no mezdados) y el contenido
puede ser sacado del continente. Un contenido no es parte de un
continente vado.
Una pieza individual de un material (actor) que representa una clase
de material (evaluadora) por una instanda concieta.
Una entidad (actor) que acta o est autorizada a actuar de parte de
otra entidad (evaluadora).
empleo de una organizadn. El enfoque est en el papel findonal en
nombre de la organizadn, no como el rol de Empleado en donde el
y la organizadn.
Una persona u organizadn (actor) que provee o redbe informadn
sobre otra entidad (evaluadora). Por ejemplo, NOK (apoderado del
padente) y contactos urgentes, contacto con garante, contacto con el
patrn.
Guardin de un distrito
El rol de una persona (actor) que es el ofidal o autoridad firmante de
una entidad evaluadora, generalmente una organizadn (evaluadora).
Una persona u organizadn (actor) que sirve como el garante
finandero de otra persona u organizadn (evaluadora).
Roles realizados por entidades y evaluados por entidades que los
identifican para varios propsitos.
Un material (ador) distribuido por un distribuidor (evaluadora) que
fundona entre un febricante y un comprador o vendedor al por menor.
Un material (ador) vendido por un vendedor al por menor
(evaluadora) que adems aconseja a posibles compradores.
Entidad que en la actualidad es posedo por un poseedor (evaluador)
que la tiene, o la usa, generalmente en base a algn acuerdo con el
propietario.
Una entidad (ador) que es mantenida por otra entidad (evaluadora).
Este rol es tpico de equipos duraderos. La evaluadora asume la
responsabilidad de su fundonamiento corredo, calidad y seguridad.
Una Entidad (actor) por el cual alguien (evaluadora) es otorgado por
ley el derecho de considerar propio el material (actor). Esto permite a
la evaluadora tomar dedsiones con respedo a la disposidn de ese
material.
Un rol que juega vm produdo cuando una compaa da una garanta al
comprador asegurando que im producto es fiable y libre de defectos
230
Captulo 9. Anexos
CHILD
Nio
CHLDADOPT
CHLDFOST
CHLDINLAW
STPCHLD
EMP
Hijo adoptivo
Hijo adoptivo
Hijo poltico
Hijastro
RolEmpleado
MIL
Persona mitar
CIT
NOT
STD
Ciudadano
Notario
Estudiante
FAX
MANU
ADTV
Paciente
Producto manufacturado
Aditivo
COLR
Aditivo colorante
FLVR
Aditivo sabor
PRSV
Conservante
STBL
Estabilizador
THER
Agente teraputico
PLC
TERR
Rol de lugar
Autoridad territorial
SDLOC
HCFAC
ISDLOC
SPEC
ALQT
ISLT
ASSIGNED
HLTHCHRT
ACCESS
conocidos y que el vendedor reparar o cambiar elementos

defectuosos sin recargo dentro de un plazo establecido y bajo c
El actor del rol es un hijo de la entidad evaluadora, en un sentido
genrico.
Una relacin entre una persona u orgsmizadn y una persona u

organizacin formada con el propsito de intercambiar trabajo por
compensacin. El objetivo del rol es identificar el tipo de relacin que
el empleado tiene con el patrn, en vez del trabajo realizado.
(Contrastar con Entidad Asignada.
Un rol realizado por un miembro de un servicio mUitar. La evaluadora
es el servicio militar (p. ej. Ejercito, Armada, Fuerzas Areas, etc.) o,
ms concretamente, la unidad (p. ej. la Compaa Q 3 Batalln, 4'
Divisin, etc.).
Qudadano de entidad apoltica.
Un rol realizado por un individuo que es un estudiante en una escuela,
que es la entidad evaluadora.
Evaluado por un proveedor.
EvJuado por el fabricante.
Un ingrediente (actor) que se aade a una base (evaluadora), que Uega
a constituir una parte menor de la mezcla global.
Una sustancia (aaor) que influye el aspecto ptico de un material
(evaluadora).
Una sustancia (actor) que se aade a una mezcla (evaluadora) para
que sepa de una cierta manera. En los alimentos, el uso es obvio; en
los farmacuticos, los sabores pueden encubrir el gusto repugnante
del ingrediente activo (importante en los tratamientos peditricos).
Una sustancia (actor) que se aade a una mezcla (evaluadora) para
impedir que mio'oorganismos (hongos, bacteria) estropeen la mezcla.
Un estabilizador (actor) que se aade a una mezcla (evaluadora) para
impedir la desintegracin molecular de la sustancia principal.
Un material manufacturado (actor) que se emplea por sus propiedades
teraputicas. El fabricante es la evaluadora.
Una entidad, tpicamente una Organizacin (evalxiadora) que tiene

cierta autoridad (jurisdiccin) sobre cierto lugar o regin (el que
coloca). Por ejemplo, la Autoridad Sanitaria Regional de Calgary
(Organizacin actor) tiene autoridad territorial sobre "la Regin 4 de
Alberta" (Lugar evaluador).
Localizacn del servicio de entrega Un rol realizado por im lugar en el cual se pueden proveer servicios
de asistencia sanitaria.
Centro sanitario
Un lugar (actor) que est autorizado a albergar la provisin de
servicios de asistencia sanitaria. La evaluadora es la agencia pblica
autorizadora.
Localizacn del servicio de entrega Un rol realizado por un lugar en el cual se pueden proveer servicios
incidental
de asistencia sanitaria sin designacin o autorizacin previa.
RolEspcimen
Un rol realizado por una entidad material que es un espcimen para
una actuacin. Es evalueido por la fuente del espcimen.
Alcuota
Una porcin (actor) de un espcimen original o fuente (evaluadora)
empleado para una prueba o transporte.
Aislado
Un mCTOorganismo que ha sido aislado de otros microorganismos o
de un matriz fuente.
RolEntidadDesgnada
empleo de una organizacin. El enfoque est en el papel funcional en
nombre de la organizacin, no como el rol de Empleado en donde el
y la organizacin.
El rol de un material (actor) que es el esquema sanitario fsico de un
Esquema Sanitario
sujeto vivo (evaluadora).
Un rol en el cual la entidad aaor (material) provee acceso a otra
Acceso
entidad. El caso de uso principal es para lneas de acceso intravenosas
(u otras corporales) preexistentes a las que hay que referir para
instrucciones sobre vas para la administracin de medicacin.
231
Captulo 9. Anexos
HLTHCHRT
SCHED
STAK
SUBS
El rol de un material (actor) que es la grfica de salud fsica de un

sujeto vivo (evaluadora).
Recurso que puede ser inventariado Un recurso que puede ser inventariado. Es evaluado por la entidad
que realiza el inventario.
Una entidad que tiene participaciones en la entidad que evala el rol.
RolAcdonista
Una entidad que subsume la identidad de otra. Se emplea en el
Subsumidor
contexto de fusionar instancias de entidad documentâs. Tanto el
actor como la evaluadora tienen que tener el mismo Cdigo de clase.
Esquema Sanitario
Anexo 6. Tipos de Participacin

Descripcin
Mnemnico
Nombre de
Impresin
Actores de
El tipo actor principal especifica lo que hace el actor en el servicio a im nivel amplio que es esencial para
la interoperabidad fundonil. Ver act. FunctonCode para un cdigo informadonal extensible a un nivel
ms particular. Nota: el cdigo de tipo de actor especifica lo que realmente hace la gente, no lo que
generalmente se acredita que hacen.
actor
Una persona que realmente y principalmente lleva a cabo la accin. No tiene que ser
necesariamente el actor responsable principal, p. ej. un residente de ciruga operando
bajo la supervisin del cirujano instructor y puede ser el paciente en auto-asistencia,
p. ej. pindiarse el dedo para medir glucemia. El que tradidonalmente cumple con
vina petidn es un actor. Esta informadn debera acompaar todo evento de
servido.
autor (oreador)
Una persona u organizadn que origina y asume la responsabilidad de la
informadn incluido en el ado, p. ej. l que escribe los informes, l que esaibe la
definidn del acto, el autor de la normativa, l que hace la petidn. Esta
informadn debera acompaar todo acto (independientemente del modo).
actor ajmdante
Una persona que ayuda en un servido a travs de su presenda e impUcadn
sustancial. Esto incluye: ayudantes, taiicos, adjuntos o los ttulos de la posidn
que sean.
Un consejero partidpando en el servido por medio de la realizadn de evaluadones
consultante
y oferta de recomendadones.
supervisor
Una persona que es legalmente responsable del servido llevado a cabo por un actor
(autenticador legal) como delegado. Un supervisor no est presente necesariamente en una acdn, pero
es responsable de la acdn por su poder de delegar y su deber de revisar acdones
con el actor involuaado despus del hecho (p. ej. jefe de un laboratorio
bioqumico).
El practicante de la atendn que tiene la responsabilidad del cuidado de un padente
El que atiende
durante su estanda en el hospital.
referente
La persona que ha referido el tema del servido al actor (mdico referente). Un
mdico referente tpicamente redbe un informe.
atencin
Una partidpadn indicando la entidad a cuya atendn se enva la comunicadn.
revisor
Una persona que revisa los detalles de un servido (petidn o documentadn)
despus del hedi.
verificador
Una persona que verifica la correcdn y convenienda del servido (plan, petidn,
evento, etc.) y por tanto asume responsabilidad.
rastreador
Una persona (jue redbe copias de intercambio sobre este servido (p. ej. un
proveedor de atendn primaria redbiendo copias de resultados de estudios pedido
por un espedalista).
contacto telefnico Un contacto (frecuentemente no individual) al que dirigir preguntas inmediatas para
su clarificadn (p. ej. un centro de asistenda al que se Uama por telfono).
consentidor
La persona que da su consentimiento al servido (generalmente el propio padente o
su tutor legal). Una persona consentidora es un ador en el sentido de que pide o
delega una acdn que le va a ocurrir a si mismo.
testigo
Slo con eventos de servido. Una persona que es testigo de una acdn teniendo
lugar sin hacer nada. Un testigo no necesariamente se da cuenta de, ni mucho menos
aprueba, nada mendonado en el evento de servido. Ejemplos de testigos son
estudiantes viendo una operadn o un testigo directivo avanzado.
informador
Una fuente de informadn disponible (p. ej. un familiar que responde a preguntas
sobre la historia del padente). Para preguntas sobre la historia, lgicamente el
padente es un informador, pero el informador con respecto a preguntas sobre la
historia es impldtamente el sujeto.
Servido
PRF
AUT
ASS
CON
SPV
ATND
REF
ATTN
REV
VRF
TRC
CBC
CNS
wrr
INF
232
Captulo 9. Anexos
ENT
persona que
introduce los datos
CST
custodiador
ODV
dispositivo
originario
ADM
DIS
EST
HLD
admisor
el que da el alta
escolta
tenedor
proveedor
responsable
Objetivos (directos) del servido
DIR
Objetivo directo
RESPROV
SBJ
sujeto
PAT
paciente
PATSBJ
sujeto paciente
BBY
MTH
DON
beb
madre
donante
NOK
apoderado
PYL
SPC
DEV
cargamento
espcimen
dispositivo
NRD
dispositivo no
reutilizable
ODV
dispositivo
originario
RDV
dispositivo
reutizable
CSM
PRD
consumible
producto
ELOC
LOC
punto de entrada
localizadn
Una persona que introduce los datos en el sistema originario. La persona que
introduce los datos se recoge opdonalmente para asuntos de control de calidad
interno. Esto incluye la persona que transcribe texto dictado.
Una persona (u organizacin) que se hace cargo de mantener la informacin de este
objeto de servicio (p. ej. que mantiene el informe o el tem del catlogo del servicio
maestro, etc.).
Un dispositivo que gener la informacin en el objeto de servicio al cual est
agregado (por ejemplo, un contador Coulter en im electrocardigrafo que produjo el
informe.
El mdico responsable del ingreso en el hospital de un paciente.
El mdico responsable de darle a un paciente el alta del hospital.
Slo con servicios de Transporte. La persona que acompaa al paciente.
Participante que posee un instrumento como puede ser un contracto financiero (una
pliza de seguro), normalmente basado en algn acuerdo con el autor.
El proveedor (persona u organizacin) que tiene la responsabilidad principal del
acto.
Finalidad que est presente sustandalmente en el servido y que est directamente
afectada por la acdn del servido (incluye material gastado, dispositivos, etc.).
La objetivo prindpal sobre la cual el servido acta, p. ej. el padente en un examen
fsico, un espcimen en una observadn de laboratorio. Tambin puede ser un
miembro de la famia del padente (instruyendo) o un dispositivo o habitadn
(limpiando, desinfectando, tareas del hogar). Nota: no todas los objetivos directos
son sujetos, consiunibles, y dispositivos empleados como instrumentos para im
servido no son sujetos. Sin embargo, un dispositivo puede ser el sujeto de un
servido de mantenimiento.
El padente objetivo indica de qu historia mdica de padente forma parte este tem
de servido. Esto es espedalmente importante cuando el sujeto de tin servido no es
el propio padente. Para efectos prcticos, es bueno siempre tener un padente
objetivo cuyo sentido nico es que este servido pertenece a la historia mdica de ese
padente. Adems, otros tipos de objetivos deben ser espedfcados si el padente es
tambin un sujeto o benefidario u otro objetivo del servido.
El padente como sujeto del servido. Por ejemplo, en observadones clnicas
directas, el padente es el sujeto.
En un servido de obstetrida, el beb.
En un servido de obstetrida, la madre.
En algunos servidos de trasplante de rganos y raramente en servidos de
transfusin, un donante ser un partidpante objetivo en el servido. Sin embargo, en
la mayora de casos, el trasplante se descompone en tres servidos: extracdn,
transporte e implantadn. La identidad del donante (receptor) frecuentemente es
irrelevante para el servido de extracdn (implantadn).
Alguien que es el sujeto del servido en nombre del padente, p. ej. un miembro de la
familia del padente que es el sujeto de un servido de instrucdn sobre los asuntos
del padente.
Para servidos de transirorte, el pasajero o los bienes transportados.
El sujeto de servidos de observadn no clnica (p. ej. laboratorio) es un espcimen.
Algo empleado en el cumplimento del servido sin ser sustandalmente afectado por
el mismo(es dedr, duradero o inerte con respecto a ese servido en particular). Son
ejemplos: equipos de monitorizadn, instrumentos, pero tambin lieas de
acceso/drenaje, prtesis, marcapasos, etc.
Un dispositivo que cambia de propietario debido al servido, p. ej. un marcapasos,
una prtesis, un equipo de inyecdn de insulina (boUgrafo), etc. Puede ser necesario
reponer material de este tipo despus del servido.
Un dispositivo que gener la informadn en el objeto de servido al cual est
agregado (por ejemplo, un contador Coulter en un electrocardigrafo que produjo el
informe.
Un dispositivo que no cambia de propietario debido al servido, p. ej. im instrumento
0 herramienta quirrgica o un endoscopio. Hay que distinguir entre reutizable y no
reutilizable para saber si hay que reponer el material.
La finalidad por la que es utilizada disminuye y desaparece en el servido.
El material objetivo que se genera (se produce) en el servido (p. ej. un espcimen en
una colecdn de especmenes, acceso o drenaje en un servido de colocadn,
paquete de medicamento en un servido de dispensadn). No importa si el material
produddo exista antes del servido o si se cre durante el servido (p. ej. en
servidos de suministro, el producto se coge del stock).
Una localizadn (anatmica) donde se introdujo datos sobre un Acto.
El lugar en donde el servido se lleva a cabo. Puede ser un edifido esttico (o una
233
Captulo 9. Anexos
DST
destino
ORG
origen
RCV
RML
receptor
remoto
VIA
va
BEN
beneficiario
cov
Cobertura objetivo
TPA
agente teraputica
habitacin en l) o una locaiizaxin mvil (p. ej. una ambulancia, un helicptero, un

avin, un tren, un aimin, un buque, etc.)El destino para los servicios. Puede ser un edificio esttico (o ima habitacin en l) o
una lugar movible (p. ej. un buque).
La localizadn para el origen de los servicios. Puede ser un edificio esttico (o una
habitacin en l) o una lugar movible (p. ei'. un buque).
La persona (u organizacin) que recibe el producto de un Acto.
Algunos servicios se llevan a cabo en locaUzadn concurrentes mltiples (p. ej.
telemedidna, consulta telefnica). La localizadn en donde se encuentra el actor
prindpal se considera la localizadn prindpal (LOC), mientras la(s) otra(s)
localizacin(es) se considera(n) "remota(s)".
Para servidos, una localizadn intermedia que espedfica una ruta entre origen y
destino.
El nombre objetivo sobre quien el servido se realiza, pero que no necesariamente
est presente en el servido. Puede ocurrir conjuntamente con el objetivo directo para
indicar que el objetivo es ambas cosas. Induje un partidpante que redbe benefidos
de un acto, como una parte cubierta.
La partidpadn objetivo para un individual en un acto de cobertura de asistenda
sanitaria en que el rol objetivo es o el titular de la pliza de cobertura o una parte
cubierta por la cobertura.
Algo incorporado en el sujeto de un servido de terapia para conseguir un efecto
fisiolgico (p. ej. curar, aliviar, provocar una condidn, etc.) en el sujeto. En un
servido de administradn, el agente teraputico es un consumible, en un servido de
preparadn o dispensadn, es un producto. Por lo tanto, hay que espedficar si es un
consumible o un producto de acuerdo con el tipo de servido.
Anexo 7. Estado de la Participacin

Mnemnico
Nombre de
Impresin
Descripcin
normal
normal
active
cancelled
activo
cancelado
completed
pendlng
nuUifed
completado
pendiente
anulado
El estado "tpico". Excluye "anulado", que representa el estado de finalizacin de

una instanda de partidpadn que se cre por error.
El estado representando el hedi de que la Partidpadn est en marcha.
El estado terminal que resulta de la canceladn de la Partidpadn previo a la
activadn.
El estado terminal que representa la realizadn exitosa de la Partidpadn.
El estado que representa el hecho de que la Partidpadn todava no es activa.
El estado que representa la finalizadn de una instanda de partidpadn que se at
por error.
Anexo 8. Modo de Participacin

Mnemnico
Nombre de
Lnpresin
Descripcin
ELECTRONIC
VERBAL
DCTATE
datos electrnicos
verbal
didada
FACE
cara-a-cara
PHONE
telfono
VIDEOCONF
videoconferenda
WRITTEN
EMAILWRIT
escrita
correo electrnico
Partidpadn por seal electrnico no basado en lenguaje humano.

Partidfadn por comunicadn por voz.
Partidpadn por voz pregrabada. Comunicadn se limita a xma direcdn (de
la grabadora d receptor.
Partidpadn por comunicadn por voz en que las partes se hablan
directamente.
Partidpadn por comunicadn por voz en que las voces de las partes
comunicantes se transportan va un medio electrnico.
Partidpadn por comunicadn por voz y visual en que las voces e imgenes
de las partes comunicantes se transportan va un medio electrnico.
Partidpadn por lenguaje humano grabado en un material fsico.
Partidpadn por texto o esquemas transmitidos va un sistema de correo
electrnico.
234
Captulo 9. Anexos
FAXWRIT
telefax
HANDWRIT
escrita a mano
TYPEWRIT
mecanografiada
PHYSICAL
presencia fsica
REMOTE
presencia remota
Participacin por texto o esquemas impresos en papel que han sido

transmitidos va un dispositivo de fax.
Participacin por texto o esquemas escritos en papel u otro medio de
grabacin.
Participacin por texto o esquemas impresos en papel u otro medio de
grabacin en que la grabacin se llev a cabo usando una mquina de escribir,
una mquina tipogrfica, un ordenador o mecanismo similar.
Participacin por accin directa en que sujeto y actor se encuentran en la
misma localizadn. (La participacin comprende ms que comunicacin.)
Participacin por accin directa en que sujeto y actor se encuentran en
localizaciones diferentes y las acciones del actor se transmiten por medios
electrnicos o mecnicos. (La participacin comprende ms que
comunicacin.)
Anexo 9. Control Contexto de Participacin

Mnemnico
Nombre de
bnpresi^
I
IOS
Objeto que puede heredarse; no hereda asociaciones con otros objetos.

heredable
Herencia supeditada Objeto que puede heredarse; no hereda asociaciones con otros objetos. Una
supeditacin eimiascara objetos heredados del mismo tipo/clase o ms especfico.
no conductivo
Objeto que no puede heredarse; no hereda asociaciones con otros objetos.
Anexo 10.
Mnemnico
Nombre de
Lnpresin
ACT
Acto
CONF
AUTH
EUG
CNTRCT
FCNTRCT
COV
DOCCLIN
CDALVLONE
DOCUST
ordered
unordered
TBLDATA
Descripcin
Clases de Actividad
Descripcin
Accin de inters que ha ocurrido, puede ocurrir, est ocurriendo, hay intencin
de que ocurra o se ha pedido/mandado que ocurra.
Confirmacin
Una notificacin empleada para indicar si una peticin ha sido confirmada o no.
Autorizacin
Una notificacin empleada para indicar si un intento de llevar a cabo un acto
que se puede facturar ha sido aprobado para cobertura bajo los trminos de un
plan 0 pliza de seguros.
Elegibilidad
Una notificacin empleada para indicar si un beneficiario es elegible para
cobertura bajo los trminos de un plan o pliza de seguros.
Contracto
Un acuerdo de obligacin entre dos partes o ms que es sujeto a la ley y
cumplimiento contractuales.
Contracto econmico Un contracto cuyo valor se mide en trminos monetarios.
Una pliza o plan de asistencia mdica que compromete contractualmente a dos
Cobertura
0 ms partes.
Un documento clnico es una documentacin de observaciones y servicios
Documento clnico
clnicos que tiene las siguientes caractersticas: (1) Persistencia - Un documento
clnico permanece existiendo en un estado no alterado por un periodo de tiempo
definido por requerimientos locales y reguladores; (2) Administracin - Un
documento clnico se mantiene por una persona u organizacin a la que se
confia su cuidado; (3) Potencial de autenticacin - Un documento clnico es un
conjimto de informacin cuyo designio es ser autenticado legahnente; (4)
Integridad - Autenticacin de un documento clnico se aplica al conjunto entero
y no se aplica a porciones del documento sin el contexto entero del documento;
(5) Legibilidad humana - Un documento clnico tiene que ser legible por
humanos.
Documento clnico de Un documento clnico que se conforma al Nivel Uno de la Arquitectura de
Documento Clnico (ADQ HL7.
nivel uno de ADC
Lista de documentos Un lista de tems.
Especifica si una Hsta est "ordenada".
Ordenada
Especifica si una hsta no est "ordenada".
No ordenada
Una clula de datos en formato de tabla.
Clula de datos en
235
Captulo 9. Anexos
UNKHTML
LOCAIATTR
documento en
formato de tabla
Clula de
encabezamiento de im
documento en
formato de tabla
Columna de un
documento en
formato de tabla
Grupo de columnas
de un documento en
formato de tabla
Cuerpo de tabla
Pie de tabla
Encabezamiento de
tabla
Fila de una tabla en
un documento
Cuerpo de un
documento
Contenido de
documento
Un tem de una lista
de un documento
Prrafo de im
documento
Seccin de un
documento
Tabla de un
documento
Enlace va html
Atributo local
LOCALMRKP
Etiquetado local
FDSr
DMVE
Acto financiero
Elemento de
facturacin
Elemento de
facturacin
informativo
Cuenta
TBIHDR
TBLCOL
TBLCOLGP
tbody
tfoot
thead
TBLROW
DOCBODY
DOCCNTNT
DOCLSTITM
DOCPARA
DOCSECT
DOCTBL
INFINVE
ACCr
INS
XACT
OBS
ARTBLD
C3SITM
DILUTION
ENVFCTS
INTFRIDX
Cobertura de
beneficio de
asistencia semitaria
Transaccin
financiero
Una clula de encabezamiento en una tabla.
Una columna en una tabla.
Un grupo de columnas definido en una tabla.
El cuerpo de una tabla segn definido por el Modelo de Tabla XHTML 4.0.
El pie de una tabla segn definido por el Modelo de Tabla XHTML 4.0.
El encabezamiento de una tabla segn definido por el Modelo de Tabla XHTML
4.0.
Una fila en una tabla.
Representa el cuerpo de un documento segn las normas de Arquitectura del
Documento Clnico.
Una envoltura no semntica para texto llano en un documento clnico.
Un tem en una lista.
Un prrafo en un documento clnico.
Representa un seccin en un documento segn las normas de Arquitectura del
Documento Clnico.
Un contenedor que consiste de clulas mltiples dispuestas en filas y columnas.
Un enlace empleando una etiqueta de anclaje HTML.
Un atributo XML empleado cuando la semntica local no tiene \ma
representacin correspondiente en la especificacin ADC.
Un etiquetado XML empleado cuando la semntica local no tiene una
representacin correspondiente en la especificacin ADC.
Un acto utilizado principalmente para efectos administrativos (no clnicos).
Representa conceptos relacionados con el proceso de facturacin en la asistencia
sanitaria.
Una trozo de informacin o detalle de soporte que no altera el total financiero de
una factura.
Una cuenta financiera establecida para trazar el resultado neto de actos
financieros.
Este tipo cubre tanto la pliza de producto de beneficio de asistencia sanitaria
como el tem de cobertura hasta el momento en que se completa la cartografa.
Una subclase de Acto que representa cualquier transaccin entre dos cuentas
cuyo valor se mide en trminos monetarios. En el modo "intencin", comunica
una peticin de iniciar una transaccin o comunica una transferencia de valor
entre dos cuentas. En el modo "evento", comunica el envo de una transaccin a
una cuenta.
Observaciones son actos que se llevan a cabo para determinar una respuesta o
Observacin
un valor de resultado. Valores de resultado de observacin (Observation.value)
incluyen informacin espetfica sobre el objeto observado. El tipo y
limitaciones de valores de resultados dependen del tipo de accin llevada a
cabo. Doctmientos clnicos firecuentemente tienen hallazgos 'Sujetivos' y
'Objetivos', ambos siendo tipos de Observaciones. Adems, documentos
clnicos frecuentemente contienen 'Valoraciones', que tambin son tipos de
Observaciones. Por lo tanto, el establecimiento de un diagnstico es una
Observacin.
Seingre artificial
Describe el identificador de sangre artifidal que se asocia con el espcimen.
Contaminantes
Describe el identificador del contaminante de un espcimen que se asocia con el
espcimen.
Dilucin
Una observacin que informa sobre la dilucin de una muestra.
Factores ambientales Describe otros factores ambientales que se asocian con el espcimen, p. ej. la
exposicin atmosfrica.
ndice de
| Una clase de observaciones que se relacionan con factores que pueden
236
Captulo 9. Anexos
TEMP
interferencia
Temperatura
VOLUME
CASE
Volumen
Caso de Sanidad
Pblica
OUTB
Brote
ALRT
Alerta
DGMG
MPROT
Imagen diagnstico
Programa de
monitorizadn
Coordinado
referendado
REFCOORD
SPLY
Suministro
DIET
Diettica
UST
Lista de trabajo
potendalmente provocar interferenda con la observadn.

La temperatura del espcimen en centgrados [ C] en el momento de la
observadn.
Una observadn que informa sobre el volumen de una muestra.
Un caso de sanidad pblica es una Observadn que representa una condidn o
evento que tiene una significadn espetfica con respecto a la salud pblica.
Tpicamente implica una nstanda o instandas de una enfermedad infecdosa de
declaradn obligatoria u otra condidn. El caso de salud pblica puede incluir
un evento reladonado con la salud que conderne xm solo individuo o puede
referirse a eventos mltiples reladonado con la salud que son casos de la misma
enfermedad o condidn que son de inters para la Scilud pblica. Un brote
implicando a individuos mltiples puede considerarse un tipo de caso de sanidad
pblica. Una definidn de un caso de sanidad pblica (Act.moodCode =
"definicin") incluye la descripcin de los indicadores clnicos, analticos y
epidemiolgicos asodados con ima enfermedad o condidn de inters para la
salud pblica. Hay definidones de caso para condidones que son de declaradn
obligatoria y para las que no lo son. Tambin hay definidones de caso para
brotes. Una definidn de un caso de la sanidad pblica es una construcdn
empleada por la sanidad pblica para el propsito de contar casos, y no debe
utilizarse como indicadones clnicas de tratamiento. Los ejemplos incluyen
SIDA, el sndrome de choque txico y salmonelosis y sus indicadores asodados
que son utilizados para definir un caso.
Un brote representa una serie de casos de sanidad pblica. La fedia en que
empieza un brote es la fecha ms temprana de su aparidn entre los casos
asignados al brote, y su fecha final es la ltima fecha de su aparidn entre los
casos asignados al brote.
Una observadn que indica un evento potendalmente negativo como resultado
de un Acto o combinadn de Actos.
Clase para la tenenda de atributos exclusivos a imgenes diagnsticos.
Un programa instituido ofidalmente o no ofideilmente para trazar actos de un
tipo 0 categorizadn en particular.
La clase Referenced_coordinate se emplea para referirse a coordinados
espedcos en imgenes, formas de hondas u otros conjuntos de datos, por
ejemplo, para espedficar la localizadn de un hallazgo radiolgico o para
identificar la regin sobre la cual se bas un hallazgo. Por ejemplo, clnicos
pueden induir imgenes grneos en sus notas y marcar una regin de inters en
particular con un crculo. Entonces se refiere espedficamente a esta regin de
inters en su nota. La reladn entre un Referenced_coordinate y su imagen
referendado se espedfica por medio de un ActRelationship (empleando un
valor de ActRelationship.typeCode de "REFV")- Coordinados Referenciados
slo tiene sentido en conexin con un dato objeto cuyo contenido referendan.
Las unidades de los valores de coordinados son las del dato objeto referendado.
Por ejemplo, si el objeto referendado es urna imagen como mapa de bits, los
coordinados se expresaran en unidades de pxel. La presenta de parmetros de
escala como atributos en una imagen como mapa de bits no cambia los
coordinados de la muestra: permEinecen en unidades de pxel. Si el objeto
referendado es una figura grfica de vector espedficada en centmetros, los
valores de coordinado se espedfican en centmetros.
Pedidos y entregas de suministros son Actos sendUos que se centran en el
producto entregado. El producto se asoda con el Acto de Suministro va
Participation.typeCode = "producto". Con Actos de Suministro generales, la
identificadn predsa del Material (fabricante, nmeros de serie, etc.) es
importante. La mayora de la informadn detallada sobre el Suministro debe
representarse usando la clase Material. Si la entrega tiene que ser programada,
trazada y facturada por separado, se puede asodar una Acto de Transporte con
el Acto de Suministro. Servidos de dispensadn farmacutica se representan
como Actos de Sxministro asodados con im Acto de Administradn de
Sustandas. La clase Administradn de Sustandas representa la administradn
de medicadn, mientras dispensadn es suministro.
Servidos de diettica son servidos de suministro, con algunos aspectos que se
parecen a los de servidos de Medicadn; los detalles de la dieta se presentan
como una descjipdn del Material asedado va Partidpation.typeCtode =
"producto". Tipos de dieta mdicamente relevantes pueden ser comunicados en
el atributo Diet.code usando el ActDietCode dominio. Sin embargo, los detalles
de los alimentos suministrados y las combinadones diferentes de platos deben
comunicarse como instandas de Material.
Working^list recoge una sta dinmica de instandas individuales de Acto va
ActRelationship, que reeja la necesidad de un trabajador, equipo de
237
Captulo 9. Anexos
GOL
lista de Servicio de
Asuntos
lista de objetivos
PRB
Lista de problemas
LOG
SCH
Registro log
Programa
ACCM
Alojamiento
ACSN
Accesin
ADJUD
Resultados de
Adjudicacin
Financiera
CACT
Acto de control
CONS
Consentimiento
CONTREG
ENC
Registro de
continente
Encuentro
INC
Inridente
ISS
trabajadores o una organizacin de manejar listas de actos para mudios motivos

clnicos y administrativos diferentes. Ejemplos de listas de trabajo incluyen
listas de problemas, listas de objetivos, listas de alergias y listas de cosas por
hacer.
Una coleccin de servicios como asuntos que se tienen que resolver.
Una lista de los objetivos de un paciente desde el punto de vista de un proveedor
en particular,
Una lista de los problemas de un paciente desde el punto de vista de un
proveedor en particular.
Un diario de servicios anteriores.
Una lista de trabajo, im programa o una lista personal que cosas que se propone
que se hagan.
Un alojamiento es un servicio que se realiza para ima Persona u otro Sujeto Vivo
en que se ofrece al sujeto un lugar para vivir durante un periodo de tiempo.
Normalmente empleado para hacer el seguimiento de la provisin de
alojamiento privado y semi-privado para un paciente a.
Una unidad de trabajo, que agrupa tems de trabajo segn definido por el
sistema que realiza ese trabajo. Tpicamente, los que despachan pedidos de
laboratorio comunican referencias a accesiones en sus comunicaciones sobre
pedidos de laboratorio. Frecuentemente, uno o ms especmenes se relacionan
con una accesin de manera que en algunos escenarios el nmero de accesin se
considera un identifcador de un espcdmen (grupo).
Un proceso de transformacin en que una factura pedido se transforma en una
factura acordada. Representa el procedimiento de adjudicacin de una factura
(reclamacin). Los resultados de adjudicacin pueden ser adjudicados tal y
como se remitieron, con modificaciones o pueden ser denegados. Los resultados
de adjudicacin tienen dos componentes: los resultados del procedimiento de
adjudicacin y una factura o reclamacin reformulada (o adjudicada).
Un acto que representa una accin del sistema como puede ser el cambio de
estado de otro acto o la iniciacin de una pregunta. Todos los actos de control
representan eventos de desencadenamiento en el contexto de HL7. Actos de
control pueden ocurrir en distintos modos.
La clase consentimiento representa consentimientos informados y todas las
transacciones mdico-legales similares entre al paciente (o su tutor legal) y el
proveedor. Ejemplos son el consentimiento informado para intervenciones
quirrgicas, consentimiento informado para ensayos clnicos, aviso por
adelantado al beneficiario, contra el renimdo de consejo mdico del servicio,
acuerdo sobre la divulgacin de informacin, etc. Los detalles de la clase
consentimiento varan. Una institucin frecuentemente tiene varios formularios
de consentimiento diferentes para propsitos distintos, incluso para recordar al
mdico los temas que debe comentar. Didios formularios tambin incluyen
material para instruir al paciente. En la comimicadn electrnica de historias
mdicas, los propios consentimientos por lo tanto son actos de la generacin de
informacin y se tienen que manejar de un modo similar a las actividades
mdicas. Por lo tanto, se modela Consentimiento como una clase especial de
Acto. Las "firmas" en los docimientos de consentimiento se representan
electrnicamente va instancias de Participacin al objeto de consentimiento.
Tpicamente un consentimiento informado tiene un Participation.t)êCode de
"actor", el proveedor de la asistencia sanitaria que informa al paciente, y
"consentidor", el paciente o su tutor legal. Algunos consentimientos pueden
asociar un testigo o notario (p. ej. testamentos en vida, directivos avanzados). En
consentimientos que no requieren un proveedor de asistencia sanitaria (p. ej. el
testamento en vida), el actor puede ser el propio paciente o un notario. Algunos
consentimientos tienen una espera mnima obligatoria entre el consentimiento y
el servicio para permitirle al paciente repensar sus decisiones. Esta espera
mnima puede expresarse en la definicin del acto por el atributo
ActRelationship.pauseQuantity que retrasa el servicio hasta que el tiempo de
espera despus de completar el consentimiento se haya agotado.
Un Acto en que se registra im continente o por sensor automtico, como el
lector de cdigos de barras, o por recibo manual.
Una interaccin entre un paciente y el o los participantes en la asistencia
sanitaria para proveer servido(s) al padente o evaluar el estado de salud de un
pariente. Por ejemplo, una visita a mltiples departamentos de un ambulatorio,
apoyo domiciliario de la salud (incluyendo fisioterapia), ingreso hospitalario,
visita a la sala de urgendas, visita fuera del hospital (p. ej. un acddente de
trfico), visita a la consulta, terapa ocupadonal, llamada por telfono.
Un evento que ocuni fuera del control de uno o ms de las partes implicadas.
238
Captulo 9. Anexos
PROC
Procedimiento
REFR
Referencia
REG
Registro
SBADM
Administricin de
sustancias
SPCTRT
Tratamiento de
espedmenes
Transporte
TRNS
Anexo 11.
Mnemnico
DEF
EVN
ORD
casiF
INT
PRMS
PRP
RMD
OPT
APT
ARQ
EVN.CRT
Incluye el concepto del accidente.

El trmino "procedimiento" tambin se conoce comimiente como
"procedimiento quirrgico" o "procedimiento operativo". Una intervencin
quirrgica tpicamente implica una alteracin planeada de la estructura corporal,
normalmente requiriendo la disrupcin de la superficie del cuerpo, generalmente
a travs de una incisin.
Una introduccin de un paciente de un cuidador fuente a un cuidador objetivo
institucin proveedor, tpicamente para obtener la evaluacin del paciente y
recomendaciones para tratamiento del cuidador dicuia. Una referencia puede
autorizar ima cantidad especfica de un tipo o nivel de servicio en particular.
Una referencia tambin puede ser simplemente una recomendacin o
introduccin.
Representa el acto de mantener informacin sobre una entidad o rol en un
registro. La clase es muy general, diseada para soportar una variedad de
registros para personas, pacientes, mdicos, equipamiento, etc. Si es necesario,
tipos especficos de registros sern tratados como espedalizadones de esta
clase.
SubstanceAdministration es xm Acto que emplea Material como agente
teraputico. El efecto de la sustanda teraputica tpicamente se establece en
base a aspectos bioqumicos; sin embargo, eso no es un requerimiento. Por
ejemplo, radioterapia bsicamente puede describirse del mismo modo,
espedaknente si es una terapia sistmica como radio-yodo.
Un procedimiento o tratamiento al que se somete un espcimen para prepararlo
para anlisis.
Transportar es mover una carga (personas o material) de una localizadn de
origen a una localizadn de destino. Por lo tanto, cualqxiier servido de
transporte tiene tres instandas objetivo de tipo carga, origen y destino, aparte de
las dianas que se emplean generalmente para cualquier servido (es dedr, actor,
dispositivo, etc.).
Cdigo Mood de Actividad
Nombre de
Descripcin
Impresin
definidn
Definidn de un servido (maestro).
evento (inddenda) Un servido que realmente ocurre. Puede ser un servido que contina o urna
documentadn de un servido cumplido en el pasado.
orden
Una petidn de im servido es una intendn dirigida del petidonario (autor del
intento) al cumplidor (realizador del servido).
confirmadn
Una promesa que se ha solidtado a travs de una petidn (va un orden).
intento
Una intendn o plan para realizar un servido.
promesa
Un intento de resdizar un servido que tiene la fuerza de un compromiso, es dedr, otras
partes pueden confiar en el origen de tal promesa para que dicho origen se ocupar de
que el acto prometido ser cumplido. Una promesa puede ser solidtada o no
solidtada.
Un intento no conferido por mandato de realizar un acto. Utilizado para registrar
proposidn
intentos que expldtamente no son rdenes. Responsabihdad profesional de la
"proposicin" puede o no existir.
Un intento no conferido por mandato de realizar un acto en que un nivel de
recomendadn
responsabilidad profesional se acepta por el hecho de hacer la proposidn.
Una opdn es un conjunto de ligaduras propiedad-valor alternativas. Opdones
opdn
espedfican conjuntos de valores alternativos, empleados tpicamente en definidones u
rdenes para describir alternativas. Una opdn slo puede emplearse como conjunto,
es decir, todos los valores asignados tienen que utilizarse en conjunto.
dta
Un Acto planeado para un momento y un lugar espedficos.
Petidn de una dta Una petidn para la reserva de una dta.
Un criterio o condidn sobre eventos de servido que tiene que ser apHcado para un
criterio de un
evento
servido asodado que a ser considerado.
239
Captulo 9. Anexos
Anexo 12.
Estado de Actividad
Mnemnco
Nombre de
Impresin
Descripcin
new
normal
nuevo
normal
aborted
active
cancelled
completed
abortado
activo
cancelado
completado
held
retenido
suspended
suspendido
obsolete
nullified
obsoleto
anulado
Un Acto que se encuentra en etapas preparatorias y que puede no realizarse todava.

Comprende los estados esperados de un Acto, pero excluye "anulado" y "obsoleto"
que representan estados terminales inusitados para el ciclo de vida.
El Acto ha sido finalizado antes de la terminacin originalmente programada.
El Acto puede realizarse o se est realizando.
El Acto ha sido abandonado antes de ser activado.
Un Acto que se ha terminado de forma normal despus de la realizacin de todos sus
componentes.
Un Acto que contina en las etapas preparatorias que ha sido dejado a un lado. No
puede ocurrir ninguna accin hasta que el Acto sea librado.
Un Acto que ha sido activado (acciones pueden haber o han sido realizadas en su
cumplimiento), pero que ha sido deshabilitado temporalmente. Ninguna accin
adicional pniede ser realizada en su cumpHmiento hasta que sea librado.
Esta instancia de Acto ha sido reemplazada por una nueva instancia.
Esta instancia de Acto se cre por error y ha sido "retirada" y se trata como si jams
hubiera existido. Se retiene tm registro exclusivamente para efectos de auditoria.
Anexo 13.
Tipos de Relacin entre Actividades
Mnemnico
Nombre de
Impresin
Descripcin
OUTC
tiene resultado
GOAL
tiene objetivo
OBJC
tiene objetivo
continuado
OBJF
tiene objetivo final
RISK
tiene riesgo
PERT
AUTH
CAUS
tiene informacin
pertinente
autorizado por
es causa de
COVBY
cubierto por
DRIV
est derivado de
Una observacin que debe realizarse o definitivamente se realiza como resultado o

consecuencia de una condicin o accin (a veces ejq)resado como "postcondicin"). El objetivo ha de ser una observacin como objetivo, riesgo o
cualquier criterio. Para resultados complejos, un atributo de conjundn
Un objetivo que uno define segn la condicin de salud del paciente. Acciones
planeadas subsecuentemente estn ideadas para cumplir con ese objetivo. La fuente
es im nodo de observacin o de condicin; el objetivo tiene que ser una
observacin en modo objetivo.
Un estado deseado que una accin de servido procura mantener, e. ej. mantener la
presin sisthca sangunea entre 90 y 110 mm Hg. La fuente es \m servido de
intervendn. El objetivo tiene que ser una observadn en modo criterio.
Un resultado deseado al que una acdn de servido apunta a llegar finalmente. La
fuente es cualquier servido (tpicamente una intervendn). El objetivo tiene que
ser una observadn en modo aiterio.
Un resultado no deseado notable de la condidn de un padente que o es bastante
probable que llegar a ser un tema que tratar o es menos probable pero
sufidentemente peligroso como para ser atendido.
Esta es un reladn muy poco espetfico de un tem de informadn clnica con
otro. No juzga con respecto al rol realizado por la informadn pertinente.
Una reladn en que el acto objetivo autoriza o certifica el acto fuente.
Una aserdn de que se dio por sentado que una nueva observadn fue la causa de
una observadn existente. La suposidn se atribuye al mismo actor que asevera la
observadn. Esto es ms fuerte y ms espetfico que el enlace de soporte. Por
ejemplo, una colonizadn por Staphylococcus aureus puede ser considerado la
causa de un absceso. La fuente (causa) es tpicamente una observadn, pero puede
ser cualquier servido, mientras el objetivo tiene que ser una observadn.
Una reladn en que el acto fuente est cubierto por es est bajo la autoridad de un
acto diana. Un instrumento fnandero como un Elemento de Facturadn est
cubierto por uno o ms instandas espedficas de una Pliza de Seguros.
Un enlace de derivadn sirve para asodar expUdtamente una observadn con sus
parmetros de entrada. Tanto la fuente como el objetivo tienen que ser
observadones, tpicamente observadones numricas. P. ej., una observadn de
aninico gap puede ser asodado como siendo derivada de observadones de sodio,
(potasio), cloruro, y bicarbonato dadas.
240
Captulo 9. Anexos
EXPL
tiene explicacin
UMIT
limitado por
MFST
es una manifestacin
de
AME
asigna nombre
PREV
tiene instancia previa
REFR
refiere a
REFV
tiene valores de
referencia
SPRT
tiene soporte
SUMM
resumido por
CHRG
tiene cargo
COST
tiene costo
CREDIT
tiene crdito
DEBIT
tiene dbito
PRCN
tiene precondidn
CIND
tiene contraindicacin
RACT
es requerido por
Esto es una inversin de soporte. Empleada para indicar que una observacin dada
se explica por medio de otra observacin o condicin.
Una relacin que limita o restringe el acto fuente por los elementos del acto diana.
Por ejemplo, una autorizacin puede limitarse por una cantidad de dinero (hasta
$500). El acto objetivo tiene que estar en modo EVN.CRTT.
Una asercin de que tma nueva observacin puede ser la manifestacin de otra
observcicin o acdn existente. Esta suposicin se atribuye al mismo actor que
asevera la manifestacin. Esto es ms fuerte y ms especfico que un enlace de
soporte invertido. Por ejemplo, se puede aseverar que un aspecto agitado es la
manifestacin (efecto) de una hipertiroxia conocida. Esto expresa el hecho de que
uno puede no haberse dado cuenta de un sntoma si no fuera ima manifestacin
comn de una condicin conocida. El objetivo (causa) puede ser cualquier servicio,
mientras la fuente (manifestacin) tiene que ser una observacin.
Empleado para asignar un "nombre" a un ho de condicin. La fuente es un nodo
de condicin; el objetivo puede ser cualquier servido.
Una reladn en que el acto objetivo es ima instanda predecesor al acto fuente.
Generalmente, cada una de estas instandas es similar, pero no idntica. En la
cobertura sanitaria, se emplea para enlazar un tem de reclamadn a un tem de
reclamadn previo que puede haberse reclamado por el mismo conjunto de
servidos.
Una reladn en que el acto objetivo es referido por el acto fuente. Esto permite
una reladn referenda sendlla que distingue entre el referente y el referee.
Intervalos de referenda que esendalmente son desaiptores de una clase de valores
de resultados que se suponen son "normales", "anomiales" o "crticos". Estos
pueden variar en cuanto al sexo, la edad o cualquier otro oiterio. La fuente y el
objetivo son observadones; el objetivo est en modo criterio. Este tipo de enlace
puede actuar como un gatillo en el caso de que se desencadenen alarmas por
resultados crticos.
Usado para indicar que im servido existente est sugiriendo evidenda para una
nueva observadn. La suposidn de soporte se atribuye al mismo actor asevera la
observadn. La fuente tiene que ser ima observadn; el objetivo puede ser
cualquier servido (p. ej., paia indicar un puesto de estatus).
Un acto que contiene valores de resumen para una lista o conjunto de actos
subordinados. Por ejemplo, un resumen de transacdones para un periodo de
contabilidad en particular.
Una reladn que provee una habilidad de asodar una transacdn finandera
(diana) como cargo a un acto clnico (fuente). Un acto clnico puede tener un cargo
asodado con la ejecudn o entrega del servido. La transacdn nandera definir
el cargo (factura) por la entrega o realizadn del servido. Cargos y costes son
trminos distintos. Un cargo define lo que es cargado o facturado a otra
organizadn o entidad dentro de una organizadn. El coste define lo que cuesta a
una organizadn realizar o entregar un servido o producto.
Una reladn que provee una habilidad de asodar una transacdn finandera
(diana) como costo a un acto clnico (fuente). Un acto clnico puede tener un costo
inherente asodado con la ejecudn o entrega del servido. La transacdn
finandera definir el costo de la entrega o realizadn del servido. Cargos y costes
son trminos distintos. Un cargo define lo que es cargado o facturado a otra
organizadn o entidad dentro de una organizadn. El coste define lo que cuesta a
una organizadn realizar o entregar un servido o producto.
Una reladn de crdito vincula una transacdn finandera a una cuenta. Un
crdito, una vez aplicado (apuntado), puede tener un efecto positivo o negativo
sobre el balance de la cuenta, dependiendo del tipo de cuenta. Un ardito de cuenta
de activos redudr el balance de la cuenta. Un crdito de cuenta no de activos
reducir el balance de la cuenta.
Una reladn de dbito vincula una transacdn finandera (diana) a una cuenta
(fuente). Un dbito, una vez aplicado (apuntado), puede tener un efecto positivo o
negativo sobre el balance de la cuenta, dependiendo del tipo de cuenta. Un dbito
de cuenta de activos incrementar el balance de la cuenta. Un dbito de cuenta no
de activos redudr el balance de la cuenta
Un requisito que tiene que ser verdadera antes de que se realice un servido. El
objetivo puede ser cualquier servido en modo condidn. Para precondidones
mltiples, se puede aplicar un atributo de conjundn (AND, OR, XOR).
Una contraindicadn es simplemente una negadn de una razn (es dedr, ofrece
una condidn bajo la cual la acdn no se puede llevar a cabo. Tanto la fuente
como el objetivo pueden ser cualquier tipo de servido; el servido de objetivo est
en modo criterio. El modo en que se expresa la fuerza de una contraindicadn (p.
ef., relativa, absoluta) se deja abierto. Se puede emplear el atributo priorityNumber.
Un ado requerido para un servido o instrumento finandero como puede ser un
241
Captulo 9. Anexos
RSON
tiene razn
SUGG
sugiere
TRIG
tiene activador
RPLC
reemplaza
SUCC
SEQL
sucede
es continuacin
FLFS
despacha (un pedido)
DISP
OCCR
dispensando para (un

pedido)
incidente
OREF
referencia peticin
SCH
programa peticin
APND
es apndice
GEN
tiene generalizacin
GEVL
evala (objetivo)
INST
representa por una

instancia concreta
(maestro)
ITGT
tiene objetivo de
interaccin
MTCH
pareja
REV
invierte
plan 0 pliza de seguros. El acto requerido se desencadenar tpicamente por un

Acto criterio evento. Es decir, si ocurre una condicin especfica (p. ej., se exceden
los lmites de cobertura), entonces se tiene que realizar el acto requerido (p. ej.,
notificar a la parte cubierta).
La razn o racional para un servicio. Un enlace de razn es ms dbil que un
gatUlo; slo sugiere que algn servicio puede o no haber sido la razn por alguna
accin, pero no que esta razn requiere/requiri que la accin se realizara.
Tambin, al contrario al gatillo, no hay una relacin temporal fuerte entre la razn
y la accin.
Esto es vma inversin del enlace de razn, usada para expresar recomendaciones o
sugerencias, por ejemplo, las recomendaciones ofi'ecidas por un especialista al
final de un informe diagnstico.
Una precondidn que si verdadera, permitira, sugerira o demandara que el
servicio fuente (accin) fuera ejecutado. El objetivo est en modo criterio. Un
retraso entre el activador y la accin desencadenada puede ser espedficado.
Un acto fuente reemplazante reemplaza un acto objetivo existente. El estado del
acto objetivo siendo reemplazado se convierte en obsoleto, pero tpicamente, se
retiene el acto en el sistema para referenda histrica. La fuente y el objetivo tienen
que ser del mismo tipo.
Un nuevo orden que aade a pero no reemplaza completamente su predecesor.
Una reladn de acto indicando que el acto fuente es la continuadn del acto diana.
En prindpio, el acto fuente debe representar el mismo tipo de acto que el acto
diana. Fuente y objetivo no necesariamente tienen el mismo cdigo de modo
(muchas veces el modo ser diferente). El objetivo de una continuadn se llama
antecedente. Ejemplos de reladones de continuadn son: una revisin, una
transformadn, una derivadn de un prototipo (como una especializadn es una
derivadn de una generalizadn), un seguimiento, una realizadn, representadn
de la reladn por una instanda concreta.
El acto fuente despacha (en su totalidad o en parte) el acto diana. El acto fuente
tiene que estar en un modo i ^ a l a o ms real que el acto diana.
Enlace un servido de medicadn (\m pedido) con un servido de provisin,
representando la dispensadn de la droga (como pedido o evento).
El acto fuente es un inddente aislado de un acto objetivo repetible. Los actos
fuente y objetivo pueden estar en cualquier modo en la "trayectoria de
cumplimento" pero el acto fuente slo puede ser igual o ms avanzado que el acto
objetivo(es dedr, el que ocurra un intento puede ser un evento, pero no viceversa).
Reladona o una petidn de una dta o una dta con el pedido del servido que se
est programando.
Asoda un tiempo espetfico (y recursos asodados) con una petidn de
programadn u otro intento.
Una addenda (fuente) a un objeto de servido existente (diana) que contiene
informadn adidonal. La propia addenda es un objeto de servido original
enlazada al objeto de servido suplementado. El objeto de servido suplementado
permanece en su sitio y su contenido y estado no cambian.
La reladn de generalizadn puede utilizarse para expresar conodmientos
categricos con respecto a servidos (p. ej., amilorida, triamtereno y
espironolactona tienen la generalizadn comn de diurtico ahorrador de potasio.
La evaluadn de un objetivo enlaza una observadn (intento o real) a un objetivo
para indicar que le observadn evala el objetivo. Conoddos el objetivo y la
observacin, una "distancia de objetivo" (p. ej., objetivo u observacin) puede ser
"calculada" y no tiene que enviarse expldtamente.
Usado para capturar el enlace entre un servicio potencial ("maestro" o plan) y un
servido real, en que el servido real representa el servido potencial por una
instanda concreta. Esta representadn por una instancia conaeta puede supeditar
las carendas del maestro.
Reladona un evento de Control al Acto (o actos) con que se reladona. Se puede
usar tanto cuando desencadenando el evento como para mostrar eventos
desencadenados anteriormente (p. ej., una Hsta de eventos previos modificando el
Acto).
Una pareja-gatiUo enlaza un servido real (p. ej., una observadn o procedimiento
que tuvo lugar) con un servido en modo criterio. Por ejemplo, si el gatillo es
"observacin de dolor" y realmente se observa el dolor, y si esa observacin de
dolor hizo que el gatillo disparara, esa observadn de dolor se puede enlazar con el
gatillo.
Una reladn entre dos transacdones finanderas que se emplea cuando una
transacdn apuntada se invierte y tiene que ser referendada por la transacdn de
inversin subsiguiente. La transacdn finandera fuente es la transacdn que tiene
que invertirse y la transacdn finandera objetivo es la que se est invirtiendo.
242
Captulo 9. Anexos
SBST
UPDT
RPLC
succ
APND
COMP
DOC
OPTN
XFRM
sustituye (producto de Un enlace especial entre medicamentos indicando que la fuente es un genrico de
marca)
la diana.
actualiza (condicin) Una relacin hilo de condicin enlaza especfcamente nodos de condicin para
formar un hilo de condicin. La fuente es el nuevo nodo de condicin y el objetivo
enlaza al nodo ms reciente del ho de condicin existente.
reemplaza
Un acto fuente reemplazante reemplaza un aao objetivo existente. El estado del
acto objetivo siendo reemplazado se convierte en obsoleto, pero tpicamente, se
retiene el acto en el sistema para referencia histrica. La fuente y el objetivo tienen
que ser del mismo tipo.
Un nuevo orden que aade a pero no reemplsiza completamente su predecesor.
sucede
Una addenda (fuente) a xm objeto de servicio existente (diana) que contiene
es apndice
informacin adicional. La propia addenda es un objeto de servicio original
enlazada al objeto de servicio suplementado. El objeto de servido suplementado
permanece en su sitio y su contenido y estado no cambian.
Una coleccin de sub-servidos como pasos o subtareas realizados para el servido
tiene componente
fuente. Los servidos pueden realizarse de manera secuendal o concurrente. Ver
abajo la Secdn 1 para detalles.
documentos
El acto fuente documenta el acto diana.
tiene opcin
Opdones alternativas mltiples para opdones o preferendas para una pedido, va o
programadn pueden espedficarse para un servido planeado (o pedido). La fuente
(plan) est en modo definidn, intento o pedido.
transformacin
Empleado cuando el Acto objetivo es una transformadn del Acto fuente. (Por
ejemplo, se emplea para mostrar que un documento CDA es una transformadn de
va documento DICOM SR.)
Anexo 14. Control Contexto de Relacin entre Actividades

Mnemnico
Nombre de
Impresin
I
IOS
heredable
El objeto puede ser heredado; no hereda asodadones con otros objetos.
supeditado heredable El objeto puede heredarse; no hereda asodadones con otros objetos. Una
supeditadn enmascara objetos heredados del mismo tipo/clase o ms espedfico.
conductivo
El objeto no puede ser heredado, pero hereda asodadones con otros objetos.
no conductivo
El objeto no puede ser heredado; no hereda asodadones con otros objetos.
Descripcin
243

PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

PDF

Hochgeladen von

Copyright:

Verfügbare Formate

UNIVERSroAD POLITCNICA DE MADRID

ESCUELA TCNICA SUPERIOR DE INGENIEROS DE

Modelo de Historia Clnica Electrnica

Carlos Hernndez Salvador

Departamento de Tecnologa Fotnica

Modelo de Historia Clnica Electrnica

Autor: Carlos Hernndez Salvador

Director: Francisco del Pozo Guerrero

Tribunal nombrado por el Magnfico y Excelentsimo Sr. Rector de la Universidad

Realizado el acto de defensa y lectura de la Tesis el da

1.1 Teleconsulta entre profesionales sanitarios

1.1.1 Aspectos estructurales de la teleconsulta

1.1.2 Aspectos legales y de seguridad de la teleconsulta

1.1.3 Tipos de teleconsulta

1.1.3.1 Teleconsulta a un especialista

1.1.3.2 Teleconsulta en trabajo cooperativo

1.1.3.3 Teleconsulta en telepresencia

1.1.3.4 Sesiones clnicas distribuidas

1.2 Descripcin del problema. Integracin de la teleconsulta en el proceso asistencial

1.2.1 Soporte a la colaboracin en equipos asistenciales

1.2.2 i^aricin de un nuevo escenario

1.3 Descripcin del planteamiento del trabajo

1.4 Descripcin del documento

Captulo 2. Hiptesis y Objetivos

2.1 Hiptesis departida

2.2 Objetivos del trabajo

2.2.1 Objetivo primario

2.2.2 Objetivos especficos

Captulo 3. Situacin actual de la normalizacin de la historia cKnica

3.1 Dominio de la informacin clnica

3.2 Propuesta de desarrollo de estndares

3.2.1 Requerimientos de usuario

3.2.2 Paradigmas de Diseo

3.2.2.1 Separacin de responsabilidades

3.2.2.2 Separacin de puntos de vista

3.2.2.3 Separacin Conocimiento / Informacin

3.2.3 Nueva metodologa de desarrollo

3.2.3.1 Terminologa en la HCE

3.2.3.2 Modelo de Referencia

3.2.3.3 Modelo de Conocimiento

3.2.3.4 Variabilidad en ios conceptos

3.2.3.6 Propuesta con doble modelo

3.2.4 Representacin del conocimiento del dominio

3.2.4.1 Anlisis ontolgico

3.2.4.2 Anlisis del contexto

3.2.4.3 Propuesta sobre Arquetipos y Tompiates

3.2.4.3.1 Consideraciones semnticas

3.2.4.3.2 Consideraciones de usuario

3.2.4.4 Propuesta de doble modelo + representacin controlada

3.3 Modelo Universal del dominio

3.3.1 CEN/TC251AVG1, WG2

Captulo 4. Material y Mtodos

Material. Modelos de referencia

Modelo de referencia EHR_Extract (prENV13606:2003)

Clases y relaciones relevantes

Modelo de referencia HL7 RIM (subconjunto para GPICs)

Material. Conceptos del dominio

Componentes de informacin de propsito general (GPIC)

4.2.1.1 Descripcin de los GPICs

4.2.1.1 GPICs No-Clnicos

4.2.1.2 GPICs Clnicos

Sistema de conceptos en asistencia continuada

4.2.2.2 Temas de salud y su gestin