View
215
Download
0
Category
Preview:
Citation preview
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 1
Presentaciónde HL7 versión 3
Josep Vilalta Marzo
Universitat Internacional de Catalunya
www.vico.org
Con la colaboración de:
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 2
Conceptos clave V3
HL7 V2
• Implementada desde 1989.
• Utilizada para el intercambio de datos entre hospitales y sus proveedores.
• Ampliamente usada en USA y a nivel internacional.
• Se han realizado múltiples adaptaciones.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 3
Conceptos clave V3
HL7 V2: Problemas• No dispone de un vocabulario controlado.
• Diferentes modelos de datos
• No está fundamentada sobre una tecnología orientada a objetos.
• Falta una trazabilidad entre mensajes, eventos y campos.
• No es “Plug and Play”
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 4
Conceptos clave V3
HL7 V3• Facilita una nueva metodología de desarrollo.
• Incluye mecanismos que le permiten adptarse a cualquier contexto sanitario internacional.
• Compatibilidad funcional con las versiones anteriores V2.x.
• Garantía de compatibilidad con futuras versiones V3.x.
• Utiliza un vocabulario controlado para construir mensajes a partir de modelos abstractos.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 5
Conceptos clave V3
HL7 V3 compatibilidad• Cualquier estructura de mensaje modificada en
nuevas versiones del protocolo será aceptada por un sistema con una versión anterior.
• Cuando no sea posible una compatibilidad real con un nuevo protocolo, podrá implementarse de manera escalable.
• Cuando una estructura de mensaje se declare obsoleta en una versión, proporcionará una estructura alternativa.
• Tanto la estructuta de mensaje obsoleta como la alternativa podrán utilizarse en todos los sistemas que soporten dicha versión.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 6
Conceptos clave V3
HL7 V3 metodología
• La tecnología orientada a objetos facilita un modelado que captura los datos esenciales y la semántica asociada a las actuaciones sanitarias.
• Utiliza la notación UML (Unified Modeling Language) para definir su arquitectura.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 7
Conceptos clave V3
HL7 V3 metodología
• Se basa en un modelo de referencia “Reference Information Model” (RIM) a partir del cual podemos modelar todas las piezas necesarias para construir los planos de un mensaje y su dinámica.
• El RIM define unas 70 Clases que provienen de un núcleo principal con 6 Clases fundamentales. Representa la lógica de negocio de cualquier contexto sanitario.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 8
Conceptos clave V3
HL7 V3 RIM nucleo principal
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 9
Conceptos clave V3
HL7 V3 RIM
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 10
Conceptos clave V3
HL7 V3 metodología
• Un mensaje concreto se construye a partir de un modelo (los planos) donde reside su especificación.
• La especificación exacta de los campos de un mensaje, sus agrupaciones, secuencia, opcionalidad y cardinalidad, está definida por un HMD “Hierarchical Message Description”.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 11
Conceptos clave V3
HL7 V3 metodología
Define
HMD
Mensaje
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 12
Conceptos clave V3
HL7 V3 metodología
• El modelo de un HMD es elaborado a partir de una estructura de información definida por el R-MIM “Refined Message Information Model”que representa los requerimientos de un conjunto de mensajes que comparten una misma tipología.
• Todos los conceptos usados para construir un conjunto de R-MIMs orientados a soportar los requerimientos de comunicación de un dominio concreto de HL7 provienen de un D-MIM “Domain Message Information Model”
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 13
Conceptos clave V3
HL7 V3 metodología
Define
Define
Define
D-MIM
R-MIM
HMD
Mensaje
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 14
Conceptos clave V3
HL7 V3 metodología
• Todos los conceptos usados para construir un D-MIM “Domain Message Information Model” provienen del modelo de referencia “Reference Information Model” (RIM) que como ya sabemos es el que articula todas las piezas necesarias para elaborar los planos de un mensaje y su dinámica.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 15
Conceptos clave V3
HL7 V3 metodología
Instancia
Define
Define
Define
RIM
D-MIM
R-MIM
HMD
Mensaje
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 16
Conceptos clave V3
HL7 V3 metodología
• Para poder capturar toda la información necesaria que define un mensaje concreto necesitamos formalizar:
• Roles de Aplicación (application roles).-Definen las responsabilidades del sistema emisor y del sistema receptor.
• Eventos de Activación (trigger events).-Definen las causas que motivan el envío de un mensaje.
• Escenarios (storyboards).- Definen un escenario de usabilidad del sistema por parte de un usuario.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 17
Conceptos clave V3
HL7 V3 metodología
Escenario
Emisor
Receptor
Activa
Rol deAplicación
EventoActivador
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 18
Conceptos clave V3
HL7 V3 metodología
• Para construir un mensaje conforme a la norma HL7 se requiere:
• Modelo de Interacción
• HMD
• R-MIM
• D-MIM
• Estos modelos deben ser evaluados en un proceso de revisión y consenso (balloting).
• Si el nuevo mensaje requiere modificar el RIM se realiza un balloting específico.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 19
Conceptos clave V3
HL7 V3 metodología
Escenario
Emisor
Receptor
Activa
Instancia
Contiene
Define
Define
Define
Rol deAplicación
EventoActivador
Interacción
RIM
D-MIM
R-MIM
HMD
Mensaje
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 20
Conceptos clave V3
HL7 V3 metodología
Escenario:
• Es una descripción sucinta de un proceso donde necesitamos un “Mensaje” para resolver un problema de interoperabilidad entre un sistema emisor y otro receptor (Rol de Aplicación).
• Todo escenario dispone de un identificador y de un propósito.
• Es formalizado mediante el artefacto UML denominado Caso de Uso que define el flujo de eventos de la interacción y declara las precondiciones necesarias y las postcondiciones
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 21
Conceptos clave V3
HL7 V3 metodología
Escenario
Especifica
Emisor
Receptor
Activa
Instancia
Contiene
Define
Define
Define
Caso deUso
Rol deAplicación
EventoActivador
Interacción
RIM
D-MIM
R-MIM
HMD
Mensaje
Es formalizado
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 22
Conceptos clave V3
HL7 V3 metodología
Escenario:
• Un traumatólogo recibe a un paciente aquejado de un dolor articular en la rodilla izquierda con un mes de evolución. Una vez realizada la consulta, decide solicitar la autorización de una Resonancia Magnética a la mútua del paciente y consulta la disponibilidad de agenda de distintos centros concertados.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 23
Conceptos clave V3
HL7 V3 metodología
Roles de Aplicación:
• En la HL7 V2 la construcción de mensajes se centra sólo en su estructura.
• En la HL7 V3 todo mensaje define el rol del sistema emisor y el rol del sistema receptor.
• El rol especifica el comportamiento de la aplicación que envía o recibe el mensaje.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 24
Conceptos clave V3
HL7 V3 metodología
Roles de Aplicación:
• Justifican las razones por las cuales dicho mensaje ha sido enviado en base al propósito de un proceso.
• Todo sistema emisor puede disponer de una serie de roles de aplicación de acuerdo con los mensajes que puede enviar y recibir.
• Las causas que desencadenan el envío de un mensaje quedan identificadas como eventos activadores.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 25
Conceptos clave V3
HL7 V3 metodologíaRol de Aplicación:
• Publicador de eventos determinación analítica
Descripción:
• Una aplicación que es capaz de notificar a otro sistema sobre los distintos eventos que se producen durante la realización de una determinación en el laboratorio.
• Un sistema que dispone de este rol, será capaz de saber los distintos hitos del ciclo de vida de una determinación (ej. Resultados disponibles).
• Este sistema también será capaz de notificar cada hito relevante a otro sistema.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 26
Conceptos clave V3
HL7 V3 metodologíaRol de Aplicación:
• Está asociado a una lista de interacciones donde este rol participa.
• El rol Publicador de eventos determinación analítica participa en la interacción:
“Determinación analítica finalizada”
• La definición completa de esta interacción incluye un “rol de aplicación de envío”, un “rol de aplicación de recepción” y la definición del mensaje que es intercambiado.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 27
Conceptos clave V3
HL7 V3 metodología
Rol de Aplicación:
• HL7 ni condiciona ni trata de estandarizar los mecanismos internos del sistema emisor y receptor que serán necesarios para llevar a cabo las responsabilidades que exige el rol de aplicación que han asumido.
• HL7 define los términos de comportamiento de cada sistema como un contrato de funcionalidaden base a un rol de aplicación.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 28
Conceptos clave V3
HL7 V3 metodología
Rol de Aplicación:
• Cuando un proveedor de software afirma que sus aplicaciones cumplen la conformidad de unos roles de aplicación HL7:
• Envían todos los mensajes requeridos.
• Reciben todos los mensajes requeridos.
• Ejecutan la funcionalidad asociada a todas las interacciones
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 29
Conceptos clave V3
HL7 V3 metodología
Evento Activador:
• Relación de condiciones que activan el transfer de información entre los componentes de distintos sistemas.
• Ejemplos: Petición de una analítica, Prescripción de un fármaco, cualquier orden médica o de enfermería.
• El evento activador ha de ser reconocido e interpretado por un sistema.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 30
Conceptos clave V3
HL7 V3 metodología
Definición de un Evento Activador:
• Nombre
• Identificador
• Descripción
• Nombre estructurado (Clasifica distintos dominios: Laboratorio, Farmacia, Radiología...)
• Tipo
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 31
Conceptos clave V3
HL7 V3 metodología
Tipos de Evento Activador:
• EA basado en una interacción de sistemaEj.- La respuesta a un Query
• EA basado en una transición de estadosEj.- La cancelación de una petición de laboratorio
• EA basado en una consulta de usuarioEj.- Subscripción a un monitor de información que actualiza datos clínicos cada 12 horas
• EA genéricoEj.- No puede clasificarse en las tres categorías anteriores
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 32
Conceptos clave V3
HL7 V3 metodología
Ejemplo descripción de Evento Activador:
• Nombre estructurado.- Notificación final de evento de Farmacia.
• Tipo.- EA basado en una transición de estados.
• Indica que ha finalizado la dispensación y administración de un fármaco.
• Indica que la aplicación receptora ha sido informada pero sin necesidad de requerir su actuación a partir de este evento.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 33
Reference Information Model (RIM)
• Modelo de información expresado en artefactos UML que representa clases de información que debe ser intercambiada y sus diferentes relaciones.
• Todo la estructura de los mensajes HL7 V3 está construida a partir de las clases y asociaciones definidas en el RIM.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 34
Reference Information Model (RIM)
• Con la notación UML definimos mediante Clases las representaciones abstractas de objetos y eventos del mundo real.
Entidad
Class_CD : CSCD : CVDeterminer_CD : CSStatus_CD : CSID : II
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 35
Reference Information Model (RIM)
• Actuación.- Algo que ha sucedido, está sucediendo, o puede suceder en el futuro.
• Entidad.- Persona, especímen, organización, documento o cualquier otro objeto.
• Rol.- Responsabilidad o papel que puede jugar una entidad.
• Participante.- La involucración de un rol en una actuación.
• Actuación_Relacionada.- Asociación definida entre dos Actuaciones.
• Rol_Relacionado.- Asociación definida entre dos Roles.
El RIM de HL7 define seis Clases fundamentales:
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 36
Reference Information Model (RIM)Clases fundamentales:
0..*
1 0..*
1EntidadEntidad ParticipanteParticipante ActuaciónActuación
RolRolRelacionadoRelacionado
0..* 0..*
1 1
ActuaciónActuaciónRelacionadaRelacionada
1 1
0..* 0..*
RolRol0..1
0..*
OrganizaciónForma de vidaMaterialPunto actuaciónDocumento
PacienteEmpleadoMédico de cabeceraMédico de guardiaMuestra de análisis
DerivaciónTransporteSuministroProcedimientoCondiciónConsentimientoObservaciónMedicaciónActo clínicoActo económico
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 37
Reference Information Model (RIM)
• Cada clase dispone de un conjunto de items de datos que son agrupados en distintas categorías con el nombre de atributos.
• Todas las demás Clases del RIM son especializaciones de las seis Clases fundamentales.
• Cada Clase especializada añade nuevos atributos para definir su especialización.
• Persona es una especialización de la Clase Entidad“Forma de Vida” y añade atributos como “domicilio”, “código de discapacidad”, etc.
Atributos y especializaciones:
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 38
Reference Information Model (RIM)
• Con UML podemos describir relaciones lógicas entre Clases.
• Podemos establecer asociaciones entre diferentes Clases o entre dos instancias de una misma Clase.
• Representamos una asociación mediante una línea que vincula a dos Clases mediante dos conectores.
Asociaciones entre Clases:
Entidad
Class_CD : CSCD : CVDeterminer_CD : CSStatus_CD : CSID : II
Rol
Class_CD : CSCD : CVEffective_TMR : IVL<TS>Status_CD : CSID : II
0..1juega
0..*
0..1habilita
0..*
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 39
Reference Information Model (RIM)
• Cada conector de una asociación tiene una propiedad que especifica el mínimo y el máximo número de instancias de la clase que conecta.
• Denominamos a esta propiedad la cardinalidad de la asociación.
Asociaciones entre Clases:
Entidad
Class_CD : CSCD : CVDeterminer_CD : CSStatus_CD : CSID : II
Rol
Class_CD : CSCD : CVEffective_TMR : IVL<TS>Status_CD : CSID : II
0..1juega
0..*
0..1habilita
0..*
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 40
Reference Information Model (RIM)
Clases fundamentales:
1 0..* 10..*
Rol_Relacionado
Type_CD : CSEffective_TMR : IVL<TS>
0..* 0..*0..*
1 1
Entidad
Class_CD : CSCD : CVDeterminer_CD : CSStatus_CD : CSID : II
Rol
Class_CD : CSCD : CVEffective_TMR : IVL<TS>Status_CD : CSID : II
Participante
Type_CD : CSTMR : IVL<TS>Status_CD : CS
Actuación
Class_CD : CSCD : CDMood_CD : CSStatus_CD : CSActivity_Time : GTSID : II
Actuación_Relacionada
0..1
juega
0..*
0..1
habilita
0..*
0..*
Type_CD : CS
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 41
Reference Information Model (RIM)
Clases fundamentales:
A_Observationactivity_time : GTScd : CDclass_cd : CSid : SET<II>mood_cd : CS
A_Observationactivity_time : GTScd : CDclass_cd : CSid : SET<II>mood_cd : CS
P_Authorsignature_cd : CVsignature_txt : EDtype_cd : CS
1..1 1..1
has
1..1
for
1..1
P_Subjecttype_cd : CS0..11..1
for
0..1
has
1..1
P_Performertype_cd : CS
0..*
1..1
for
0..*
has1..1
A_Observationactivity_time : GTScd : CDclass_cd : CSid : SET<II>mood_cd : CS
P_Authorsignature_cd : CVsignature_txt : EDtype_cd : CS
1..1 1..1
has
1..1
for
1..1
P_Subjecttype_cd : CS0..11..1
for
0..1
has
1..1
P_Performertype_cd : CS
0..*
1..1
for
0..*
has1..1
R_Providerclass_cd : CSid : SET<II>telecom : SET<TEL>0..* 1..1
has_as_participant
0..*participates_in
1..1
R_practitionerclass_cd : CSid : SET<II>telecom : SET<TEL>0..* 1..1
has_as_participant
0..*participates_in
1..1
R_patientaddr : SET<AD>class_cd : CSid : SET<II>
0..* 1..1
has_as_participant
0..*participates_in
1..1
A_Observationactivity_time : GTScd : CDclass_cd : CSid : SET<II>mood_cd : CS
P_Authorsignature_cd : CVsignature_txt : EDtype_cd : CS
1..1 1..1
has
1..1
for
1..1
P_Subjecttype_cd : CS0..11..1
for
0..1
has
1..1
P_Performertype_cd : CS
0..*
1..1
for
0..*
has1..1
R_Providerclass_cd : CSid : SET<II>telecom : SET<TEL>0..* 1..1
has_as_participant
0..*participates_in
1..1
R_practitionerclass_cd : CSid : SET<II>telecom : SET<TEL>0..* 1..1
has_as_participant
0..*participates_in
1..1
R_patientaddr : SET<AD>class_cd : CSid : SET<II>
0..* 1..1
has_as_participant
0..*participates_in
1..1
E_Organizationclass_cd : CSid : SET<II>nm : SET<EN>
played_by plays
0..10..* 0..10..*
E_Person_practitionerclass_cd : CSid : SET<II>nm : SET<EN>telecom : SET<TEL>
plays
played_by0..* 1..10..* 1..1
E_Person_patientclass_cd : CSid : SET<II>nm : SET<EN>telecom : SET<TEL>administrative_gender_cd : CEbirth_time : TS
plays
played_by0..* 0..10..* 0..1
ActuaciónActuación ParticipanteParticipante RolRol EntidadEntidad
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 42
Reference Information Model (RIM)Clases fundamentales:
A_Observationactivity_time : GTScd : CDclass_cd : CSid : SET<II>mood_cd : CS
P_Authorsignature_cd : CVsignature_txt : EDtype_cd : CS
1..1 1..1
has
1..1
for
1..1
P_Subjecttype_cd : CS0..11..1
for
0..1
has
1..1
P_Performertype_cd : CS
0..*
1..1
for
0..*
has1..1
R_Providerclass_cd : CSid : SET<II>telecom : SET<TEL>0..* 1..1
has_as_participant
0..*participates_in
1..1
R_practitionerclass_cd : CSid : SET<II>telecom : SET<TEL>0..* 1..1
has_as_participant
0..*participates_in
1..1
R_patientaddr : SET<AD>class_cd : CSid : SET<II>
0..* 1..1
has_as_participant
0..*participates_in
1..1
E_Organizationclass_cd : CSid : SET<II>nm : SET<EN>
played_by plays
0..10..* 0..10..*
E_Person_practitionerclass_cd : CSid : SET<II>nm : SET<EN>telecom : SET<TEL>
plays
played_by0..* 1..10..* 1..1
E_Person_patientclass_cd : CSid : SET<II>nm : SET<EN>telecom : SET<TEL>administrative_gender_cd : CEbirth_time : TS
plays
played_by0..* 0..10..* 0..1
12 3 4
5 6 7
8 9 10
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 43
• Un D-MIM “Domain Message Information Model” muestra todas las clases y las relaciones usadas para construir un mensaje correspondiente a un dominio concreto (Ej.-Farmacia, Laboratorio, Radiología...).
• Un R-MIM “Refined Message Information Model” define un conjunto relacionado de mensajes correspondiente a un sector de un dominio concreto.
Del RIM al modelado de D-MIMs y R-MIMs
Origen / DestinotypeCode*:<=?
Origen / DestinotypeCode*:<=?
Origen / DestinotypeCode*:<=?
Origen / DestinotypeCode*:<=?
Origen / DestinotypeCode*:<=?
Origen / DestinotypeCode*:<=?
typeCode*: <= ParticipantetypeCode*: <= Participante
EntidadclassCode*: <= ENTdeterminerCode*: <= EntityDeterminername*: PN [0..1] addr*: AD [0..1]
EntidadclassCode*: <= ENTdeterminerCode*: <= EntityDeterminername*: PN [0..1] addr*: AD [0..1]
ActuaciónclassCode*: <= ACTmoodCode*: <= ActMoodcode*: CS CNE [1..1] <= (type of substitution)reasonCode*: CS CNE [0..1] <=
ActuaciónclassCode*: <= ACTmoodCode*: <= ActMoodcode*: CS CNE [1..1] <= (type of substitution)reasonCode*: CS CNE [0..1] <=
RolclassCode*: <= ROLid*: SET<II> [0..*] (Identifier(s)code*: CE CNE [0..1] <=
RolclassCode*: <= ROLid*: SET<II> [0..*] (Identifier(s)code*: CE CNE [0..1] <=
0..1
jugador
0..*
rol jugado
0..1
jugador
0..*
rol jugado
0..1habilitador
0..*rol habilitado
0..1habilitador
0..*rol habilitado
0..*rol origen
0..* rol destino
0..*rol origen
0..* rol destino
0..* participantes
0..*actuaciones
0..* participantes
0..*actuaciones
0..*actuación origen
0..*actuacióndestino
0..*actuación origen
0..*actuacióndestino
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 44
Origen / DestinotypeCode*:<=?
Origen / DestinotypeCode*:<=?
typeCode*: <= Participante
Del RIM al modelado de D-MIMs y R-MIMs
EntidadclassCode*: <= ENTdeterminerCode*: <= EntityDeterminername*: PN [0..1] addr*: AD [0..1]
ActuaciónclassCode*: <= ACTmoodCode*: <= ActMoodcode*: CS CNE [1..1] <= (type of substitution)
reasonCode*: CS CNE [0..1] <=
RolclassCode*: <= ROLid*: SET<II> [0..*] (Identifier(s)code*: CE CNE [0..1] <=
0..1
jugador
0..*
rol jugado
0..1habilitador
0..*rol habilitado
0..*rol origen
0..* rol destino
0..* participantes
0..*actuaciones
0..*actuación origen
0..*actuacióndestino
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 45
• El propósito de un D-MIM “Domain Message Information Model” es suministrar un punto de referencia común para los mensajes de todo el dominio y validar la compatibilidad de los R-MIM “Refined Message Information Model” de un mismo dominio (Ej.- Farmacia, Laboratorio, Radiología...).
Del RIM al modelado de D-MIMs y R-MIMs
Origen / DestinotypeCode*:<=?
Origen / DestinotypeCode*:<=?
Origen / DestinotypeCode*:<=?
Origen / DestinotypeCode*:<=?
Origen / DestinotypeCode*:<=?
Origen / DestinotypeCode*:<=?
typeCode*: <= ParticipantetypeCode*: <= Participante
EntidadclassCode*: <= ENTdeterminerCode*: <= EntityDeterminername*: PN [0..1] addr*: AD [0..1]
EntidadclassCode*: <= ENTdeterminerCode*: <= EntityDeterminername*: PN [0..1] addr*: AD [0..1]
ActuaciónclassCode*: <= ACTmoodCode*: <= ActMoodcode*: CS CNE [1..1] <= (type of substitution)reasonCode*: CS CNE [0..1] <=
ActuaciónclassCode*: <= ACTmoodCode*: <= ActMoodcode*: CS CNE [1..1] <= (type of substitution)reasonCode*: CS CNE [0..1] <=
RolclassCode*: <= ROLid*: SET<II> [0..*] (Identifier(s)code*: CE CNE [0..1] <=
RolclassCode*: <= ROLid*: SET<II> [0..*] (Identifier(s)code*: CE CNE [0..1] <=
0..1
jugador
0..*
rol jugado
0..1
jugador
0..*
rol jugado
0..1habilitador
0..*rol habilitado
0..1habilitador
0..*rol habilitado
0..*rol origen
0..* rol destino
0..*rol origen
0..* rol destino
0..* participantes
0..*actuaciones
0..* participantes
0..*actuaciones
0..*actuación origen
0..*actuacióndestino
0..*actuación origen
0..*actuacióndestino
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 46
• Una actuación es un elemento de un proceso de negocio donde participan una o varias entidades jugando un rol determinado.
• Dispone de un ciclo de vida y de una determinada situación en el tiempo. Ambos conceptos combinados fijan sus posibles estados y transiciones.
Del RIM al modelado de D-MIMs y R-MIMs
Actuación
Ejemplo: R-MIM “Refined Message Information Model”Médico de cabecera prescribe un fármaco a un paciente
PrescripcionclassCode*: <= SPLYmoodCode*: <= ORDstatusCode: <= ActStatusactivityTime:availabilityTime:
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 47
• Propósito: Ordenar la dispensación de un fármaco a un paciente.
• classCode Indica el tipo de actuación:
• SPLY.- Suministrar un item
• ENC.- Encuentro – Contacto – Cita
• OBS.- Determinación analítica
• SBADM.- Administrar una substancia
Del RIM al modelado de D-MIMs y R-MIMs
Actuación
Ejemplo: R-MIM “Refined Message Information Model”Médico de cabecera prescribe un fármaco a un paciente
PrescripcionclassCode*: <= SPLYmoodCode*: <= ORDstatusCode: <= ActStatusactivityTime:availabilityTime:
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 48
• moodCode indica el ciclo de vida de la actuación. En este caso, ha sido ordenada, pero aún no está entregada o administrada.
• PRP.- Propuesta – Plan
• ORD.- La prescripción ha sido ordenada
• PRMS.- – Compromiso
• APT.- Programado a fecha-hora
• EVN.- Evento en curso o realizado
Del RIM al modelado de D-MIMs y R-MIMs
Actuación
Ejemplo: R-MIM “Refined Message Information Model”Médico de cabecera prescribe un fármaco a un paciente
PrescripcionclassCode*: <= SPLYmoodCode*: <= ORDstatusCode: <= ActStatusactivityTime:availabilityTime:
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 49
Del RIM al modelado de D-MIMs y R-MIMs
Actuación
Ejemplo: R-MIM “Refined Message Information Model”Médico de cabecera prescribe un fármaco a un paciente
PrescripcionclassCode*: <= SPLYmoodCode*: <= ORDstatusCode: <= ActStatusactivityTime:availabilityTime:
• moodCode: Indica el ciclo de vida de una actuación, desde que se crea hasta que finaliza su vigencia o destrucción.
• statusCode: Indica la situación o estado que condiciona la evolución de su Ciclo de Vida.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 50
Del RIM al modelado de D-MIMs y R-MIMs
Estados de una Actuación
AparcadaSuspendida
Activa Completada
Abortada
Nueva
Cancelada
Anulada Obsoleta
evaluar
evaluar evaluar evaluar
evaluar
liberar
anulación obsolescencia
cancelaractivar
reiniciar
completar
finalizar
abortar
abortar
suspenderreactivar
crear
aparcar
activar completar
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 51
Del RIM al modelado de D-MIMs y R-MIMs
Entidad
Ejemplo: R-MIM “Refined Message Information Model”Médico de cabecera prescribe un fármaco a un paciente
PersonaclassCode*: <= PSNdeterminerCode*: <= INSTANCEname*: PN [1..1] addr*: AD [1..1]
• Una entidad representa un objeto, o grupo de objetos, capaz de participar en una actuación.
• Puede ser un objeto real: persona, organización, dispositivo, substancia, punto de actuación, etc.
• Puede ser un objeto virtual: diagnóstico, regla de negocio, clasificador, etc.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 52
Del RIM al modelado de D-MIMs y R-MIMs
Entidad
Ejemplo: R-MIM “Refined Message Information Model”Médico de cabecera prescribe un fármaco a un paciente
PersonaclassCode*: <= PSNdeterminerCode*: <= INSTANCEname*: PN [1..1] addr*: AD [1..1]
• classCode.- Indica el tipo de entidad:
• PSN.- Persona
• ORG.- Organización
• determinerCode: Indica la condición de la entidad.-
• INSTANCE.- Es una instancia de otra clase.
• VALUE.- Es un valor cuantificable.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 53
Del RIM al modelado de D-MIMs y R-MIMs
Rol
Ejemplo: R-MIM “Refined Message Information Model”Médico de cabecera prescribe un fármaco a un paciente
PersonaclassCode*: <= PSNdeterminerCode*: <= INSTANCEname*: PN [1..1] addr*: AD [1..1]
PacienteclassCode*: <= PATid*: [0..1] 1..1
pacientePersona
• Un rol representa una responsabilidad, una posición, o el papel que juega una entidad con respecto a su participaciónen una serie de actuaciones.
Entidad
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 54
Del RIM al modelado de D-MIMs y R-MIMs
Rol
Ejemplo: R-MIM “Refined Message Information Model”Médico de cabecera prescribe un fármaco a un paciente
PersonaclassCode*: <= PSNdeterminerCode*: <= INSTANCEname*: PN [1..1] addr*: AD [1..1]
PacienteclassCode*: <= PATid*: [0..1] 1..1
pacientePersona
• Esta asociación muestra que la entidad Persona, en el escenario de ejemplo, está jugando un rol de Paciente.
• El rol y la entidad se representan separadamente porque una entidad Persona puede jugar otros roles en distintos escenarios.
Entidad
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 55
Del RIM al modelado de D-MIMs y R-MIMs
Rol
Ejemplo: R-MIM “Refined Message Information Model”Médico de cabecera prescribe un fármaco a un paciente
• El rol de Agente también es jugado por una entidad Persona que es el Facultativo. Ambas entidades (Persona – Facultativo), provienen de la misma clase del RIM, pero son mostradas separadamente para relacionarlas con distintos roles.
Entidad
AgenteclassCode*: <= AGNTid*: [1..1]
FacultativoclassCode*: <= PSNdeterminerCode*: <= INSTANCEname*: [1..1] telecom*: [1..*]
agenteMedicoCabecera1..1
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 56
Del RIM al modelado de D-MIMs y R-MIMs
Rol
Ejemplo: R-MIM “Refined Message Information Model”Médico de cabecera prescribe un fármaco a un paciente
Entidad
AgenteclassCode*: <= AGNTid*: [1..1]
CentroAtencionPrimariaclassCode*: <= ORGdeterminerCode*: <= INSTANCEid*: [1..1] name*: [1..1]
agenteCentroAtencionPrimaria
0..1
• La entidad Centro de Atención Primaria también dispone del rol de Agente pero su tipo indica que es una Organización.
• La entidad Organización habilita al rol Agente para poder realizar una determinada práctica asistencial.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 57
Del RIM al modelado de D-MIMs y R-MIMs
Ejemplo: R-MIM “Refined Message Information Model”Médico de cabecera prescribe un fármaco a un paciente
• Un participante representa el tipo de involucración de un rol en una actuación.
• Un rol puede participar en múltiples actuaciones.
• Una actuación puede reunir a múltiples roles participantes.
typeCodeautor
*: <= AUT
typeCode*: <= PRFrealizador
typeCode*: <= PATSBJ sujetoPaciente
PrescripcionclassCode*: <= SPLYmoodCode*: <= ORDstatusCode: <= ActStatusactivityTime:availabilityTime:
1..1 paciente
1..1 medicoCabecera
1..1 farmaceutico
Participante
PacienteclassCode*: <= PATid*: [0..1]
MedicoCabeceraclassCode*: <= AGNTid*: [1..1]
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 58
Del RIM al modelado de D-MIMs y R-MIMs
Ejemplo: R-MIM “Refined Message Information Model”Médico de cabecera prescribe un fármaco a un paciente
typeCodeautor
*: <= AUT
typeCode*: <= PRFrealizador
typeCode*: <= PATSBJ sujetoPaciente
PrescripcionclassCode*: <= SPLYmoodCode*: <= ORDstatusCode: <= ActStatusactivityTime:availabilityTime:
1..1 paciente
1..1 medicoCabecera
1..1 farmaceutico
Participantes
PacienteclassCode*: <= PATid*: [0..1]
MedicoCabeceraclassCode*: <= AGNTid*: [1..1]
FarmaceuticoclassCode*: <= AGNTid*: [1..1]
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 59
Del RIM al modelado de D-MIMs y R-MIMs
Ejemplo: R-MIM “Refined Message Information Model”Médico de cabecera prescribe un fármaco a un paciente
• Una Actuación_Relacionada representa un tipo de asociación entre dos actuaciones.
• En este ejemplo el tipo de Actuación_Relacionada indica que la actuación ItemPrescripción es un simple componente de otra actuación, la Prescripción.
PrescripcionclassCode*: <= SPLYmoodCode*: <= ORDstatusCode: <= ActStatusactivityTime:availabilityTime:
ActuaciónRelacionada
ComponentetypeCode*:<=COMP
ItemPrescripcionclassCode*: <= SPLYmoodCode*: <= ORDcode*: [1..1] <= DrugCode text*: [1..1] <= effectiveTime: availabilityTime:
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 60
typeCodeautor
*: <= AUT
typeCode*: <= PRFrealizador
Ejemplo: R-MIM “Refined Message Information Model”Médico de cabecera prescribe un fármaco a un paciente
typeCode*: <= PATSBJ sujetoPaciente
PersonaclassCode*: <= PSNdeterminerCode*: <= INSTANCEname*: PN [1..1] addr*: AD [1..1]
PacienteclassCode*: <= PATid*: [0..1]
ComponentetypeCode*:<=COMP
DosisPrescritaclassCode*: <= SBADMmoodCode*: <= ORDcode*: DoseCode
activityTime:
MedicoCabeceraclassCode*: <= AGNTid*: [1..1]
FarmaceuticoclassCode*: <= AGNTid*: [1..1]
CentroAtencionPrimariaclassCode*: <= ORGdeterminerCode*: <= INSTANCEid*: [1..1] name*: [1..1]
FacultativoclassCode*: <= PSNdeterminerCode*: <= INSTANCEname*: [1..1] telecom*: [1..*]
FarmaciaclassCode*: <= ORGdeterminerCode*: <= INSTANCEid*: [1..1] name*: [1..1]
typeCode*: <= COMP Componente
PrescripcionclassCode*: <= SPLYmoodCode*: <= ORDstatusCode: <= ActStatusactivityTime:availabilityTime:
Del RIM al modelado de D-MIMs y R-MIMs
ItemPrescripcionclassCode*: <= SPLYmoodCode*: <= ORDcode*: [1..1] <= DrugCode text*: [1..1] <= effectiveTime: availabilityTime:
1..1
pacientePersona
agenteCentroAtencionPrimaria
1..1
agenteMedicoCabecera1..1
agenteFarmacia 1..1
1..1 paciente
1..1 medicoCabecera
1..1 farmaceutico
1..* itemPrescripcion
0..1 dosisPrescrita
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 61
Del RIM al modelado de D-MIMs y R-MIMs
Clases del RIM que no provienen de núcleo
IdiomaidiomaCode*: <= modeCode
• Hay un pequeño grupo de clases en el RIM que no provienen del núcleo de 6 clases fundamentales.
• La clase Idioma puede asociarse a una Persona o a una Organzación para habilitar el procesamiento de distintos idiomas en las actuaciones realizadas.
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 62
HL7 V3 Standard
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 63
HL7 V3 Standard
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 64
HL7 V3 Standard
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 65
HL7 V3 Standard
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 66
HL7 V3 Standard
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 67
HL7 V3 Standard
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 68
jvilalta@vico.orgSeminario Técnico HL7 – Claves de la interoperabilidad de un Sistema Sanitario
Madrid 25 de Mayo de 2004 69
jvilalta@vico.org
Con la colaboración de:
Recommended