Proyecto FEMI Salud Digital Marco lógico del Prototipo de Servicio

Proyecto FEMI Salud Digital
Marco lógico del Prototipo de Servicio
de Identificación de Personas
Asistente Informático
A/C Pablo Pazos Gutiérrez
Historial de revisiones
Revisión
0.1
0.2
0.3
1.0
Principales cambios
Versión inicial
Agregado de secciones 1, 2, 4, 5 y 6
Revisión
Completo punto 4, agrego información
de OpenEHR.
Autor
Fecha
Pablo Pazos Gutiérrez
Pablo Pazos Gutiérrez
Pablo Pazos Gutiérrez
Pablo Pazos Gutiérrez
20-12-2008
29-12-2008
04-01-2009
06-08-2009
Índice
Proyecto FEMI Salud Digital ........................................................................................... 1
Documento: Prototipo de Índice Maestro de Pacientes Federal ..................................... 1
Historial de revisiones ...................................................................................................... 2
Índice ................................................................................................................................ 3
1. Sobre el presente documento.................................................................................... 4
2. Introducción al problema.......................................................................................... 5
2.1
Escenario: verificación de identidad de persona presente ................................ 6
2.1.1
Ejemplos de casos posibles para la verificación de identidad de un
paciente: 6
2.2
Escenario: correspondencia de identidad entre sistemas.................................. 8
2.3
Solución: Índice Maestro de Pacientes (IMP) .................................................. 9
3. Estándares y especificaciones:................................................................................ 10
3.1
Estándar de identificación de pacientes de SUEIIDISS: ................................ 10
3.1.1
Introducción............................................................................................ 10
3.1.2
El estándar de identificación contiene:................................................... 10
3.1.3
Clases de identificadores y atributos definidos en el estándar: .............. 10
3.1.4
Proceso de identificación de personas .................................................... 11
3.1.5
Identificadores y atributos ...................................................................... 12
3.1.6
Ejemplo de información registrada para identificación de un paciente.. 13
3.2
Perfiles IHE involucrados en el índice maestro de pacientes......................... 14
3.2.1
Introducción............................................................................................ 14
3.2.2
Perfil PIX................................................................................................ 15
3.3
Otros estándares de identificación y especificaciones para manejo de
información demográfica a nivel mundial.................................................................. 17
HL7 v3 uvpa: dominio de administración de pacientes ......................................... 17
OpenEHR Reference Model:.................................................................................. 17
4. Relevamiento de información demográfica........................................................ 19
5. Consideraciones de arquitectura de software para el Índice Maestro de Pacientes:20
5.1
Analizando el perfil PIX de IHE .................................................................... 20
5.2
Consideraciones de opciones de arquitectura................................................. 22
Discusión extraída del proyecto IMaPac [14] ........................................................ 22
Referencias ..................................................................................................................... 24
6. Referencia de imágenes .......................................................................................... 25
1. Sobre el presente documento
Este documento se encuentra en el marco del desarrollo del prototipo de Índice
Maestro de Pacientes (IMP). En el mismo se intentará dar una visión general del
problema, exponiendo diversas opciones y alternativas que fomenten la discusión de
cada tema, y permitan plantear los requerimientos sobre el prototipo y elegir las
opciones que satisfagan mejor cada requerimiento.
Algunos temas que aborda este documento son:
•
•
•
Estándares y especificaciones
Relevamiento de información demográfica
Arquitectura del sistema informático
Estándares y especificaciones
En esta sección se mencionan, de forma reducida, diversos estándares y
especificaciones nacionales e internacionales referentes a la identificación de
personas y el modelado de la información demográfica para sistemas informáticos.
Entre otros se mencionan: IHE, HL7, OpenEHR, ISO13606.
Relevamiento de información demográfica
En esta sección se darán guías para, en principio, determinar que información
demográfica se está registrando hoy en las instituciones que participan del presente
prototipo, y que información útil faltaría registrar. Esto es para luego definir un estándar
de cual información y en que forma será necesaria para identificar a un paciente
dentro de FEMI.
Arquitectura del sistema informático
En esta sección se abordarán varias opciones de arquitectura del sistema de
información y del servicio de identificación para abrir la discusión del tema y elegir la
mejor opción según los requerimientos que se planteen sobre el índice de pacientes.
2. Introducción al problema
Un índice maestro de pacientes sirve para identificar personas, en su rol de paciente,
entre varias instituciones, las cuales podrían identificar a sus pacientes de distinta
manera. El problema es que pueden tener pacientes en común, pero al estar
identificados de forma distinta, en el sistema existirán dos registros disjuntos para la
misma persona, por lo tanto siempre se tendrá información incompleta sobre los
pacientes que se atiendan en varias instituciones.
A continuación se plantearán varios escenarios y casos donde se muestra el problema
de identificación de personas en la práctica.
Escenarios principales en la identificación de personas:
•
•
Verificación de identidad de persona presente
Correspondencia de identidad entre sistemas
En ambos escenarios existen dos casos:
•
•
Identificadores accesibles
Identificadores no accesibles
El caso de “Identificadores Accesibles” es en el que se cuenta con identificadores de la
persona, como su número interno de paciente o su cédula de identidad, los cuales
identifican al paciente de forma unívoca (se necesita por lo menos un identificador). El
caso de “Identificadores No Accesibles” es cuando no se cuenta con estos
identificadores pero se cuenta con alguna información demográfica de la persona
(nombre, edad, sexo, etc).
En el primer caso la identificación de la persona es directa, porque se cuenta con
algún identificador de la misma.
En el segundo caso la verificación de la identidad es más compleja porque los datos
demográficos pueden coincidir entre varias personas distintas, por lo que es necesario
definir un criterio que determine que grado de coincidencia de la información
demográfica garantiza la verificación positiva de la identidad. Un posible criterio es el
estándar de identificación de personas que se mencionará en la sección de
“Estándares y especificaciones” del presente documento.
2.1
Escenario: verificación de identidad de persona presente
En general este escenario incluye un sistema que almacena registros demográficos de
pacientes, un usuario del sistema y un paciente. El paciente comunica ciertos datos
que el usuario utiliza para ingresar al sistema para verificar que esa persona es quien
dice ser. Luego que la verificación de la identidad es positiva, el usuario puede obtener
o generar registros para el paciente, como generar una reserva de hora para una
consulta médica, o si el usuario es un médico, puede agregar nuevos registros a la
Historia Clínica Electrónica (HCE) del paciente.
Figura 1: Escenario verificación de identidad de persona presente.
2.1.1 Ejemplos de casos posibles para la verificación de identidad
de un paciente:
Caso 0: El más común, una persona llega al centro de atención por una
herida menor, está consciente y porta su cédula
El usuario del sistema ingresa la cédula de la persona, verifica los datos registrados en
el sistema contra los que aparecen en la cédula: nombres, fecha de nacimiento, sexo y
verifica visualmente la coincidencia de la foto de la cédula contra la persona que está
siendo asistida. Todo coincide, no hay dudas para identificar unívocamente al
paciente.
Caso 1: Un niño llega al hospital y no porta ni sabe su cédula de identidad
El usuario ingresa al sistema el nombre del niño y obtiene tres personas con el mismo
nombre. Si el sistema cuenta también con registro fotográfico de los pacientes, el
usuario puede, con solo ver las fotos, saber de que paciente se trata. Lo mismo
pasaría en el caso de las edades, si uno de los pacientes tiene 9 años, el otro 43 y el
tercero 55, claramente el paciente de 9 años es el paciente que estamos buscando. En
este caso no se cuenta con identificadores de paciente, y los atributos no son
suficientes para identificarlo unívocamente, por lo que necesita intervención humana.
Caso 2: Persona accidentada inconsciente traída por un conocido, no
porta cédula
El conocido sabe el nombre de la persona, donde vive y su teléfono. Si el sistema está
cargado con los nombres, ubicación del hogar y teléfonos de los pacientes, con los
datos que se conocen del paciente, el sistema puede identificar a dicho paciente de
forma unívoca. En este caso no se cuenta con identificadores de paciente, pero el
sistema cuenta con atributos suficientes para identificarlo unívocamente.
Caso 3: Persona extranjera está veraneando y necesita atención, porta
pasaporte de su país de origen
La persona se apersona en una emergencia por malestar estomacal. El paciente ya
tiene registro en el hospital porque veranea siempre en el mismo lugar y ya se había
atendido en dicho hospital. Si el sistema registra documentos extranjeros y
nacionalidades, con la nacionalidad y el número del pasaporte de ese país se podía
identificar unívocamente a la persona, ya que el número de pasaporte es un
identificador único en su país, y con la nacionalidad y dicho número, se logra un
identificador único en el mundo.
2.2
Escenario: correspondencia de identidad entre sistemas
En general, este escenario incluye dos sistemas distintos, ambos con registros del
mismo paciente, en donde los sistemas utilizan distintos identificadores internos para
identificar a sus pacientes. Estos sistemas deben intercambiar información de
pacientes (por ejemplo información clínica) la cual tiene asociada la identidad del
paciente en el sistema que emite la información. El problema que salta a la vista es:
¿cómo hace el sistema receptor para saber a cual de sus pacientes le corresponde la
información recibida?
Figura 2: Escenario correspondencia de identidad entre sistemas.
En este escenario el sistema emisor genera un documento con información clínica del
paciente, al que se agrega información demográfica e identificadores del paciente al
que pertenece el documento. Esos identificadores son internos del sistema emisor.
El sistema receptor recibe el documento, pero como los identificadores que aparecen
en el mismo no son de su conocimiento (por ser internos del sistema emisor) debe
realizar algún tipo de correspondencia de la información del paciente disponible en el
documento que recibe y los registros de pacientes con los que cuenta el sistema
receptor.
2.3
Solución: Índice Maestro de Pacientes (IMP)
La solución para resolver los problemas en ambos escenarios es la creación de un
IMP. Un IMP es un sistema al cual se le consulta para verificar la identidad de los
pacientes, independientemente de los identificadores del paciente en una institución
particular.
Existen dos enfoques principales para la creación de un IMP:
•
•
Identificadores globales
Correspondencia entre identificadores
2.3.1 Identificadores globales
Esta opción implica que las varias organizaciones que utilizan distintos identificadores
para sus pacientes se pongan de acuerdo en identificar a los pacientes mediante un
mecanismo común. De esta forma, teniendo el identificador global del paciente, la
verificación sería siempre positiva o negativa. Si bien este podría ser el caso más
frecuente, también se debe afrontar el caso en el que no se pueda contar con el
identificador y el paciente necesite ser identificado en el sistema mediante la
información demográfica disponible (Caso de “Identificadores No Accesibles”).
2.3.2 Correspondencia entre identificadores
Esta opción implica la definición de una correspondencia entre los identificadores de
los pacientes de las distintas organizaciones, más comúnmente esto es conocido
como “manejo de referencias cruzadas entre identificadores” de distintas
organizaciones. Esto es básicamente generar un sistema donde se registren las
organizaciones y los identificadores de sus pacientes, donde se almacenen también
las referencias entre distintos identificadores de la misma persona. Este enfoque es
distinto al anterior en que no se define un nuevo identificador global para los pacientes,
si no que se guarda información de correspondencia ente los identificadores
particulares existentes. Este enfoque tampoco resuelve el problema del caso de
“Identificadores No Accesibles” del paciente y este tenga que ser identificado.
Figura 3. Esquema de identificación global.
Figura 4. Esquema de correspondencia entre
identificadores.
3. Estándares y especificaciones:
Esta sección presenta un resumen de los principales estándares y especificaciones
que pueden ser de utilidad para desarrollar el presente prototipo de IMP federal para
FEMI.
3.1 Estándar de identificación de pacientes de SUEIIDISS:
Este es un resumen basado en el documento: SUEIIDISS-HL7V3-ESP-001 versión 1.0
que especifica el estándar de identificación de pacientes, propuesto por el comité de
identificación de personas de la SUEIIDISS para su adopción en Uruguay. [2]
3.1.1 Introducción
La identificación unívoca de pacientes es la base de todo sistema distribuido de
historias clínicas electrónicas. Sin una correcta identificación de los pacientes se
pueden presentar varios problemas:
•
•
•
•
En el intercambio de información de pacientes entre instituciones.
Recetar un medicamento o definir un tratamiento a la persona equivocada.
Costos administrativos por mantenimiento de información duplicada e
inconsistente.
Costos clínicos de tener dos registros para la misma persona: nunca se tendrá
toda la información clínica del paciente.
3.1.2 El estándar de identificación contiene:
•
•
•
Definición de todos los identificadores y atributos que componen la identidad de
una persona en Uruguay, jerarquizados de acuerdo a sus características.
La recomendación de un algoritmo de verificación de identidad.
Ejemplos de implementación del estándar de identificación en HL7 V3 y
documentos CDA.
3.1.3 Clases de identificadores y atributos definidos en el
estándar:
El estándar define dos grandes conjuntos de información, separados entre
“identificadores” y “atributos”.
Identificadores del paciente:
Estos identificadores determinan por sí mismos unívocamente al paciente, existen dos
clases:
•
•
Identificadores universales: son los que identifican unívocamente al paciente
en cualquier ámbito del Uruguay.
Identificadores particulares: son los que identifican unívocamente al paciente
sólo dentro de un ámbito especificado (por ejemplo una mutualista).
Atributos del paciente:
Ante la ausencia de identificadores propios del paciente, se utilizan combinaciones de
distintos atributos del paciente, para intentar identificarlo unívocamente al paciente.
•
Números de identificadores referenciales:
Números identificadores que no son propios del paciente pero si de una
persona responsable de ese paciente. El rol que cumple esa persona con
respecto al paciente se especifica en la propia norma.
o Números de identificadores duros: identificadores que no varían en el
tiempo.
o Números de identificadores blandos: identificadores que varían en el
tiempo.
•
•
Atributos de identificación duros: Atributos que no varían en el tiempo.
Atributos de identificación blandos: Atributos que varían en el tiempo.
Es importante recordar que no siempre se pueden contar con identificadores del
paciente a la hora de verificar su identidad, en la siguiente sección 2.1.2 se mostraron
ejemplos de algunos casos donde esto ocurre.
3.1.4 Proceso de identificación de personas
El proceso de identificación, o verificación de identidad de una persona, puede no ser
siempre satisfactorio. De no poder identificar a la persona de forma unívoca (por
ejemplo si con la información disponible se obtiene más de una persona), se
necesitaría la intervención de una persona en el proceso.
El resultado de los procesos de identificación de pacientes puede ser:
•
•
•
Validación negativa: no es la persona (se está seguro de que la persona no
está registrada en el sistema, o con los datos con los que se cuenta no se pudo
encontrar un registro que le corresponda)
Validación positiva: es la persona (se está 100% seguro de que es quien dice
ser)
Validación manual: necesidad de intervención humana en el proceso de
verificación de identidad (existe algún grado de coincidencia pero no se está
100% seguro)
3.1.5 Identificadores y atributos
En esta sección se listan los identificadores y atributos como se encuentran definidos
en el estándar de identificación de personas:
•
Identificadores del paciente
o Identificadores universales
ƒ Cédula de identidad uruguaya
ƒ Pasaporte uruguayo
ƒ Licencia de conductor Uruguaya
ƒ Documento de identidad extranjero
ƒ Pasaporte extranjero
o Identificadores particulares
ƒ Número interno de identificación
ƒ Número interno de identificación prenatal
ƒ Número de historia clínica
•
Atributos del paciente
o Números identificadores referenciales
ƒ Números identificadores duros
• Cédula de identidad de la madre
• Cédula de identidad del padre
• Número interno de identificación de la madre
• Número de historia clínica de la madre
ƒ Números identificadores blandos
• Cédula de identidad uruguaya del responsable.
• Pasaporte responsable
o Atributos de identificación duros
ƒ Sexo
ƒ Nacimiento
ƒ Indicador de nacimiento múltiple
ƒ Indicador de fallecido.
o Atributos de identificación blandos
ƒ Nombre de la persona
ƒ Nombre de la madre
ƒ Nombre del padre
ƒ Domicilio particular en Uruguay
ƒ Domicilio alternativo en Uruguay
ƒ Forma de contacto personal
ƒ Forma de contacto alternativa
ƒ Imagen biométrica - Foto carné
3.1.6 Ejemplo de información registrada para identificación de un
paciente
Un paciente socio de la institución XX1
N° de matrícula:
201911
N° de historia clínica: 201911
N° de CI:
1.292.523-6
1er nombre:
Juan
2do nombre:
José
1er apellido:
González
2do apellido:
López
Fecha de nacimiento: 28/09/1960
Lugar de nacimiento: Argentina
Sexo:
Masculino
Domicilio particular
Tipo de vía:
Nombre de vía:
Número de puerta:
Otra designación:
Localidad y Depto:
Código postal:
País:
Forma de contacto
Teléfono:
Móvil:
Calle
18 de Julio
156
Complejo ZZZ - Block C - Ap. 406
La Paz - Canelones
Uruguay
364 4456
099 354258
3.2 Perfiles IHE involucrados en el índice maestro de
pacientes
El siguiente resumen está basado en los documentos de especificación del marco de
trabajo de IHE (IHE IT Infrastructure Technical Framework, o simplemente IHE ITI-TF)
y en el suplemento para HL7v3:
•
•
•
IHE_ITI_TF_5-0_Vol1_FT_2008-10-10-2.pdf [4]
IHE_ITI_TF_5-0_Vol2_FT_2008-10-10.pdf [4]
IHE_ITI_TF_Supplement_PIX_PDQ_-HL7v3_-TI_2008-11-11.pdf [5]
3.2.1 Introducción
Los perfiles IHE definen un marco de trabajo que identifica un conjunto de
componentes y transacciones para un sistema distribuido de asistencia sanitaria (por
ejemplo una HCE federal). Este marco de trabajo es una especificación que utiliza
estándares, pero no es un estándar en sí mismo. Las transacciones definidas están
basadas en estándares ASTM [7], DICOM [8], HL7 [9], IETF [10], ISO [11], OASIS [12]
y W3C [13].
Las transacciones definidas en los perfiles se implementan utilizando mensajería HL7.
Cabe señalar que en la especificación del IHE ITI-TF se utilizan mensajes HL7 v2.x, y
en Uruguay se utilizará solo HL7 v3. Pero existe un suplemento asociado a los perfiles
“Patient Identifier Cross-reference” (PIX) y “Patient Demographic Query” (PDQ) que se
encuentra en estado de “borrador de implementación”, por lo que no es del todo
estable pero es una gran ayuda para la implementación de los perfiles con mensajes
HL7v3.
Relación entre los distintos perfiles IHE ITI-FT:
Figura 5: Relación entre perfiles IHE ITI-TF
3.2.2 Perfil PIX
El perfil PIX (Patient Identifier Cross-referencing) provee la funcionalidad de manejar
referencias cruzadas entre identificadores de pacientes en distintos dominios de
identificación (Patient Identifier Domains). Estos identificadores de pacientes pueden
ser utilizados por “sistemas consumidores de identificadores” para correlacionar
información acerca de un único paciente desde fuentes que conocen al paciente por
diferentes identificadores.
Un dominio de identificación de pacientes es un conjunto de organizaciones que se
ponen de acuerdo en cómo deben identificar a sus pacientes, por lo que una persona
que se atienda en cualquiera de las organizaciones que componen el dominio de
identificación será identificado de la misma forma siempre. Entonces las referencias
cruzadas que maneja este perfil son entre identificadores de distintos dominios, donde
si un paciente se atiende en una organización de cada dominio, esas organizaciones
deben de alguna forma saber que sus registros pertenecen al mismo paciente.
Entonces si una de esas organizaciones debiera enviar información de un paciente a
la otra organización, esta última organización debiera consumir el identificador del
paciente correspondiente para correlacionar sus registros con la información que
recibe. El esquema de correspondencia entre identificadores, o de referencias
cruzadas entre identificadores, fue mencionado en la sección 2.3.2.
3.2.2.1 PIX: actores y transacciones
Figura 6: Actores y transacciones del perfil PIX.
El perfil PIX define tres actores:
1. Patient Identifier Cross-reference Manager (PIXM)
Es el componente que mantiene los identificadores de todos los pacientes del
sistema y sus referencias cruzadas (varios identificadores para las mismas
personas para distintas instituciones).
2. Patient Identity Source (PIS)
Es el componente que alimenta el PIXM con identidades de pacientes, cada
organización que tenga identificadores para sus pacientes será un PIS.
3. Patient Identifier Cross-reference Consumer (PIXC)
Es el componente que puede consultar el PIXM para preguntar por
identificadores de un paciente para otras instituciones, o también puede ser
notificado de cambios en los datos de sus pacientes que se den en el PIXM.
El perfil PIX define tres transacciones:
1. Patient Identity Feed (PIF)
Esta transacción sirve para comunicar información de pacientes desde un PIS
al PIXM, incluyendo sus identificadores y datos demográficos que servirán para
verificar la identidad del paciente.
2. PIX Query (PIXQ)
Esta transacción sirve para que un PIXC pida una lista de identificadores de un
paciente presentes en el PIXM, dado un identificador conocido por el PIXC.
3. PIX Update Notification (PIXUN)
Esta transacción sirve para que el PIXM notifique a los PIXC, previamente
registrados para ser notificados, sobre cambios en los identificadores de
pacientes contenidos en el PIXM.
Para implementar las transacciones se utilizan los siguientes mensajes HL7v3:
1. Patient Identity Feed (PIF) Î 201301
2. PIX Query (PIXQ) Î 201302
3. PIX Update Notification (PIXUN) Î 201304
Estos mensajes se encuentran definidos en el dominio “Patient Administration” (uvpa)
de HL7v3 [15]. Notar que IHE utiliza una versión simplificada de estos mensajes para
implementar las transacciones del perfil PIX.
En la página 116 del documento “IHE_ITI_TF_Supplement_PIX_PDQ_-HL7v3_TI_2008-11-11.pdf” hay links a los esquemas de los mensajes antes mencionados. [5]
3.3 Otros estándares de identificación y especificaciones
para manejo de información demográfica a nivel mundial
A modo de referencia se listan algunos estándares que pueden ser sujetos de estudio
en el futuro:
•
•
•
•
•
•
•
•
AS5017: estándar australiano para identificación de usuarios del sistema de
salud, especifica una forma de verificar la identidad de una persona a nivel
nacional.
AS4590: estándar australiano de intercambio de información de usuarios del
sistema de salud, especifica una forma estándar de la información de
direcciones y medios de contacto de las personas.
ASTM E1714-95: guía estándar de propiedades de un identificador universal
para el sector salud (UHID).
CCDS: Common Client Data Set, es la especificación de un conjunto de
información demográfica e identificadores de pacientes utilizado entre distintas
organizaciones de Australia. [16]
ISO 22220: identificación de sujetos en la atención sanitaria.
HL7 v3 uvpa: dominio de administración de pacientes de HL7. [15]
OpenEHR RM: modelo de referencia de OpenEHR (el paquete demográfico y
los arquetipos demográficos). [6]
ISO 13606: modelo de referencia del estándar ISO 13606 (el paquete
demográfico). [17]
HL7 v3 uvpa: dominio de administración de pacientes
La administración de pacientes, también conocida como ADT (por la sigla en inglés de
Admisión, Alta y Transferencia), soporta varias funciones administrativas básicas en la
atención sanitaria, como registro de personas y pacientes y administración de
encuentros (por ejemplo: consultas). En general la información es ingresada en el
registro del paciente o de la persona, o en un sistema de administración de pacientes y
comunicada a otros sistemas como sistemas clínicos, otros registros, sistemas
financieros, etc.
Este dominio define los mensajes HL7 necesarios para comunicar información de
pacientes entre distintos sistemas. Estos mensajes son los que se deberían utilizar si
se implementara el perfil PIX de IHE utilizando HL7v3 (recordar que solo el
suplemento de implementación de PIX y PDQ utilizan HL7v3, ya que las
especificaciones de los perfiles IHE ITI-TF recomiendan utilizar HL7 v2.x).
OpenEHR Reference Model:
OpenEHR propone una especificación de arquitectura para implementar una HCE
distribuida. La principal característica de OpenEHR es que sigue un modelo dual de
conocimiento + datos, separando los conceptos de la realidad de los datos registrados
por el sistema, permitiendo agregar nuevo conocimiento al sistema sin necesidad de
modificar los datos ya registrados. El conocimiento es representado mediante
arquetipos. Todo concepto presente en el modelo de referencia de OpenEHR tiene un
arquetipo que lo especifica, es decir que toda la información es “arquetipable”. La
arquetipación de la información permite además verificar la correctitud de la
información, tanto de los datos como de las estructuras.
Figura 7: lugar del modelo demográfico en la arquitectura OpenEHR.
El paquete demográfico del modelo de referencia de OpenEHR presenta, de forma
genérica, todos los conceptos necesarios para representar información demográfica.
Cabe notar, primero, que todos los conceptos son arquetipables y, segundo, que los
conceptos no presentan atributos particulares, si no que tienen estructuras genéricas
capaces de adaptarse a lo que indique el arquetipo, por lo tanto se podría crear un
arquetipo en el cual la persona tuviera los atributos: nombre, apellido y cédula de
identidad, y otro arquetipo en el cual la persona tenga: primer nombre, segundo
nombre, primer apellido, segundo apellido, cédula y fecha de nacimiento.
Figura 8: modelo demográfico de OpenEHR.
Este modelo en particular sirve para representar personas, relaciones entre ellas (p.e.
padre-hijo), roles (p.e. médico, enfermera, paciente), grupos de personas y
organizaciones. Además de información de contacto como teléfonos o direcciones.
4. Relevamiento de información demográfica
Se llevó a cabo un relevamiento de los datos de pacientes que se registran de forma
electrónica en algunas instituciones de FEMI. Ya se relevaron 12 instituciones y se
procesaron 6 relevamientos. La información del relevamiento se encuentra en el sitio
web del Prototipo de Identificación de Personas:
http://femisaluddigital.net.uy/portal/page/display/prototipos#id_imp
El resultado reveló que el nivel de la información en cuanto a su completitud no era el
mismo en las distintas instituciones de FEMI. Aquellas instituciones que no tenían los
datos mínimos que conforman la identificación de la personas, fueron oportunamente
asesoradas en este sentido.
En el punto 3.1.5 se lista el conjunto de datos completo que se puede utilizar para la
identificación de personas, a continuación listamos un conjunto de datos mínimos con
algunos comentarios a tener en cuenta.
Como mínimo, el Índice Maestro de Pacientes deberá contar con los siguientes
datos:
•
•
Conjunto de identificadores del paciente:
o Puede ser tanto un identificador de ciudadano como la Cédula de
Identidad Uruguaya, como un identificador interno de paciente de una
institución prestadora de salud.
o Tener especial cuidado en considerar casos de pacientes extranjeros que
no tienen Cédula de Identidad Uruguaya.
o La representación de los identificadores más flexible es la de tener el
número de documento por un lado y el tipo de documento por otro.
Atributos del paciente:
o Nombres y apellidos
ƒ Primer y segundo nombre.
ƒ Primer y segundo apellido.
o Fecha de nacimiento
o Sexo
Opcionalmente también se podrá contar con los siguientes datos:
•
•
Atributos del paciente:
o Indicador de nacimiento múltiple (Si/No)
o Orden de nacimiento (1..10)
ƒ Si es hijo de un parto NO múltiple, el orden de nacimiento será 1.
o Indicador de fallecido (Si/No)
o Fecha de fallecido
Información de contacto:
o Dirección
ƒ Personal, trabajo
o Teléfonos
ƒ Personal, trabajo, celular.
o Emails
Para alimentar el Índice Maestro de Pacientes Federal será necesaria la comunicación de
datos de personas por parte de las instituciones hacia el IMP. Los datos de cada
institución como la cédula de identidad o las fechas deberán convertirse a un formato
estándar dado, de forma de que el IMP entienda los datos que le llegan. Uno de los
documentos generados en el relevamiento de datos se plantearon estos formatos
estándar:
http://femisaluddigital.net.uy/files/prototipos/indice_pacientes/Relevamiento_de_inform
acion_de_pacientes-Incompatibilidades_entre_instituciones%5B16-06-2009%5D.pdf
5. Consideraciones de arquitectura de software para
el Índice Maestro de Pacientes:
•
•
•
Un Índice Maestro de Pacientes (Master Patient Index), es un repositorio de
identificadores de pacientes de distintas instituciones. El IMP permite identificar
unívocamente a un paciente que podría tener distintos identificadores en
distintas instituciones.
El IMP es la base de una Historia Clínica Electrónica Federada, ya que para
intercambiar cualquier documento de un paciente entre distintas instituciones,
se deben tener los identificadores del paciente en las instituciones involucradas
en la comunicación.
El perfil PIX de IHE define una posible arquitectura de alto nivel para un IMP,
con los componentes y transacciones necesarias. Es necesario:
o Evaluar opciones de arquitectura con un mayor nivel de detalle,
considerando requerimientos y restricciones que se impongan sobre el
presente prototipo de MPI.
o Evaluar si las transacciones definidas en el perfil PIX alcanzan para
modelar las necesidades de FEMI sobre un MPI o si hay que agregar
transacciones o ampliar las ya definidas.
o Estas evaluaciones quedarán para una etapa posterior, cuando se
tengan definidos los requerimientos específicos sobre el MPI y se
impongan las restricciones necesarias.
5.1 Analizando el perfil PIX de IHE
En la primer sección se comentó sobre los perfiles IHE, más específicamente sobre
PIX. Este perfil define tres actores Patient Identifier Cross-reference Manager
(PIXM), Patient Identity Source (PIS), Patient Identifier Cross-reference Consumer
(PIXC), los cuales son algunos de los componentes que se definen como parte del
MPI. El siguiente diagrama muestra todos los componentes que intervienen en las
distintas transacciones del perfil y sus relaciones:
Figura 9: Componentes definidos en PIX
En particular, el único componente que no fue mencionado anteriormente es el Patient
Identifier Domain (PID), que puede constar de uno o más sistemas que se ponen de
acuerdo en identificar a sus pacientes de la misma forma, por lo tanto distintos
dominios (PID) identifican a sus pacientes de forma distinta, y mediante la intervención
del PIXM pueden referirse a los mismos pacientes mediante distintos identificadores.
El otro componente no mencionado anteriormente es el Patient Identifier Crossreference Domain (PIXD), el cual está compuesto por todos los componentes
mencionados anteriormente.
En los siguientes diagramas se muestra dos casos de la relación entre el perfil PIX y el
MPI:
Figura 10: Relación de PIX con IMP
Según IHE, un MPI está asociado a la creación de identificadores maestros para los
pacientes, y el registro de los mismos en un “dominio maestro”, de esta forma, un MPI
sería considerada una implementación particular del perfil PIX. Un dominio maestro de
identificación de pacientes es un caso particular de referencia cruzada de los
identificadores de pacientes en los distintos dominios con los identificadores de
pacientes en el dominio maestro. Entonces, a lo que se le llama MPI sería a la
combinación del PIXM con un PIS maestro.
5.2 Consideraciones de opciones de arquitectura
Siempre que se tiene un sistema con un único componente que brinda servicios, es
necesario considerar los enfoques de componente centralizado y componente
distribuido, para así compararlos y elegir el esquema que más se adapte a las
necesidades del caso. A continuación se muestra el análisis sobre el componente
PIXM definido en el perfil PIX de IHE. El componente PIXM que se dedica a manejar
las referencias cruzadas entre identificadores de pacientes de distintos dominios de
identificación (PID).
Discusión extraída del proyecto IMaPac [14]
5.2.1 Opción centralizada:
Como toda solución centralizada, el problema principal es que en caso de caerse el
servicio, todo sistema que lo utilice se verá afectado, impidiendo su normal
funcionamiento. La mayor ventaja de la opción centralizada es que es más simple de
implementar.
5.2.2 Opción distribuida:
Teniendo varios (al menos dos) servicios simétricos (todos proveen la misma interfaz y
funcionalidad) en caso de que algún servicio se caiga, los sistemas que lo utilizan
simplemente usan cualquier otro de los servicios que si esté disponible.
La opción distribuida también tiene sus desventajas o dificultades. Al contar con
servicios simétricos, es decir que los servicios distintos pero equivalentes, se debería
garantizar la dicha equivalencia, de modo que la información que sea solicitada a
cualquier servicio sea la misma, independientemente de cual es el servicio consultado.
En general, un componente PIS daría de alta información de un paciente en uno de los
servicios, por lo que será necesario algún mecanismo de sincronización para enviar la
nueva información a los demás servicios, y así garantizar que todos los servicios
cuentan con la misma información y que ante las mismas consultas, todos los servicios
responderán de la misma manera.
Una alternativa a la sincronización, o sea a copiar la misma información en todos los
servicios, podría ser la de que los componentes PIXM puedan “rutear” los pedidos, de
forma que si cierta información es solicitada a un PIXM y este no cuenta con dicha
información, el PIXM pueda enviar el pedido a otro PIXM que si tenga la información
solicitada. Estrictamente hablando, con este enfoque, el PIXM se actuaría también
como un PIXC. Notar que si la información estuviera disponible solo en un PIXM,
volveríamos a tener el problema de la opción centralizada, o sea si dicho PIXM no se
encuentra en línea, el sistema no podrá dar respuesta a la consulta realizada.
Entonces se podría tener un cierto número de servicios que cuentan con la misma
información (sincronizada entre ellos) y otros servicios que no estén sincronizados o
se sincronicen con menos frecuencia, los cuales tengan la inteligencia suficiente como
para saber que con cuentan con la información que les fue solicitada y pidan la
información a otro servicio que si la tenga.
Opciones de sincronización:
En cuanto a la forma de sincronizar los datos existen dos posibles opciones:
•
•
Sincronización inmediata
Sincronización perezosa
Sincronización inmediata
Cuando se da un alta o una modificación de información en algún componente del
PIXM, inmediatamente se envían notificaciones del hecho a los demás componentes
del PIXM, con los respectivos cambios, para que cada uno actualice su base local.
Esto garantiza que todos los componentes tienen en su base los mismos datos. Una
desventaja de este enfoque podría ser el generar mucho tráfico en momentos donde el
sistema es muy utilizado, ya que las notificaciones serían enviadas de inmediato al
detectarse cambios.
Sincronización perezosa
Es cuando las notificaciones de los cambios “esperan” y se acumulan hasta un
momento donde le sistema no esté siendo muy utilizado, momento en el cual se
envían las notificaciones a los demás sistemas para que actualicen sus datos. La
ventaja con respecto a la opción anterior es el no saturar el tráfico en horas pico. Una
posible desventaja es que los datos en los demás sistemas, mientras esperan a ser
actualizados, serían inválidos (o por lo menos no serían los últimos datos). Esto se
soluciona fácilmente, por ejemplo no permitiendo el acceso a los nuevos datos hasta
que todas las notificaciones hayan sido correctamente enviadas, de esta forma se
garantiza que todos los sistemas responderán de la misma manera ante la misma
consulta.
Características deseables
En el momento de definir la arquitectura, deberá ser necesario pensar en las
características no funcionales que deberá tener el sistema. Una de ellas, tal vez la más
importante, sea la de “alta disponibilidad”. Otra característica esencial derivada de lo
antes mencionado es la de “consistencia de datos”. También deberán discutirse temas
relacionados con la “seguridad” y “desempeño”.
Ejemplos:
Alta disponibilidad: el sistema debe garantizar que los servicios ofrecidos estén
funcionando el 100% del tiempo.
Consistencia de datos: si se realiza dos veces la misma consulta, se deberá obtener
la misma respuesta.
Seguridad: quien accede a la información debe estar correctamente identificado, y no
se podrá enviar información a quienes no lo estén.
Desempeño: los servicios que son consultados deben devolver la información correcta
en un tiempo adecuado según el caso, por ejemplo se pueden tener consultas en
tiempo real que no pueden esperar demasiado, o notificaciones de sincronización
perezosa que pueden esperar mucho más tiempo.
Referencias
[1] Comisión de identificación de pacientes SUEIIDISS
http://wiki.sueiidiss.org/index.php/Comisiones:ID
[2] 1er Informe de Acuerdo del Estándar de Identificación de Personas e
Implementación del HL7-V3, en el Sector Salud de Uruguay”
http://wiki.sueiidiss.org/images/d/d5/SUEIIDISS-HL7V3-ESP-001.pdf
[3] Frameworks IHE
http://www.ihe.net/Technical_Framework/
[4] IHE ITI-TF
http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_5-0_Vol1_FT_2008-12-12.pdf
http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_5-0_Vol2_FT_2008-12-12.pdf
[5] IHE suplemento de implementación para HL7 v3
http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Supplement_PIX_PDQ_-HL7v3_TI_2008-11-11.pdf
[6] OpenEHR modelo demográfico
http://www.openehr.org/svn/specification/BRANCHES/Release-1.0.2candidate/publishing/architecture/rm/demographic_im.pdf
[7] ASTM
http://www.astm.org/
[8] DICOM
http://medical.nema.org/
[9] HL7
http://www.hl7.org/
[10] IETF
http://www.ietf.org/
[11] ISO
http://www.iso.org/iso/home.htm
[12] OASIS
http://www.oasis-open.org/home/index.php
[13] W3C
http://www.w3c.es/
[14] IMaPac
http://groups.google.com/group/imapac
[15] HL7 v3 dominio Patient Administration (UVPA)
http://www.hl7.org/v3ballot2008may/html/domains/uvpa/uvpa.htm
[16] Common Client Data Set
http://www.health.vic.gov.au/hacims/downloads/ccdsv21_spec.pdf
[17] Estándar de comunicación de información clínica ISO 13606
http://www.msc.es/organizacion/sns/planCalidadSNS/docs/MUNOZ_CARRERO.pdf
http://secure.cihi.ca/cihiweb/en/downloads/ISO_136061_Ron_Parker.pdf
http://pangea.upv.es/bie/images/documentos/alta13606_inforsalud08.pdf
6. Referencia de imágenes
Figura 1 [pag. 6]: Escenario verificación de identidad de persona presente.
Figura 2 [pag. 8]: Escenario correspondencia de identidad entre sistemas.
Figura 3 [pag. 9]: Esquema de identificación global.
Figura 4 [pag. 9]: Esquema de correspondencia entre identificadores.
Figura 5 [pag. 14]: Relación entre perfiles IHE ITI-TF
Figura 6 [pag. 15]: Actores y transacciones del perfil PIX.
Figura 7 [pag. 18]: lugar del modelo demográfico en la arquitectura OpenEHR.
Figura 8 [pag. 18]: modelo demográfico de OpenEHR.
Figura 9 [pag. 20]: Componentes definidos en PIX
Figura 10 [pag. 21]: Relación de PIX con IMP