ARQUITECTURA DE REFERENCIA PARA EL INTERCAMBIO DE INFORMACIÓN ENTRE SISTEMAS DE INFORMACIÓN DE REGISTRO ELECTRÓNICO PARA LA SALUD

SECRETARÍA DE SALUD SUBSECRETARÍA DE INTEGRACIÓN Y DESARROLLO DEL SECTOR SALUD DIRECCIÓN GENERAL DE INFORMACIÓN EN SALUD ARQUITECTURA DE REFERENCIA PARA EL INTERCAMBIO DE INFORMACIÓN ENTRE SISTEMAS DE INFORMACIÓN DE REGISTRO ELECTRÓNICO PARA LA SALUD Versión 01

Contenido Contenido 2 Prefacio 4 Información de contacto 4 Historial de revisiones 4 Participantes 4 Presentación 4 Introducción 4 Objetivo 5 Audiencia 5 Alcance 5 Justificación 5 Términos y Definiciones 6 Referencias 7 Ligas Web 7 Bibliografía 7 Portafolio de Estándares 8 HEALTH LEVEL SEVEN - HL7 8 HL7 REFERENCE INFORMATION MODEL 8 HL7 VERSIÓN 3 9 HL7 CLINICAL DOCUMENT ARCHITECTURE R2 10 HL7 CONTINUITY OF CARE DOCUMENT (CCD) 11 HL7 EHR-S FUNCTIONAL MODEL 11 HL7 VERSIÓN 2.X 12 MENSAJERÍA VERSIÓN 2.X - XML 13 HL7 SERVICE ORIENTED ARCHITECTURE 13 HL7 ROLE BASED ACCESS CONTROL (RBAC) 13 INTEGRATING THE HEALTHCARE ENTERPRISE - IHE 14 IHE - PATIENT IDENTIFIER CROSS REFERENCING (PIX) 14 IHE - PATIENT DEMOGRAPHICS QUERY (PDQ) 15 IHE - CROSS ENTERPRISE DOCUMENT SHARING (XDS) 16 IHE - CROSS ENTERPRISE DOCUMENT MEDIA INTERCHANGE (XDM) 18 IHE - CROSS ENTERPRISE DOCUMENT RELIABLE INTERCHANGE (XDR) 18 IHE - CROSS COMMUNITY ACCESS (XCA) 19 IHE - AUDIT TRAIL AND NODE AUTHENTICATION (ATNA) 19 IHE - PATIENT ADMINISTRATION MANAGEMENT (PAM) 20 IHE - CONSISTENT TIME (CT) 21 Página 2 de 24

IHE - BASIC PATIENT PRIVACY CONSENTS (BPPC) 21 IHE - MULTI PATIENT QUERIES (MPQ) 22 DIGITAL IMAGING AND COMMUNICATION IN MEDICINE (DICOM) 22 CLASIFICACIÓN INTERNACIONAL DE ENFERMEDADES 10ª EDICIÓN CIE- 10 23 CLASIFICACIÓN INTERNACIONAL DE ENFERMEDADES MODIFICACIÓN CLÍNICA 9ª EDICIÓN CIE-9 MC 23 CLASIFICACIÓN INTERNACIONAL DEL FUNCIONAMIENTO, DE LA DISCAPACIDAD Y DE LA SALUD - CIF 23 EXTENSIBLE MARKUP LANGUAGE (XML) 23 Declaraciones 24 Página 3 de 24

PREFACIO Información de contacto Para mayor información sobre este documento, favor de contactar a la Dirección General de Información en Salud, ubicada en Av. Paseo de la Reforma No. 450-11 Col. Juárez Delegación Cuauhtémoc, México D.F. C.P. 06600, Teléfono. +52 (55) 5514 5964, 5208 4929, o bien, por medio de correo electrónico a dgis@salud.gob.mx con el asunto ARQUITECTURA DE REFERENCIA NOM-024-SSA3-2012. Historial de revisiones Fecha Versión Madurez Descripción Autor 20/NOV/2012 01 Borrador interno Creación del documento ECJ 27/NOV/2012 02 Borrador interno Revisión del documento ECJ 03/DIC/2012 03 Borrador Oficial Revisión técnica del documento ECJ Participantes Institución, dependencia u organismo Dirección General de Información en Salud, Secretaría de Salud Nombre y Cargo Efrain Cruz Jiménez, Subdirector de Procesos Electrónicos en Salud Ana Hilda Morales Aranda, Directora de Proyectos Iniciales ECJ AHMA PRESENTACIÓN Introducción Existe hoy en día la necesidad y la regulación que exige a los Prestadores de Servicios de Salud dentro del Sistema Nacional de Salud el intercambio de información entre sus diferentes Sistemas de Registro Electrónico para la Salud, por lo que la definición de reglas de intercambio y datos mínimos a compartir bajo mecanismos estandarizados y apegados a la regulación aplicable es un área de oportunidad importante a nivel sectorial, siendo en este sentido la Secretaría de Salud quien como cabeza de sector lidera esta iniciativa. En el presente documento, a partir de estándares probados nacional e internacionalmente y Página 4 de 24

