MANUAL de Operación del Sistema Nacional de Información Básica en Materia de Salud MANUAL de Operación del Sistema Nacional de Información Básica en Materia de Salud.
Al margen un sello con el Escudo Nacional, que dice: Estados Unidos Mexicanos.- Secretaría de Salud.
JUAN CARLOS REYES OROPEZA, Director General de Información en Salud de la Secretaría de Salud, con fundamento en lo dispuesto por el artículo 24 del Reglamento Interior de la Secretaría de Salud, y en el Transitorio Segundo del Acuerdo por el que se establece el Sistema Nacional de Información Básica en Materia de Salud, publicado en el Diario Oficial de la Federación el 5 de septiembre de 2012, y
CONSIDERANDO
Que el 5 de septiembre de 2012, se publicó en el Diario Oficial de la Federación el Acuerdo por el que se establece el Sistema Nacional de Información Básica en Materia de Salud, el cual tiene por objeto establecer el Sistema Nacional de Información Básica en Materia de Salud, como una herramienta que garantice el intercambio de información y su análisis en materia de salud a nivel nacional que integrará de forma estructurada y sistematizada la INFORMACION BASICA en materia de salud, a través de los procedimientos, protocolos y las plataformas tecnológicas que permitan la operación de dicho Sistema, el cual será administrado por la Secretaría de Salud, en su carácter de coordinadora del SNS, por conducto de la Dirección General de Información en Salud, y
Que en términos de lo dispuesto por el Transitorio Segundo del mencionado Acuerdo, la Dirección General de Información en Salud expedirá y publicará en el Diario Oficial de la Federación el Manual de Operación del Sistema Nacional de Información Básica en Materia de Salud, dentro de los cuarenta y cinco días hábiles siguientes a la fecha en que entre en vigor dicho Acuerdo, por lo cual he tenido a bien expedir el siguiente:
| MANUAL DE OPERACION DEL SISTEMA NACIONAL DE INFORMACION BASICA EN MATERIA DE
SALUD
|
INDICE
0. TERMINOS Y ABREVIATURAS
1. GENERALES
1.1. Presentación
1.2. Marco Jurídico
1.3. Objetivo
1.4. Responsabilidades
2. PROCESOS DE ADMINISTRACION Y OPERACION DEL PGS
2.1 Políticas de Administración del Padrón
2.2 Políticas de Administración de la Información
2.2.1. Mecanismos de consulta
2.2.1.1. Aplicación web
2.2.1.2. Información Estadística
2.2.2. Procedimientos de autorización
2.2.2.1. Generación de usuarios para la aplicación web
2.2.2.2. Baja de usuario para la aplicación web
2.2.3. Entrega de información
2.2.3.1. Periodicidad de envíos
2.2.4. Respaldo de los sistemas y base de datos
2.2.5. Administración de versiones
2.2.6. Administración de la base de datos PGS
2.2.7. Administración de certificados
3. REGLAS DE NEGOCIO PARA LA INTEGRACION DE INFORMACION
3.1 Marco Metodológico
3.2 Modelo Conceptual
3.3 Integración de la Información
3.3.1. Tipo de información
3.3.2. Información solicitada
3.3.3. Alta de beneficiarios
3.4 Procesos de Integración de Información de beneficiarios
3.4.1. Objetivo
3.4.2. Primer envío de información
3.4.2.1. Actores
3.4.2.2. Descripción
3.4.2.3. Datos
3.4.2.4. Reglas
3.4.2.5. Formato de nombre de archivo
3.4.3. Integración de nuevos registros de beneficios
3.4.3.1. Actores
3.4.3.2. Descripción
3.4.3.3. Datos
3.4.3.4. Reglas
3.4.3.5. Formato de nombre de archivo
3.4.4. Actualización de información de vigencia de derechos
3.4.4.1. Actores
3.4.4.2. Descripción
3.4.4.3. Datos
3.4.4.4. Reglas
3.4.4.5. Formato del nombre del archivo
4. PROCESOS DE ENVIO Y RECEPCION DE INFORMACION
4.1 Alcance
4.2 Audiencia
4.3 Definición del estándar para envío y recepción de información
4.3.1. Descripción
4.3.2. Los mensajes de información XML
4.3.3. Descripción del protocolo de transferencia
4.3.3.1. Validación de esquema
4.4 Procedimiento de recepción de información del beneficiario y vigencia de derechos
4.4.1. Recepción de información de nuevos beneficiarios
4.4.2. Procesos para envío de archivo de nuevos beneficiarios
4.4.2.1. Diagrama de flujo del proceso
4.4.3. Proceso de integración de nuevos beneficiarios
4.4.3.1. Diagrama de flujo del proceso
4.4.4. Procesos para consulta de resultados â Alta de beneficiarios
4.4.4.1. Diagrama de flujo de proceso
4.4.5. Proceso de recepción de información para actualización de vigencias
4.4.5.1. Diagrama de flujo del proceso
4.4.6. Procesos de integración para - Actualización de vigencias
4.4.6.1. Diagrama de flujo del proceso
4.4.7. Proceso para consulta de resultados â Actualización de vigencias
4.4.7.1. Diagrama de flujo del proceso
4.5 Reporte de Inconsistencias
4.5.1. Inconsistencias de datos
4.5.2. Inconsistencias de integración
4.6 Seguridad
4.6.1. SSL (Secure Socket Layer)
4.6.2. HTTPS
4.6.2.1. Características Técnicas
4.6.2.2. Diferencias con HTTP
4.6.2.3. Capas de Red
4.7 Propósito
4.8 Audiencia
4.9 Dominio de Patient Administration
4.9.1. Diagrama D-MIM
4.9.2. Mensajes
4.9.3. Eventos
4.9.4. Mensaje Patient Registry â PRPA_IN213109UV
4.9.5. Diagrama RMIM
4.9.6. Información Detallada
4.9.7. Lista de tipos de mensaje
4.9.8. Interacciones
4.9.9. Diccionario de Datos
4.9.9.1. Integración de beneficiarios
4.9.9.2. Actualización de vigencia
4.9.9.3. Archivo de Inconsistencias de datos
4.9.10. Definición de mensajes
4.9.10.1. Patient Registry â PRPA_IN213109UV02
4.9.10.2. Patient Registry â PRPA_MT213039UV02
4.9.11. Mensajes XML
4.9.11.1. Mensaje completo â Integración de beneficiarios
4.9.11.2. Mensaje mínimo â Integración de beneficiarios
4.9.11.3. Mensaje único - Actualización de vigencia de beneficiario
4.9.11.4. Mensaje único â Inconsistencias de datos
| 0. TERMINOS Y ABREVIATURAS |
| ACUERDO
| Acuerdo por el que se establece el Sistema Nacional de Información Básica en Materia de Salud publicado en el Diario Oficial de la Federación el 5 de septiembre de 2012. |
| BENEFICIARIOS
| Todas aquellas personas que tienen el carácter de afiliados y/o derechohabientes y/o beneficiarios y/o pacientes de los servicios de salud que presten las Dependencias y Entidades de la Administración Pública Federal. |
| CNPSS, SEGURO
POPULAR
| Comisión Nacional de Protección Social en Salud, de la Secretaría de Salud. |
| CURP
| Clave Unica de Registro de Población. |
| D-MIM
| Domain Message Information Model por su nombre en inglés. Es una forma del R-MIM, construido para representar la totalidad de conceptos contenidos en los R-MIM necesarios para dar soporte a los requerimientos de comunicación dentro de un dominio específico de HL7. |
| DEPENDENCIAS Y
ENTIDADES
| Las señaladas en los Artículos 2o. y 3o. de la Ley Orgánica de la Administración Pública Federal, que presten servicios de salud. |
| DGIS
| Dirección General de Información en Salud, de la Secretaría de Salud. |
| DGTI
| Dirección General de Tecnologías de la Información, de la Secretaría de Salud. |
| ENTIDADES
FEDERATIVAS
| Los Estados de la República Mexicana y el Distrito Federal. |
| HL7
| Health Level Seven por su nombre en inglés. Organización internacional que desarrolla y publica estándares de comunicación entre sistemas clínicos. |
| INFORMACION BASICA
| Información mínima en Materia de Salud, misma que se encuentra conformada, en forma enunciativa y no limitativa por: a) El nombre completo, edad, sexo, domicilio, así como el historial clínico, hospitalario e información de última cita de urgencias, respecto de los BENEFICIARIOS; y, b) La infraestructura con que se cuenta en atención médica y hospitalaria, así como la capacidad instalada para la prestación de los servicios médicos a nivel nacional. |
| MANUAL
| Manual de Operación del Sistema Nacional de Información Básica en Materia de Salud, que define las responsabilidades, funciones, reglas y actividades que se deberán llevar a cabo de conformidad con el ACUERDO. |
| PADRONES
| Las listas, registros y/o bases de datos de BENEFICIARIOS que hayan creado, administren, operen y/o tengan a su cargo las DEPENDENCIAS Y ENTIDADES, con respecto a programas y/o acciones de la Administración Pública Federal en la prestación de servicios de salud. |
| PARTICIPANTES
| Las DEPENDENCIAS Y ENTIDADES de la Administración Pública Federal que presten servicios de salud, así como las ENTIDADES FEDERATIVAS y/o Municipios que, en su caso, se adhieran al ACUERDO, en los términos de los convenios que al efecto se celebren, de conformidad con lo dispuesto por el ACUERDO, el MANUAL y demás disposiciones jurídicas aplicables. |
| PATIENT
ADMINISTRATION
| Administración de Pacientes por su nombre en inglés. Dominio del estándar de mensajería HL7 V3 que define requisitos y especificaciones para apoyar la interoperabilidad entre sistemas con respecto a los registros clínicos y administrativos de pacientes. |
| PGS
| Padrón General de Salud. El cual se integra con la INFORMACION BASICA de los BENEFICIARIOS que se encuentra en los archivos y/o base de datos de las instituciones que prestan servicios de salud de la Administración Pública Federal. |
| PLATAFORMA
TECNOLOGICA
| Conjunto de protocolos, estándares y componentes que sirven para intercambiar datos entre sistemas o aplicaciones, con independencia del lenguaje de programación o plataforma en la que fueron desarrollados y operan. |
| R-MIM
| Refined Message Information Model por su nombre en inglés. Modelo de Información de mensaje refinado. |
| RENAPO
| Registro Nacional de Población e Identificación personal. |
| RIM
| Reference Information Model por su nombre en inglés. Modelo de información de Referencia que contiene las Clases especificadas por HL7 para el área de salud. |
| RUP
| Rational Unified Process por su nombre en inglés. Proceso de desarrollo de software que junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. |
| SECRETARIA
| Secretaría de Salud, de la Administración Pública Federal, en su carácter de Coordinadora del Sistema Nacional de Salud. |
| SNIBMS
| Sistema Nacional de Información Básica en Materia de Salud, de conformidad con lo señalado por los artículos 5, 6 y 7 fracción X de la Ley General de Salud en vigor, así como por el ACUERDO por el que se establece el Sistema Nacional de Información Básica en Materia de Salud publicado en el Diario Oficial de la Federación el 5 de septiembre de 2012. |
| SNS
| Sistema Nacional de Salud |
| UML
| Unified Modeling Lenguage por su nombre en inglés. Lenguaje para modelar la arquitectura de los componentes (visión estática) y de los procesos (visión dinámica) de un sistema y/o organización. |
| XML
| Extensible Markup Language. Lenguaje de marcado utilizado por HL7 v3. |
1.1. Presentación
El C. Secretario de Salud expidió el ACUERDO por el que se establece el SNIBMS, considerando la necesidad de contar con un sistema que permita una integración más eficiente y eficaz de la información en materia de salud de las DEPENDENCIAS Y ENTIDADES de la Administración Pública Federal que presten servicios de salud, así como las ENTIDADES FEDERATIVAS y/o Municipios que, en su caso, se adhieran al ACUERDO.
El ACUERDO y el MANUAL contribuyen con el SNS a propiciar una adecuada participación de las DEPENDENCIAS Y ENTIDADES que presten servicios de salud, a efecto de que la universalidad en la prestación de los servicios de salud sea sustentable. En este sentido, se requiere el intercambio de servicios entre las distintas instituciones que integran el SNS y para conseguir esto último es requisito indispensable contar con el intercambio de información. Por lo tanto el ACUERDO y su MANUAL son instrumentos para observancia y aplicación a las instituciones que prestan servicios de salud en la Administración Pública
Federal.
Por lo anterior, contar con información de calidad con la debida oportunidad por parte de las instituciones públicas que prestan servicios de salud en el país, facilitará la instrumentación, ejecución, supervisión y evaluación de políticas públicas en beneficio de la población.
1.2. Marco Jurídico
Artículos 39 de la Ley Orgánica de la Administración Pública Federal; 4o. de la Ley Federal de Procedimiento Administrativo; 5o., 6o., 7o., 104, 105, 106, 107 y 109 BIS de la Ley General de Salud y 7, fracción XVI, 16 y 24 del Reglamento Interior de la Secretaría de Salud, así como por lo señalado en el Acuerdo por el que se establece el Sistema Nacional de Información Básica en Materia de Salud.
1.3. Objetivo
De acuerdo con lo establecido por el artículo 3 del ACUERDO, los PARTICIPANTES entregarán a la DGIS la INFORMACION BASICA para conformar el SNIBMS y todas ellas tendrán acceso para usar y aprovechar esa INFORMACION BASICA, en términos de este MANUAL.
1.4. Responsabilidades
Las facultades de la SECRETARIA referentes al MANUAL, incluyendo su interpretación serán ejercidas por la DGIS, conforme lo establece el ACUERDO.
La DGTI y la CNPSS, los cuales forman parte de la SECRETARIA, permitirán a la DGIS usar su Infraestructura Tecnológica en lo que se refiere a la ejecución del ACUERDO, de este MANUAL y particularmente del PGS; en ese sentido facilitarán a la propia DGIS todo lo necesario a fin de que ésta use, explote y administre la información contenida en el PGS, de conformidad con lo señalado en el ACUERDO.
El presente MANUAL detalla las responsabilidades que corresponden a cada una de las unidades administrativas, Entidades o Dependencias, de conformidad con el ACUERDO.
En el supuesto de que los PARTICIPANTES responsables de proporcionar e intercambiar la INFORMACION BASICA acrediten y justifiquen que no se encuentran en capacidad de hacerlo, la DGIS, previo el dictamen correspondiente, podrá establecer un plazo distinto para la entrega de la información correspondiente.
| 2. Procesos de Administración y Operación del PGS |
2.1 Políticas de Administración del PGS
De acuerdo a lo establecido en el artículo 4, fracciones IX y X del ACUERDO, en este MANUAL a continuación se definen los procedimientos y mecanismos necesarios para la captación, actualización e integración de datos en las diversas fuentes de INFORMACION BASICA que proporcionen los PARTICIPANTES.
La primer iniciativa a implementar como parte del SNIBMS es el proyecto denominado PGS, el cual estará integrado con información concerniente a personas físicas, identificadas o identificables y por lo tanto, se trata de un sistema de datos personales, en tanto que constituye un conjunto ordenado de datos personales que están en posesión de los PARTICIPANTES que forman parte del SNS, con independencia de su forma de acceso, creación, almacenamiento u organización; en consecuencia, su diseño, integración, administración y explotación, se ajusta a la normatividad vigente en esa materia.
El PGS será de tipo nominal y contendrá, al menos, los siguientes datos:
1. CURP.
2. Nombre.
3. Primer Apellido.
4. Segundo Apellido, en caso de contarse con él.
5. Fecha de nacimiento.
6. Entidad federativa de nacimiento.
7. Sexo.
8. Nacionalidad, en caso de conocerla.
9. Folio o número de identificación con el que los PARTICIPANTES identifican al beneficiario.
10. Localidad.
11. Municipio.
12. Entidad Federativa de residencia.
13. Tipo de beneficiario.
14. Clave de la Dependencia.
15. Clave del programa de salud.
La integración del PGS, está basada en el modelo "Contenedor de Información" en capas, que garantiza la calidad, integridad y gobernabilidad de la información.
Será responsabilidad de cada una de las partes la validación de la CURP de cada BENEFICIARIO con el RENAPO de la Secretaría de Gobernación, previo a su envío al PGS. En esta etapa del PGS no se integrarán derechohabientes sin una CURP previamente validada.
A continuación se muestra el diagrama conceptual de la solución tecnológica:
Descripción de las diferentes capas:
- Interfaces de Comunicación.
Servicios para la recepción de información para su carga al PGS y entrega de información de control y consulta para los usuarios autorizados, es decir, que cumplan con las reglas y políticas de seguridad.
- Integración de Información.
En esta capa residen los procesos de integración y de extracción de información. Los procesos de integración son los encargados de validar las reglas de negocio, para permitir la carga de información al padrón y la generación de cifras de control de la información procesada. Los procesos de extracción son los encargados de generar reportes o archivos con la información de los reportes y/o entregas de información permitidas por la capa normativa.
- Calidad de Información.
Procesos para validar la limpieza, integridad y homologación de la información.
- Gestión de Identidad.
Procesos para la administración de identidades, basados en una primera etapa en la CURP.
- Capa Normativa.
Reglas y políticas de seguridad para el acceso y consulta de la información contenida en el PGS.
2.2 Políticas para la Administración de la Información
2.2.1. Mecanismos de consulta
Para consultar la información contenida en el PGS se cuenta con los siguientes mecanismos.
2.2.1.1. Aplicación web
La aplicación web del PGS brindará diferentes consultas de la información contenida. Estas consultas se listan a continuación.
- BENEFICIARIOS vigentes.- Presentará el número de BENEFICIARIOS vigentes al mes actual, por cada PARTICIPANTE.
- Terminaciones de vigencia.- Presentará el número de BENEFICIARIOS no vigentes al mes actual por cada PARTICIPANTE.
- BENEFICIARIOS vigentes existentes en más de un PARTICIPANTE (Vigentes Concurrentes).- Presentará el número de BENEFICIARIOS vigentes concurrentes (BENEFICIARIOS registrados en más de un PARTICIPANTE), al mes actual, para cada combinación posible de los PARTICIPANTES.
- Histórico de BENEFICIARIOS por PARTICIPANTE.- Presentará el número de BENEFICIARIOS vigentes, no vigentes y totales, por cada mes en el periodo de tiempo especificado por el usuario.
- Histórico de movimientos.- Presentará el número de movimientos de alta, reinicio y terminación relacionados reportados por cada PARTICIPANTE, para cada mes en el periodo de tiempo especificado por el usuario.
La DGIS autorizará y asignará los usuarios de acuerdo al apartado "Generación de usuarios para la aplicación web".
2.2.1.2. Información Estadística
De acuerdo a lo establecido en el artículo 4 del ACUERDO, la administración y operación del SNIBMS quedará a cargo de la SECRETARIA, por conducto de la DGIS, quien será la encargada de utilizar herramientas informáticas de procesamiento de datos e inteligencia de negocio para generar la información estadística que el SNS requiera del SNIBMS respetando siempre las disposiciones jurídicas aplicables en materia de protección de datos personales y transparencia.
2.2.2. Procedimientos de autorización
2.2.2.1. Generación de usuarios para la aplicación web
Para obtener un usuario con privilegios para acceder a las pantallas de consulta que existirán en la aplicación web del PGS, se debe llevar a cabo el siguiente procedimiento:
1. El solicitante deberá requerir la generación del nuevo usuario a la DGIS mediante un oficio con los siguientes datos:
- Fecha de solicitud.
- Clave y nombre de la ENTIDAD O DEPENDENCIA solicitante.
- Nombre completo, puesto y datos de contacto de la persona a la que se asignará el usuario.
- Consultas a las que se solicita el acceso.
- Nombre y firma del Titular de la Unidad Administrativa de adscripción del usuario.
2. La DGIS considerará la solicitud, observando en todo momento las disposiciones jurídicas aplicables.
3. En caso de ser autorizado el usuario solicitado, la DGIS a través de la DGTI llevará a cabo las actividades necesarias para crear el usuario autorizado.
4. La DGIS hará saber mediante oficio a la Entidad solicitante la resolución del requerimiento y en su caso se le harán llegar el usuario y contraseña para ingresar a la aplicación Web. Sólo se podrá otorgar un usuario por PARTICIPANTE, salvo que por una situación fundada y motivada, a juicio de la DGIS, amerite otro usuario.
2.2.2.2. Baja de usuario para la aplicación web
Para deshabilitar a un usuario existente en la aplicación web del PGS, se debe llevar a cabo el siguiente procedimiento:
1. La Entidad o Dependencia deberá solicitar a la DGIS, la baja de un usuario existente en la aplicación web del PGS. Esta solicitud deberá entregarse mediante un oficio con los siguientes datos:
- Fecha de solicitud.
- Clave y nombre de la Entidad o Dependencia solicitante.
- Nombre completo, puesto y datos de contacto de la persona que tiene asignado el usuario existente.
- Descripción del motivo por la que se solicita la baja del usuario.
- Nombre y firma del Titular de la Entidad o Dependencia.
2. La DGIS considerará la solicitud, observando en todo momento las disposiciones jurídicas aplicables.
3. En caso de ser autorizada la baja del usuario, la DGIS a través de la DGTI llevará a cabo las actividades necesarias para dar de baja el usuario.
4. La DGIS notificará al solicitante mediante un oficio que el usuario ha sido deshabilitado.
2.2.3. Entrega de información
2.2.3.1. Periodicidad de envíos
Los periodos para la entrega de información correspondiente a nuevos BENEFICIARIOS y actualización de vigencias, se deberá realizar mensualmente en el transcurso de los primeros quince días hábiles del mes posterior al que corresponde la información y apegándose a los procesos definidos para este fin, en el apartado "Procesos de Envío y Recepción de Información" del presente documento.
El primer envío de información lo realizará cada usuario en los términos y plazos estipulados por el ACUERDO y convenios que para el efecto se celebren. Para el caso en el que para la carga inicial de información los volúmenes de información que se estén manejando superen la capacidad de procesamiento de la aplicación web, la entrega de la información se hará por única ocasión en medios electrónicos físicos. Los envíos posteriores de información serán mensuales durante los primeros quince días hábiles del mes, a través de la aplicación del PGS, siendo de forma incremental incluyendo las modificaciones con respecto a envíos anteriores.
2.2.4. Respaldo de los sistemas y base de datos
El respaldo de información del PGS se basa en lo establecido en el ACUERDO, artículo 6 fracción II que especifica que para garantizar la calidad, integración y actualización de la INFORMACION BASICA, las DEPENDENCIAS Y ENTIDADES deberán llevar a cabo acciones de mantenimiento, respaldo y depuración periódica de la INFORMACION BASICA que entreguen a la DGIS, bajo procedimientos que garanticen su confiabilidad, integridad, seguridad y vigencia, este proceso se hará a través de la DGTI de acuerdo con lo establecido en el apartado "Responsabilidades" y Artículo 4 fracciones VI, VII y VIII del ACUERDO, quien será la responsable de implementar la política de respaldos.
2.2.5. Administración de versiones
Con base en lo establecido en el Artículo 4 fracciones VI, VII y VIII del ACUERDO, la administración de versiones de los aplicativos desarrollados para el PGS será realizada por la DGTI; dichas versiones de código fuente serán resguardadas en un repositorio de código en la infraestructura que para estos fines haya sido asignada por la DGIS.
2.2.6. Administración de la base de datos del PGS
De acuerdo a lo establecido en el artículo 4 fracciones VI, VII y VIII la DGTI será la responsable de instrumentar y administrar la PLATAFORMA TECNOLOGICA que reciba la información objeto del ACUERDO que garantice su intercambio, así como la encargada de su seguridad y resguardo.
Por lo que concierne a la administración de base de datos, se debe llevar a cabo la instalación del software del manejador de base de datos, la configuración de parámetros para su adecuado funcionamiento, la creación de usuarios y privilegios, la asignación de espacio físico y lógico, la implementación de la política de respaldos, la restauración de información en caso de falla y de su monitoreo. Dicha administración estará a cargo de la DGTI.
2.2.7. Administración de certificados
La DGIS a través de DGTI asignará a cada PARTICIPANTE un certificado digital único, para cifrar y firmar la información que se intercambie con el PGS.
Cada cuenta de usuario debe estar relacionada solamente con un PARTICIPANTE y no podrá utilizarse un certificado digital que esté relacionado con un PARTICIPANTE distinto.
El funcionario designado por cada PARTICIPANTE será responsable del uso adecuado del certificado asignado.
| 3. REGLAS DE NEGOCIO PARA LA INTEGRACION DE INFORMACION |
3.1 Marco Metodológico
Con la finalidad de integrar de forma ordenada el PGS, se desarrolló el proyecto de acuerdo a las mejores prácticas establecidas por las siguientes metodologías:
- Gestión de Proyectos.
- Desarrollo de aplicativos (UP â Unified Process).
- Definición de servicios de Centro de Datos.
- Administración de base de datos.
3.2 Modelo Conceptual
El modelo conceptual del PGS se presenta a continuación:
Los PARTICIPANTES cuentan con bases de datos locales en las que registran los datos propios de la gestión de sus procesos particulares y la información de sus BENEFICIARIOS, es por ello que cada PARTICIPANTE deberá generar la INFORMACION BASICA de sus BENEFICIARIOS y la vigencia de derechos, insumo principal del PGS.
A través de mecanismos y herramientas de integración, se concentrará bajo reglas específicas, la información de los PARTICIPANTES para conformar el PGS, utilizando la CURP como llave principal para la identificación de los BENEFICIARIOS.
3.3 Integración de información
Estas reglas definen la información que contendrá el PGS, la cual contempla los datos generales de los BENEFICIARIOS, la información relacionada con la vigencia de derechos, definiendo el formato y protocolo de transmisión.
3.3.1. Tipo de información
La información enviada debe apegarse a las siguientes premisas:
a. El ingreso de registros al PGS se hará a partir de la CURP.
b. Debe enviarse información solamente de aquellos BENEFICIARIOS cuya CURP se encuentre validada por RENAPO. Será responsabilidad de cada PARTICIPANTE asegurar este hecho.
c. Sólo se aceptarán registros con información completa en cada uno de los campos obligatorios y de acuerdo a las características definidas adelante.
3.3.2. Información solicitada
Para el proceso de envío de información de BENEFICIARIOS al PGS, los PARTICIPANTES prepararán la información de cada programa de los BENEFICIARIOS con CURP validada por RENAPO y que se encuentren vigentes al momento del corte, conforme a las especificaciones de los campos que se describen a continuación.
3.3.3. Alta de BENEFICIARIOS
Cada registro de BENEFICIARIO debe contener los campos que se muestran a continuación. Cada campo debe apegarse a las reglas indicadas.
| No
.
| Nombre
| Tipo
| Longitud
| Característica
| Descripción
|
| 1
| CURP | Alfanumérico
| 18
| Obligatorio
| Clave Unica de Registro de Población validada por RENAPO. |
| 2
| NOMBRE | Alfanumérico
| 50
| Obligatorio
| Los apellidos y nombres: - No podrán exceder de 50 posiciones para cada campo. - Se deben evitar cualquier tipo de abreviaturas en un apellido o nombre compuesto. - La información deberá entregarse en mayúsculas. - Como caracteres especiales solamente se deberán enviar vocales mayúsculas con acento o con diéresis y apóstrofes. |
| 3
| PRIMERAPELLIDO | Alfanumérico
| 50
| Obligatorio
|
| 4
| SEGUNDOAPELLIDO | Alfanumérico
| 50
| Opcional
|
| 5
| FECNAC | Fecha
| 8
| Obligatorio
| La fecha de nacimiento debe tener un formato de 8 posiciones numéricas, asignando como se describe a continuación: - Cuatro posiciones para el año. - Dos posiciones para el mes (del 01 al 12). - Dos posiciones para el día (del 01 al 31). Ejemplo: "16 de Junio del 2000" deberá formarse de la siguiente forma: "20000616". |
| 6
| EDONAC | Alfanumérico
| 2
| Obligatorio
| El estado de nacimiento conforme al catálogo de ENTIDADES FEDERATIVAS del INEGI. A dicho catálogo se le agregan las siguientes opciones: - En caso de que haya nacido en el extranjero se agrega la clave "NE" (Nacido en el Extranjero). - En caso de que sea mexicano y se desconoce el estado de nacimiento del BENEFICIARIO, se agrega la clave "00" (No disponible). |
| 7
| SEXO | Alfanumérico
| 1
| Obligatorio
| Clave del sexo, conforme al catálogo del RENAPO. Valores válidos: - "H" para hombre - "M" para mujer |
| 8
| NACORIGEN | Alfanumérico
| 3
| Obligatorio
| Nacionalidad de origen conforme al Catálogo de RENAPO. A dicho catálogo se le agregan las siguientes opciones: - En caso de que sea extranjero, pero se desconoce la nacionalidad específica, se agrega la clave "NEE" (Nacido en el Extranjero). - Cuando se desconoce la nacionalidad del BENEFICIARIO, se agrega la clave "NND" (Nacionalidad No Disponible). |
| 9
| FOLIOPROGRAMA | Alfanumérico
| 18
| Obligatorio
| Folio o número con el que cada PARTICIPANTE identifica internamente al BENEFICIARIO en un programa (RFC, NSS, Folio de productor, entre otros). |
| 10
| CVEDEPENDENCIA | Alfanumérico
| 3
| Obligatorio
| Clave de la Dependencia encargada del programa. Cada Entidad o Dependencia participante deberá indicar a la DGIS mediante oficio la clave que tiene asignada previo al primer envío de información. |
| 11
| CVEPROGRAMA | Alfanumérico
| 20
| Obligatorio
| Clave del programa al que está inscrito el BENEFICIARIO. Cada Entidad o Dependencia participante deberá indicar a la DGIS mediante oficio la clave asignada a cada uno de los programas que le corresponda, previo al primer envío de información. En caso de que en la Entidad o Dependencia no existan Programas, se debe capturar "ND" (No Disponible). |
| 12
| EDO | Alfanumérico
| 2
| Obligatorio
| Clave de la Entidad federativa de residencia, conforme al catálogo del INEGI. A dicho catálogo se le agrega la siguiente opción: - En caso de no conocer la Entidad federativa de residencia, se agrega la clave "00". |
| 13
| MUN | Alfanumérico
| 3
| Obligatorio
| Clave del municipio de residencia, conforme al catálogo del INEGI. A dicho catálogo se le agrega la siguiente opción: - En caso de no conocer el municipio de residencia, se agrega la clave "000". |
| 14
| LOC | Alfanumérico
| 4
| Obligatorio
| Clave de la localidad de residencia, conforme al catálogo del INEGI. A dicho catálogo se le agrega la siguiente opción: - En caso de no conocer la localidad de residencia, se agrega la clave "0000". |
| 15
| TIPOBENEFICIARIO | Alfanumérico
| 2
| Obligatorio
| El catálogo de tipos de BENEFICIARIO, es el siguiente: - "01" - Trabajador/Asegurado. - "02" - Beneficiario del Seguro Popular. - "03" - Familiar. - "04" - Pensionado. |
3.4 Procesos de Integración de Información de BENEFICIARIOS
Aquí se describen las reglas y procedimientos que deben seguir los PARTICIPANTES, para el envío inicial de información de sus BENEFICIARIOS vigentes, así como el posterior envío mensual de nuevos BENEFICIARIOS y la actualización de la vigencia de derechos de los BENEFICIARIOS.
3.4.1. Objetivo
⢠Integrar, actualizar y sincronizar la información general y de vigencia de derechos de los BENEFICIARIOS de los PARTICIPANTES y el PGS.
⢠Definir un proceso automatizado y sistemático para la aplicación del registro y actualizaciones de información provenientes de los PARTICIPANTES, a la base de datos del PGS.
⢠Definir el protocolo de envío de la información al PGS.
⢠Definir el protocolo de acuse de recibo que el PGS generará, para confirmar la recepción de la información enviada por los PARTICIPANTES.
⢠Describir las reglas de negocio para integrar a nuevos BENEFICIARIOS de los PARTICIPANTES al PGS.
⢠Describir las reglas de negocio para la actualización de la vigencia de derechos de los BENEFICIARIOS en el PGS.
3.4.2. Primer envío de información
3.4.2.1. Actores
Los PARTICIPANTES que reporten información al PGS.
3.4.2.2. Descripción
- Los PARTICIPANTES deben entregar un archivo con la información inicial de sus BENEFICIARIOS vigentes.
- Si el archivo no se ajusta al formato o tiene problemas de integridad de información, se genera un aviso de rechazo de la información. El mensaje puede consultarse en la aplicación web del PGS.
- Si el archivo de carga inicial no reporta problemas en los procesos anteriormente mencionados, se ejecuta el proceso de integración de información en el PGS.
El resumen de resultados y el reporte de inconsistencias pueden consultarse en la aplicación web que el
PGS dispondrá para estos fines. El medio para notificar las inconsistencias se define en la sección "Definición del proceso de envío y recepción de información".
3.4.2.3. Datos
La información que envíen los PARTICIPANTES al PGS se debe ajustar conforme a las especificaciones de los campos descritos en la sección 3.3.3 del presente documento.
3.4.2.4. Reglas
- El archivo de BENEFICIARIOS, proporcionado por los PARTICIPANTES no debe contener registros duplicados.
- Todos los BENEFICIARIOS reportados en el primer archivo, el denominado T0, serán marcados como vigentes dentro del PGS.
3.4.2.5. Formato de nombre de archivo
Cada PARTICIPANTE identificará el archivo de carga inicial proporcionado, de tal manera que no exista posibilidad de confusión o duplicidad, para lo cual la estructura del nombre de archivo será de la siguiente manera:
PGS_[CLAVEDELADEPENDENCIA]_[FECHADEVIGENCIA]_T0.XML
Dónde:
PGS: Etiqueta para identificar que son archivos del PGS.
CLAVEDELADEPENDENCIA: Clave de la Dependencia.
FECHADEVIGENCIA: En formato de 6 posiciones numéricas: [AAAAMM], que indica el año y mes de vigencia, al que corresponde el archivo.
- Tipo de archivo: Conjunto de caracteres ISO 8859-1.
- Formato: XML.
3.4.3. Integración de nuevos registros de BENEFICIARIOS
3.4.3.1. Actores
Los PARTICIPANTES que reporten información al PGS.
3.4.3.2. Descripción
- Los archivos subsecuentes a la carga inicial se enviarán utilizando la aplicación del PGS.
- Estos archivos contendrán el conjunto de los BENEFICIARIOS cuya vigencia inició después de la fecha de corte previa y hasta la fecha de corte actual inclusive.
- A través de la aplicación de escritorio del PGS, se debe verificar la integridad y formato del archivo de BENEFICIARIOS.
- Una vez terminado el proceso de verificación anterior, se presenta un resumen de resultados que contiene:
o La cantidad total de registros procesados en el archivo de BENEFICIARIOS.
o La cantidad de registros procesados que no presentan inconsistencias y almacenadas en el archivo a ser enviado al PGS.
o La cantidad de registros que presentan inconsistencias y almacenados en el archivo de inconsistencias del proceso actual.
o Trayectoria del archivo generado de registros CORRECTOS.
o Trayectoria del archivo generado de registros INCONSISTENTES.
- El usuario decide si se realiza el envío del archivo que contiene los registros correctos al PGS.
- El PGS recibe el archivo de BENEFICIARIOS, generando un acuse de recibo que es enviado al PARTICIPANTE correspondiente.
- Se ejecuta el proceso de integración al PGS.
- Cada PARTICIPANTE utilizará la aplicación web para consultar el estatus de atención del archivo y, en su momento, el resultado del proceso de integración.
3.4.3.3. Datos
Se debe enviar la información especificada en el numeral 3.3.3 del presente documento.
3.4.3.4. Reglas
- El archivo de BENEFICIARIOS enviado por cada PARTICIPANTE no debe contener registros duplicados.
- Para que un nuevo BENEFICIARIO de un PARTICIPANTE quede registrado en el PGS mediante este proceso, su CURP no debe estar registrada previamente para ese PARTICIPANTE. Si la CURP en cuestión, ya se encuentra registrada, se reportará la siguiente inconsistencia:
o La CURP ya se encuentra registrada en el PGS, con la misma clave de Dependencia, por lo que este registro no puede ser ingresado como nuevo BENEFICIARIO.
- En caso de que la CURP ya se encuentre registrada en el PGS, con una clave de Dependencia distinta, se registrará solamente la vigencia de ese BENEFICIARIO en la Dependencia que corresponda.
3.4.3.5. Formato de nombre de archivo
Cada PARTICIPANTE identificará el archivo proporcionado, de tal manera que no exista posibilidad de confusión o duplicidad, para lo cual la estructura del nombre de archivo será de la siguiente manera:
PGS_[CLAVEDELADEPENDENCIA]_[FECHADEVIGENCIA]_TN.XML
Dónde:
PGS: Etiqueta para identificar que son archivos del PGS.
CLAVEDELADEPENDENCIA: Clave de la Dependencia.
FECHADEVIGENCIA: En formato de 6 posiciones numéricas: [AAAAMM], que indica el año y mes de vigencia, al que corresponde el archivo.
- Tipo de archivo: Conjunto de caracteres ISO 8859-1.
- Formato: XML.
3.4.4. Actualización de información de vigencia de derechos
3.4.4.1. Actores
Los PARTICIPANTES que reporten información al PGS.
3.4.4.2. Descripción
- Los archivos subsecuentes a la carga inicial se enviarán mensualmente durante los primeros quince días hábiles del mes, utilizando la aplicación de escritorio del PGS. Estos archivos contendrán el conjunto de los BENEFICIARIOS cuya vigencia fue renovada o terminada después de la fecha de corte previa y hasta la fecha de corte actual inclusive.
- La aplicación de escritorio del PGS verificará la integridad y formato del archivo de actualizaciones.
- Una vez terminado el proceso de verificación anterior, se presenta un resumen de resultados que contiene:
o La cantidad total de registros procesados en el archivo de BENEFICIARIOS.
o La cantidad de registros procesados que no presentan inconsistencias y almacenadas en el archivo a ser enviado al PGS.
o La cantidad de registros que presentan inconsistencias y almacenados en el archivo de inconsistencias del proceso actual.
o Trayectoria del archivo generado de registros CORRECTOS.
o Trayectoria del archivo generado de registros INCONSISTENTES.
- El usuario debe decidir si se realiza el envío del archivo que contiene los registros correctos al PGS.
- El PGS recibe el archivo de BENEFICIARIOS, generando un acuse de recibo electrónico, en el momento que termina su envío, mediante la aplicación de escritorio del PGS y valida su correcta recepción.
- Se ejecuta el proceso de integración al PGS.
- Cada PARTICIPANTE debe utilizar la aplicación web para consultar el estatus de atención del archivo y, en su momento, el resultado del proceso de integración.
3.4.4.3. Datos
La información que envíe cada PARTICIPANTE al PGS, se debe ajustar a la siguiente especificación:
| No.
| Nombre
| Tipo
| Longitud
| Característica
| |
| 1
| CURP | Alfanumérico
| 18
| Obligatorio
| Clave Unica de Registro de Población validada por RENAPO. |
| 2
| FOLIOPROGRAMA | Alfanumérico
| 18
| Obligatorio
| Folio o número con el que cada PARTICIPANTE identifica internamente al BENEFICIARIO en un programa. (RFC, NSS, Folio de productor, entre otros). |
| 3
| TIPO_OPERACION | Alfabético
| 1
| Obligatorio
| Clave que define el tipo de actualización a realizar. Los valores permitidos son los siguientes: - "T" indica una operación de terminación de la vigencia de derechos. - "R" indica una operación de reactivación de la vigencia de derechos. |
| 4
| TIPOBENEFICIARIO | Alfanumérico
| 2
| Obligatorio
| El catálogo de tipos de BENEFICIARIO es el siguiente: - "01" - Trabajador/Asegurado. - "02" - Beneficiario del Seguro Popular. - "03" - Familiar. - "04" - Pensionado. |
| 5
| CVEDEPENDENCIA | Alfanumérico
| 3
| Obligatorio
| Clave de la Dependencia encargada del programa. Cada PARTICIPANTE deberá indicar a la DGIS mediante oficio, la clave que tiene asignada previo al primer envío de información. |
| 6
| CVEPROGRAMA | Alfanumérico
| 20
| Obligatorio
| Clave del programa al que está inscrito el BENEFICIARIO. Cada PARTICIPANTE deberá indicar a la DGIS mediante oficio, la clave asignada a cada uno de los programas que le corresponda, previo al primer envío de información. En caso de que en la Entidad o Dependencia no existan Programas, se debe capturar "ND" (No Disponible). |
3.4.4.4. Reglas
Para que la actualización de vigencia de derechos de un BENEFICIARIO quede registrada en el PGS, se deben cumplir las siguientes reglas:
- La combinación CURP y clave de Dependencia asociada, deben estar registradas previamente en el PGS (lo cual implica que el envío de nuevos BENEFICIARIOS se hará en un archivo separado cada
mes, conforme a lo descrito en el presente documento).
- Si el tipo de actualización es "T", el registro del BENEFICIARIO se marca como "vigencia de derechos terminada". Para estos casos, el registro debe estar registrado previamente en el padrón con un estatus de vigente o de reactivado.
- Si el tipo de actualización es "R", el registro del BENEFICIARIO se marca como "reactivación de vigencia" en sus derechos. Para estos casos, el registro debe estar registrado previamente en el padrón, con un estatus de vigencia como terminada.
- Todos los registros previamente registrados en el PGS, marcados como vigentes, mantendrán este estatus en tanto no sean modificados en algún procedimiento de actualización.
- En caso de no cumplir la regla anterior, se reportará alguna de las siguientes inconsistencias:
o CURP no localizada para la Dependencia que desea actualizar un registro.
o Solicitudes de reactivación de vigencia no procedentes y la causa.
o Solicitudes de terminación de vigencia no procedentes y la causa.
3.4.4.5. Formato del nombre de archivo
Cada PARTICIPANTE identificará su archivo de información, de tal manera que no exista posibilidad de confusión o duplicidad, para lo cual, la estructura del nombre de archivo será de la siguiente manera:
PGS_[CLAVEDELADEPENDENCIA]_[FECHADEVIGENCIA]_TA.XML
Dónde:
PGS: Etiqueta para identificar que son archivos del PGS.
CLAVEDELADEPENDENCIA: Clave de la Dependencia.
FECHADEVIGENCIA: En formato de 6 posiciones numéricas: [AAAAMM], que indica el año y mes de vigencia, al que corresponde el archivo.
- Tipo de archivo: Conjunto de caracteres ISO 8859-1.
- Formato: XML.
| 4. PROCESOS DE ENVIO Y RECEPCION DE INFORMACION |
La presente sección establece los estándares de envío y recepción de información desde/hacia el PGS. Para esto se emplean mecanismos basados en HL7; así mismo, se definen los lineamientos que deben ser considerados para el diseño y la implementación de los mensajes a utilizar durante la comunicación con el PGS.
4.1 Alcance
Definición de los procesos de envío y recepción de información referente a nuevos registros y actualización de vigencias.
4.2 Audiencia
Personal técnico de los diferentes PARTICIPANTES, con conocimiento de disciplinas como RUP, UML, XML y estructuras de datos, así como también deberán contar con sólido conocimiento de los estándares de HL7.
4.3 Definición del estándar para envío y recepción de información
4.3.1. Descripción
Con base en el modelo de intercambio de información clínica de HL7, los registros administrativos están contenidos en el modelo de información de referencia (RIM), el cual describe el conjunto de clases, atributos y las asociaciones de intercambio de información entre los registros administrativos y otras aplicaciones de atención médica.
4.3.2. Los mensajes de información XML
Los mensajes de información XML que se implementarán son los siguientes:
- Alta de Beneficiario.
- Actualización de vigencia de beneficiario.
- Inconsistencias de datos.
- Confirmación de recepción de archivo.
4.3.3. Descripción del protocolo de transferencia
La transferencia de la información de los BENEFICIARIOS de los diferentes PARTICIPANTES, se realizará mediante mensajería XML basada en el estándar HL7 v3.
4.3.3.1. Validación de esquema
Se deberán implementar los procesos sistemáticos para efectuar la validación de que el archivo XML entregado por cada PARTICIPANTE, se encuentre formado con el esquema definido. Se debe tomar en cuenta que el conjunto de caracteres definido para el archivo XML es el ISO 8859-1, por lo tanto, cualquier carácter que venga en el archivo y no se encuentre dentro de este conjunto, romperá el esquema XML y no pasará el proceso de validación. Para evitar esta situación, cuando se quieran enviar caracteres que no estén dentro del conjunto ISO 8859-1, se deberán codificar como se muestran algunos ejemplos a continuación:
o Ampersand (&) = "&".
o Abrir corchete angular (<) = "<".
o Cerrar corchete angular (>) = ">".
o Comilla recta (") = """.
o Apóstrofe (â) = "'".
4.4 Procedimiento de recepción de información del BENEFICIARIO y vigencia de derechos
A continuación se presenta el diagrama conceptual de la solución para llevar a cabo estas actividades:
En este apartado se detallan los servicios que deben implementarse y que serán utilizados de manera horizontal en la solución.
- Administración de Certificados.- Servicio que genera y administra un repositorio de certificados para los PARTICIPANTES que requieren intercambiar información con el PGS. (PKI, LDAP, entre otros).
- Administración de Usuarios.- Servicio para crear y modificar usuarios, que son asignados a los PARTICIPANTES y provee servicios de seguridad para la aplicación.
- Administración de Procesos.- Servicio que controla la recepción de información, proceso de integración, generación de archivos con inconsistencias y publicación de resultados.
4.4.1. Recepción de información de nuevos BENEFICIARIOS
A continuación se ilustra el proceso para enviar el archivo con la información de nuevos BENEFICIARIOS, para su posterior integración al PGS:
4.4.2. Proceso para envío del archivo de nuevos BENEFICIARIOS
A continuación se describe paso a paso el proceso para el envío del archivo:
1. Generación del archivo con los mensajes HL7, que contienen la información de nuevos BENEFICIARIOS.
2. Si la aplicación se descargó anteriormente, debe ejecutar el acceso directo generado en el escritorio "Padrón General en Salud" y dirigirse al punto 11, en caso contrario continuar con los puntos siguientes.
3. Colocar el "KEYSTORE" proporcionado por la DGIS a través de la DGTI, en la siguiente ruta: %USERPROFILE%/PGS/LLAVE. En caso de no existir las carpetas indicadas, es necesario crearlas manualmente. NOTA: En caso de no existir el directorio y el "KEYSTORE" correspondiente, no podrá acceder a la aplicación web del PGS.
4. Acceder al sistema web con el certificado digital, usuario y contraseña asignados por la DGIS para el PGS.
5. El sistema validará el certificado, usuario y contraseña capturados. Cuando todos los elementos son correctos, se mostrará la pantalla principal del sistema.
6. Seleccionar la opción "Descargas" del menú principal.
7. El sistema mostrará un submenú con las opciones de "Descargar Aplicación" y "Esquemas XSD-HL7"
8. El usuario deberá descargar los esquemas de HL7, por única vez, y descomprimirlos manualmente en la siguiente ruta: %USERPROFILE%/PGS/SCHEMA. En caso de no existir las carpetas indicadas, es necesario crearlas manualmente.
9. El usuario deberá descargar la aplicación de escritorio seleccionando la opción "Descargar Aplicación".
10. Al terminar la descarga se ejecutará automáticamente la aplicación de escritorio, presentando la siguiente información para el inicio de sesión:
Usuario.
Contraseña.
11. El usuario deberá ingresar el usuario y contraseña correspondiente y seleccionar la opción de "Entrar".
12. El sistema mostrará una ventana emergente para ingresar la contraseña del "KEYSTORE" y seleccionará aceptar para ingresar a la aplicación.
13. El sistema presentará las opciones de "Nuevos BENEFICIARIOS" y "Archivo de Actualizaciones".
14. El usuario deberá oprimir el botón de "Nuevos BENEFICIARIOS".
15. El usuario seleccionará el botón de "Validar Archivo" y después presionará el botón de "Seleccionar archivo".
16. El sistema presentará una ventana de selección de archivo para que se proporcione el archivo que desea sea validado.
17. La aplicación de escritorio valida que el nombre del archivo seleccionado cumpla con el formato definido en este documento y que el mes y año correspondan con lo esperado por la aplicación central.
18. La aplicación tomará el archivo y validará la estructura del XML y la integridad de la información, con base en las reglas definidas en este documento para nuevos BENEFICIARIOS.
19. Al terminar el proceso, la aplicación mostrará la siguiente información:
Número de registros leídos en el archivo a procesar.
Número de registros que cumplen con la integridad de la información.
Número de registros que no cumplen con la integridad de la información. En el caso de que existan registros en este caso, se tendrá acceso a ellos mediante el archivo que genere la aplicación.
Trayectoria del archivo generado con los registros correctos.
Trayectoria del archivo generado con los registros con incidencias.
20. El usuario selecciona la opción de "Enviar Archivo".
21. El sistema mostrará una ventana emergente de confirmación.
22. La aplicación comprime y cifra el archivo, con el certificado digital que se encuentra en el KEYSTORE, en la siguiente ruta: %USERPROFILE%/PGS/LLAVE.
23. La aplicación valida si existe conexión con el servidor del PGS vía el protocolo FTP. En caso de no existir conexión por este medio, se presentará un mensaje indicando que no existe conexión y solicita se intente nuevamente, cuando esté restablecido el servicio de comunicación. En caso de que exista, la aplicación envía el archivo por este medio.
24. Al terminar la transmisión del archivo, la aplicación muestra un mensaje de "Exitoso" y el comprobante electrónico de envío de archivo.
25. El usuario selecciona la opción de salir de la aplicación.
26. Fin del proceso.
4.4.2.1. Diagrama de flujo del proceso
4.4.3. Proceso de integración de nuevos BENEFICIARIOS
El procesamiento del archivo enviado, es asíncrono, esto quiere decir que una vez que se reciba el archivo, éste será procesado de manera independiente al proceso de envío y recepción.
A continuación se describe el proceso que deberá llevar a cabo el sistema del PGS, para integrar a los nuevos BENEFICIARIOS recibidos:
1. El sistema toma el archivo recibido e integra a los nuevos BENEFICIARIOS en el PGS.
2. Al integrarlos se valida si el BENEFICIARIO existe registrado para el PARTICIPANTE emisor.
3. En caso de que NO exista previamente, el BENEFICIARIO se registra al padrón del PARTICIPANTE emisor.
4. En caso de existir previamente, se considera como una inconsistencia, por lo que no se integra al PGS.
5. El sistema genera un archivo con los registros que cumplen con estas características, para que los pueda validar el PARTICIPANTE que lo reportó.
6. El sistema actualiza el estatus del archivo procesado y publica el archivo con inconsistencias, en caso de existir.
4.4.3.1. Diagrama de flujo del proceso
4.4.4. Procesos para consulta de resultados â Alta de BENEFICIARIOS
El usuario de cada PARTICIPANTE, deberá acceder al sistema web al siguiente día hábil de haber realizado el envío del archivo, para consultar el resultado del proceso de integración de BENEFICIARIOS y en caso de existir, consultar las inconsistencias reportadas.
A continuación se detalla el proceso para llevar a cabo estas consultas:
1. Acceder al sistema web con el certificado digital, usuario y contraseña asignados.
2. El sistema mostrará la pantalla principal y se selecciona la opción de "Bitácora".
3. Se deberá ingresar uno o todos los criterios de búsqueda: PARTICIPANTE que envió el archivo, año y mes de envío, y número de ticket. Solamente el administrador podrá consultar archivos de todos los PARTICIPANTES. Cada PARTICIPANTE podrá consultar únicamente los archivos que ha enviado.
4. El sistema mostrará una lista con los archivos que cumplan los criterios de búsqueda configurados y presentará la siguiente información:
Número de Ticket: Código asignado a un archivo recibido exitosamente por el PGS.
Nombre de archivo: Nombre del archivo recibido.
Tipo de operación: Tipo de proceso aplicado al archivo. (Carga Inicial, Nuevos BENEFICIARIOS o Actualización de Vigencias).
Fecha de recepción: Fecha en que se recibió el archivo.
Fecha de proceso: Año y mes de proceso, al que corresponde el archivo recibido.
Recibidos: Número de registros procesados en el archivo.
Integrados: Número de registros integrados exitosamente al PGS.
No integrados: Número de registros que generaron una inconsistencia al momento de integrarlos y por lo tanto son rechazados.
En el caso de que existan registros no integrados, se presenta como liga desde la cual podrá descargarse un archivo CSV. La información que contiene este archivo por cada registro no integrado, es la siguiente:
CURP.- CURP del registro con la inconsistencia detectada.
Clave del Campo.- Indicará que es el campo "CURP".
Clave de la Inconsistencia.- Indicará que es la clave "INTEG".
Descripción de la Inconsistencia.- Indicará el mensaje "Error de integración al padrón".
No procesados: Información para el Administrador del Padrón, que indica el número de registros que no se procesaron correctamente durante la integración. En el caso de que existan registros no procesados, el administrador decidirá cuando sea necesario reprocesar el archivo.
Estatus Actual: Estatus del proceso de integración del archivo. (En Proceso, Terminado, Terminado con error).
Control de Procesos: Al usuario con perfil de "administrador del sistema", se le presentan dos opciones para el control de procesos, cuando sucede algún error al procesarse un archivo. Las opciones son las siguientes:
RB (Rollback de proceso).- Elimina los registros de control del archivo procesado del mes correspondiente.
LB â (Ejecuta Batch).- Ejecuta el proceso batch de integración manualmente para el mes y año del archivo deseado.
5. El usuario podrá validar en esta pantalla el resultado del proceso de integración, del mes correspondiente. En caso de existir inconsistencias reportadas, se podrá seleccionar la liga para descargar el archivo correspondiente. El sistema presentará una pantalla para que el usuario seleccione en qué lugar de su equipo de cómputo desea que se deposite el archivo seleccionado.
6. El usuario selecciona la opción de salir del sistema web.
4.4.4.1. Diagrama de flujo de proceso
4.4.5. Proceso de recepción de información para actualización de vigencias
A continuación se ilustra el proceso, para enviar el archivo con la información de actualizaciones de vigencias, para integrarlo al PGS:
A continuación se describe cada paso del proceso para el envío del archivo:
1. Generación del archivo con los mensajes HL7, que contienen la información de actualización de vigencias.
2. Si la aplicación se descargó anteriormente, debe ejecutar el acceso directo generado en el escritorio "Padrón General en Salud" y dirigirse al punto 11, en caso contrario favor de continuar con los puntos siguientes.
3. Colocar el "KEYSTORE" proporcionado por la DGIS a través de la DGTI del PGS, en la siguiente ruta: %USERPROFILE%/PGS/LLAVE. En caso de no existir las carpetas indicadas, es necesario crearlas manualmente. NOTA: En caso de no existir el directorio y el "KEYSTORE" correspondiente, no podrá acceder a la aplicación web del PGS.
4. Acceder al sistema web con el certificado digital, usuario y contraseña asignados.
5. El sistema validará el certificado, usuario y contraseña capturados. Cuando todos los elementos son correctos, se mostrará la pantalla principal del sistema.
6. Seleccionar la opción "Descargas" del menú principal.
7. El sistema mostrará un submenú con las opciones de "Descargar Aplicación" y "Esquemas XSD-HL7"
8. El usuario deberá descargar los esquemas de HL7, por única vez, y descomprimirlos manualmente en la siguiente ruta: %USERPROFILE%/PGS/SCHEMA. En caso de no existir las carpetas indicadas, es necesario crearlas manualmente.
9. El usuario deberá descargar la aplicación de escritorio seleccionando la opción "Descargar Aplicación".
10. Al terminar la descarga se ejecutará automáticamente la aplicación de escritorio, presentando la siguiente información para el inicio de sesión:
Usuario.
Contraseña.
11. El usuario deberá ingresar el Usuario y contraseña correspondiente y seleccionar la opción de "Entrar".
12. El sistema mostrará una ventana emergente para ingresar la contraseña del "KEYSTORE", seleccionar aceptar para ingresar a la aplicación.
13. El sistema presentará las opciones de "Nuevos BENEFICIARIOS" y "Archivo de Actualizaciones"
14. El usuario deberá oprimir el botón de "Archivo de Actualizaciones"
15. El usuario seleccionará el botón de validar archivo y presionará el botón de "Seleccionar archivo"
16. El sistema presentará una ventana de selección de archivo para que se seleccione el archivo que desea sea validado.
17. La aplicación de escritorio valida que el nombre del archivo seleccionado cumpla con el formato definido en este documento y que el mes y año correspondan con lo esperado por la aplicación central.
18. La aplicación tomará el archivo y validará la estructura del XML y la integridad de la información, con base en las reglas definidas en este documento para actualización de vigencias de BENEFICIARIOS.
19. Al terminar el proceso, la aplicación mostrará la siguiente información:
Número de registros leídos en el archivo a procesar.
Número de registros que cumplen con la integridad de la información.
Número de registros que no cumplen con la integridad de la información. En el caso de que existan registros en este caso, se tendrá acceso a ellos mediante el archivo que generé la aplicación.
Trayectoria del archivo generado con los registros correctos.
Trayectoria del archivo generado con los registros con incidencias.
20. El usuario selecciona la opción de "Enviar Archivo".
21. El sistema mostrará una ventana emergente de confirmación.
22. La aplicación comprime y cifra el archivo, con el certificado digital que se encuentra en el KEYSTORE, en la siguiente ruta: %USERPROFILE%/PGS/LLAVE.
23. La aplicación valida si existe conexión con el servidor del PGS vía el protocolo FTP. En caso de no existir conexión por este medio, se presentará un mensaje indicando que no existe conexión y solicita se intente nuevamente, cuando esté restablecido el servicio de comunicación. En caso de que exista, la aplicación envía el archivo por este medio.
24. Al terminar la transmisión del archivo, la aplicación muestra un mensaje de "Exitoso" y el comprobante electrónico de envío de archivo.
25. El usuario selecciona la opción de salir de la aplicación.
26. Fin del proceso.
4.4.5.1. Diagrama de flujo del proceso
4.4.6. Procesos de integración para Actualización de Vigencias
El procesamiento del archivo recibido, es asíncrono, esto quiere decir que una vez que se reciba el archivo, éste será procesado de manera independiente al proceso de envío y recepción. A continuación se describe cada paso del proceso para actualizar las vigencias de los BENEFICIARIOS registrados.
1. El sistema toma el archivo recibido y actualiza las vigencias en el PGS.
2. Al actualizar la vigencia, se valida que el BENEFICIARIO correspondiente exista registrado, para el PARTICIPANTE emisor.
3. En caso de que el BENEFICIARIO no esté registrado para el PARTICIPANTE emisor, se considera como una inconsistencia, por lo que no se realiza ninguna acción en el PGS.
4. El sistema genera un archivo con los registros que caen en estas características, para que los pueda validar el PARTICIPANTE que lo reportó.
5. El sistema actualiza el estatus del archivo procesado y publica el archivo con inconsistencias, en caso de existir.
4.4.6.1. Diagrama de flujo del proceso
4.4.7. Proceso para consulta de resultados â Actualización de vigencias
El usuario de cada PARTICIPANTE, deberá acceder al sistema web al día siguiente de haber realizado el envío del archivo, para consultar el resultado del proceso de actualización de vigencias y en caso de existir, consultar las inconsistencias reportadas.
A continuación se detalla el proceso para llevar a cabo estas consultas:
1. Acceder al sistema web con el certificado digital, usuario y contraseña asignados.
2. El sistema mostrará la pantalla principal y se selecciona la opción de "Bitácora".
3. Se deberá ingresar uno o todos los criterios de búsqueda: PARTICIPANTE que envió el archivo, año y mes de envío, y número de ticket. Solamente el administrador podrá consultar archivos de todos los PARTICIPANTES. Cada PARTICIPANTE podrá consultar únicamente los archivos que ha enviado.
4. El sistema mostrará una lista con los archivos que cumplan los criterios de búsqueda configurados y presentará la siguiente información:
Número de Ticket: Código asignado a un archivo recibido exitosamente por el PGS.
Nombre de archivo: Nombre del archivo recibido.
Tipo de operación: Tipo de proceso aplicado al archivo. (Carga Inicial, Nuevos BENEFICIARIOS o Actualización de Vigencias).
Fecha de recepción: Fecha en que se recibió el archivo.
Fecha de proceso: Año y mes de proceso, al que corresponde el archivo recibido.
Recibidos: Número de registros procesados en el archivo.
Integrados: Número de registros integrados exitosamente al PGS.
No integrados: Número de registros que generaron una inconsistencia al momento de integrarlos y por lo tanto son rechazados.
En el caso de que existan registros no integrados, se presenta como enlace de internet desde el cual podrá descargarse un archivo CSV. La información que contiene este archivo por cada registro no integrado, es la siguiente:
CURP.- CURP del registro con la inconsistencia detectada.
Clave del Campo.- Indicará que es el campo "CURP".
Clave de la Inconsistencia.- Indicará que es la clave "INTEG".
Descripción de la Inconsistencia.- Indicará el mensaje "Error de integración al padrón".
No procesados: Información para el Administrador del PGS, que indica el número de registros que no se procesaron correctamente durante la integración. En el caso de que existan registros no procesados, el administrador decidirá cuando sea necesario reprocesar el archivo.
Estatus Actual: Estatus del proceso de integración del archivo. (En Proceso, Terminado, Terminado con error).
Control de Procesos: Al usuario con perfil de "administrador del sistema", se le presentan dos opciones para el control de procesos, cuando sucede algún error al procesarse un archivo. Las opciones son las siguientes:
RB (Rollback de proceso).- Elimina los registros de control del archivo procesado del mes correspondiente.
LB â (Ejecuta Batch).- Ejecuta el proceso batch de integración manualmente para el mes y año del archivo deseado.
5. El usuario puede validar en esta pantalla el resultado del proceso de integración, del mes correspondiente. En caso de existir inconsistencias reportadas, se puede seleccionar la liga para descargar el archivo correspondiente. El sistema presentará una pantalla para que el usuario seleccione en qué lugar de su equipo de cómputo desea que se deposite el archivo seleccionado.
6. El usuario selecciona la opción de salir del sistema web.
4.4.7.1. Diagrama de flujo del proceso
4.5 Reporte de Inconsistencias
Existen dos tipos de inconsistencia que serán reportadas por el PGS:
- Inconsistencias de datos.
- Inconsistencias de integración.
4.5.1. Inconsistencias de datos
La respuesta de incidencias en el proceso de validación de la aplicación de escritorio del PGS, se
notificará en el contexto de HL7.
A continuación se presentan los campos que contiene el archivo que se generará, conteniendo cada uno de los registros que no cumplan con una o varias reglas de validación de datos:
| No.
| Nombre
| Tipo
| Longitud
| Característica
| Descripción
|
| 1 | CURP | Alfanumérico | 18
| Obligatorio | Cadena de caracteres del campo CURP del registro a reportar. |
| 2 | CAMPOINCON | Numérico | 2
| Obligatorio | Número de campo en el cual se encontró la inconsistencia. |
| 3 | DESCINCON | Alfabético | 13
| Obligatorio | Breve descripción de la incidencia detectada en el registro. |
El archivo de inconsistencias lo depositará la aplicación de escritorio en la siguiente ruta: %USERPROFILE%/PGS/INCONSISTENCIAS.
Este archivo lo generará la aplicación de escritorio del PGS, en el momento que se realice la validación y contendrá tantos nodos como número de inconsistencias por registro se encuentren.
4.5.2. Inconsistencias de integración
La respuesta de incidencias en el proceso de integración del PGS, se notificará en un formato plano del tipo de archivo "CSV".
A continuación se presentan los campos que contiene el archivo que se debe generar, conteniendo cada uno de los registros que no cumplan con una o varias reglas de validación de datos.
| No.
| Nombre
| Tipo
| Longitud
| Característica
| Descripción
|
| 1 | CURP | Alfanumérico | 18
| Obligatorio | Cadena de caracteres del campo CURP del registro a reportar. |
| 2 | CLAVECAMPO | Alfanumérico | 4
| Obligatorio | Indicará el nombre del campo ("CURP"). |
| 3 | CLAVEINCON | Alfanumérico | 5
| Obligatorio | Indicará la clave de la inconsistencia ("INTEG"). |
| 4 | DESCINCON | Alfanumérico | 50
| Obligatorio | Breve descripción de la inconsistencia detectada ("Error de integración al padrón"). |
El archivo de inconsistencias debe estar disponible para su descarga, en la pantalla de "Bitácora", en la columna de registros no integrados, correspondiente al archivo procesado.
4.6 Seguridad
La seguridad requerida para el PGS se basa en el hecho de poder cifrar los mensajes que se envían por la red entre un servidor y un cliente, y que sólo ellos puedan descifrar los contenidos a partir de una clave común conocida sólo por ambos.
Cada PARTICIPANTE que envíe y reciba información desde/hacia el PGS debe considerar la implementación en sus comunicaciones de los siguientes protocolos de seguridad:
- SSL: Usado principalmente en comunicaciones de hipertexto pero con posibilidad de uso en otros protocolos.
- HTTPS: Usado exclusivamente para comunicaciones de hipertexto.
4.6.1. SSL (Secure Socket Layer)
SSL proporciona autenticación y privacidad de la información entre extremos sobre Internet mediante el uso de criptografía. Habitualmente, sólo el servidor es autenticado (es decir, se garantiza su identidad) mientras que el cliente se mantiene sin autenticar; la autenticación mutua requiere un despliegue de una serie de fases básicas:
- Negociar entre las partes el algoritmo que se usará en la comunicación.
- Intercambio de claves públicas y autenticación basada en certificados digitales.
- Cifrado del tráfico basado en cifrado simétrico.
Durante la primera fase, el cliente y el servidor negocian qué algoritmos criptográficos se van a usar. Las implementaciones actuales proporcionan las siguientes opciones:
- Para criptografía de clave pública: RSA, Diffie-Hellman, DSA (Digital Signature Algorithm) o Fortezza;
- Para cifrado simétrico: RC2, RC4, IDEA (International Data Encryption Algorithm), DES (Data
Encryption Standard), Triple DES o AES (Advanced Encryption Standard), y
- Con funciones hash: MD5 o de la familia SHA.
4.6.2. HTTPS
La idea principal de HTTPS es la de crear un canal seguro sobre una red insegura. Esto proporciona una protección razonable contra ataques eavesdropping y man-in-the-middle, siempre que se empleen métodos de cifrado adecuados y que el certificado del servidor sea verificado y resulte de confianza.
La confianza inherente en HTTPS está basada en una Autoridad de certificación superior que viene preinstalada en el software del navegador, equivalente a "Confiar en una autoridad de certificación (por ejemplo: VeriSign/Microsoft/etc.) para saber en quien debería confiar". Sin embargo una conexión HTTPS a un Website puede ser validada si y sólo si todo lo siguiente es verdad:
- El usuario confía en la Autoridad de certificación para dar fe sólo para sitios web legítimos sin nombres engañosos.
- El sitio web proporciona un certificado válido (y un certificado inválido muestra una alerta en la mayoría de los navegadores), lo que significa que está firmado por una autoridad confiable.
- El certificado identifica correctamente al sitio.
- Cada uno de los nodos involucrados en internet son dignos de confianza, o que el usuario confíe en que la capa de cifrado del protocolo (TLS o SSL) es inquebrantable por un eavesdropper.
| Ubicación en la pila de protocolos
|
| Aplicación
| HTTPS
|
| Transporte | SSL/TLS TCP
|
| Red | IP
|
4.6.2.1. Características Técnicas
El sistema HTTPS utiliza un cifrado basado en SSL/TLS para crear un canal cifrado (cuyo nivel de cifrado depende del servidor remoto y del navegador utilizado por el cliente) más apropiado para el tráfico de información sensible que el protocolo HTTP. De este modo se consigue que la información sensible (usuario y claves de paso normalmente) no pueda ser usada por un atacante que haya conseguido interceptar la transferencia de datos de la conexión, ya que lo único que obtendrá será un flujo de datos cifrados que le resultará imposible de descifrar. El puerto estándar para este protocolo es el 443.
4.6.2.2. Diferencias con HTTP
En el protocolo HTTP las direcciones web comienzan con "http://" y utilizan por defecto el puerto 80, Las URLs de HTTPS comienzan con "https://" y utilizan el puerto 443 por defecto.
HTTP es inseguro y está sujeto a ataques man-in-the-middle y eavesdropping que pueden permitir al atacante obtener acceso a cuentas de un sitio web e información confidencial. HTTPS está diseñado para resistir esos ataques y ser seguro.
4.6.2.3. Capas de Red
HTTP opera en la capa más alta del Modelo OSI, la Capa de Aplicación; pero el protocolo de seguridad opera en una subcapa más baja, cifrando un mensaje HTTP previo a la transmisión y descifrando un mensaje una vez recibido.
Estrictamente hablando, HTTPS no es un protocolo separado, pero refiere el uso del HTTP ordinario sobre una Capa de Conexión Segura cifrada Secure Sockets Layer (SSL) o una conexión con Seguridad de la Capa de Transporte (TLS).
Los datos pueden ser o no cifrados en el canal de comandos, en el canal de datos, o más a menudo en ambos. Si el canal de comandos no se cifra, se dice que el protocolo está usando un canal de comandos en claro (CCC). Si el canal de datos no está cifrado, se dice que el protocolo usa un canal de datos en claro (CDC).
Estos protocolos se utilizan para asegurar la integridad de los archivos que están viajando de la aplicación de escritorio PGS hacia la aplicación web que se encarga de procesar e integrar los registros contenidos en ellos.
Especificación e Implementación de Mensajes HL7
En la presente sección se proporciona en forma detallada la especificación que los PARTICIPANTES deben observar para el envío de la información de sus BENEFICIARIOS hacia el PGS.
4.7 Propósito
Comunicar la forma de implementar la mensajería para el envío y recepción de información desde/hacia el PGS basándose en el dominio Patient Administration de HL7 y su adecuación para implementar los datos que desean que se transmitan en él.
4.8 Audiencia
Este apartado está dirigido principalmente a personal con perfil técnico, con conocimiento de disciplinas como RUP, UML, XML y estructuras de datos, así como también deberán contar con conocimiento básico del estándar HL7.
4.9 Dominio Patient Administration
El dominio de Administración de Pacientes, soporta muchas de las funciones básicas administrativas en el cuidado de la salud, como registro de personas, pacientes y BENEFICIARIOS además del manejo de atenciones clínicas.
4.9.1. Diagrama D-MIM
Es un subconjunto refinado de información HL7 (RIM), que incluye un conjunto de clases, atributos y relaciones usadas para crear mensajes nuevos o actualizaciones de datos demográficos e información de visitas del paciente.
4.9.2. Mensajes
A continuación se muestra el mensaje seleccionado de este dominio, que se debe utilizar para realizar el envío y la recepción de la información de un BENEFICIARIO, así también se integrarán los datos demográficos y de los programas a los que pertenece.
| Mensajes Patient Administration
|
| Nombre
| Código HL7
|
| Patient Registry | PRPA_RM213109UV |
4.9.3. Eventos
- Patient Registry (PRPA_TE213079UV02): Es iniciada cuando un PARTICIPANTE envía información
demográfica y de programas hacia el PGS.
4.9.4. Mensaje Patient Registry -- PRPA_IN213109UV
Este mensaje se usa para enviar y recibir los datos de identificación y demográficos de un BENEFICIARIO, en el caso del PGS, se debe utilizar como transporte para la información del BENEFICIARIO.
4.9.5. Diagrama RMIM
El Modelo de Información Refinada (RMIM), define el mensaje de envío de información de un BENEFICIARIO hacia el PGS.
4.9.6. Información Detallada
| PRPA_HD213109UV02 Patient Registry |
| PatientEvent |
| classCode [1..1] (M) Act (CS) {CNE:V:ActClassInform, root= "INFRM"} |
| moodCode [1..1] (M) Act (CS) {CNE:V:ActMoodEventOccurrence, root= "EVN"} |
| subject [0..*] (Subject) |
| Subject |
| typeCode [1..1] (M) Participation (CS) {CNE:V:ParticipationTargetSubject, root= "SBJ"} |
| patient [1..1] (Patient) |
| Patient |
| classCode [1..1] (M) Role (CS) {CNE:V:RoleClassPatient, root= "PAT"} |
| id [0..*] Role (SET<II>) |
| addr [0..*] Role (BAG<AD>) |
| telecom [0..*] Role (BAG<TEL>) |
| statusCode [0..1] Role (CS) {CNE:D:RoleStatus, default= "active"} |
| effectiveTime [0..1] Role (IVL<TS>) |
| veryImportantPersonCode [0..1] Patient (CE) {CWE:D:PatientImportance} |
| providerOrganization [0..1] (E_OrganizationContact) |
| patientPerson [0..1] (Person) |
| specimenOf [0..*] (Specimen) |
| Person |
| classCode [1..1] (M) Entity (CS) {CNE:V:EntityClassPerson, root= "PSN"} |
| determinerCode [1..1] (M) Entity (CS) {CNE:V:EntityDeterminerSpecific, root= "INSTANCE"} |
| id [1..1] (M) Entity (II) |
| quantity [0..1] Entity (PQ) |
| name [0..*] Entity (BAG<EN>) |
| telecom [0..*] Entity (BAG<TEL>) |
| administrativeGenderCode [0..1] LivingSubject (CE) {CWE:D:AdministrativeGender} |
| birthTime [0..1] LivingSubject (TS) |
| organDonorInd [0..1] LivingSubject (BL) |
| addr [0..*] Person (BAG<AD>) |
| maritalStatusCode [0..1] Person (CE) {CWE:D:MaritalStatus} |
| educationLevelCode [0..1] Person (CE) {CWE:D:EducationLevel} |
| disabilityCode [0..1] Person (CE) {CWE:D:PersonDisabilityType} |
| livingArrangementCode [0..1] Person (CE) {CWE:D:LivingArrangement} |
| religiousAffiliationCode [0..1] Person (CE) {CWE:D:ReligiousAffiliation} |
| ethnicGroupCode [0..*] Person (SET<CE>) {CWE:D:Ethnicity} |
| asStudent [0..*] (Student) |
| asBirthplace [0..*] (Birthplace) |
| employee [0..*] (Employee) |
| careGiver [0..*] (CareGiver) |
| Student |
| classCode [1..1] (M) Role (CS) {CNE:V:RoleClassStudent, root= "STD"} |
| name [0..*] Role (BAG<EN>) |
| schoolOrganization [0..1] (E_OrganizationInformational) |
| Birthplace |
| classCode [1..1] (M) Role (CS) {CNE:V:RoleClassBirthplace, root= "BIRTHPL"} |
| name [0..*] Role (BAG<EN>) |
| birthplaceForPlace [0..1] (E_PlaceInformational) |
| Employee |
| classCode [1..1] (M) Role (CS) {CNE:V:RoleClassEmployee, root= "EMP"} |
| jobTitleName [0..1] Employee (SC) |
| occupationCode [0..1] Employee (CE) {CWE:D:EmployeeOccupationCode} |
| employeeOrganization [0..1] (E_OrganizationInformational) |
| CareGiver |
| classCode [1..1] (M) Role (CS) {CNE:V:RoleClassCaregiver, root= "CAREGIVER"} |
| careGiverPerson [1..1] (E_PersonInformational) |
| Specimen |
| typeCode [1..1] (M) Participation (CS) {CNE:V:ParticipationSpecimen, root= "SPC"} |
| specimenObservation [1..1] (SpecimenObservation) |
| SpecimenObservation |
| classCode [1..1] (M) Act (CS) {CNE:V:ActClassSpecimenObservation, root= "SPCOBS"} |
| moodCode [1..1] (M) Act (CS) {CNE:V:ActMoodEventOccurrence, root= "EVN"} |
| id [1..1] Act (II) |
| code [0..1] Act (CD) {CWE:D:ObservationType} |
| value [1..1] (M) Observation (ANY) |
4.9.7. Lista de tipos de mensaje
Elementos usados del dominio Common Types
| E_Organization | COCT_MT150003UV |
| E_Person | COCT_MT030207UV |
| E_Place | COCT_MT710007UV |
Elemento
| Patient Registry | PRPA_MT213039UV02 |
4.9.8. Interacciones
Resultado de una consulta previa de paciente. Patient Registry (PRPA_IN213109UV02)
| Trigger Event | Patient Registry | PRPA_TE213089UV02 |
| Transmission Wrapper | Application Transmission | MCCI_MT023009UV |
| Control Act Wrapper | Master File / Registry Role Subject | MFMI_MT700711UV01 |
| Message Type | Patient Registry | PRPA_MT213039UV02 |
4.9.9. Diccionario de Datos
4.9.9.1. Integración de BENEFICIARIOS
| Mensaje Patient Registry | PRPA_MT213109UV |
| # | Campo | Tipo de Dato | | Elemento | Atributo | Comentarios
|
| 1 | CURP | Alfanumérico | R | /patient/id | extension | Clave Unica de Registro
de Población.
|
| 2 | NOMBRE | Alfanumérico | R | /patient/patientPerson/name/family | | Nombre o nombres.
|
| 3 | PRIMERAPELLIDO | Alfanumérico | R | /patient/patientPerson/name/given | | Primer Apellido.
|
| 4 | SEGUNDOAPELLIDO | Alfanumérico | O | /patient/patientPerson/name/given | | Segundo Apellido.
|
| 5 | FECNAC | Fecha | R | /patient/patientPerson/birthTime | value | Fecha de nacimiento de
BENEFICIARIO.
|
| 6 | EDONAC | Alfanumérico | R | /patient/patientPerson/asBirthplace/birthPlaceForPlace/addr/state | | Estado de nacimiento.
|
| 7 | SEXO | Alfanumérico | R | /patient/patientPerson/administrativeGenderCode | Code | Sexo de
BENEFICIARIO.
|
| 8 | NACORIGEN | Alfanumérico | R | /patient/patientPerson/asBirthplace/birthPlaceForPlace/addr/city | | Nacionalidad de origen.
|
| 9 | FOLIOPROGRAMA | Alfanumérico | R | /patient/patientPerson/Id | extension | Folio o número con el
que cada
PARTICIPANTE
identifica internamente
al BENEFICIARIO en un
programa.
|
| 10 | CVEDEPENDENCIA | Alfanumérico | R | /patient/providerOrganization/id | root | Clave de la
Dependencia encargada
del programa.
|
| 11 | CVEPROGRAMA | Alfanumérico | R | /patient/patientPerson/quantity | value | Clave del programa al
que está inscrito el
BENEFICIARIO.
|
| 12 | EDO | Alfanumérico | R | /patient/patientPerson/addr/state | | Clave de la Entidad
federativa de residencia.
|
| 13 | MUN | Alfanumérico | R | /patient/patientPerson/addr/city | | Clave del municipio de
residencia.
|
| 14 | LOC | Alfanumérico | R | /patient/patientPerson/addr/streetAddressLine | | Clave de la localidad de
residencia.
|
| 15 | TIPOBENEFICIARIO | Alfanumérico | R | /patient/providerOrganization/contactparty | | Tipo de
BENEFICIARIO.
|
4.9.9.2.Actualización de vigencia
| Mensaje Patient Registry | PRPA_MT213019UV |
| # | Campo | Tipo de Dato | | Elemento | Atributo | Comentarios |
| 1 | CURP | Alfanumérico | R | /patient/id | extension | Clave Unica de Registro de Población. |
| 2 | CVEDEPENDENCIA | Alfanumérico | R | /patient/providerOrganization/id | root | Clave de la Dependencia encargada del programa. |
| 3 | TIPOOPERACION | Alfabético | R | /patient/patientPerson/livingArrangementCode | code | Clave que define el tipo de actualización a realizar. |
| 4 | CVEPROGRAMA | Alfanumérico | R | /patient/patientPerson/quantity | value | Clave del programa al que está inscrito el BENEFICIARIO. |
| 5 | TIPOBENEFICIARIO | Alfanumérico | R | /patient/providerOrganization/contactparty | | Tipo de BENEFICIARIO. |
| 6 | FOLIOPROGRAMA | Alfanumérico | R | /patient/patientPerson/Id | extension | Folio o número con el que cada PARTICIPANTE identifica internamente al BENEFICIARIO en un programa. |
4.9.9.3. Archivo de Inconsistencias de datos
| Mensaje Patient Registry | PRPA_MT213019UV |
| # | Campo | Tipo de Dato | | Elemento | Atributo | Comentarios |
| 1 | CURP | Alfanumérico | R | /patient/id | extension | Clave Unica de Registro de Población. |
| 2 | CAMPOINCON | Numérico | R | /patient/specimenOf/specimenObservation/value | Code | Número de campo en el cual se encontró la inconsistencia. |
| 3 | DESCINCON | Alfabético | R | /patient/specimenOf/specimenObservation/value | displayName | Breve descripción de la incidencia detectada en el registro. |
4.9.10. Definición de mensajes
4.9.10.1. Patient Registry â PRPA_IN213109UV02
<?xml version="1.0" encoding="utf-8" standalone="no"?>
<xs:schema xmlns:xs="http:/www.w3.org/2001/XMLSchema" xmlns:mif="urn:hl7-org:v3/mif"
xmlns="urn:hl7-org:v3" targetNamespace="urn:hl7-org:v3" elementFormDefault="qualified">
<xs:include schemaLocation="../coreschemas/infrastructureRoot.xsd"/>
<xs:include schemaLocation="MCCI_MT023009UV.xsd"/>
<xs:include schemaLocation="MFMI_MT700711UV.xsd"/>
<xs:include schemaLocation="PRPA_MT213039UV02.xsd"/>
<xs:include schemaLocation="PRPA_MT213069UV02.xsd"/>
<xs:element name="PRPA_IN213109UV02">
<xs:complexType>
<xs:complexContent>
<xs:extension base="PRPA_IN213109UV02.MCCI_MT023009UV.Message">
<xs:attribute name="ITSVersion" type="xs:string"
use="required" fixed="XML_1.0"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:complexType name="PRPA_IN213109UV02.MCCI_MT023009UV.Message">
<xs:sequence>
<xs:group ref="InfrastructureRootElements"/>
<xs:element name="id" type="II" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="creationTime" type="TS" minOccurs="0"/>
<xs:element name="responseModeCode" type="CS" minOccurs="0"/>
<xs:element name="interactionId" type="II" minOccurs="0"/>
<xs:element name="acceptAckCode" type="CS" minOccurs="0"/>
<xs:element name="sequenceNumber" type="INT" minOccurs="0"/>
<xs:element name="receiver" type="MCCI_MT023009UV.Receiver"
maxOccurs="unbounded"/>
<xs:element name="sender" type="MCCI_MT023009UV.Sender"
maxOccurs="unbounded"/>
<xs:element name="acknowledgement"
type="MCCI_MT023009UV.Acknowledgement" maxOccurs="unbounded"/>
<xs:element name="controlActProcess"
type="PRPA_IN213109UV02.MFMI_MT700711UV.ControlActProcess"/>
</xs:sequence>
<xs:attributeGroup ref="InfrastructureRootAttributes"/>
<xs:attribute name="nullFlavor" type="NullFlavor" use="optional"/>
</xs:complexType>
<xs:complexType
name="PRPA_IN213109UV02.MFMI_MT700711UV.ControlActProcess">
<xs:sequence>
<xs:group ref="InfrastructureRootElements"/>
<xs:element name="id" type="II" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="code" type="CD" minOccurs="0"/>
<xs:element name="text" type="ED" minOccurs="0"/>
<xs:element name="effectiveTime" type="IVL_TS" minOccurs="0"/>
<xs:element name="priorityCode" type="CE" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="reasonCode" type="CE" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="languageCode" type="CE" minOccurs="0"/>
<xs:element name="overseer" type="MFMI_MT700711UV.Overseer"
nillable="true" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="authorOrPerformer"
type="MFMI_MT700711UV.AuthorOrPerformer" nillable="true" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="dataEnterer" type="MFMI_MT700711UV.DataEnterer"
nillable="true" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="informationRecipient"
type="MFMI_MT700711UV.InformationRecipient" nillable="true" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="subject"
type="PRPA_IN213109UV02.MFMI_MT700711UV.Subject1"/>
<xs:element name="reasonOf" type="MFMI_MT700711UV.Reason"
nillable="true" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="queryAck" type="MFMI_MT700711UV.QueryAck"/>
<xs:element name="queryByParameter"
type="PRPA_MT213069UV02.QueryByParameter" nillable="true" minOccurs="0"/>
</xs:sequence>
<xs:attributeGroup ref="InfrastructureRootAttributes"/>
<xs:attribute name="nullFlavor" type="NullFlavor" use="optional"/>
<xs:attribute name="classCode" type="ActClassControlAct" use="required"/>
<xs:attribute name="moodCode" type="x_ActMoodIntentEvent" use="required"/>
</xs:complexType>
<xs:complexType name="PRPA_IN213109UV02.MFMI_MT700711UV.Subject1">
<xs:sequence>
<xs:group ref="InfrastructureRootElements"/>
<xs:element name="registrationEvent"
type="PRPA_IN213109UV02.MFMI_MT700711UV.RegistrationEvent"/>
</xs:sequence>
<xs:attributeGroup ref="InfrastructureRootAttributes"/>
<xs:attribute name="nullFlavor" type="NullFlavor" use="optional"/>
<xs:attribute name="typeCode" type="ActRelationshipHasSubject" use="required"/>
<xs:attribute name="contextConductionInd" type="bl" use="optional"
default="false"/>
</xs:complexType>
<xs:complexType name="PRPA_IN213109UV02.MFMI_MT700711UV.RegistrationEvent">
<xs:sequence>
<xs:group ref="InfrastructureRootElements"/>
<xs:element name="id" type="II" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="statusCode" type="CS"/>
<xs:element name="effectiveTime" type="IVL_TS" minOccurs="0"/>
<xs:element name="subject1"
type="PRPA_IN213109UV02.MFMI_MT700711UV.Subject2"/>
<xs:element name="author" type="MFMI_MT700711UV.Author2"
nillable="true" minOccurs="0"/>
<xs:element name="custodian" type="MFMI_MT700711UV.Custodian"
nillable="true"/>
<xs:element name="inFulfillmentOf"
type="MFMI_MT700711UV.InFulfillmentOf" nillable="true" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="definition" type="MFMI_MT700711UV.Definition"
nillable="true" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="replacementOf"
type="MFMI_MT700711UV.ReplacementOf" nillable="true" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="InfrastructureRootAttributes"/>
<xs:attribute name="nullFlavor" type="NullFlavor" use="optional"/>
<xs:attribute name="classCode" type="ActClassRegistration" use="required"/>
<xs:attribute name="moodCode" type="ActMoodEventOccurrence"
use="required"/>
</xs:complexType>
<xs:complexType name="PRPA_IN213109UV02.MFMI_MT700711UV.Subject2">
<xs:sequence>
<xs:group ref="InfrastructureRootElements"/>
<xs:element name="role" type="PRPA_MT213039UV02.PatientEvent"/>
</xs:sequence>
<xs:attributeGroup ref="InfrastructureRootAttributes"/>
<xs:attribute name="nullFlavor" type="NullFlavor" use="optional"/>
<xs:attribute name="typeCode" type="ParticipationTargetSubject" use="required"/>
</xs:complexType>
</xs:schema>
4.9.10.2. Patient Registry - PRPA_MT213039UV02
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<xs:schema xmlns:xs="http:/www.w3.org/2001/XMLSchema" xmlns:ex="urn:hl7-org/v3-example"
xmlns="urn:hl7-org:v3" targetNamespace="urn:hl7-org:v3" elementFormDefault="qualified">
<xs:include schemaLocation="../coreschemas/infrastructureRoot.xsd"/>
<xs:include schemaLocation="COCT_MT150003UV03.xsd"/>
<xs:include schemaLocation="COCT_MT710007UV07.xsd"/>
<xs:include schemaLocation="COCT_MT150007UV.xsd"/>
<xs:include schemaLocation="COCT_MT030207UV07.xsd"/>
<xs:complexType name="PRPA_MT213039UV02.Birthplace">
<xs:sequence>
<xs:group ref="InfrastructureRootElements"/>
<xs:element name="name" type="EN" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="birthPlaceForPlace"
type="COCT_MT710007UV07.Place" nillable="true" minOccurs="0"/>
</xs:sequence>
<xs:attributeGroup ref="InfrastructureRootAttributes"/>
<xs:attribute name="nullFlavor" type="NullFlavor" use="optional"/>
<xs:attribute name="classCode" type="RoleClassBirthplace" use="required"/>
</xs:complexType>
<xs:complexType name="PRPA_MT213039UV02.CareGiver">
<xs:sequence>
<xs:group ref="InfrastructureRootElements"/>
<xs:element name="careGiverPerson"
type="COCT_MT030207UV07.Person" nillable="true"/>
</xs:sequence>
<xs:attributeGroup ref="InfrastructureRootAttributes"/>
<xs:attribute name="nullFlavor" type="NullFlavor" use="optional"/>
<xs:attribute name="classCode" type="RoleClassCaregiver" use="required"/>
</xs:complexType>
<xs:complexType name="PRPA_MT213039UV02.Employee">
<xs:sequence>
<xs:group ref="InfrastructureRootElements"/>
<xs:element name="jobTitleName" type="SC" minOccurs="0"/>
<xs:element name="occupationCode" type="CE"
minOccurs="0"/>
<xs:element name="employeeOrganization"
type="COCT_MT150007UV.Organization" nillable="true"/>
</xs:sequence>
<xs:attributeGroup ref="InfrastructureRootAttributes"/>
<xs:attribute name="nullFlavor" type="NullFlavor" use="optional"/>
<xs:attribute name="classCode" type="RoleClassEmployee" use="required"/>
</xs:complexType>
<xs:complexType name="PRPA_MT213039UV02.Patient">
<xs:sequence>
<xs:group ref="InfrastructureRootElements"/>
<xs:element name="id" type="II" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="addr" type="AD" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="telecom" type="TEL" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="statusCode" type="CS" minOccurs="0"/>
<xs:element name="effectiveTime" type="IVL_TS" minOccurs="0"/>
<xs:element name="veryImportantPersonCode" type="CE" minOccurs="0"/>
<xs:element name="patientPerson" type="PRPA_MT213039UV02.Person"
nillable="true" minOccurs="0"/>
<xs:element name="specimenOf"
type="PRPA_MT213039UV02.Specimen" nillable="true" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="providerOrganization"
type="COCT_MT150003UV03.Organization" nillable="true" minOccurs="0"/>
</xs:sequence>
<xs:attributeGroup ref="InfrastructureRootAttributes"/>
<xs:attribute name="nullFlavor" type="NullFlavor" use="optional"/>
<xs:attribute name="classCode" type="RoleClassPatient" use="required"/>
</xs:complexType>
<xs:complexType name="PRPA_MT213039UV02.PatientEvent">
<xs:sequence>
<xs:group ref="InfrastructureRootElements"/>
<xs:element name="subject" type="PRPA_MT213039UV02.Subject"
nillable="true" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="InfrastructureRootAttributes"/>
<xs:attribute name="nullFlavor" type="NullFlavor" use="optional"/>
<xs:attribute name="classCode" type="ActClassInform" use="required"/>
<xs:attribute name="moodCode" type="ActMoodEventOccurrence"
use="required"/>
</xs:complexType>
<xs:complexType name="PRPA_MT213039UV02.Person">
<xs:sequence>
<xs:group ref="InfrastructureRootElements"/>
<xs:element name="id" type="II"/>
<xs:element name="quantity" type="PQ" minOccurs="0"/>
<xs:element name="name" type="EN" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="telecom" type="TEL" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="administrativeGenderCode" type="CE"
minOccurs="0"/>
<xs:element name="birthTime" type="TS" minOccurs="0"/>
<xs:element name="organDonorInd" type="BL" minOccurs="0"/>
<xs:element name="addr" type="AD" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="maritalStatusCode" type="CE" minOccurs="0"/>
<xs:element name="educationLevelCode" type="CE" minOccurs="0"/>
<xs:element name="disabilityCode" type="CE" minOccurs="0"/>
<xs:element name="livingArrangementCode" type="CE" minOccurs="0"/>
<xs:element name="religiousAffiliationCode" type="CE" minOccurs="0"/>
<xs:element name="ethnicGroupCode" type="CE" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="asStudent" type="PRPA_MT213039UV02.Student"
nillable="true" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="asBirthplace"
type="PRPA_MT213039UV02.Birthplace" nillable="true" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="employee" type="PRPA_MT213039UV02.Employee"
nillable="true" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="careGiver" type="PRPA_MT213039UV02.CareGiver"
nillable="true" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="InfrastructureRootAttributes"/>
<xs:attribute name="nullFlavor" type="NullFlavor" use="optional"/>
<xs:attribute name="classCode" type="EntityClassPerson" use="required"/>
<xs:attribute name="determinerCode" type="EntityDeterminerSpecific"
use="required"/>
</xs:complexType>
<xs:complexType name="PRPA_MT213039UV02.Specimen">
<xs:sequence>
<xs:group ref="InfrastructureRootElements"/>
<xs:element name="specimenObservation"
type="PRPA_MT213039UV02.SpecimenObservation" nillable="true"/>
</xs:sequence>
<xs:attributeGroup ref="InfrastructureRootAttributes"/>
<xs:attribute name="nullFlavor" type="NullFlavor" use="optional"/>
<xs:attribute name="typeCode" type="ParticipationSpecimen" use="required"/>
</xs:complexType>
<xs:complexType name="PRPA_MT213039UV02.SpecimenObservation">
<xs:sequence>
<xs:group ref="InfrastructureRootElements"/>
<xs:element name="id" type="II"/>
<xs:element name="code" type="CD" minOccurs="0"/>
<xs:element name="value" type="ANY"/>
</xs:sequence>
<xs:attributeGroup ref="InfrastructureRootAttributes"/>
<xs:attribute name="nullFlavor" type="NullFlavor" use="optional"/>
<xs:attribute name="classCode" type="ActClassSpecimenObservation"
use="required"/>
<xs:attribute name="moodCode" type="ActMoodEventOccurrence"
use="required"/>
</xs:complexType>
<xs:complexType name="PRPA_MT213039UV02.Student">
<xs:sequence>
<xs:group ref="InfrastructureRootElements"/>
<xs:element name="name" type="EN" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="schoolOrganization"
type="COCT_MT150007UV.Organization" nillable="true" minOccurs="0"/>
</xs:sequence>
<xs:attributeGroup ref="InfrastructureRootAttributes"/>
<xs:attribute name="nullFlavor" type="NullFlavor" use="optional"/>
<xs:attribute name="classCode" type="RoleClassStudent" use="required"/>
</xs:complexType>
<xs:complexType name="PRPA_MT213039UV02.Subject">
<xs:sequence>
<xs:group ref="InfrastructureRootElements"/>
<xs:element name="patient" type="PRPA_MT213039UV02.Patient" nillable="true"/
>
</xs:sequence>
<xs:attributeGroup ref="InfrastructureRootAttributes"/>
<xs:attribute name="nullFlavor" type="NullFlavor" use="optional"/>
<xs:attribute name="typeCode" type="ParticipationTargetSubject" use="required"/>
</xs:complexType>
</xs:schema>
4.9.11. Mensajes XML
En esta sección están contenidos ejemplos del mensaje HL7 para Patient Registry, para los casos de datos mínimos (los marcados como requeridos en el diccionario de datos), y datos completos (incluyendo los opcionales). En el caso que todos los elementos del mensaje sean obligatorios, sólo se presenta el mensaje único.
4.9.11.1. Mensaje completo â Integración de BENEFICIARIOS
<PRPA_IN213109UV02 ITSVersion="XML_1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:hl7-org:v3" xsi:schemaLocation="urn:hl7-org:v3 PRPA_IN213109UV02.xsd">
<id extensión="IDENTIFICADOR_MENSAJE"/>
<creationTime value="FECHA_CREACION"/>
<responseModeCode code="D"/>
<interactionId extensión="CODIGO_INTERACCION"/>
<acceptAckCode code="AL"/>
<sequenceNumber/>
<receiver typeCode="RCV">
<device classCode="DEV" determinerCode="INSTANCE">
<telecom use="WP" value="HOST_RECEPTOR"/>
<softwareName mediaType="text/plain"
representation="TXT">NOM_SOFT_DESTINO</softwareName>
<asAgent classCode="CON">
<representedOrganization classCode="ORG" determinerCode="INSTANCE">
<id root="OID_ENT_DESTINO" extensión="CLV_ENT_DESTINO"/>
<name
use="SRCH">NOM_ENT_SALUD_DESTINO</name>
</representedOrganization>
</asAgent>
<asLocatedEntity classCode="LOCE">
<location classCode="PLC" determinerCode="INSTANCE">
<id root="2.16.840.1.113883.5.16"/>
<name
use="SRCH">UBICACION_SRV_DESTINO</name>
</location>
</asLocatedEntity>
</device>
</receiver>
<sender typeCode="SND">
<device classCode="DEV" determinerCode="INSTANCE">
<telecom use="WP" value="HOST_EMISOR"/>
<softwareName mediaType="text/plain"
representation="TXT">NOM_SOFT_ORIGEN</softwareName>
<asAgent classCode="CON">
<representedOrganization classCode="ORG" determinerCode="INSTANCE">
<id root="OID_ENT_ORIGEN" extension="CLV_ENT_ORIGEN"/>
<name
use="SRCH">NOM_ENT_SALUD_ORIGEN</name>
</representedOrganization>
</asAgent>
<asLocatedEntity classCode="LOCE">
<location classCode="PLC" determinerCode="INSTANCE">
<id root="2.16.840.1.113883.5.16"/>
<name use="SRCH">UBICACION_SRV_ORIGEN</name>
</location>
</asLocatedEntity>
</device>
</sender>
<controlActProcess classCode="CACT" moodCode="EVN">
<id root="2.16.840.1.113883.11.11534"/>
<code code="_ActCareProvisionCode"/>
<text mediaType="text/plain" representation="TXT">INFORMACION DE BENEFICIARIO</
text>
<effectiveTime value="FECHA_ACTUAL"/>
<priorityCode code="R"/>
<reasonCode code="PATADMIN"/>
<subject typeCode="SUBJ" contextConductionInd="false">
<registrationEvent classCode="REG" moodCode="EVN">
<statusCode code="active"/>
<effectiveTime value="0"/>
<subject1 typeCode="SBJ">
<role classCode="INFRM" moodCode="EVN">
<subject typeCode="SBJ">
<patient classCode="PAT">
<id extension="CURP"/>
<telecom use="H" value=""/>
<statusCode code="active"/>
<patientPerson classCode="PSN" determinerCode="INSTANCE">
<id extension="FOLIOPROGRAMA"/>
<quantity value="CVEPROGRAMA"/>
<name use="SRCH">
<given>PRIMERAPELLIDO</given>
<given>SEGUNDOAPELLIDO</given>
<family>NOMBRE</family>
</name>
<telecom use="H"
value=""/>
<administrativeGenderCode code="SEXO" displayName=""/>
<birthTime value="FECNAC"/>
<addr use="DIR">
<streetName/>
<houseNumber/>
<streetAddressLine>LOC</streetAddressLine>
<city>MUN</city>
<state>EDO</state>
<country/>
<postalCode/>
</addr>
<maritalStatusCode code=""/>
<educationLevelCode code=""/>
<disabilityCode code=""/>
<livingArrangementCode code=""/>
<religiousAffiliationCode code=""/>
<ethnicGroupCode code=""/>
<asBirthplace classCode="BIRTHPL">
<birthPlaceForPlace classCode="PLC" determinerCode="INSTANCE">
<addr use="DIR">
<city>NACORIGEN</city>
<state>EDONAC</state>
<country/>
</addr>
</birthPlaceForPlace>
</asBirthplace>
</patientPerson>
<providerOrganization classCode="ORG" determinerCode="INSTANCE">
<id root="CVEDEPENDENCIA" extension="NOM_ENT_SALUD"/>
<name use="SRCH">
<prefix/>
</name>
<contactParty classCode="CON">TIPOBENEFICIARIO</contactParty>
</providerOrganization>
</patient>
</subject>
</role>
</subject1>
</registrationEvent>
</subject>
</controlActProcess>
</PRPA_IN213109UV02>
4.9.11.2. Mensaje mínimo â Integración de BENEFICIARIOS
<PRPA_IN213109UV02 ITSVersion="XML_1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:hl7-org:v3" xsi:schemaLocation="urn:hl7-org:v3 PRPA_IN213109UV02.xsd">
<id extensión="IDENTIFICADOR_MENSAJE"/>
<creationTime value="FECHA_CREACION"/>
<responseModeCode code="D"/>
<interactionId extensión="CODIGO_INTERACCION"/>
<acceptAckCode code="AL"/>
<sequenceNumber/>
<receiver typeCode="RCV">
<device classCode="DEV" determinerCode="INSTANCE">
<telecom use="WP" value="HOST_RECEPTOR"/>
<softwareName mediaType="text/plain"
representation="TXT">NOM_SOFT_DESTINO</softwareName>
<asAgent classCode="CON">
<representedOrganization classCode="ORG" determinerCode="INSTANCE">
<id root="OID_ENT_DESTINO" extensión="CLV_ENT_DESTINO"/>
<name
use="SRCH">NOM_ENT_SALUD_DESTINO</name>
</representedOrganization>
</asAgent>
<asLocatedEntity classCode="LOCE">
<location classCode="PLC" determinerCode="INSTANCE">
<id root="2.16.840.1.113883.5.16"/>
<name use="SRCH">UBICACION_SRV_DESTINO</name>
</location>
</asLocatedEntity>
</device>
</receiver>
<sender typeCode="SND">
<device classCode="DEV" determinerCode="INSTANCE">
<telecom use="WP" value="HOST_EMISOR"/>
<softwareName mediaType="text/plain"
representation="TXT">NOM_SOFT_ORIGEN</softwareName>
<asAgent classCode="CON">
<representedOrganization classCode="ORG" determinerCode="INSTANCE">