en el marco de la NOM-024-SSA3-2012, se desarrollará una Arquitectura de Referencia, la cual consiste en un marco general de especificaciones técnicas en el que se basa el desarrollo de Guías y Formatos, así como las interfaces de intercambio de información con el fin de asegurar la homologación de las mismas en los Sistemas de Registro Electrónico para la Salud de los diferentes prestadores de Servicios de Salud dentro del Sistema Nacional de Salud. Esta Arquitectura de Referencia considera estándares y lineamientos publicados internacionalmente por IHE, HL7 o aquellos que la propia Secretaría a través de la DGIS ha determinado de acuerdo a los avances tecnológicos y situación del Sistema Nacional de Salud en México. Los sistemas de información de la Secretaría para recopilación y consulta de información deben implementar interfaces de intercambio de información de acuerdo a los estándares definidos en la NOM-024-SSA3-2012, así como apegar su diseño a la Arquitectura de Referencia que a través de este documento emite la DGIS. Objetivo Crear una especificación técnica descriptiva basada en estándares que provea las bases a partir de las cuales los Sistemas de Información de Registro Electrónico para la Salud dentro del Sistema Nacional de Salud en México intercambien información. Audiencia Este documento está dirigido a personal con conocimientos técnicos en tecnologías de la información de los Prestadores de Servicios de Salud del Sistema Nacional de Salud de México que utilicen o deseen implementar Sistemas de Información de Registro Electrónico en Salud, así como aquellas organizaciones interesadas en el desarrollo e implementación de interfaces para el intercambio de información en salud, lo anterior en el marco de la NOM- 024-SSA3-2012. Alcance Con base en lo establecido en el numeral 1. Objetivo y Campo de Aplicación de la NOM-024- SSA3-2012, la presente Arquitectura de Referencia es de observancia obligatoria para todos aquellos Prestadores de Servicios de Salud del sector Social, Público y Privado que utilicen Sistemas de Información de Registro Electrónico para la Salud. Justificación El Plan Nacional de Desarrollo 2007 2012, en el Eje 3 Igualdad de Oportunidades, Apartado 3.2. Salud, específicamente en la Estrategia 7.1., plantea avanzar hacia la universalidad en el Página 5 de 24

acceso a servicios médicos de calidad a través de una integración funcional y programática de las instituciones públicas bajo la rectoría de la Secretaría de Salud. Así mismo, el Plan Nacional de Desarrollo 2007 2012, considera en los mismos Ejes y Apartado, particularmente en la Estrategia 5.3., asegurar recursos humanos, equipamiento, infraestructura y tecnologías de salud, suficientes, oportunas y acordes a las necesidades de la población. Adicionalmente, como uno de sus grandes objetivos de política social está el brindar servicios de salud, eficientes, con calidad y seguridad para el paciente. En congruencia con lo que establecen los artículos 6 fracción I y 7 fracción X de la Ley General de Salud, corresponde a la Secretaría de Salud la coordinación del Sistema Nacional de Salud, el cual tiene entre sus objetivos primordiales proporcionar servicios de salud a toda la población y mejorar la calidad de los mismos, así como promover el establecimiento de un sistema nacional de información básica en materia de salud. El artículo 109 Bis de la misma Ley, indica que corresponde a la Secretaría de Salud emitir la normatividad a que deberán sujetarse los Sistemas de Información de Registro Electrónico que utilicen las instituciones del Sistema Nacional de Salud, a fin de garantizar la interoperabilidad, procesamiento, interpretación y seguridad de la información contenida en los expedientes clínicos electrónicos. De acuerdo al Artículo 24, fracciones XIII, XIV y XV del Reglamento Interior de la Secretaría de Salud, corresponde a la DGIS: Proponer y, en su caso, opinar respecto de la normatividad, políticas y lineamientos que regirán el uso de tecnologías, estándares, vocabularios, funciones y catálogos que permitan la interoperabilidad de los sistemas y aplicaciones de salud electrónicos dentro del Sistema Nacional de Salud, de conformidad con la normatividad aplicable; Establecer las estrategias para la instrumentación del expediente clínico electrónico orientadas a la integración funcional del sector salud y al mejoramiento de la calidad en la gestión de servicios de salud, y Dirigir en la Secretaría de Salud y promover en las entidades del sector coordinado y en los servicios estatales de salud, la implementación de soluciones tecnológicas, estándares y servicios que faciliten el desarrollo de los servicios de salud electrónicos. Términos y Definiciones Describir de acuerdo al formato propuesto los términos y definiciones que deberán ser claros para los prestadores de servicios de salud y desarrolladores de software que deseen implementar esta Guía: Término Definición Página 6 de 24

Término SIRES ECE NOM SECRETARÍA DGIS HL7 IHE CDA Definición Sistemas de Información de Registro Electrónico para la Salud Expediente Clínico Electrónico Norma Oficial Mexicana Secretaría de Salud Dirección General de Información en Salud de la Secretaría de Salud Health Level Seven Integrating the Healthcare Enterprise Clinical Document Architecture REFERENCIAS Ligas Web HL7 http://www.hl7.org http://www.hl7spain.org/ http://www.hl7.org/implement/standards/product_matrix.cfm?ref=nav IHE http://www.ihe.net http://www.iheusa.org/connectconf2011.aspx http://wiki.ihe.net Otros http://cemece.salud.gob.mx Proyectos Similares http://epsos.eu https://www.niem.gov http://www.nhs.uk http://www.connectingforhealth.nhs.uk/ Bibliografía The CDA TM BOOK, Keith W. Boone, Editorial Springer. NOM-024-SSA3-2012, Sistemas de Registro Electrónico para la Salud. Intercambio de Información. Publicada en el DOF el 30 de Noviembre de 2012. Página 7 de 24

NOM-035-SSA3-2012, en materia de Información en Salud. Publicada en el DOF el 30 de Noviembre de 2012. Acuerdo por el que se establece el Sistema Nacional de Información Básica en Materia de Salud. Publicado en el DOF el 05 de Septiembre de 2012. Manual de Operación del Sistema Nacional de Información Básica en Materia de Salud. Publicado en el DOF el 08 de Noviembre de 2012. PORTAFOLIO DE ESTÁNDARES A continuación se describen los estándares para el intercambio de información que conforman la presente Arquitectura de Referencia, se describe la utilidad y manejo que deberá de darse para cada escenario de intercambio de información. HEALTH LEVEL SEVEN - HL7 Salud Nivel 7, por su nombre en inglés, es la Organización internacional generadora de estándares de interoperabilidad para informática médica, enfocada en el entendimiento y uso de la información más que los mecanismos para transportarla. Es una organización desarrolladora de estándares certificada por ANSI (American National Standards Institute). HL7 es una organización no gubernamental y sin fines de lucro con más de 35 países afiliados a nivel mundial, incluido México. Actualmente cuenta con más de 50 grupos de trabajo para la actualización, revisión y/o creación de nuevas especificaciones y estándares, para lo cual hace uso de políticas estrictas de consenso para la toma de decisiones, tanto a nivel estándares como a nivel organización, siendo incluyente con los sectores involucrados en el ámbito de Salud, tales como: Gobierno, Hospitales, Academia, Industria, Aseguradoras, entre otros. Así mismo ofrece programas de capacitación y certificación en sus distintas versiones de estándares. HL7 no es un lenguaje en sí, sino más bien un conjunto de estándares que dictan el formato en el que se puede intercambiar información en formato electrónico entre los diferentes sistemas informáticos de los prestadores de servicios de salud. Para ver más detalles y tener información más amplia de todos los estándares e iniciativas que HL7 posee, consultar los enlaces del apartado Ligas Web. HL7 REFERENCE INFORMATION MODEL Modelo de Información de Referencia que facilita la construcción de artefactos de interoperabilidad; Normaliza la definición de modelos de datos a partir de un metamodelo; facilita la interoperabilidad semántica. Página 8 de 24

Es la fuente a partir de la cual se construye cualquier artefacto de interoperabilidad basado en HL7 Versión 3. Es un modelo estático construido con la notación Unified Modeling Language (UML) del Object Management Group (OMG). A través de una escala de abstracción variable, facilita la definición de los objetos que participan en un escenario de interoperabilidad con un modelo de información específico para un dominio. Incluye diagramas de clases y máquinas de estado, así mismo se acompaña de los modelos de casos de uso, modelos de interacción, los modelos de tipos de datos, modelos de terminología, y otros tipos de modelos para proporcionar una visión completa de los requisitos y diseño de los estándares de HL7. El RIM, junto con los tipos de datos (DataTypes) y Vocabulario son la base de todo el modelado de información dentro de HL7. Los modelos derivados de estos sirven como documentos y mensajes. Como tales, son "parte" de cada versión estándar HL7 3. HL7 VERSIÓN 3 V3 es más que otro tipo de mensajería, es una nueva manera de abordar la interoperabilidad clínica con el apoyo de modelos de referencia. A partir de un escenario concreto (Evento, Aplicación Emisor y Receptor, etc.), construye artefactos de interoperabilidad (mensajes / documentos), en base a un modelo de datos restringido, con sucesivas abstracciones, de un núcleo común, el RIM (Reference Information Model). El RIM da consistencia a todas las posibles extensiones que requieren los distintos dominios de implantación y abre la vía para llegar a una interoperabilidad semántica. Página 9 de 24

La esencia de la Versión 3 es el establecimiento de una base de modelado de información que sea: - Estable. - Capaz de soportar la representación de todos los conceptos en el dominio de interés de HL7. - Tecnológicamente independiente, con el fin de permitir su implementación en una variedad de entornos como la tecnología evoluciona usuarios. Aplica las "mejores prácticas" de desarrollo de software para la elaboración de una metodología para la generación de estándares. Predica con los tres fundamentos semánticos de diseño: un modelo de información de referencia, un robusto conjunto de tipos de datos y un conjunto completo de dominios de terminología y exige que todos los estándares de la versión 3 se desarrollen bajo estos tres fundamentos. HL7 CLINICAL DOCUMENT ARCHITECTURE R2 CDA-R2 como es comúnmente conocido es el núcleo de la historia clínica electrónica de un paciente. Establece la composición de cualquier documento clínico, por ejemplo: Informe de Alta Hospitalaria, Informe de Resultados de estudios de laboratorio o de una imagen diagnóstica, o bien, un Resumen Clínico. La estructura de un documento CDA se define por una cabecera y un cuerpo con unas entradas en XML normalizadas que facilitan el procesamiento de su contenido y a la vez su visualización a través de cualquier navegador de internet con una personalización del formato para los usuarios. Es términos generales, un estándar de etiquetado para definir la estructura y semántica de un documento clínico que se requiere intercambiar entre distintos sistemas. Es un estándar ANSI realizado por el comité Structured Documents Technical Committee (SDTC) de la organización internacional HL7 y es una especificación para el intercambio de documentos electrónicos utilizando: - XML - Reference Information Model de HL7, - Metodología de desarrollo de la versión 3 de HL7, - Vocabularios controlados (SNOMED, LOINC, CIE-9-MC, etc.). Estructura un documento clínico en varias secciones normativas y define el nivel de interoperabilidad de sus contenidos. Todos sus elementos y tipos de datos configuran un esquema XML que deriva del Modelo de Información de Referencia HL7 RIM. Puede adaptarse a múltiples formatos de presentación y visualizarse con cualquier navegador web. A continuación se presenta el diagrama R-MIM correspondiente a la especificación de CDA: Página 10 de 24

HL7 CONTINUITY OF CARE DOCUMENT (CCD) CCD es un esfuerzo conjunto de HL7 y ASTM para mejorar la atención del Paciente a través de una óptima interoperabilidad de datos clínicos entre facultativos. Representa la implementación del Continuity of Care Record (CCR) de ASTM con un esquema HL7 CDA. Combina lo mejor de ambas tecnologías, es un estándard basado en XML que especifica la estructura y codificación del resumen clínico de un Paciente en un espacio/tiempo dado. HL7 EHR-S FUNCTIONAL MODEL Este estándar facilita el avance de los sistemas de registro electrónico para la salud, orientados a la continuidad asistencial para optimizar la calidad, seguridad y eficiencia de la atención al paciente. Su modelo permite a personal técnico enfocar el desarrollo de un sistema de registro electrónico para la salud bajo un conjunto de requisitos funcionales de relevancia clave para los usuarios clínicos y pacientes. En su versión 2 (propuesta para su aprobación como estándar durante 2013 de acuerdo con el grupo de trabajo de HL7 encargado de su elaboración), el Modelo Funcional de HL7 se compone de un listado de más de 2500 funcionalidades, divididas en siete secciones: Generalidades, Atención Clínica, Soporte a la Atención Clínica, Soporte a la Salud Pública, Soporte Administrativo, Almacenamiento de Información e Infraestructura y Seguridad. Página 11 de 24

Asociado a este estándar, HL7 Internacional creo el concepto de Perfiles Funcionales. Un Perfil funcional es una especificación que utiliza el Modelo Funcional para indicar que funciones son requeridas o deseables para determinado sistema de Registro Electrónico para la Salud, atención médica u otros propósitos dentro del ámbito de la salud. Crear un Perfil Funcional es un método a través del cual se definen subconjuntos del total funcionalidades del Modelo Funcional. HL7 VERSIÓN 2.X Es el estándar internacional de mensajería para el intercambio electrónico de datos en los ámbitos clínico, asistencial, económico y logístico más utilizado en el mundo de la salud. La última versión del estándar incorpora esquemas basados en XML y un progresivo alineamiento con la metodología de desarrollo de la versión 3. Es un estándar de intercambio de archivos de texto plano, ampliamente utilizado desde 1990, la mensajería en esta versión es ampliamente utilizada para la comunicación entre sistemas clínicos (Laboratorio, Imagen, etc.), así como financieros y administrativos. Se recomienda únicamente para el intercambio de información al interior de las los sistemas de los Prestadores de Servicios de Salud. Normalmente utiliza mensajes ASCII puros con un formato plano. Esta versión tiene menos restricciones semánticas, es decir que no especifica el modelo subyacente y el vocabulario de forma tan estricta como la versión 3. Cada mensaje está compuesto por: Segmentos. Un segmento HL7 es una agrupación de campos. Campos. Un campo es una cadena de caracteres definida por un tipo de dato de HL7. Componentes. Son cada uno de los elementos que conforman un campo. Caracteres delimitadores. En la construcción de mensajes se utilizan caracteres especiales como delimitadores, algunos como:, &, ~, \, <CR>, entre otros. Página 12 de 24

Ejemplo: MSH ^~\& MReg HospC SOE ImgCtr 20060529090131-0500 ADT^A01^ADT_A01 01052901 P 2.5 EVN 200605290901 200605290900 PID 56782445^^^UAReg^PI SUE^BARRY^Q^JR 19620910 M 2028-9^^HL70005^RA99113^^XYZ 260 GOODWIN CREST DRIVE^^BIRMINGHAM^AL^35 209^^M~NICKELL S PICKLES^10000 W 100TH AVE^BMNGHM^AL^35200^^O 0105I30001^^^99DEF^AN PV1 I W^38^1^UAB^^^^3 123^MORGAN^DEX^J^^^MD^010^UAMC^L 678^GRAIN^LUCY^X^^^MD^0010^ UAMC^L MED A0 13579^POTTER^T^^^MD^0010^MC^L 200605290900 OBX 1 NM ^Body Height 1.80 m^meter^iso+ F OBX 2 NM ^Body Weight 79 kg^kilogram^iso+ F AL1 1 ^ASPIRIN DG1 1 786.50^CHEST PAIN, UNSPECIFIED^I9 A MENSAJERÍA VERSIÓN 2.X - XML Esta especificación también conocida por HL7 V2.xml facilita que los mensajes de la Versión 2.x sean procesados a través de internet mediante un esquema XML en lugar de los clásicos caracteres de barras verticales. También incrementa los niveles de validación para reducir errores en la construcción y en el envío/recepción del mensaje. HL7 SERVICE ORIENTED ARCHITECTURE HL7 en colaboración con el Object Management Group (OMG) ha desarrollado una guía práctica para la utilización de SOA en sistemas de salud en el marco del Healthcare Services Specification Project (HSSP). HL7 está desarrollando su Services-Aware Enterprise Architecture Framework (SAEAF). Su propósito es alinear SOA con su repertorio de estándares: mensajes, documentos clínicos y servicios. En el mediano plazo, todos los modelos funcionales de servicios HL7 estarán regidos por SAEAF. El siguiente diagrama representa el Proceso de Desarrollo del Paradigma de la Interoperabilidad basado en SOA. Está estructurado como un conjunto de artefactos pueden ser derivados entre sí. HL7 ROLE BASED ACCESS CONTROL (RBAC) RBAC es un estándar utilizado para controlar el acceso a los recursos en un sistema de información. Ha sido desarrollado para superar las complejidades de la administración de permisos para usuarios individuales y sus asignaciones. RBAC ha sido desarrollado por HL7 para: - Simplificar la administración de autorizaciones - Reducir los costos administrativos - Mejorar la seguridad - Mejorar la interoperabilidad Página 13 de 24

- Mejorar el servicio hacia: miembros, clientes y pacientes INTEGRATING THE HEALTHCARE ENTERPRISE - IHE Organización internacional promovida por iniciativa de la industria de la salud en pro del intercambio de información en salud. Las soluciones que genera integran diversos estándares, mismos que se definen más adelante en el presente documento. Define perfiles de integración como guías de buena práctica para resolver escenarios de interoperabilidad con una combinación de los estándares más acreditados. Certifica el alineamiento de las aplicaciones a sus perfiles de integración. A continuación se presenta un diagrama que muestra los diferentes escenarios y niveles de interoperabilidad soportados por IHE, así como la interacción que puede existir entre ellos: IHE - PATIENT IDENTIFIER CROSS REFERENCING (PIX) Este perfil es útil para la identificación de pacientes en múltiples dominios. Estos identificadores pueden ser utilizados por sistemas de "identificación" para correlacionar la información acerca de un paciente entre diferentes fuentes de información que "conocen" al paciente por medio de identificadores diferentes. Esto permite que un médico pueda tener una visión más completa de la información del paciente. Este perfil de integración no define las políticas específicas o algoritmos de referencias cruzadas. PIX se basa en dos niveles de mensajería HL7 V2 (PIXV2) y HL7 V3 (PIX V3), mismo propósito, diferentes estándares. A través de este perfil se puede transmitir la información de identidad de un paciente desde la fuente de la información hacia un administrador de referencias cruzadas. Proporciona la posibilidad de acceder a listas de identificación del paciente con referencias cruzadas mediante una consulta o a través de una notificación de actualización. Página 14 de 24

Se pueden realizar las referencias cruzadas y la vinculación de la información del paciente sin necesidad de definir o poner en riesgo políticas o algoritmos de referencias cruzadas. Proporciona mecanismos necesarios para el intercambio de información basado en referencias cruzadas y es flexible para ser usado bajo cualquier política o algoritmo que determine cada Prestador de Servicios de Salud. IHE - PATIENT DEMOGRAPHICS QUERY (PDQ) Este Perfil se utiliza para la consulta de datos demográficos del paciente (Patient Demographics Query - PDQ), permitiendo a las aplicaciones consultar a un servidor central de información del paciente para obtener una lista de pacientes, así como sus datos demográficos e información de visita. PDQ se apoya en dos niveles de mensajería HL7 V2 (PDQ) y HL7 V3 (PDQ V3), mismo propósito, diferentes estándares. PDQ proporciona un medio muy sencillo para consultar información demográfica, basada en: - Nombre parcial o completo. - Identificación del paciente. - Fecha de nacimiento / rango de edad. Permite a un sistema proveedor de información de pacientes recibir una consulta de datos demográficos y/o clínicos desde un sistema. Cuando un sistema proveedor de información de pacientes se agrupa con otros sistemas que implementan perfiles de IHE y almacenan información adicional de sus pacientes identificados, el sistema Proveedor puede a través de este perfil hacer uso de información actualizada de otros sistemas para responder a las consultas que le sean requeridas. Además, el perfil de PDQ puede integrarse como parte de una solución integral con otros perfiles IHE. Página 15 de 24

IHE - CROSS ENTERPRISE DOCUMENT SHARING (XDS) Perfil creado por IHE para facilitar el intercambio de documentos clínicos entre instituciones. XDS proporciona un método centralizado para la indexación de documentos. Facilita el registro, distribución y acceso a los registros electrónicos de los pacientes entre instituciones de salud. El perfil XDS se enfoca en proporcionar una especificación basada en estándares para administrar el intercambio de documentos entre prestadores de servicios de salud, que van desde un consultorio médico privado hasta una clínica de especialidades, hospitalización, etc. Se administra a través de repositorios federados de documentos y un registro de documentos para crear un registro longitudinal de información acerca de un paciente dentro de un ámbito de la salud dado. A continuación se dan algunos ejemplos de entidades con responsabilidades separadas: Un repositorio de documentos se encarga de almacenar documentos de manera transparente, segura, confiable y persistente, así como responder a las solicitudes de consulta de documentos que se le hagan. Un sistema de registro de documentos es responsable de almacenar la información sobre esos documentos para que los documentos de interés para el cuidado de un paciente puedan ser fácilmente encontrados, seleccionados y obtenidos, independientemente del repositorio donde se almacenan realmente. Los documentos pueden ser proporcionados por una o más fuentes documentales, posteriormente, estos documentos pueden ser revisados por uno o más sistemas consumidores o de consulta de Documentos. Dentro de los principales beneficios obtenidos del uso de este perfil se encuentran: - Fácil gestión del Expediente Clínico Electrónico. - Fácil registro, distribución y acceso a la información entre una diversidad de Prestadores de Servicios de Salud a los registros médicos electrónicos de los pacientes. Este perfil se enfoca en proporcionar una especificación basada en estándares para la gestión de la distribución de documentos entre diferentes Prestadores de Servicios de Salud, que van desde un consultorio médico privado a una clínica para un cuidado intensivo u hospitalización. El perfil XDS asume que las los sistemas de los Prestadores de Servicios de Salud pertenecen a uno o más dominios de XDS. Un dominio XDS se refiere a un grupo de prestadores de servicios de salud que han acordado trabajar juntos utilizando serie de políticas afines y comparten una infraestructura común. Página 16 de 24

Ejemplos donde es de gran utilidad el perfil XDS: - Conjunto de hospitales que atienden a pacientes en una región determinada. - Expediente Clínico Electrónico a nivel nacional. - Atención Especializada: - Especialistas en Cardiología y un Centro de Cardiología aguda - Red de atención Oncológica - Red de atención de diabetes - Prestadores de Servicios de Salud federados: - Una región integrada por varios hospitales locales y los prestadores de servicios de salud. - Aseguradoras El concepto de un documento dentro del perfil XDS no se limita a la información textual. Dado que XDS es neutral en cuanto al contenido de los documentos, cualquier tipo de información clínica sin tener en cuenta el contenido y la representación, es compatible. Esto hace que el perfil de Integración XDS sea igualmente capaz de manejar los documentos que contienen texto simple, texto con formato (por ejemplo, HL7 CDA R1), imágenes (por ejemplo, DICOM) o estructurada y vocabulario información codificada clínica (por ejemplo, CDA Release 2, CCR, etc.). Con el fin de garantizar la interoperabilidad entre las diferentes fuentes y consumidores de información (en este caso documentos), los diferentes Prestadores de Servicios de Salud que agrupados formen un Dominio XDS deben adoptar políticas relativas al formato, estructura y contenido de los documentos que compartirán. Página 17 de 24

IHE - CROSS ENTERPRISE DOCUMENT MEDIA INTERCHANGE (XDM) Perfil de IHE que permite el intercambio de documentos mediante un directorio de archivos a través de varios medios de comunicación estándar. Esto permite al paciente utilizar medios físicos para llevar consigo documentos médicos en formato electrónico. También permite el uso de correo electrónico de persona a persona para transmitir documentos médicos. Facilita el intercambio de información en salud de persona a persona. Soporta el transporte vía USB o CD-R, así como el correo electrónico. La solución XDM está concebida para facilitar la implementación con clientes de correo electrónico pre-existentes, sistemas de grabado en medios físicos como CD y puertos USB. XDM requiere que el receptor sea capaz de soportar la intervención humana con el fin de controlar manualmente la importación de los datos (reconciliación de identificación del paciente, la selección de paciente de interés de, posiblemente, múltiples documentos de los pacientes en los medios de comunicación). XDM es independiente del formato de documento, dando el mismo soporte tanto al contenido de un documento de los perfiles XDS y XDR. Ejemplos de ello son XDS-MS (Resúmenes clínicos), XPHR (Expediente Clínico Personal), XDS-SD (Documentos Escaneados) y Cualquier documento de Reportes de Laboratorio. XDM no define nuevos metadatos. Aprovecha metadatos XDS con énfasis en la identificación de pacientes, identificación de documentos, así como la descripción y sus relaciones. Su estructura mantiene áreas separadas para cada paciente en la lista y es compatible con todos los tipos de referencia de los medios. Los medios electrónicos que generalmente se seleccionan son: CD-R, USB y el correo electrónico con archivo adjunto ZIP. IHE - CROSS ENTERPRISE DOCUMENT RELIABLE INTERCHANGE (XDR) Este perfil de IHE se utiliza para el intercambio de documentos mediante un sistema de mensajería confiable. Esto permite el intercambio de documentos directamente entre los diferentes Sistemas de Registro Electrónico para la Salud, a falta de una infraestructura de uso compartido de documentos como repositorios y/o plataformas centrales. XDR, proporciona una transferencia automatizada y confiable de documentos y metadatos de un paciente entre diferentes sistemas de Registro Electrónico para la Salud, incluso en ausencia de una infraestructura XDS. XDR soporta la reutilización del conjunto de transacciones realizadas a través de Web Services (Proveer y Registrar). La transferencia es directa desde la fuente hasta el receptor, no hay repositorios o sistemas de registro involucrados. XDR es independiente del formato del documento a compartir, dando el mismo soporte tanto Página 18 de 24

al contenido de documento XDS como de XDM. EL contenido de los documentos a compartir se describe con perfiles XDS. Ejemplos de ello son: XDS-MS (Resúmenes clínicos), XPHR (Expediente Clínico Personal), XDS-SD (Documentos Escaneados) y Cualquier documento de Reportes de Laboratorio. Aprovecha metadatos XDS con énfasis en la identificación del paciente, de documento, así como la descripción y sus relaciones. IHE - CROSS COMMUNITY ACCESS (XCA) Perfil de IHE que permite tener compatibilidad con los diferentes medios necesarios para consultar y obtener registros de información de pacientes en posesión de instituciones u organizaciones externas. El perfil XCA da soporte a los mecanismos requeridos para consultar y obtener datos clínicos de pacientes en poder de otro(s) sistema(s) (comunidades). Una Comunidad se define como un conjunto de Prestadores de Servicios de Salud que se han comprometido a trabajar conjuntamente utilizando políticas afines, con el objetivo de compartir información clínica a través de un determinado mecanismo establecido. Los participantes de una Comunidad pueden acoger cualquier tipo de Sistema de Registro Electrónico para la Salud, como Expediente Clínico Electrónico, Sistemas de Laboratorio, Sistemas de Farmacia etc. Una comunidad es identificada por un identificador único global llamado homecommunityid. La pertenencia de un Prestador de Servicios de Salud a una Comunidad no le impide ser parte de otra Comunidad. Estas Comunidades pueden ser dominios XDS que acuerdan compartir documentos utilizando el perfil XDS o cualquier otra comunidad, independientemente de su estructura interna de intercambio de información. IHE - AUDIT TRAIL AND NODE AUTHENTICATION (ATNA) El Perfil de Integración denominado Rastro de Auditoría y Autenticación por Nodo (ATNA) establece las medidas de seguridad que, junto con la Política de Seguridad y Procedimientos, proporcionan confidencialidad, integridad de datos y rendición de cuentas a la información del paciente. Este entorno se considera el dominio de seguridad y se puede escalar desde un departamento o área, una unidad médica o un dominio específico. Proporciona soporte y mecanismos que facilitan la implementación de políticas de seguridad y confidencialidad. Esta especificación técnica se basa en el supuesto de que habrá escenarios en los cuales los documentos estén siendo intercambiados y almacenados entre sistemas de información de registro electrónico para la salud. Esto cubre la necesidad de los diferentes sistemas para operar en situaciones de desastres y/o sobrecarga, donde está limitado o nulo el funcionamiento de las comunicaciones. Es importante señalar que existe la necesidad que en determinados escenarios de intercambio de información haya no sólo lectura de la información intercambiada, sino que ésta se pueda ser almacenada por los destinatarios, lo que significa que habría copias de la Página 19 de 24

información intercambiada, por lo anterior debe existir un diseño completo de seguridad / privacidad para el tratamiento de situaciones en las que se almacenan los datos después de su consulta. El perfil de integración ATNA facilita el control de acceso mediante la limitación de acceso a la red entre los nodos y limita el acceso a cada nodo de los usuarios autorizados. Las comunicaciones entre nodos seguros en un dominio seguro se limitan únicamente a otros nodos seguros dentro del mismo dominio. Asegura acceso limitado a los nodos de usuarios autorizados según lo especificado por la autenticación local y la política de control de acceso. Respecto de la autenticación de usuarios, ATNA requiere sólo la autenticación local de usuarios. El perfil permite que cada nodo seguro utilice la tecnología de control de acceso de su elección para autenticarlos. Para la Autenticación de Conexiones, ATNA requiere del uso bidireccional de autenticación basada en nodos certificados para conexiones hacia y desde cada nodo. Los protocolos DICOM, HL7 y HTML tienen mecanismos definidos basados en certificados de autenticación. Estos autentican los nodos, en lugar de usuarios. Las conexiones a los dispositivos que no son autenticados de forma bidireccional serían prohibidas para impedir el acceso a la información restringida o identificada como confidencial. La trazabilidad y seguimiento de las actividades de cuentas de usuario se proporciona a través de rastros de auditoría. El rastro de auditoría permite que cualquier personal, responsable de la seguridad de la información al interior de una institución pueda llevar a cabo actividades de auditoría, para evaluar el cumplimiento de las políticas de un dominio seguro, detectar casos sospechosos de comportamiento y para facilitar la detección de la creación, acceso, modificación y/o eliminación de información de salud confidencial, protegida o restringida. IHE - PATIENT ADMINISTRATION MANAGEMENT (PAM) El perfil de Integración para el Manejo de la Administración de Pacientes establece la continuidad e integridad de los datos del paciente e información adicional, como datos de personas vinculadas al paciente (familiares, tutor, representante legal, etc.) Además, coordina el intercambio de información y registro de pacientes entre los sistemas de actualización que deben ser capaces de proporcionar información actualizada sobre el paciente, independientemente de su ubicación o estado actual. Este perfil beneficia la eficiencia de la atención al paciente y evita errores en el registro de datos, garantizando que los datos de identificación y clínicos se registran una sola vez y los pone a disposición de aplicaciones que lo requiera. Este perfil facilita la interoperabilidad entre aplicaciones clínicas, administrativo y de Página 20 de 24

servicios, basándose en un identificador común y datos demográficos de pacientes. Avisa en aplicaciones en tiempo real de los centros de atención de pacientes agudos con llegadas y salidas, movimientos, previstos o efectivos, lo que mejora la eficiencia global de los servicios prestados por los equipos que ejecutan estas aplicaciones. Sincroniza la corrección de errores humanos (fusionar o actualizar los registros de pacientes, actualizar el traslado del paciente) entre todas las aplicaciones que se han visto afectados por estos errores. IHE - CONSISTENT TIME (CT) Este perfil de IHE proporciona un medio para asegurar que los relojes del sistema de los diferentes servicios de red están bien sincronizados. Este perfil especifica la sincronización con una mediana de error inferior a 1 segundo. El Perfil CT define mecanismos para sincronizar el tiempo base entre múltiples sistemas y equipos asociados dentro de un entorno de interoperabilidad. Tanto infraestructura, seguridad y perfiles de adquisición requieren del uso de un tiempo base consistente en varios equipos, para sincronizar los registros, autenticar a los usuarios, firmar digitalmente documentos, entre otras actividades, es por ello que el perfil CT requiere el uso del Protocolo de Tiempo de Red (Network Time Protocol - NTP) definido en el RFC 1305. Cuando el servidor de hora está interconectado con equipos cliente para obtener la hora de un servidor de hora de nivel superior, el cliente utiliza el protocolo NTP. Para aquellos equipos cliente que no se agrupan con un servidor de hora, pueden utilizar SNTP (RFC 4330). IHE - BASIC PATIENT PRIVACY CONSENTS (BPPC) Con este perfil de IHE se proporciona un mecanismo para registrar los consentimientos de privacidad del paciente y obliga a aquellos que desean obtener información del mismo a dar el uso apropiado de la información de acuerdo con los consentimientos de privacidad. Este perfil complementa al perfil XDS, describiendo un mecanismo que permita en un dominio específico de XDS desarrollar y poner en práctica varias políticas de privacidad, así mismo describe cómo este mecanismo se puede integrar con los mecanismos de control de acceso soportados por los diferentes participantes en un escenario de intercambio de información basado en XDS. A través de la implementación de este perfil se pueden desarrollar políticas de privacidad y ponerlas en práctica bajo mecanismos de control basados en roles o de otro tipo de acceso soportados por sistemas de registro electrónico para la salud. Así mismo, estas políticas pueden ser de conocimiento de los pacientes y los diferentes prestadores de servicios de salud tendrán la oportunidad de controlar selectivamente el acceso a su información. Página 21 de 24

A continuación se describen tres pasos generales a través de los cuales se puede implementar un perfil BPPC: - En un ambiente de interoperabilidad con varios sistemas de registro electrónico para la salud intercambiando información (dominio) se debe crear un conjunto de políticas. A cada política se le debe asignar un identificador único (OID). Este identificador (OID) se considera un vocabulario específico dentro del dominio. Existen ejemplos de cómo construir estas políticas forma tal que se permite al paciente seleccionar adecuadamente el tipo de intercambio con el que está de acuerdo y aquellos con los que no. Esto es importante ya que permitir a los sistemas y en generar a los prestadores de servicios de salud definir sus propias políticas claramente tanto para ellos como para los pacientes, sistemas y otras instancias alrededor del dominio en el que apliquen. - El perfil BPPC indica cómo registrar el consentimiento y/o firma de un paciente aprobando una o más políticas. Esta es registrada utilizando el estándar CDA con la posibilidad de incluir una copia escaneada o una firma digital. La copia escaneada del consentimiento puede provenir de un papel firmado por el paciente, esta opción ha sido muy bien recibida por los prestadores de servicios de salud ya que puede visualizarse directamente el consentimiento del paciente de su puño y letra. - Cuando dentro de un dominio utiliza un documento, estará obligado a dar uso aceptable al documento. Así mismo, aquellos documentos a los cuales no se les autoriza el acceso, serán bloqueados. Actualmente existen mecanismos a través de los cuales BPPC puede generar metadatos para un perfil XDS mismos que se pueden utilizar en la mensajería de HL7 y DICOM. En ambos casos existe ya un código: confidentiality Code definido para este propósito. IHE - MULTI PATIENT QUERIES (MPQ) Este perfil define un mecanismo para permitir consultas a un registro de documentos basado en ciertos criterios requeridos por las áreas relacionadas con el análisis de datos, tales como la acreditación de calidad de los diferentes Prestadores de Servicios de Salud, recolección de datos, ensayos clínicos de investigación o el monitoreo de la salud en una determinada población. Ofrece beneficios y facilidades para tomar decisiones acertadas en materia de Salud Pública. Este perfil es de gran utilidad en áreas de investigación en el ámbito de la salud, permite tomar decisiones acertadas a instituciones a cargo de la salud pública y calidad en la prestación de la atención, proporcionando mecanismos de consulta simples o agrupación de consultas. DIGITAL IMAGING AND COMMUNICATION IN MEDICINE (DICOM) DICOM es una estándar internacional cuya estructura está diseñada para garantizar la Página 22 de 24

interoperabilidad entre los sistemas de registro electrónico para la salud utilizados para: producir, almacenar, visualizar, procesar, enviar, obtener, consultar o imprimir imágenes médicas y documentos estructurados asociado, así como para la gestión de flujo de trabajo relacionado. Es un estándar reconocido mundialmente para el intercambio de imágenes médicas. DICOM puede ser utilizado en cualquiera de los siguientes servicios de especialidad médica: radiología, cardiología, oftalmología, cirugía, neumología, neurología, patología, oncología, radioterapia y veterinaria. CLASIFICACIÓN INTERNACIONAL DE ENFERMEDADES 10ª EDICIÓN CIE-10 Estándar internacional de uso obligatorio en todo el país, para la codificación y generación de estadísticas de morbilidad y mortalidad uniformes, que permiten la comparabilidad nacional e internacional. Conocida por su acrónimo en español CIE-10, determina la clasificación y codificación de las enfermedades a nivel mundial. Para efectos de este documento y en el marco de la NOM-024-SSA3-2012 se considera la versión vigente adoptada en nuestro país. CLASIFICACIÓN INTERNACIONAL DE ENFERMEDADES MODIFICACIÓN CLÍNICA 9ª EDICIÓN CIE-9 MC Estándar de uso obligatorio en todo el país para la codificación y generación de estadísticas de procedimientos médicos: quirúrgicos y no quirúrgicos (diagnóstico y terapéuticos); que permite la comparabilidad nacional. Clasificación Internacional de enfermedades modificación clínica 9ª edición, determina la clasificación y codificación de los procedimientos clínicos. Para efectos de este documento y en el marco de la NOM-024-SSA3-2012 se considera la versión vigente adoptada en nuestro país. CLASIFICACIÓN INTERNACIONAL DEL FUNCIONAMIENTO, DE LA DISCAPACIDAD Y DE LA SALUD - CIF Estándar internacional de uso obligatorio en todo el país para el estudio, codificación y generación de estadísticas de funcionamiento y discapacidad, que permiten la comparabilidad nacional e internacional. Para efectos de este documento y en el marco de la NOM-024-SSA3-2012 se considera la versión vigente adoptada en nuestro país. EXTENSIBLE MARKUP LANGUAGE - XML extensible Markup Language, lenguaje estándar usado en la comunicación entre aplicaciones mediante servicios web en cualquier contexto. Diseñado para estructurar, transportar y almacenar información, por otro lado no ha sido diseñado para mostrar en Página 23 de 24

forma amigable la información. DECLARACIONES La información, diagramas, bibliografía y demás referencias plasmadas en el presente documento son propiedad de sus respectivos dueños. Este documento únicamente es una referencia a cada uno de ellos, para tener acceso y poder hacer uso de los mismos, se deberán observar las disposiciones, lineamientos, costos y/o procedimientos para su adquisición de forma directa con sus autores. Página 24 de 24