Centro Nacional de Investigación y Desarrollo Tecnológico

Transcripción

1 cnológico Subsecretaría de Educación Superior Dirección General de Educación Superior Tecnológica Coordinación Sectorial Académica Dirección de Estudios de Posgrado e Investigación Centro Nacional de Investigación y Desarrollo Tecnológico Subdirección Académica Departamento de Ciencias Computacionales TESIS DE MAESTRÍA EN CIENCIAS Metodología para el Manejo de Información Clínica Basada en la NOM-168 por Medio de un Dispositivo Móvil Y la Tecnología NFC presentada por Ing. como requisito para la obtención del grado de Maestro en Ciencias de la Computación Director de tesis Dr. Juan Gabriel González Serna Codirector de tesis Dr. Máximo López Sánchez Cuernavaca, Morelos, México. Noviembre de 2013.

2 I

3 II

4 Dedicatorias Dedico la realización de la presente tesis a: A mi mama, por haber sido parte de mi formación, por las incontables ocasiones en que se esforzó junto conmigo para iniciar un nuevo día escolar y porque siempre será un ejemplo de gran voluntad. A mi papa, por todos los consejos y ejemplos ofrecidos que siempre fueron los indicados. A mis hermanos José y Miguel, que son mis amigos de viaje y con su compañía la vida es más amena. A ángeles, por ese gran apoyo ofrecido y porque siempre me has dado ánimos de seguir adelante pese a todo. III

5 Agradecimientos Agradezco ahora y siempre a dios, porque me ha otorgado la fuerza y voluntad para lograr los objetivos que me he fijado. A CENIDET, porque es una gran institución donde he aprendido mucho y donde he cambiado tanto. A CONACYT, por el apoyo económico proporcionado que sirvió para sostener mis gastos durante la realización de los estudios de la Maestría en Ciencias de la Computación. A mis directores de tesis, el Dr. Máximo López Sánchez y el Dr. Juan Gabriel González Serna, que gracias a sus indicaciones me ayudaron a realizar un mejor trabajo. A mis revisores, la Dra. Azucena Montes Rendón, el Dr. Guillermo Rodríguez Ortiz y el Dr. Noé Alejandro Castro Sánchez, por sus correcciones y observaciones durante el desarrollo de la presente tesis. A la Dra. Alicia Martínez Rebollar y al Dr. Hugo Estrada Esquivel, por los consejos recibidos durante la Maestría. A mis amigos del CENIDET (Elizabeth, Oscar, Jesús, Wendy, Francisco, Alberto, Eduardo, Israel, Edgar, Flavio) por su amistad y compañía. A mis papas, hermanos y novia, porque sin ellos ningún logro vale lo suficiente. IV

6 Abstract The management of clinical records in Mexico has to stick to Mexican norms no matter if clinical records are kept electronically or in a paper format. Although the current norms have to be mandatory, clinical records are not always filled correctly. For example, if a clinical record is not filled out correctly, the doctor might not be able to provide the best healthcare to the patient, aggravating the emergency situation in some cases. Nowadays, there are efforts to have a complete clinical record and fast access. Today there are scenarios where a patient can have a mobile device working as a monitoring system and also can access a clinical record from anywhere in the world via internet. The patient is the main source of information in an emergency situation, but in some cases this person is not able to provide the information. This thesis proposes a methodology for managing clinical information by means of a mobile device and NFC technology. The final product of the methodology is an application for android mobile devices. The clinical information that was managed for this methodology was taken from the NOM-168-SSA1-1998, Official Mexican Norm, because this establishes the minimum data for the correct clinical record. The clinical information was analyzed together with the standard HL7 CDA Version 2 to obtain an XML document. This XML document was used like as a template for creating electronic clinical documents. The incorporation of the NFC technology was necessary for managing clinical information inside the NFC memory tags. The main advantage of this process is the different size of an NFC tag (i.e. sticker, bracelet, identification card, etc.); therefore a patient can carry clinical information easily. Furthermore, that clinical information can be recovered through a mobile device with NFC support, even if the patients can not provide any information. V

7 Resumen El manejo de los expedientes clínicos de los pacientes en México (ya sea en papel o de forma electrónica) debe apegarse a las normas oficiales. Pese a que las normas actuales tienen el rigor de ser obligatorias, los expedientes clínicos no siempre cumplen en su totalidad con las mismas. Un hecho también importante es que si un expediente clínico no se encuentra completo el prestador de servicios médicos no contará con la información necesaria para ofrecer una mejor atención al paciente, lo cual se agrava en situaciones de urgencias médicas. Actualmente existen esfuerzos para contar con un expediente clínico completo y de acceso rápido. Tanto es así que hoy en día se encuentran escenarios donde un paciente puede tener en su dispositivo móvil un sistema de monitoreo y también puede acceder a su expediente clínico desde cualquier parte del mundo a través de internet. Pero en situaciones de emergencia la principal fuente de información para brindar una mejor atención es el paciente, pero este no siempre se encuentra con facultades de proporcionar información. En la presente tesis se propone una metodología para el manejo de información clínica por medio de la tecnología inalámbrica NFC y los dispositivos móviles. Como producto final de dicha metodología se obtuvo una aplicación móvil para dispositivos Android. La información clínica que fue manejada en dicha metodología, se obtuvo a partir de la Norma Oficial Mexicana NOM-168- SSA que establece los datos mínimos por los que se debe componer un expediente clínico. Dicha información clínica fue comparada con el estándar HL7 CDA Versión 2 para obtener un documento XML, el cual fue utilizado como una plantilla para crear documentos clínicos electrónicos. La incorporación de la tecnología NFC en dicha metodología fue necesaria para almacenar y recuperar la información clínica en la memoria de tags NFC. La ventaja de lo anterior es que un tag NFC tiene distintas presentaciones como puede ser un calcomanía o una tarjeta de identificación de cualquier instituto de salud, por lo que los pacientes pueden fácilmente transportar información clínica personal. Y además dicha información puede ser accedida por medio de un dispositivo móvil con soporte para NFC incluso si los pacientes se encuentran en un estado que no puedan facilitar información. VI

8 Contenido Capítulo 1. Introducción Motivación Planteamiento del problema Objetivos Objetivo general Alcances y limitaciones Alcances Limitaciones Organización de la tesis... 5 Capítulo 2. Fundamento teórico Expediente Clínico Norma Oficial Mexicana NOM 168 SSA1 1998, del Expediente Clínico (NOM-168) Norma Oficial Mexicana NOM-024-SSA (NOM-024) HL7 (Health Level Seven International, 2012) HL7 CDA Release 2 (Health Level Seven International, 2012) JSON (JSON, 2012) Ejemplo de JSON Tecnologías de Identificación Automática y Captura de Datos RFID NFC Android (Ableson, Sen, & King, 2011) La plataforma Android (Ableson, Sen, & King, 2011) Capítulo 3. Estado del arte Implementación de Expedientes Clínicos Electrónicos en México Prototipo DOXH 1.0 (Alvarado, 2011) Health Digital Systems (HDS, 2012) Expediente Clínico Electrónico del IMSS (IMSS, 2012) Comparación de las implementaciones de Expedientes Clínicos Electrónicos Sistemas y prototipos que integran la tecnología NFC en entornos clínicos El prototipo SemTag (Dünnebeil, Köbler, Koene, & Krcmar, 2011) Propuesta de un sistema de identificación por medio de NFC por IRD (Marcus, y otros, 2009) 23 VII

9 3.2.3 Sistema RFID de Administración de Registros y Rastreo (Zalzala, Chia, Zalzala, & Karimi, 2011) Comparación de los trabajos que integran la tecnología NFC en entornos clínicos Capítulo 4. Metodología de solución Introducción Fase 1.Analisis de la información Proceso Proceso Fase 2.Desarrollo de la aplicación Proceso Proceso Proceso Capítulo 5. Pruebas Plan de pruebas Introducción Elementos de la prueba Características probadas Características excluidas Enfoque Criterio de éxito/fracaso de las pruebas Criterios de suspensión y requerimientos de reanudación Documentos entregables de las pruebas Tareas de pruebas Requisitos ambientales Responsabilidades Riesgos y contingencias Aprobación Nomenclatura Conjunto de datos aleatorios Casos de pruebas Depuración de errores Corrección del caso de prueba administrador_c2_ Corrección del caso de prueba administrador_c5_ Modificaciones adicionales Capítulo 6. Conclusiones y trabajos futuros VIII

10 6.1 Conclusiones Contribuciones Publicaciones Trabajos futuros Referencias Anexo A IX

11 Figuras FIGURA 1.- COMPONENTES DE UN SISTEMA RFID (TELECTRÓNICA CODIFICACION S.A., 2012) FIGURA 2.- LAS APLICACIONES DE ANDROID UTILIZAN COMO INTERFAZ EL KERNEL DE LINUX EL CUAL PUEDE CORRER EN VARIOS TELÉFONOS CELULARES (ABLESON, SEN, & KING, 2011) FIGURA 3.- ARQUITECTURA GENERAL DEL DOXH 1.0 EL CUAL ESTÁ BASADO EN UNA ARQUITECTURA DE N CAPAS (ALVARADO, 2011) FIGURA 4.- EJEMPLO DEL FUNCIONAMIENTO DEL SISTEMA DE AUTOCOMPLETADO DE PALABRAS EN EL PROTOTIPO DOXH 1.0 (ALVARADO, 2011) FIGURA 5.- ESQUEMA GENERAL DEL EXPEDIENTE ELECTRÓNICO DEL PACIENTE DEL IMSS (FERNÁNDEZ, 2006) FIGURA 6.- RUTINA DEL PROCESO DEL SEMTAG (DÜNNEBEIL, KÖBLER, KOENE, & KRCMAR, 2011) FIGURA 7.- DIAGRAMA DE INTERACCIÓN DEL SISTEMA (MARCUS, Y OTROS, 2009) FIGURA 8.- INTERFAZ PRESENTADA AL MÉDICO PARA ESCANEAR UN TAG O INGRESAR EL ID DEL PACIENTE MANUALMENTE (MARCUS, Y OTROS, 2009) FIGURA 9.- EL MÉDICO DEBE INGRESAR EL DIAGNOSTICO DEL PACIENTE (MARCUS, Y OTROS, 2009) FIGURA 10.- PLAN DE IMPLEMENTACIÓN DEL RFID-TRM (ZALZALA, CHIA, ZALZALA, & KARIMI, 2011) FIGURA 11.- LAS 2 ETAPAS DE LA METODOLOGÍA DE SOLUCIÓN FIGURA 12.- PRIMERA FASE NOMBRADA ANÁLISIS DE LA INFORMACIÓN FIGURA 13.- PRINCIPALES COMPONENTES DE UNA DOCUMENTO HL7 CDA FIGURA 14.- CDA R-MIM (HEALTH LEVEL SEVEN, INC., 2005) FIGURA 15.- DESCRIPCIÓN JERÁRQUICA CDA EN UNA HOJA DE CÁLCULO EXCEL FIGURA 16.- PARTE DEL ESQUEMA CDA (HEALTH LEVEL SEVEN, INC., 2005) FIGURA 17.- PRIMERA PARTE DE LA PLANTILLA CDA FIGURA 18.- SEGUNDA PARTE DE LA PLANTILLA CDA FIGURA 19.- TERCERA PARTE DE LA PLANTILLA CDA FIGURA 20.- LA SEGUNDA FASE QUE DESCRIBE EL DESARROLLO DE LA APLICACIÓN EMERTAG FIGURA 21.- PANTALLA DE INICIO DE SESIÓN DE LA APLICACIÓN EMERTAG FIGURA 22.- SECCIONES DE NUEVO USUARIO Y MODIFICAR USUARIO PARA EL TIPO DE PANTALLA LARGE FIGURA 23.- SECCIONES DE BORRAR USUARIO Y BITÁCORA PARA EL TIPO DE PANTALLA LARGE FIGURA 24.- SECCIONES DE NUEVO USUARIO Y MODIFICAR USUARIO PARA EL TIPO DE PANTALLA NORMAL FIGURA 25.- SECCIONES DE BORRAR USUARIO Y BITÁCORA PARA EL TIPO DE PANTALLA NORMAL FIGURA 26.- PANTALLA PRINCIPAL DEL USUARIO FIGURA 27.- MENSAJE DE ALERTA DE UN TAG NFC INCOMPATIBLE O NO FORMATEADO FIGURA 28.- PANTALLA PARA APLICAR EL FORMATO PERSONALIZADO A UN TAG FIGURA 29.- MENSAJE DE ADVERTENCIA PARA UN TAG DIFERENTE A MIFARE CLASSIC FIGURA 30.- MENSAJE DE FORMATO CORRECTO FIGURA 31.- PANTALLAS DE ALMACENAMIENTO DE LA INFORMACIÓN DE UN PACIENTE EN UN TAG NFC FIGURA 32.- PANTALLA PARA ESCANEAR UN TAG Y OBTENER UN OBJETO JSON FIGURA 33.- PANTALLA PARA MOSTRAR LOS DOCUMENTOS CLÍNICOS FIGURA 34.- PROCESO PARA MODIFICAR UN REGISTRO FIGURA 35.- MODELO ENTIDAD-RELACIÓN DE LA BASE DE DATOS EMERTAG FIGURA 36.- MÉTODO PARA CONVERTIR LOS DATOS DEL PACIENTE A UN OBJETO JSON FIGURA 37.- EJEMPLO DE LA CONVERSIÓN DE LOS DATOS DEL PACIENTE A UN OBJETO JSON FIGURA 38.- MÉTODO PARA CONVERTIR UN OBJETO JSON A UN DOCUMENTO CLÍNICO HL7 CDA V FIGURA 39.- DOCUMENTO XML OBTENIDO A PARTIR DEL OBJETO JSON FIGURA 40.- DOCUMENTO CLÍNICO HL7 CDA V2 CON LOS DATOS DEL PACIENTE X

12 FIGURA 41.- ESTRUCTURA DE LA MEMORIA INTERNA DEL TAG MIFARE CLASSIC 1KB FIGURA 42.- GENERACIÓN DE DATOS ALEATORIOS DE PACIENTES DESDE (KEEN, 2013) XI

13 Tablas TABLA 1.- CUMPLIMIENTO DE LAS NOTAS EN EL ESTUDIO (LORÍA, MORENO DE LEÓN, & MÁRQUEZ, 2008)... 3 TABLA 2.- PORCENTAJE DE PRESENCIA Y COMPLETES DE LAS NOTAS ANALIZADAS DE LOS EC QUIRÚRGICOS EN (PINEDA, PUENTES, & GARRIDO, 2011) TABLA 3.- COMPARACIÓN DE IMPLEMENTACIONES DE EXPEDIENTE CLÍNICO ELECTRÓNICO EN MÉXICO TABLA 4.- PRIMER TABLA DE LA CORRESPONDENCIA ENTRE LA INFORMACIÓN OBTENIDA DEL PROCESO 1 Y EL HL7 CDA V TABLA 5.- SEGUNDA TABLA DE LA CORRESPONDENCIA ENTRE LA INFORMACIÓN OBTENIDA DEL PROCESO 1 Y EL HL7 CDA V TABLA 6.- CORRESPONDENCIA ENTRE ELEMENTOS DE LA NOM-168 Y EL ESTÁNDAR HL7 CDA V TABLA 7.- EQUIVALENCIA DE LOS DATOS DEL PACIENTE CON EL ESTÁNDAR HL7 CDA V TABLA 8.- EQUIVALENCIA DE LOS DATOS DEL PRESTADOR DE SERVICIOS MÉDICOS CON EL ESTÁNDAR HL7 CDA V TABLA 9.- TAREAS DEL PLAN DE PRUEBAS TABLA 10.- TABLA DE LOS DATOS DE LOS PACIENTES XII

14 Capítulo 1. Introducción En este capítulo se muestra la motivación para llevar a cabo la presente investigación, así mismo se describe el planteamiento del problema, objetivos, alcances y limitaciones. Al final del este capítulo se muestra la organización de la tesis.

15 Capítulo 1.- Introducción 1.1 Motivación En las clínicas y hospitales del mundo se ha presentado un incremento considerable de pacientes a los que se les ofrecen diversos servicios médicos. En algunos casos estos hospitales se han visto rebasados en su capacidad de administración. Esto conlleva a problemas como la perdida de información o de expedientes clínicos (EC) incompletos. Lo anterior es ocasionado principalmente por los dos problemas clásicos del EC: el crecimiento continuo del volumen almacenado y el manejo de documentos originales (Luzanía & González, 2007). Es importante contar con el EC de una persona de forma rápida y segura, porque en él se pueden observar ordenadamente datos objetivos y subjetivos de la misma, además que contiene todos los acontecimientos médicos más relevantes, es por ello que es una herramienta necesaria para la atención al paciente (López, Ortega, & Rodríguez, 2009). En los últimos años el uso de expedientes clínicos electrónicos (ECE) se ha intensificado en todo el mundo. La razón principal es debido a que el manejo de los EC por medio de estos sistemas resuelve los dos problemas clásicos y además de que permiten la transferencia rápida de la información médica existente de un paciente a puntos lejanos, esto independientemente de la institución que lo maneja para distintos usos (Luzanía & González, 2007). Un beneficio adicional del uso del ECE es la gran reducción de costos en la producción, almacenamiento y manejo de los mismos. Solo en los Estados Unidos de Norteamérica se estima que la efectiva implementación de Registros Médicos Electrónicos (o ECE) podría ahorrar eventualmente más de $81 billones de dólares anualmente (Hillestad, y otros, 2005). Pero existe otro problema heredado de los ECs tradicionales que es el mal llenado de los mismos. Particularmente en México existe la Norma Oficial Mexicana NOM-168-SSA (NOM-168), del Expediente Clínico que regula la información mínima que debe contener el EC (Gobierno Federal de México, 1999) y la Norma Oficial Mexicana NOM-024-SSA (NOM- 024) que indica los aspectos tecnológicos requeridos para la implementación de un ECE (Gobierno Federal de México, 2010). A pesar de la existencia de normas que regulan al EC y ECE, existen estudios [ (Loría, Moreno de León, & Márquez, 2008), (Pineda, Puentes, & Garrido, 2011)] en donde se comprueba que un alto porcentaje de EC revisados no se encuentran completos. Otra conclusión que se puede destacar es el hecho que en el área de urgencias el porcentaje de EC completos es bajo (Loría, Moreno de León, & Márquez, 2008). Además se comprobó en el estudio (Valdez, 2011) que incluso implementando un sistema de ECE el porcentaje de EC incompletos no tuvo un cambio significativo. Es por ello la motivación del presente trabajo donde se ofrece describe el desarrollo de una aplicación móvil que en conjunto con la tecnología NFC permita el acceso fácil e instantáneo a los datos clínicos de un paciente a los prestadores de salud. La forma de lograr esto es por medio del almacenamiento de información clínica en un tag NFC. Dicha información debe estar apegada a la normatividad vigente (NOM-168). 1.2 Planteamiento del problema La Secretaría de Salud, en su función de órgano rector, en el año de 1998 emitió la Norma 2 P á g i n a

16 Capítulo 1.- Introducción Oficial Mexicana NOM-168-SSA (NOM-168) del expediente clínico. La norma entró en vigor el 1 de octubre de 1999, un día después de su publicación en el Diario Oficial de la Federación. La importancia que reviste en el ámbito médico se debe como en sus propios lineamientos menciona: es un instrumento para la regulación del expediente clínico y orienta al desarrollo de una cultura de la calidad, permitiendo los usos: médico, jurídico, de enseñanza, investigación, evaluación, administrativo y estadístico (Gobierno Federal de México, 1999). En el estudio nacional realizado en el año de 1998 por la Comisión Nacional de Arbitraje Médico (CONAMED), se dio a conocer que del total de los expedientes clínicos revisados, sólo el 28.6% estaban completos, y también aproximadamente el 50% de los expedientes no contenían formatos necesarios para garantizar una atención de calidad (Ornelas, 2007). Este panorama ha cambiado debido a que se han realizado esfuerzos con tal fin, por mencionar algo el IMSS, éste cuenta con normas o criterios específicos para la elaboración de sus instrumentos de control y consulta archivísticos, como cuadro general de clasificación, catálogo de disposición documental e inventarios (Ornelas, 2007). Sin embargo, a pesar de los cambios realizados en las instituciones de salud para solventar la falta de apego a la NOM-168, existen aun rezagos en materia de cumplimiento de la misma. El estudio (Loría, Moreno de León, & Márquez, 2008) realizado con el objetivo de determinar el porcentaje de apego de los EC de urgencias, a la NOM-168. Cabe señalar que un EC de urgencias debe contener las siguientes notas según la NOM-168: Nota inicial, Nota de evolución, Nota de interconsulta y Nota de Referencia/Traslado (Bañuelos, 2012). Entonces como resultados el estudio de (Loría, Moreno de León, & Márquez, 2008) muestra que de un total de 768 EC de urgencias se obtuvieron un total de 1776 notas, de las cuales solo el 29.6% estaban completas. En la Tabla 1 se pueden apreciar con detalle las notas encontradas, el porcentaje de cumplimiento y los datos faltantes más frecuentes. Tabla 1.- Cumplimiento de las notas en el estudio (Loría, Moreno de León, & Márquez, 2008). Nota Revisadas Solicitadas Completas Cumplimiento Datos faltantes Consulta externa % Motivo de consulta (28.7%) Pronostico (28.7%) Ingreso a choque % Motivo de consulta (36.84%) Evolución a filtro % Resultados de laboratorio (29.16%) Signos vitales (29.16%) Evolución choque % Reporte de resultados (60%) Signos vitales Evolución observación (60%) % Reporte de laboratorio (35.05%) Interconsultas % Fecha Tratamiento Sugerencia de 3 P á g i n a

17 Capítulo 1.- Introducción Referenciatraslado Consentimiento informado % abordaje % Firma de los testigos (66.66%) En otro estudio (Pineda, Puentes, & Garrido, 2011) se analizaron un total de 5, 734 EC quirúrgicos obtenidos de 45 hospitales, con el fin de evaluar la calidad del llenado de los mismos de acuerdo a la normatividad vigente. Específicamente se comprobó la existencia de 5 notas en los ECs y si estas estaban completas según la NOM-168. En la Tabla 2 se pueden observar los resultados del estudio y los campos que fueron omitidos con más frecuencia. Tabla 2.- Porcentaje de presencia y completes de las notas analizadas de los EC quirúrgicos en (Pineda, Puentes, & Garrido, 2011). Nota % de EC con la Notas completas según Datos faltantes nota la norma Nota preoperatoria 80% 61.1% Registro de pronóstico (35.2%) Nota preanestésica 89.5% 78.2% Evaluación clínica del paciente Registro anestésico Nota postoperatoria Nota consentimiento informado de 97.5% 21.3% Registro de servicios auxiliares de diagnostico Tratamiento transoperatorio 93.3% 13.6% Con lo anteriormente expuesto se concluye que existe un gran número de EC clínicos incompletos y que en el área de urgencias el porcentaje de cumplimiento con la norma es bajo. Debido que es importante contar con la información clínica de un paciente de forma rápida y segura para que el prestador de servicios médicos otorgue una atención médica adecuada (López, Ortega, & Rodríguez, 2009). El problema consiste en proporcionar un acceso rápido, portable y disponible a los datos clínicos de los pacientes, utilizando una aplicación móvil y que los datos cumplan con la NOM Objetivos En esta sección se presenta el objetivo principal y los objetivos particulares que se abordaron para la elaboración de esta tesis Objetivo general Desarrollar una aplicación que utilice la tecnología NFC para ayudar a los prestadores de servicios médicos el manejo de la información clínica de un paciente, la cual debe cumplir con la NOM P á g i n a

18 Capítulo 1.- Introducción Objetivos específicos: Proponer una metodología para manejar la información clínica de los pacientes por medio de la tecnología NFC. Realizar un estudio y análisis del uso de la tecnología NFC en entornos clínicos. Realizar un análisis de los estándares que indican el manejo de los datos clínicos electrónicos. 1.4 Alcances y limitaciones Alcances La aplicación permitirá almacenar, recuperar y modificar los datos clínicos en un tag NFC. Los datos clínicos estarán basados de acuerdo a la NOM-168. Se utilizará el formato JSON para manejar los datos en el tag NFC. Se utilizará el estándar HL7 CDA Versión 2 para mostrar los datos en la aplicación Limitaciones Se utilizará la plataforma Android 4.0 o superior. La aplicación se desarrollará contemplando las características físicas (pantalla) de la tablet Nexus 7 y el Smartphone Samsung Galaxy S3. Sólo se utilizará el estándar HL7 CDA Versión 2 para la representación de los datos clínicos. Sólo se incluirán datos que puedan ser almacenados de acuerdo a la reducida memoria con la que cuenta un tag NFC. 1.5 Organización de la tesis En el capítulo uno se muestra la motivación, el planteamiento del problema, objetivos, alcances y limitaciones. El segundo capítulo aborda el marco teórico en donde se describen los conceptos más relevantes para facilitar al lector la lectura del presente documento. El capítulo tres presenta el estado del arte que muestra una serie de investigaciones relacionadas al presente trabajo de tesis. El capítulo cuatro aborda la metodología de solución propuesta y desarrollada en este documento, donde se describe cada una de las actividades para alcanzar los objetivos planteados en el capítulo 1. El capítulo cinco describe las pruebas realizadas a la aplicación móvil desarrollada en esta tesis y se muestran los resultados obtenidos. El capítulo seis, presenta al lector la conclusión general, los trabajos futuros, las referencias de los trabajos abordados y los anexos. 5 P á g i n a

19 Capítulo 2. Fundamento teórico En este capítulo se abarcan los conceptos más relevantes tratados en este documento. Primeramente el lector encontrara información relacionada al Expediente Clínico y las normas que lo gestionan en México. Después se relata de forma general el estándar HL7 y el HL7 CDA que son lineamientos para enviar información clínica en forma electrónica y gestionan la forma en que se debe estructurar un documento clínico electrónicamente, respectivamente. Finalmente se abordan los temas de JSON y NFC que son parte fundamental de la solución propuesta en esta tesis.

20 Capítulo 2.- Fundamento teórico 2.1 Expediente Clínico Según la NORMA OFICIAL MEXICANA NOM 168 SSA define al expediente clínico como al: conjunto de documentos escritos, gráficos e imagenológicos o de cualquier otra índole, en los cuales el personal de salud, deberá hacer los registros, anotaciones y certificaciones correspondientes a su intervención, con arreglo a las disposiciones sanitarias (Gobierno Federal de México, 1999). Dentro de la literatura se encuentra una definición de expediente clínico que no difiere mucho de la postulada en la NORMA OFICIAL MEXICANA NOM 168 SSA que dice así: El acto médico requiere de su documentación gráfica, y es, en el expediente clínico (EC) donde se debe plasmar. En el EC (ficha clínica, historial clínico o historia clínica para otros países) se plasman ordenadamente los datos objetivos y subjetivos del paciente, así como todos los acontecimientos médicos relevantes sucedidos sobre su atención médica, lo que le hace ser una herramienta universal para los cuidados de los pacientes (López, Ortega, & Rodríguez, 2009). Además (López, Ortega, & Rodríguez, 2009) indican que La importancia de elaborar con pulcritud el EC también radica en que es el instrumento legal donde se evidencia la actuación del profesional de la salud y es la prueba documental de mayor peso jurídico ante algún reclamo legal, civil o administrativo. Debido a la relevancia evidente del expediente clínico en el ámbito médico, fue necesario que la realización del mismo se gestionara bajo una regla general de carácter obligatorio. Es por ello que surgió la NORMA OFICIAL MEXICANA NOM 168 SSA1 1998, del Expediente Clínico como un medio de regulación en la creación de expedientes clínicos Norma Oficial Mexicana NOM 168 SSA1 1998, del Expediente Clínico (NOM-168) Fue publicada el 30 de agosto de 1999 en el Diario Oficial de la Federación, entrando en vigor al día siguiente de su publicación. El objetivo consiste en que: Esta norma Oficial Mexicana establece los criterios científicos, tecnológicos y administrativos obligatorios en la elaboración, integración, uso y archivo del expediente clínico (Gobierno Federal de México, 2010). Además en sus lineamientos indica que su importancia se basa en que es un ordenamiento dirigido a sistematizar, homogeneizar y actualizar el manejo del expediente clínico que contiene los registros de los elementos técnicos esenciales para el estudio racional y la solución de los problemas de salud del usuario, involucrando acciones preventivas, curativas y rehabilitadoras y que se constituye como una herramienta de obligatoriedad para los sectores público, social y privado del Sistema Nacional de Salud. La norma no solamente tiene como objetivo la regulación del expediente clínico, sino también fomenta el desarrollo de una cultura de calidad, facilitando los usos: médico, jurídico, de enseñanza, investigación, evaluación y estadístico (Gobierno Federal de México, 1999). El 22 de agosto de 2003 se realizó una modificación en el punto 5.11 para quedar de la siguiente forma Se permite el empleo de medios electrónicos, magnéticos, electromagnéticos, 7 P á g i n a

21 Capítulo 2.- Fundamento teórico ópticos, magneto ópticos o de cualquier otra tecnología, en la integración de un expediente clínico, mismo que en su caso, quedará sujeto al cumplimiento de las disposiciones legales aplicables (Gobierno Federal de México, 2003). Este cambio implica que el expediente clínico no solo pueda ser utilizado, almacenado y gestionado en papel, y en concreto según (López, Ortega, & Rodríguez, 2009) indican que esta modificación ha dado pie para la elaboración de los Expedientes Clínicos Electrónicos con las ventajas de permitirnos capturar, almacenar, recuperar, analizar y transformar toda esta información en conocimientos, llevando con ello importantes ahorros en espacio, tiempo y costos Norma Oficial Mexicana NOM-024-SSA (NOM-024) La modificación realizada en 2003 a la NOM-168 fue un preámbulo para la publicación de la NORMA OFICIAL MEXICANA NOM-024-SSA en el Diario Oficial de la Federación el 8 de Septiembre de De manera general se puede decir que la NOM-024 es una regulación de los Registros Electrónicos en Salud, que para lograrlo establece el uso de mecanismos de seguridad (el protocolo HTTPS) e interoperabilidad (el protocolo HL7) para el intercambio de información entre distintas instituciones de salud. El objetivo de la norma del expediente clínico electrónico (ECE) es: establecer los objetivos funcionales y funcionalidades que deberán observar los productos de Sistemas de Expediente Clínico Electrónico para garantizar la interoperabilidad, procesamiento, interpretación, confidencialidad, seguridad y uso de estándares y catálogos de la información de los registros electrónicos en salud (Gobierno Federal de México, 2010). Acorde al panorama actual de las instituciones de salud pública y privada, donde los sistemas de ECE, en cada una de éstas, al tener implementaciones distintas no garantizan la interoperabilidad de la información entre las mismas. Debido a que cómo en la NOM-024 se indica Los objetivos de los sistemas de salud en el mundo siguen siendo mejorar la calidad de atención y seguridad del paciente en la provisión del cuidado a la salud, asegurar la equidad en entrega y disponibilidad de los servicios de salud y por supuesto mejorar la vigilancia de las enfermedades infecciosas emergentes (Gobierno Federal de México, 2010), esto no se alcanzan si no se tiene un ECE integro y completo entre las distintas instituciones de salud. Adicionalmente en la NOM-024 se indica que La mejora de la atención de los pacientes es la razón principal para regular los Registros Electrónicos de Salud. En estudios recientes se ha demostrado que en varios escenarios reales de atención, la información clínica esencial no se encuentra disponible para el personal médico, y en algunas ocasiones es la fuente principal de errores médicos que pueden ser prevenidos con información clínica accesible y precisa obtenida en los expedientes clínicos (Gobierno Federal de México, 2010). 2.2 HL7 (Health Level Seven International, 2012) Health Level Seven (HL7) fue fundada en 1987 y es una organización sin fines de lucro que desarrolla estándares acreditados por el American National Standard Institute (ANSI). HL7 y sus 8 P á g i n a

22 Capítulo 2.- Fundamento teórico miembros proporcionan un Framework (y estándares relacionados) para el intercambio, integración, compartición y recuperación de información de salud electrónica. Los estándares de esta organización definen la configuración del lenguaje de la información, como debe ser empaquetada y enviada de una parte a la otra, además establece las estructuras y tipos de datos requeridos para una perfecta integración entre sistemas. Los estándares HL7 facilitan la práctica clínica, así como también la administración, entrega y evaluación de los servicios de salud. Actualmente son los estándares de HL7 más comúnmente utilizados en el mundo HL7 CDA Release 2 (Health Level Seven International, 2012) El HL7 Versión 3 Clinical Document Architecture (CDA ) es un documento del estándar de etiquetado que especifica las estructura y la semántica de los documentos clínicos, para el propósito de intercambio entre proveedores de atención medica y pacientes. Con él se define un documento clínico que tiene las siguientes seis características: Persistencia. Administración. Potencial para autentificación. Contexto. Integridad. Legible al humano. Un documento CDA puede contener algún tipo de contenido clínico. Típicamente los documentos CDA pueden ser Resúmenes de Alta, Reporte de Imágenes, Admisiones y Físicos, Reportes de Patología y más. El uso más popular es el uso de intercambio de información entre empresas. 2.3 JSON (JSON, 2012) JSON (JavaScript Object Notation - Notación de Objetos de JavaScript) es un formato ligero de intercambio de datos. Leerlo y escribirlo es simple para humanos, mientras que para las máquinas es simple interpretarlo y generarlo. Está basado en un subconjunto del Lenguaje de Programación JavaScript, Standard ECMA-262 3rd Edition - Diciembre JSON es un formato de texto que es completamente independiente del lenguaje pero utiliza convenciones que son ampliamente conocidos por los programadores de la familia de lenguajes C, incluyendo C, C++, C#, Java, JavaScript, Perl, Python, y muchos otros. Estas propiedades hacen que JSON sea un lenguaje ideal para el intercambio de datos. 9 P á g i n a

23 Capítulo 2.- Fundamento teórico JSON está constituido por dos estructuras: Una colección de pares de nombre/valor. En varios lenguajes esto es conocidos como un objeto, registro, estructura, diccionario, tabla hash, lista de claves o un arreglo asociativo. Una lista ordenada de valores. En la mayoría de los lenguajes esto se implementa como arreglos, vectores, listas o secuencias. Estas son estructuras universales; virtualmente todos los lenguajes de programación las soportan de una forma u otra. Es razonable que un formato de intercambio de datos que es independiente del lenguaje de programación se base en estas estructuras. A continuación se mencionan cada una de estas estructuras y una breve descripción: Objeto: conjunto desordenado de pares nombre/valor, por ejemplo: {uno: 1, dos: 2}. Arreglo: es una colección de valores. Ejemplo: [1, 2, 3]. Valor: puede ser una cadena de caracteres con comillas dobles, un número, true, false, null, un objeto o un arreglo. Estas estructuras pueden anidarse. Ejemplo: [{uno: 1, dos: 2}, 3, true]. Cadena de caracteres: es una colección de cero o más caracteres Unicode encerrados entre comillas dobles usando barras divisorias invertidas como escape. Ejemplo: \ Esto es un ejemplo\. Numero: es similar a un número C o Java, excepto que no se usan los formatos octales y hexadecimales. Ejemplo: E+999. Los espacios en blanco pueden insertarse entre cualquier par de símbolos. 2.4 Ejemplo de JSON A continuación se muestra un ejemplo simple donde se define una barra de menús usando JSON (Wikipedia, 2012): {"menu": { "id": "file", "value": "File", "popup": { "menuitem": [ {"value": "New", "onclick": "CreateNewDoc()"}, {"value": "Open", "onclick": "OpenDoc()"}, {"value": "Close", "onclick": "CloseDoc()"} ] } }} 10 P á g i n a

24 Capítulo 2.- Fundamento teórico 2.5 Tecnologías de Identificación Automática y Captura de Datos Los sistemas de etiquetado de papel comenzaron a ser reemplazados en la industria en los años 70 s por una amplia clase de tecnologías llamadas Tecnologías de Identificación Automática y Captura de Datos (AIDC por sus siglas en inglés) (Hunt, Puglia, & Puglia, 2007). Las tecnologías AIDC en general no requieren de involucramiento humano con el fin de capturar datos (Vazquez-Briseno, Hirata, Sanchez-Lopez, Jimenez-Garcia, Navarro-Cota, & Nieto-Hipolito, 2012). Entre estas tecnologías podemos encontrar el Reconocimiento de Caracteres Óptico (OCR por sus siglas en inglés), los muy conocidos códigos de barras, Identificación por Infrarrojo (IR por sus siglas en inglés), la Identificación por Radiofrecuencia (RFID por sus siglas en inglés) (Hunt, Puglia, & Puglia, 2007) y muy recientemente la tecnología Near Field Communication (NFC por sus siglas en inglés) (Vazquez-Briseno, Hirata, Sanchez-Lopez, Jimenez-Garcia, Navarro-Cota, & Nieto- Hipolito, 2012). A continuación se realizara una descripción de la tecnología RFID y NFC (que es una actualización de RFID) RFID RFID es un acrónimo para Identificación por Radiofrecuencia, que es una tecnología de comunicación inalámbrica que es utilizada únicamente para identificar objetos o personas mediante etiquetas (Hunt, Puglia, & Puglia, 2007). Un sistema típico de RFID está constituido por cuatro componentes principales: tags, lectores, antenas y un host o computadora central (ver la Figura 1). Un tag RFID está compuesto por un microchip y una antena flexible instalada sobre una superficie plástica. El lector es utilizado para leer y escribir información en el tag (actualmente, el formato más común para tags es una etiqueta adhesiva de identificación). Las etiquetas inteligentes pueden ser impresas y aplicadas en algún objeto o caja (Telectrónica Codificacion S.A., 2012). Para obtener una respuesta de una etiqueta RFID, el lector emite una onda de radio, cuando el tag se encuentra dentro del rango del lector, responde identificándose a sí mismo. Las etiquetas pueden leerse a distancia sin contacto físico o línea de vista con el lector. La distancia dentro de la cual un lector puede comunicarse con una etiqueta se llama rango de lectura. Las comunicaciones entre lectores y etiquetas están gobernadas por protocolos y estándares emergentes, como el estándar de la Generación 2 de UHF para su aplicación en la cadena de abastecimiento (Telectrónica Codificacion S.A., 2012). 11 P á g i n a

25 Capítulo 2.- Fundamento teórico Figura 1.- Componentes de un Sistema RFID (Telectrónica Codificacion S.A., 2012) NFC Introducción La tecnología NFC es una tecnología inalámbrica HF de corto alcance que habilita el intercambio de datos entre dispositivos en distancias menores a los 10 cm. Esta tecnología es una actualización de RFID. Fue diseñada y comercializada por el NFC Forum (Vazquez-Briseno, Hirata, Sanchez- Lopez, Jimenez-Garcia, Navarro-Cota, & Nieto-Hipolito, 2012). El NFC Forum fue formado para avanzar en el uso de la tecnología NFC desarrollando especificaciones para asegurar la interoperabilidad entre dispositivos y servicios, además de educar el mercado acerca de NFC (NFC Forum, 2012). Debido que NFC es una actualización de RFID muchos de los conceptos mencionados en la sección anterior se tomaran en cuenta para describir la tecnología NFC como son los tags o etiquetas, tarjetas inteligentes y demás. Con una conectividad basada en estándares de tecnología, NFC armoniza con las diversas tecnologías sin contacto, habilitando las actuales y futuras soluciones en áreas como (NFC Forum, 2012): Control de acceso. Electrónicos de consumo. Cuidado de la salud. Intercambio y recolección de información. Lealtad y cupones. 12 P á g i n a

26 Capítulo 2.- Fundamento teórico Pagos. Transporte Principales beneficios de NFC (NFC Forum, 2012) NFC proporciona un rango de beneficios al consumidor y negocios, como son: Intuitivo: las interacciones NFC no requieren más que un toque. Versátil: NFC es idealmente adecuado para el amplio rango de industrias, entornos y usos. Abierto y basado en estándares: las capas subyacentes de la tecnología NFC se rige por los estándares universalmente implementados ISO, ECMA y ETSI. Habilitador de tecnologías: facilita la configuración rápida y simple de tecnologías inalámbricas (Bluetooth, Wi-Fi, etc.). Inherentemente seguro: las transmisiones NFC son de corto alcance (a menos de 10 cm.). Interoperable: NFC trabaja con las tecnologías de tarjetas sin contacto (ISO A y B). Seguridad exprés: NFC tiene incorporadas capacidades para proporcionar aplicaciones seguras El Protocolo NCFCIP El estándar internacional Near Field Communication Interface and Protocol, ISO/IEC 18092, define los modos de comunicación para el protocolo e interface NFC. De acuerdo a este estándar, un dispositivo NFC puede operar en modo pasivo o activo. En modo activo, los dispositivos generan su propio campo electromagnético independiente, mientras en modo pasivo solo uno de ellos es capaz de de generar un campo electromagnético y el otro obtiene energía de ese campo para poder operar y transmitir la información requerida (Vazquez-Briseno, Hirata, Sanchez-Lopez, Jimenez-Garcia, Navarro-Cota, & Nieto-Hipolito, 2012). Debido a lo anterior y establecido también por el NFC Forum se tienen tres modos de operación para las aplicaciones NFC (Dünnebeil, Köbler, Koene, & Krcmar, 2011): El modo punto a punto (peer-to-peer) es utilizado para una comunicación bidireccional entre dos dispositivos con NFC integrado. Este modo habilita la transferencia de pequeñas cantidades de información entre dos teléfonos móviles, por ejemplo: información de redes sociales y contactos ó los datos enviados en el emparejamiento bluetooth. El modo de emulación de tarjeta se basa en que un dispositivo actúa como una tarjeta inteligente. En este modo, un lector NFC externo no puede distinguir entre una tarjeta inteligente o un dispositivo NFC. Este modo es principalmente ocupado por las aplicaciones de pago y venta de boletos. El modo de lectura/escritura habilita a un dispositivo NFC para leer y cambiar los datos contenidos en un transpondedor NFC pasivo (sin fuente de alimentación propia). Estos transpondedores o tags NFC pueden ser adjuntados a Carteles Inteligentes y almacenar 13 P á g i n a

27 Capítulo 2.- Fundamento teórico información adicional, por ejemplo, una dirección Web o datos de localización para una aplicación basada en localización. NFCIP-1 define los siguientes velocidades de operación: 106, 212, 424 y 848 Kb/s. Además el protocolo define la forma en que la comunicación se debe inicializar entre dispositivos y tags, así como la forma de intercambiar datos (Vazquez-Briseno, Hirata, Sanchez-Lopez, Jimenez-Garcia, Navarro-Cota, & Nieto-Hipolito, 2012). Sobre esto último se comenta en la siguiente sección con más detalle. 2.6 Android (Ableson, Sen, & King, 2011) Android es una plataforma de software que ha revolucionado el mercado global de los teléfonos celulares. Es la primera plataforma Open Source de aplicaciones móviles que se ha mudado al mayor mercado móvil alrededor del globo. Android es ante todo un esfuerzo de Google, en colaboración con la Open Handset Alliance (OHA por sus siglas en inglés). OHA es una alianza de cerca de cincuenta organizaciones comprometidas en brindar un "mejor" y más "abierto" mercado de teléfonos móviles La plataforma Android (Ableson, Sen, & King, 2011) Android es un entorno de software construido para dispositivos móviles. No es una plataforma de hardware. Android incluye un Sistema Operativo (SO) basado en un Kernel de Linux, una interfaz de usuario rica, aplicaciones de usuario final, librerías de código, Frameworks de aplicaciones, soporte de multimedia y mucho más. Las aplicaciones de usuario desarrolladas para Android están (escritas) en Java, solo algunos componentes subyacentes del SO están escritos en C o C++. Incluso las aplicaciones empotradas están escritas en Java. Una característica de la plataforma Android es que no hay diferencia entre las aplicaciones empotradas y las aplicaciones creadas con el Android Software Development Kit (SDK por sus siglas en inglés). Esto significa que se puede escribir poderosas aplicaciones para aprovechar los recursos disponibles en el dispositivo. La Figura 2 muestra la relación entre Android y el hardware sobre el que se ejecuta. La característica más notable de Android puede ser su naturaleza open source, debido que los elementos faltantes pueden ser proporcionados por la comunidad de desarrolladores global. El sistema operativo de Android está basado en un Kernel de Linux que no viene con un sofisticado entorno shell, pero debido a que es una plataforma abierta, se pueden escribir e instalar shells en el dispositivo. Igualmente, los codecs multimedia pueden ser suministrados por terceros y no necesitan depender de Google o de algún otro para proporcionar una nueva funcionalidad. Este es el poder de introducir una plataforma Open Source en el mercado móvil. 14 P á g i n a

28 Capítulo 2.- Fundamento teórico Figura 2.- Las aplicaciones de Android utilizan como interfaz el Kernel de Linux el cual puede correr en varios teléfonos celulares (Ableson, Sen, & King, 2011). 15 P á g i n a

29 Capítulo 3. Estado del arte El estado del arte está integrado por la descripción de tres implementaciones de sistemas de expediente clínico electrónico en México y por cuatro investigaciones del uso de la tecnología Near Field Communication (NFC) con fines de identificación de pacientes en entornos clínicos.

30 Capítulo 3.- Estado del arte Los trabajos que a continuación son presentados, se clasifican en dos categorías: Implementación de expedientes clínicos electrónicos en México. Sistemas y prototipos que integran la tecnología NFC en entornos clínicos. 3.1 Implementación de Expedientes Clínicos Electrónicos en México En esta sección se presentan las implementaciones de expedientes clínicos electrónicos, más relevantes, desarrolladas en México. La finalidad de realizar este estudio es la de conocer el panorama actual con respecto a los expedientes clínicos electrónicos y conocer las tecnologías utilizadas actualmente en los mismos Prototipo DOXH 1.0 (Alvarado, 2011) El prototipo DOXH 1.0 es el resultado de la tesis de maestría titulada PROPUESTA DE MODELO PARA UN EXPEDIENTE CLÍNICO ELECTRÓNICO. La finalidad del prototipo era presentar una implementación del modelo de expediente clínico electrónico propuesto por el autor (Figura 3) el cual fue realizado cumpliendo con las normas mexicanas vigentes y a requerimientos obtenidos de entrevistas con diversos especialistas en medicina. 17 P á g i n a

31 Capítulo 3.- Estado del arte Figura 3.- Arquitectura general del DOXH 1.0 el cual está basado en una arquitectura de n capas (Alvarado, 2011). Con relación al llenado del expediente clínico electrónico en este prototipo, se implementó un sistema de autocompletado de palabras para auxiliar al médico, enfermera o administrador durante el llenado de ciertas partes del expediente. Su funcionamiento se basa en extraer información de catálogos (de tratamientos, diagnósticos, medicamentos, signos vitales, etc.) almacenados en una base de datos que coincida con la palabra escrita por el usuario, la cual se muestra al usuario en forma de lista (Figura 4). Cabe mencionar que el prototipo DOXH 1.0 fue desarrollado como una aplicación web para acceder al mismo desde distintos lugares ya sea desde una computadora o dispositivo móvil. 18 P á g i n a

32 Capítulo 3.- Estado del arte Figura 4.- Ejemplo del funcionamiento del sistema de autocompletado de palabras en el prototipo DOXH 1.0 (Alvarado, 2011) Health Digital Systems (HDS, 2012) Health Digital Systems (HDS) es una empresa mexicana que desde 2003 opera creando software de salud y actualmente tiene presencia en otros países (por ejemplo Colombia). Su herramienta más importante es el Portal Médico Dendritas (PMD), el cual es un sistema que gestiona la información de los pacientes de forma integral a través de internet. La herramienta está al alcance de cualquier médico del sector público (o privado) para crear y obtener la información de los pacientes, esto debido a su bajo precio (CNN Expansion, 2012). El acceso al mismo puede ser realizado desde cualquier computadora o dispositivo móvil (CNN Expansion, 2012). 2012): Algunas de las funciones que podemos encontrar en el PMD son las siguientes (HDS, Foros de discusión. Tablero de anuncios. Comités de segunda opinión. Vademécum y distintas fuentes de información utilizadas por los médicos. 19 P á g i n a

33 Capítulo 3.- Estado del arte Recordatorio de citas y tareas. Agenda e interoperabilidad con celulares que soportan Java. Soporte de imagenopedia y casos de estudio Expediente Clínico Electrónico del IMSS (IMSS, 2012) El Instituto Mexicano del Seguro Social (IMSS) es la institución de vanguardia en la salud y en los expedientes clínicos electrónicos en México (DGIS, 2012). Esto último debido a que actualmente cuenta con tres sistemas de información que recolectan la información de los pacientes como expedientes clínicos electrónicos. Estos sistemas mencionados son los siguientes: Sistema de Información de Medicina Familiar (SIMF), Sistema de Consulta Externa Hospitalaria (SICEH) y el Sistema de Información Hospitalaria IMSS-Vista los cuales se pueden observar en la Figura 5 (IMSS, 2012). Figura 5.- Esquema general del Expediente Electrónico del Paciente del IMSS (Fernández, 2006). Los estándares internacionales utilizados por el IMSS en su Expediente Clínico Electrónico son: el HL7 para intercambio de datos clínicos, SOAP y DICOM para imaginología digital [ (DGIS, 2012), (Fernández, 2006)]. Cabe destacar que el sistema de expediente clínico electrónico del IMSS cuenta con la mayor cobertura en México (IMSS, 2007). El siguiente paso es unificar los tres sistemas en una plataforma tecnológica llamada Nuevo Expediente Clínico Electrónico (NECE) que proporcione las funcionalidades de SIMF, SICEH y el IMSS-Vista. Para el 2011 el desarrollo de NECE estaba por terminarse y en planes de realizar pruebas para su posterior implementación (IMSS, 2012). 20 P á g i n a

34 Capítulo 3.- Estado del arte Comparación de las implementaciones de Expedientes Clínicos Electrónicos Tabla 3.- Comparación de implementaciones de Expediente Clínico Electrónico en México. Expediente Clínico Electrónico Tecnologías de desarrollo Apego a la NOM-168 Software propietario Integración del CIE 10 Estándares de interoperabilidad Soporte de imaginología DOXH 1.0 Microsoft Visual Studio 2010 Si Indefinido Si No implementado No HDS No especificado No especificado Si Si HL7 Si IMSS No especificado Si Indefinido Si HL7 Versión 3 Si (DICOM) 3.2 Sistemas y prototipos que integran la tecnología NFC en entornos clínicos A continuación se describen algunos prototipos y sistemas que integran la tecnología NFC para el manejo de la información clínica de los pacientes. Las tres investigaciones presentadas tienen como finalidad común identificar de forma única a una persona, aunque difieren en los escenarios y tecnologías donde fueron desarrollados. La intención de mostrar estas investigaciones es que adicionalmente a que utilizan NFC para identificar de forma única a una persona, también hacen uso de los tags NFC para almacenar datos relacionados al paciente El prototipo SemTag (Dünnebeil, Köbler, Koene, & Krcmar, 2011) El prototipo SemTag surge de la necesidad en el sector de la población de más de 65 años que es vulnerable a una emergencia médica y además siendo que un 23 por ciento de la población de Alemania es soltera. Entonces en caso de un percance el equipo de emergencia solo tiene una fuente de información posible que es el paciente, el cual puede estar en una condición en la que no pueda proporcionar información alguna. En Alemania se ha propuesto por las autoridades de salud una Infraestructura Telemática (TI) de cobertura nacional, con el fin de unificar a todos los sistemas de información de los distintos proveedores de salud. Parte de dicha propuesta incluye el uso de dispositivos electrónicos (por ejemplo: Tablets) y el sistema de Tarjetas de Salud Electrónicas (ehc por sus siglas en inglés) para almacenamiento de la información del paciente así como también el uso de repositorios centrales. De manera general la TI propuesta ofrecería acceso a la información del paciente por medio de servicios Web y los datos del mismo estarían alojados en servidores centrales. La idea de que los datos clínicos de los pacientes estén alojados en un solo lugar ha causado rechazo en los médicos por aceptar la iniciativa de TI. La mayor parte de los servicios propuestos de la TI han sido 21 P á g i n a

35 Capítulo 3.- Estado del arte pospuestos por cuestiones de privacidad a excepción de los registros de emergencia que es parte del sistema ehc. El prototipo SemTag pretende ayudar a la aceptación del Sistema ehc al incorporar la tecnología NFC en las Tarjetas Inteligentes agregándoles seguridad y permitiendo un almacenamiento descentralizado al utilizar la (reducida) capacidad de almacenamiento de los Tags NFC. El SemTag es un complemento del Sistema ehc que a su vez es parte de la infraestructura TI, que incluye en su arquitectura orientada a servicios asistencia para encriptación, firma digital y autorización a los datos de emergencia. Lo anterior se logra gracias al servicio llamado Connector que adicionalmente a las funciones mencionadas anteriormente es capaz de establecer una Red Privada Virtual (VPN por sus siglas en inglés) a los servidores centrales para solicitar claves públicas y privadas tanto de instituciones como de médicos para lograr el acceso o encriptación de los datos de emergencia del paciente Funcionamiento del SemTag En la Figura 6 se puede observar la forma de operar el prototipo SemTag. Este prototipo se compone de una aplicación Web que hace uso del elemento Connector y un lector de tarjetas inteligentes para acceder a los datos de emergencia del paciente. Los datos del paciente son manejados en formato XML de acuerdo a las especificaciones de los datos de emergencia de la TI. A continuación se describe la rutina del proceso de la Figura 6: 1. El Servicio Connector proporciona una clave simétrica que cifra el registro de datos de emergencia. 2. Debido a que la desencriptación de un conjunto de datos debe ser restringido a un grupo especifico de médicos, la clave de desencriptación solo debe estar disponible para estos. Por lo tanto la clave simétrica es cifrada con las claves públicas de los médicos del paciente. 3. Los datos y las claves encriptados son almacenados en uno o varios tags NFC. 4. Los Tags deben ser puestos en un lugar altamente visible en el hogar (ej: la entrada de la casa) y además deben ser llevados por el paciente (ej: la cartera). 5. Una Tablet clínica equipada con un RFID y un lector de tarjetas inteligentes, puede ser utilizado para leer y desencriptar los datos almacenados en los tags NFC. 6. La clave simétrica es desencriptada dentro de la tarjeta inteligente del médico utilizando la clave privada del médico. 7. La desencriptación de los datos con la clave simétrica es facilitada por el software del SemTag en combinación con el servicio Connector. 8. Los datos de emergencia entonces son mostrados por el dispositivo utilizando el Lenguaje de Hojas de Estilo Extensible (XSL por sus siglas en ingles) para mostrar el documento XML de una forma úniforme. 22 P á g i n a

36 Capítulo 3.- Estado del arte Figura 6.- Rutina del proceso del SemTag (Dünnebeil, Köbler, Koene, & Krcmar, 2011) Propuesta de un sistema de identificación por medio de NFC por IRD (Marcus, y otros, 2009) Este trabajo fue desarrollado por la organización, sin fines de lucro, Interactive Research and Development (IRD) que fue fundada en Karachi, Pakistán. La misión de IRD es mejorar el bienestar de las comunidades vulnerables a través de la innovación en la investigación y prestación de la salud. En los sistemas de salud de Karachi existe una mezcla dispar de proveedores de salud tanto públicos como privados lo que provoca que la obtención del expediente de un paciente sea complicado. Además que un paciente puede cambiar frecuentemente de proveedor. La identificación del paciente y captura de sus datos es un verdadero reto en este escenario, además si a esto se le agrega que para ciertas enfermedades por su naturaleza contagiosa (ej.: Neumonía) es necesario realizar un seguimiento de la evolución del paciente, el reto de identificar a un paciente se vuelve crucial. Con la finalidad de facilitar la detección de neumonía en niños pequeños se plantea en este trabajo un sistema electrónico que integra dispositivos móviles con NFC, para identificar y rastrear los pacientes a través de los distintos proveedores. La arquitectura del sistema se compone en dos partes: un celular y un servidor Web centralizado. En la Figura 7 se puede observar el diagrama de interacción de la arquitectura del sistema. 23 P á g i n a

37 Capítulo 3.- Estado del arte Figura 7.- Diagrama de interacción del sistema (Marcus, y otros, 2009). En el primer paso de la Figura 7 se realiza la identificación del paciente. En el sistema se utilizó el celular Nokia 6131 con tecnología NFC y como lenguaje de desarrollo J2ME en conjunto con la API JSR-257 para leer y escribir mensajes NDEF en los tags NFC. Se utilizaron los tags Mifare que hacen uso del protocolo ISO 14443A. Los tags contienen el ID del paciente, entonces un médico solo debe escanear con el celular el tag del paciente para obtener su número de identificación. En caso de que el tag este dañado o sea un nuevo paciente el médico puede ingresar el ID del paciente y escribir el mismo en un nuevo tag. Lo anteriormente descrito se puede ver en la Figura 8 que muestra la interfaz de la aplicación. En el paso 2 de la Figura 7 se muestra una interfaz al médico para que seleccione el diagnostico del paciente. Se le muestran tres opciones que son: Sin Neumonía, Neumonía leve y Neumonía grave. El médico debe seleccionar alguna de estas opciones dependiendo de la condición del paciente (ver Figura 9). 24 P á g i n a

38 Capítulo 3.- Estado del arte Figura 8.- Interfaz presentada al médico para escanear un tag o ingresar el ID del paciente manualmente (Marcus, y otros, 2009). Figura 9.- El médico debe ingresar el diagnostico del paciente (Marcus, y otros, 2009). El paso 3 se realiza una vez que el médico ingresa el diagnostico del paciente en el celular, a lo que inmediatamente se envía este ultimo junto con el ID del paciente y la ubicación del 25 P á g i n a

39 Capítulo 3.- Estado del arte dispositivo móvil al servidor web. Como medio de transmisión se utilizó la red GPRS y el protocolo HTTP. Para ofrecer una mayor seguridad en el manejo de los datos del paciente se puede utilizar el protocolo de encriptación SSL. Adicionalmente se puede emplear un sistema de clave asimétrica para garantizar que los datos son confiables. Debido a que el tiempo de espera utilizando GPRS puede demorar varios segundos y para evitar que la pantalla el dispositivo móvil se bloqueara, se implementó un sistema de registro de cada diagnostico dentro del móvil y un hilo que se ejecuta en segundo plano cuando se realiza un cambio el sistema de archivos hasta que se recibe la respuesta por medio de un mensaje HTTP GET Sistema RFID de Administración de Registros y Rastreo (Zalzala, Chia, Zalzala, & Karimi, 2011) El proyecto de Desafío de Tecnología Humanitaria (HTC por sus siglas en ingles) surge de la necesidad de identificar los mayores retos debido a la falta de una adecuada disposición del cuidado de la salud en países en desarrollo. El proyecto lo componen instituciones sin fines de lucro (como la Fundación IEEE, la Fundación de las Naciones Unidas, etc.), estudiantes, humanitarios y demás personas interesadas en resolver los mismos problemas que HTC. Los principales retos a resolver son: electricidad confiable, conectividad de datos y la identificación ligada a los expedientes clínicos. El último reto es el que se aborda en este trabajo. Identificar a una persona de forma univoca evita cometer errores en el momento de proporcionar atención médica. Para la implementación de un sistema de expedientes clínicos electrónicos es necesario contar con sistema de identificación de los pacientes. Son muchas las ventajas de identificar correctamente a una persona, pero son más las desventajas y entre las más importantes es que se corre el riesgo de realizar un diagnostico inadecuado. Un beneficio destacable de identificar unívocamente a una persona es que se pueden realizar estadísticas para control de enfermedades. La propuesta realizada por HTC es la implementación de un Sistema RFID de Administración de Registros y Rastreo para los pacientes Funcionamiento del Sistema RFID de Administración de Registros y Rastreo El Sistema RFID de Administración de Registros y Rastreo (RFID-TRM) identifica y rastrea a cada uno de los pacientes por medio de un chip RFID para habilitar el manejo de su información clínica. En la Figura 10 se puede observar la arquitectura del RFID-TRM. 26 P á g i n a

40 Capítulo 3.- Estado del arte Figura 10.- Plan de implementación del RFID-TRM (Zalzala, Chia, Zalzala, & Karimi, 2011). Como se puede observar en la Figura 10, la identificación de un paciente comienza con su registro en una BD y el almacenamiento en el chip RFID (Mifare, ICODE y tags compatibles con el ISO A o B) de información como nombre, edad, género, detalles de contacto, notas y datos de su huella digital. El chip esta embebido en una tarjeta de identificación que puede llevar el nombre de la institución prestadora del servicio de salud, la foto del paciente y datos personales. La información del paciente es almacenada en un servidor central y solo es accedida por personal autorizado, ya sea por medio de dispositivos móviles (Motorola MC75 por mencionar alguno) con lectores RFID utilizando las redes inalámbricas (Wi-FI, 3G, GPRS) o por medio de una PC o laptop. Adicionalmente el sistema debe proporcionar soporte para las tecnologías utilizadas por distintos proveedores. Los paquetes de administración de registros contemplados son 7i Clinic y Microsoft Dynamics. Para lograr la integración con distintas tecnologías, sistemas operativos y distinto hardware el sistema cuenta con tres interfaces. Con respecto al manejo de la información clínica del paciente RFID-TRM utiliza el estándar Health Level Seven (HL7) y particularmente el Clinical Documental Architecture (CDA) que es un Framework para representación de documentos clínicos en XML. Los documentos escritos en CDA pueden ser desplegados en un formato legible a los humanos. 27 P á g i n a

41 Capítulo 3.- Estado del arte Comparación de los trabajos que integran la tecnología NFC en entornos clínicos Trabajo o propuesta Plataforma de desarrollo en los dispositivos móviles Uso de redes Inalámbricas (3G, Wi-Fi, GPRS) Estándares de interoperabilidad Basado en la NOM-168 Almacenamiento de datos clínicos en el tag NFC Implementación de seguridad en el acceso a los datos clínicos del tag. Prototipo SemTag No especificado Si Si (XML según las especificaciones del TI de Alemania) No Si (Emergencia) Si (clave simétrica) Propuesta IRD de J2ME Si No aplica No No (Clave de identificación) No RFID-TRM Windows Mobile Si HL7 CDA No Si (Datos del paciente y su huella digital) Si (Validación de la huella digital y foto del paciente) Aplicación propuesta Android No HL7 CDA Si Si (Por definir) Si (Configuración de acceso en el tag) 28 P á g i n a

42 Capítulo 4. Metodología de solución En este capítulo, se presenta la metodología empleada para el manejo de la información clínica de un paciente con apego a la NOM-168 a través de un dispositivo móvil, la cual está compuesta por 2 fases principales: el análisis de la información y el desarrollo de la aplicación.

43 Capítulo 4.- Metodología de solución 4.1 Introducción La metodología de solución mostrada en la Figura 11 se compone de dos fases principales: análisis de la información y desarrollo de la aplicación. Cada una de éstas se compone de actividades que describen la secuencia que se siguió para desarrollar la aplicación. Las actividades van desde delimitar la cantidad de información que será manipulada por la aplicación hasta la forma en que ésta información debe ser manejada en el tag NFC. En la primera etapa llamada análisis de información se obtiene un conjunto de información referente al paciente, la cual es obtenida a partir del estudio de la NOM-168 (Gobierno Federal de México, 1999). Para obtener dicha información se realizó una selección de la información más importante a partir de criterios de selección. Una vez que se obtuvo la información se convirtió al estándar HL7 CDA Versión 2 (HL7, 2004). Como resultado de esta fase se obtuvo un documento XML que se utilizó como una plantilla para crear documentos clínicos electrónicos. En la segunda etapa denominada Desarrollo de la aplicación, con base en la información contenida en el documento XML se desarrolló la aplicación: la interfaz de usuario, la base de datos, la traducción de la información a JSON, el manejo de los datos clínicos en el tag NFC y demás aspectos de la aplicación que será explicado a detalle en la sección P á g i n a

44 Capítulo 4.- Metodología de solución Figura 11.- Las 2 etapas de la metodología de solución. Como resultado de las fases descritas anteriormente, se obtuvo una aplicación móvil para el sistema operativo Android 4.2, la cual permite el manejo de los datos clínicos de un paciente con la tecnología NFC. Entre la información clínica contemplada se encuentra: la ficha de identificación del paciente, antecedentes heredo-familiares, antecedentes personales patológicos y antecedentes personales no patológicos. 4.2 Fase 1.Analisis de la información En la Figura 12 se muestra la fase de análisis de la información, que es una fase importante porque es donde se realiza la selección de la información que será contemplada para ser almacenada en el tag NFC. Como se recordará, la memoria de un tag NFC es relativamente escasa. La cantidad máxima de memoria de los tags varían desde 1 Kb, 4 Kb, 8 Kb y 1 Mb, dependiendo el modelo. Entonces la elección de la información a ser incluida en el tag tiene gran relevancia. Es por ello la justificación del análisis de la NOM-168 y además debido a que el tag NFC utilizado en esta tesis cuenta con 1Kb de memoria que tiene el nombre de Mifare Classic 1Kb (NXP, 2013). 31 P á g i n a

45 Capítulo 4.- Metodología de solución Figura 12.- Primera fase nombrada análisis de la información. La finalidad de esta fase es obtener un documento XML que contenga los datos clínicos del paciente de acuerdo al estándar HL7 CDA Versión 2 y que estos mismos datos cumplan con la NOM-168. Este documento es necesario para que el desarrollo de la aplicación gire alrededor a este conjunto de información. A continuación se describen las actividades que se realizaron para obtener dicho documento Proceso 1 La NOM-168 establece los datos mínimos del paciente y de la institución prestadora de servicios médicos que deben contenerse en el expediente clínico. Debido a que la aplicación desarrollada en la presente tesis no será implementada en alguna institución u hospital, sino más bien es una propuesta para que los pacientes lleven consigo parte de su información clínica y pueda ser accedida en caso de un percance, se ha descartado los puntos de la norma que se refieren a los datos de la institución. El punto 5.9 de la NOM-168 indica cualquier nota del expediente clínico incluir los siguientes elementos: fecha, hora, nombre completo y firma de quien la elabora (Gobierno Federal de México, 1999). Estos datos son incluidos en la información que se almacenará en el tag NFC a excepción de la firma de quien la elabora. Esto debido que la NOM-168 hace referencia a la firma autógrafa de los prestadores de servicios médicos. Aunque la NOM-024 (Gobierno Federal de México, 2010) del expediente clínico electrónico contempla el uso de la firma electrónica simple en el manejo de la información clínica en forma electrónica. La aplicación desarrollada no pretende ser un sistema de expediente clínico electrónico, es por ello que no se apega a dicha norma, más bien retoma ciertos puntos de la misma para enriquecer este trabajo como es el uso del estándar HL7 CDA para el manejo de los mismos de forma electrónica. 32 P á g i n a

46 Capítulo 4.- Metodología de solución En el punto 5.13 de la NOM-168 se indica qué se debe aplicar a los expedientes clínicos de los servicios de: consulta externa (general y especializada), urgencias y hospitalización (Gobierno Federal de México, 1999). Los expedientes clínicos de cada uno de estos servicios difieren en la cantidad y tipo de notas por las que se componen. A continuación se muestran los expedientes clínicos de las tres áreas mencionadas anteriormente y sus notas: Consulta Externa: o Historia clínica. o Nota de evolución. o Nota de interconsulta o Nota de referencia/traslado. Notas médicas en Urgencias: o Nota inicial. o Nota de evolución. o Nota de referencia/traslado. Hospitalización: o Nota de ingreso. o Historia clínica. o Nota de evolución. o Nota de referencia/traslado. o Nota pre-operatoria. o Nota pre-anestésica, vigilancia y registro anestésico. o Nota post-operativa. o Nota de egreso. De las notas anteriormente presentadas la mayoría se elaboran en ciertas circunstancias (por ej.: cirugías, traslados u hospitalizaciones). Entonces se descartaron este tipo de notas circunstanciales y se eligió la Historia Clínica. Una razón adicional de elegir esta nota es debido a que la información que abarca, en su mayoría, se refiere a los padecimientos del paciente. En seguida se muestran los elementos de la Historia clínica en el mismo orden que establece la norma: Interrogatorio: o Ficha de identificación. o Antecedentes heredo familiares. o Antecedentes personales patológicos (incluidos ex-fumador, ex-alcohólico y exadicto). o Antecedentes personales no patológicos. 33 P á g i n a

47 Capítulo 4.- Metodología de solución o Padecimiento actual (incluido tabaquismo, alcoholismo y otras adicciones). o Interrogatorio por aparatos y sistemas. Exploración física: o Habitus exterior. o Signos vitales (pulso, temperatura, tensión arterial, frecuencia cardiaca y respiratoria). o Datos de cabeza, cuello, tórax, abdomen, miembros y genitales. Resultados previos y actuales de estudios de laboratorio, gabinete y otros. Terapéutica empleada y resultados obtenidos. Diagnósticos o problemas clínicos. Como ya se mencionó anteriormente, el tag NFC utilizado para almacenar datos clínicos es el Mifare Classic 1Kb con el cual se tiene un espacio de almacenamiento muy limitado. Tomando esto en cuenta, en un principio se eligieron los elementos de ficha de identificación, antecedentes heredo familiares, antecedentes personales patológicos y antecedentes personales no patológicos, pertenecientes a la nota de interrogatorio, para ser almacenadas en el tag NFC. Sintetizando todo lo anterior la información elegida es la siguiente: Fecha, nombre completo y titulo de quien captura la información. Ficha de identificación. Antecedentes heredo familiares. Antecedentes personales patológicos. Antecedentes personales no patológicos. En (Secretaría de Salud del Estado de México, 2013) el lector puede encontrar un manual para el llenado de los expedientes clínicos el cual estaba basado en la NOM-168. Tomando como referencia la nota de Historia Clínica General que es parte del expediente de Consulta Externa que se muestra en (Secretaría de Salud del Estado de México, 2013), se eligieron los siguientes elementos que son parte de la ficha de identificación: Nombre del paciente: o Apellido paterno. o Apellido materno. o Nombre(s). Genero (masculino o femenino). Fecha de nacimiento (día, mes y año). Ocupación del paciente. Domicilio: 34 P á g i n a

48 Capítulo 4.- Metodología de solución o Calle. o Número. o Colonia. o Municipio. o Entidad federativa. Con respecto a los antecedentes heredo familiares, antecedentes personales patológicos y antecedentes no patológicos son secciones del interrogatorio que no se componen de elementos, en estas áreas el prestador de servicios médicos escribe libremente. Con referencia a (Secretaría de Salud del Estado de México, 2013) los antecedentes heredo familiares son las enfermedades del tipo hereditario presentes en la familia del paciente, los antecedentes personales patológicos son los padecimientos que ha presentado el paciente a consecuencia de alguna enfermedad y los antecedentes personales no patológicos se refiere a los datos generales con respecto a la vivienda, escolaridad, alimentación, estado civil, etc. Adicionalmente se decidió agregar al conjunto de información los siguientes elementos por su importancia: El número de seguridad social (o NSS) del paciente. El nombre de la institución prestadora de servicios médicos al que está afiliado el paciente. Teléfono de contacto del paciente Proceso 2 En esta sección se describe el procedimiento que se llevó a cabo para obtener una plantilla del estándar HL7 CDA V2 en base a la información obtenida del Proceso 1. Para una mayor organización se dividirá en dos partes esta descripción: 1. Descripción general del HL7 CDA V2. 2. Desarrollo de la plantilla CDA en base a la información obtenida del Proceso Descripción general del HL7 CDA V2. El HL7 Clinical Document Architecture (CDA) es un documento etiquetado estándar que especifica la estructura y semántica de los documentos clínicos para el propósito de intercambio (HL7, 2004). Un documento clínico contiene observaciones y servicios que tienen las siguientes características: Persistencia - Un documento clínico continúa existiendo en un estado inalterado, por un periodo de tiempo definido localmente y por los requerimientos regulatorios. Administración - Un documento clínico es mantenido por una organización encargada de su cuidado. Potencial para la autentificación - Un documento clínico es una colección de información con la intención de ser legalmente autentificada. Contexto - Un documento clínico establece el contexto por default para sus contenidos. 35 P á g i n a

49 Capítulo 4.- Metodología de solución Integridad - La autenticación de un documento clínico aplica para la integridad y no aplica para partes del documento sin el contexto completo de sus contenidos. Legibilidad - Un documento clínico debe ser legible. Un documento CDA es un objeto de información definida y completa que puede incluir texto, imágenes, sonidos y otros contenidos multimedia (Secretaría de Salud del Estado de México, 2013). Los principales aspectos de la especificación CDA incluyen: Los documentos CDA están codificados en XML. Los documentos obtienen su significado del HL7 Reference Information Model (RIM) y del uso de los tipos de datos HL7 Versión 3. La especificación CDA es ricamente expresiva y flexible. Plantillas de nivel de documento, nivel de sección y nivel de entrada puede ser utilizado para restringir la especificación genérica CDA Alcance del CDA (HL7, 2004) El alcance del CDA es la estandarización de los documentos clínicos para el intercambio. Por eso, el formato de los datos de los documentos clínicos fuera del contexto de intercambio no es considerado en dicha especificación. El contenido clínico de los documentos CDA es definido en el HL7 RIM. Los documentos CDA pueden ser transmitidos en mensajes HL7 diseñados para transferir documentos clínicos. La especificación para dichos mensajes está fuera del alcance del CDA, sin embargo este estándar determina como empaquetar los documentos CDA dentro de mensajes HL7. El CDA no especifica la creación o administración de documentos solo el etiquetado para el intercambio. La administración de documentos esta críticamente interdependiente con las especificaciones del CDA pero esta fuera del alcance del CDA Principales conceptos CDA (HL7, 2004) Los mayores componentes de documento típico CDA son mostrados en el ejemplo de la Figura 13. Un documento CDA se encuentra determinado entre la etiqueta <ClinicalDocument>. Dicho documento se compone de dos partes: el encabezado y el cuerpo. El encabezado (que se sitúa entre el elemento <ClinicalDocument> y <StructuredBody>) identifica y clasifica tanto el documento como la información proporcionada de la autenticación, el entrevistador, el paciente y los proveedores involucrados. El cuerpo contiene el reporte clínico y puede ser tanto texto no estructurado como texto compuesto con una estructura etiquetada. En la Figura 13 se muestra un cuerpo estructurado dentro del elemento <StructuredBody> y es dividido en forma recursiva en secciones acoplables del propio documento. 36 P á g i n a

50 Capítulo 4.- Metodología de solución Figura 13.- Principales componentes de una documento HL7 CDA. Una sección de documento CDA es definida por el elemento <Section>. Cada sección puede contener un bloque de narrativa y algún número de entradas CDA y referencias externas. El bloque narrativo CDA es establecido por el elemento <text> que se encuentra anidado dentro del elemento <Section>. El elemento <text> proporciona un espacio para contenido legible al humano para ser renderizado. Las entradas CDA representan el contenido estructurado proporcionado por una computadora. Las entradas CDA codifican el contenido presente en el bloque de narrativa de la misma sección. En la Figura 13 se muestran dos entradas CDA <Observation>. Las referencias externas CDA siempre se presentan dentro del contexto de una entrada CDA y se ubican dentro del elemento <reference>. Las referencias externas se refieren a cosas que existen fuera del documento CDA (ejemplo: imágenes, procedimientos o alguna observación) que es definida entre el elemento <ExternalObservation>. La entrada CDA que envuelve la referencia externa puede ser usada para codificar porciones específicas de la referencia externa que es direccionada en el bloque de narrativa La arquitectura en CDA La especificación CDA permite el uso de códigos de documentos y secciones. Es por ello, que es posible diferencias una "Nota de consulta" de un "Informe de alta" porque los dos tendrán distintos códigos de documentos en la instancia del documento (HL7, 2004). Una plantilla HL7 proporciona un mecanismo formal para decir que una nota de consulta o informe de alta particular debe contener ciertas secciones (HL7, 2004). 37 P á g i n a

51 Capítulo 4.- Metodología de solución Legibilidad y renderización de documentos CDA El requerimiento CDA para legibilidad garantiza que un receptor de un documento CDA puede algorítmicamente mostrar el contenido clínico de la nota en un navegador Web estándar (HL7, 2004). Para lograr lo anterior es necesario el uso de una hoja de estilo especial, puede ser la misma para todos los documentos CDA de la misma categoría Especificaciones técnicas del CDA El HL7 CDA se encuentra regido por diferentes elementos que juntos permiten definir la especificación. Los elementos son: CDA R-MIM (Health Level Seven, Inc., 2005). La descripción jerárquica CDA (Health Level Seven, Inc., 2005). El esquema CDA (Health Level Seven, Inc., 2005). El HL7 RIM es la fuente de referencia para la definición de clases y atributos del CDA. La especificación no cumple rigurosamente con las definiciones del RIM, pero el CDA se basa en las definiciones del RIM. En la Figura 14 se muestra el CDA R-MIM (Health Level Seven, Inc., 2005), que es una modelo restringido del HL7 RIM. El CDA R-MIM es una copia del HL7 RIM por que utiliza las mismas clases, pero especializa algunas de ellas. El CDA R-MIM es una representación gráfica de la especificación del CDA. Comprender el CDA R-MIM es importante debido que la descripción jerárquica CDA y el esquema CDA se obtienen a partir de este modelo. Como se puede observar en la Figura 14 el CDA R-MIM está representado con la notación UML y a la izquierda de esta se puede observar la clase ClinicalDocument que tiene definidos ciertos atributos como id y title. 38 P á g i n a

52 Capítulo 4.- Metodología de solución Figura 14.- CDA R-MIM (Health Level Seven, Inc., 2005). 39 P á g i n a

53 Capítulo 4.- Metodología de solución La descripción jerárquica CDA (o CDA HD por sus siglas en inglés) es una representación tabular de la secuencia de elementos mostrados en el CDA R-MIM, pero no hace referencia a alguna implementación tecnológica. En el siguiente enlace se puede encontrar dicha descripción en formato Excel (Health Level Seven, Inc., 2005) (ver Figura 15). Dentro de un documento CDA se puede hacer referencia al CDA HD por medio de la cadena de texto POCD_HD En la Figura 15 se puede observar el elemento ClinicalDocument, que junto con sus atributos coinciden con los mostrados en el CDA R-MIM. Figura 15.- Descripción jerárquica CDA en una hoja de cálculo Excel. Por último, el esquema CDA es la descripción de la especificación de la implementación tecnológica XML HL7 (HL7 XML ITS por sus siglas en inglés). Su función básicamente es servir de referencia para que un usuario pueda relacionar los elementos de un documento CDA con su etiqueta correspondiente en XML. También se pueden encontrar los tipos de datos que deben ser utilizados y la forma de implementar bloques de narrativa. En (Health Level Seven, Inc., 2005) se pueden encontrar los documentos en formato XSD que describen el esquema CDA. A manera de seguimiento a lo descrito con las coincidencias entre el CDA R-MIM y el CDA HD, se muestra en la Figura 16 parte del esquema HL7 XML ITS donde se puede observar que el elemento ClinicalDocument y sus atributos son consistentes al CDA R-MIM y al CDA HD. 40 P á g i n a

54 Capítulo 4.- Metodología de solución Figura 16.- Parte del esquema CDA (Health Level Seven, Inc., 2005). De esta manera se da por terminada la presente sección donde se describió de manera general los componentes principales del estándar HL7 CDA. Para una mayor referencia se puede consultar la especificación completa (HL7, 2004). Esta sección sirve como antesala para continuar con la descripción del desarrollo de la plantilla HL7 en base a la información seleccionada del Proceso Desarrollo de la plantilla CDA en base a la información obtenida del Proceso 1. En la presente sección se describirá el proceso que se siguió para crear una plantilla CDA en base a la información obtenida del Proceso 1. Dicha plantilla es importante porque a partir de la misma se desarrolló la aplicación móvil descrita en la Fase 2. Ahora, como se mencionó en la sección Descripción general del HL7 CDA V2, un documento CDA está compuesto por dos partes que son encabezado y cuerpo, las cuales se ubican dentro de la etiqueta <ClinicalDocument>. Entonces en base a la información descrita en (HL7, 2004) y (IMSS, 2013) acerca del estándar HL7 CDA, se realizó un estudio de los elementos y etiquetas contenidos este estándar y se comparo con el conjunto de información obtenida del Proceso 1. En la Tabla 4 se muestra las etiquetas correspondientes a algunos elementos seleccionados de la NOM-168, las etiquetas padres de los mismos y la sección del documento CDA a la que pertenece. Tabla 4.- Primer tabla de la correspondencia entre la información obtenida del Proceso 1 y el HL7 CDA V2. NOM-168 HL7 CDA V2 Elemento CDA Se ubica dentro de Sección del documento CDA 41 P á g i n a

55 Capítulo 4.- Metodología de solución Nombre completo del paciente <name> <patient> Encabezado Nombre <given> <patient> Encabezado Apellido paterno <family> <patient> Encabezado Apellido materno <family> <patient> Encabezado Genero <administrativegendercode> <patient> Encabezado <recordtarget> Fecha de <birthtime> <patient> Encabezado nacimiento Ocupación del <employment> <patient> Encabezado paciente Domicilio del <addr> <patientrole> Encabezado paciente Calle <streetname> <addr> Encabezado Número externo <buildingnumber> <addr> Encabezado Número interno <housenumber> <addr> Encabezado Colonia <additionallocator> <addr> Encabezado Municipio <county> <addr> Encabezado Estado <state> <addr> Encabezado Teléfono del <telecom> <patientrole> Encabezado paciente NSS <id> <patientrole> Encabezado Nombre de la institución prestadora de servicios médicos <name> < representedcustodianorganization> Encabezado El lector puede consultar la descripción jerárquica CDA (Health Level Seven, Inc., 2005) y comprobar que las etiquetas mostradas en la Tabla 4 están descritas en dicho documento y además estas son parte de la sección cabecera de un documento CDA común. Con respecto a los antecedentes heredo familiares, antecedentes personales patológicos y antecedentes personales no patológicos según se puede leer en el documento de referencia del HL7 CDA V2 (HL7, 2004), se pueden describir como bloques de narrativa. Un bloque de narrativa es un elemento donde un prestador de servicios médico puede escribir libremente. Además un bloque de narrativa se encuentra determinado por la etiqueta <text> que se encuentra anidada dentro de la sección <section>. Pero para diferenciar una sección de otra fue necesario consultar el LOINC que es un sistema universal de códigos para identificar las observaciones clínicas y de laboratorio (LOINC, 2013). En la Tabla 5 se resume el análisis tanto al LOINC como al HL7 CDA V2 que sirvió para definir los elementos de antecedentes heredo familiares, antecedentes personales patológicos y antecedentes personales no patológicos. 42 P á g i n a

56 Capítulo 4.- Metodología de solución Tabla 5.- Segunda tabla de la correspondencia entre la información obtenida del Proceso 1 y el HL7 CDA V2. Elemento de la NOM-168 Etiquetas CDA V2 HL7 Código LOINC Código resultante Antecedentes heredo familiares Antecedentes personales patológicos Antecedentes personales no patológicos <section> <text> </text> </section> <section> <text> </text> </section> <section> <text> </text> </section> " <section> <code code=" " codesystem=" " codesystemname="loinc"/><text> </text></section> <section> <code code=" codesystem=" " codesystemname="loinc"/><text> </text></section> <section> <code code=" " codesystem=" " codesystemname="loinc"/><text> </text></section> Los elementos mostrados en la Tabla 5 se ubican en la sección de cuerpo de un documento CDA. Los últimos elementos por definir su correspondencia con el HL7 CDA V2 son: Fecha, nombre completo y titulo de quien captura la información. A continuación se muestra en la Tabla 6 la correspondencia entre el HL7 CDA y dichos elementos. Tabla 6.- Correspondencia entre elementos de la NOM-168 y el estándar HL7 CDA V2. HL7 CDA V2 NOM-168 Elemento CDA Se ubica dentro de Sección del documento CDA Fecha <time> <legalauthenticator> Encabezado Nombre <given> <assignedperson> Encabezado Apellido paterno <family> <assignedperson> Encabezado Apellido materno <family> <assignedperson> Encabezado Titulo <suffix> <assignedperson> Encabezado La plantilla además de los elementos mencionados anteriormente, también contendrá elementos establecidos en el CDA R-MIM (HL7, 2004), como por ejemplo: <title> que es parte de la cabecera y está definido para dentro del elemento <ClinicalDocument>. En las Figuras 17, 18 y 19 se muestran la plantilla CDA completa con lo que se finaliza el presente proceso. 43 P á g i n a

57 Capítulo 4.- Metodología de solución Figura 17.- Primera parte de la plantilla CDA. 44 P á g i n a

58 Capítulo 4.- Metodología de solución Figura 18.- Segunda parte de la plantilla CDA. 45 P á g i n a

59 Capítulo 4.- Metodología de solución Figura 19.- Tercera parte de la plantilla CDA. 4.3 Fase 2.Desarrollo de la aplicación En esta fase se explica los procesos que se llevaron a cabo para desarrollar la aplicación que lleva por nombre EMERTAG. Como se puede observar en la Figura 20, la fase dos comenzó a partir de que se obtuvo un documento XML producto de la fase uno. Al contar con dicho documento se diseñó y desarrolló tanto la interfaz de usuario como una base de datos en SQLite (proceso 3). Por medio de la interfaz de usuario se obtienen los datos del paciente. Una vez terminado el proceso 3, se realizó el proceso 4 que consiste en convertir la información del paciente en primera instancia al formato JSON para ser almacenado en el tag NFC y, además, cuando se recuperó la información del tag NFC en formato JSON, también este proceso se encargó de transformar la información a HL7 CDA Versión 2, según el documento XML de la fase 1. Por último en el proceso 5 se desarrolló el modulo que se encarga de escribir y recuperar información en el tag NFC. Figura 20.- La segunda fase que describe el desarrollo de la aplicación Emertag. Cada uno de los procesos que conforman la fase dos de ésta metodología, son descritos a continuación presentando con más detalle cada uno de ellos, con lo que se mostrará que su finalidad 46 P á g i n a

60 Capítulo 4.- Metodología de solución no sólo consistió es desarrollar un aplicación Android, sino proponer una forma de manejo de los datos clínicos de los pacientes con ayuda de los dispositivos móviles y la tecnología NFC Proceso 3 En esta sección se describirá el proceso que se realizó para desarrollar tanto la interfaz de usuario como la base de datos para la gestión de usuarios de la aplicación que lleva por nombre Emertag. Existen una serie de limitaciones que se tomaron en cuenta para el desarrollo de estos componentes de la aplicación las cuales se describen a continuación: Sistema operativo Dispositivos móviles Tag NFC Usuarios Android fue el Sistema Operativo (SO) elegido debido a que en los últimos años la cantidad de dispositivos móviles con este sistema está creciendo a pasos agigantados (Google, 2013), convirtiéndolo en uno de los SO más populares actualmente. Además, Android ofrece un SDK (Software Development Kit) y un conjunto de herramientas de desarrollo de forma gratuita (Google, 2013). Con respecto a los dispositivos móviles elegidos son: la tableta Nexus 7 y el Smartphone Samsung Galaxy S3. La elección de estos dispositivos radica principalmente que incluyen un chip NFC, los cuales permiten la lectura y escritura de tags NFC. Elegir estos dispositivos conlleva restricciones como la versión de Android y el tamaño de pantalla. La versión de Android que incluye la tableta Nexus 7 es la 4.2 (Jelly Bean) (Google, 2013) y en el Samsung Galaxy S3 es la 4.0 (Ice Cream Sandwich) (Samsung Electronics Co.,LTD., 2013). La pantalla de la tableta es de 7 pulgadas (Google, 2013) y en cambio, la del Smartphone es de 4.8 pulgadas (Samsung Electronics Co.,LTD., 2013). Esto implica según (Android, 2013) se deben desarrollar dos interfaz de usuario para cada dispositivo por el tamaño de la pantalla, siendo la pantalla del Nexus 7 del tipo Large y Normal para el Samsung Galaxy S3. Continuando con la descripción de las limitaciones y teniendo en cuenta las ya descritas, el tag NFC elegido fue el tag Mifare Classic de 1Kb. Aunque como se puede comprobar en (Android, 2013) Android soporta gran variedad de tags y la elección de este tipo se basó en la disponibilidad y precio de los mismos. La última limitación es el tipo de usuarios que manejara la aplicación. Esta va directamente relacionada al diseño de la base de datos y enseguida se describen sus funciones: Administrador: que tiene la funcionalidad de crear, modificar y borrar usuarios, además de consultar la historial de cambios a través de búsquedas. Usuario: que define las funciones de capturar, modificar, escanear y formatear los datos del paciente en el tag NFC. 47 P á g i n a

61 Capítulo 4.- Metodología de solución Es por ello que se realizaron dos secciones en la interfaz de usuario. La primera llamada Interfaz de Administrador diseñada para gestionar usuarios y la segunda nombrada Interfaz de Usuario con la finalidad de ser utilizada por los prestadores de servicios médicos. De igual manera la base de datos fue diseñada para que por un lado se le facilite el manejo de usuarios al administrador y por otro se almacenen las actividades realizadas por los usuarios (almacenar, modificar o borrar los datos contenidos en el tag NFC). Una vez descritas todas las limitaciones tomadas en cuenta para el desarrollo de la interfaz de usuario, a continuación se muestra al lector el desarrollo de la misma Pantalla de inicio de sesión Con la primicia de que la aplicación Emertag contempla dos tipos de usuarios, era necesario realizar una pantalla de inicio se sesión (ver Figura 21). Figura 21.- Pantalla de inicio de sesión de la aplicación Emertag. En un inicio cuando la aplicación es instalada y ejecutada por primera vez, se crea el usuario administrador el cual solo tendrá acceso a la sección del administrador. Esto se debe a que el administrador tiene dentro de sus funciones registrar y crear cuentas para los usuarios (prestadores de servicios médicos). Una vez que se registren nuevos usuarios estos podrán acceder a la sección del usuario. 48 P á g i n a

62 Capítulo 4.- Metodología de solución El id de usuario y contraseña del administrador son asignadas por la aplicación, los cuales son: administrador y respectivamente. Estos pueden ser cambiados por el usuario administrador Interfaz de administrador La interfaz del administrador se compone de cuatro secciones: Nuevo usuario, Modificar usuario, Borrar usuario y Bitácora. Para dar de alta un nuevo usuario (prestador de servicios médicos), el administrador debe ingresar los siguientes datos: Titulo (MD., Enf., etc.). Nombre. Apellido paterno. Apellido materno. . Teléfono. Id del usuario. Contraseña del usuario. Después de ingresar los datos del usuario, estarán disponibles en las secciones de Modificar usuario y borrar usuario. Así mismo el nuevo usuario obtendrá el acceso para poder manipular los datos de algún paciente contenidos en un tag NFC. En las Figuras 22 y 23 se muestran las cuatro secciones de la interfaz de administrador para dispositivos con pantalla Normal tomando como referencia las recomendaciones descritas en (Android, 2013). 49 P á g i n a

63 Capítulo 4.- Metodología de solución Figura 22.- Secciones de Nuevo usuario y Modificar usuario para el tipo de pantalla Large. Figura 23.- Secciones de Borrar usuario y Bitácora para el tipo de pantalla Large. 50 P á g i n a

64 Capítulo 4.- Metodología de solución En la Figura 24 y 25 se pueden las cuatro secciones con la diferencia que fueron diseñadas para la pantalla de tipo Large establecido en (Android, 2013). Figura 24.- Secciones de Nuevo usuario y Modificar usuario para el tipo de pantalla Normal. Figura 25.- Secciones de Borrar usuario y Bitácora para el tipo de pantalla Normal. En las Figuras mostradas anteriormente se puede observar que existe una diferencia en la forma de distribuir los elementos de entrada de texto por el tamaño de la de pantalla. 51 P á g i n a

65 Capítulo 4.- Metodología de solución Interfaz del usuario La interfaz del usuario se desarrolló en base a las siguientes funciones: Escanear (visualizar), ingresar, modificar y formatear (borrar) los datos de un paciente contenidos en un tag NFC. En la Figura 26 se puede observar la pantalla principal del usuario donde se proporciona acceso a estas funciones. Figura 26.- Pantalla principal del usuario. Antes de continuar con la descripción de cada una de las funciones del usuario es necesario mencionar que se estableció un formato personalizado para almacenar datos en un tag NFC del tipo Mifare Classic. Entonces si un tag NFC no tiene dicho formato no se podrá realizar ninguna acción y mostrará un mensaje de alerta como se muestra en la Figura 27. La descripción detallada de este formato personalizado se describe en la sección que corresponde al Proceso 5 de la Fase P á g i n a

66 Capítulo 4.- Metodología de solución Figura 27.- Mensaje de alerta de un tag NFC incompatible o no formateado. Es por ello que es un requisito para realizar alguna acción con un nuevo tag, se aplique el formato personalizado al tag. Partiendo de la explicación previa se muestra en la Figura 28 la pantalla para formatear un tag NFC Mifare Classic. Figura 28.- Pantalla para aplicar el formato personalizado a un tag. 53 P á g i n a

67 Capítulo 4.- Metodología de solución En caso de que se intente formatear un tag diferente al tipo Mifare Classic, se mostrará un mensaje de alerta como el que se muestra en la Figura 29. En caso contrario se mostrará el mensaje ilustrado en la Figura 30, no importando la capacidad de almacenamiento del tag. Figura 29.- Mensaje de advertencia para un tag diferente a Mifare Classic. Figura 30.- Mensaje de formato correcto. La siguiente función a explicar es la de Nuevo registro, la cual se realiza a través de dos pantallas. La primera (ver Figura 31) que es básicamente un formulario. Para llenarlo el proveedor de servicios médicos deberá solicitar la información al paciente u obtener la información de algún expediente clínico. Si algún campo se encuentra vacio no se permitirá continuar almacenar la información en el tag y se mostraran mensajes de advertencia de los campos que necesitan ser llenados. Una vez que todos los campos se han completado, al presionar el botón de guardar se muestra la segunda pantalla (ver Figura 31) que permitirá escribir los datos en el tag NFC. Para escribir la información en el tag es necesario que sea Mifare Classic y que tenga el formato personalizado. Además la ésta es convertida a un objeto JSON, de esta manera los datos clínicos son almacenados de una forma estructurada. 54 P á g i n a

68 Capítulo 4.- Metodología de solución Figura 31.- Pantallas de almacenamiento de la información de un paciente en un tag NFC. La función de Escanear registro (ver Figura 32) consiste en mostrar los datos en un formato legible y ordenado según establece el estándar HL7 CDA Versión 2. Como se describirá con más detalle en la sección que corresponde al Proceso 4, los datos almacenados en el tag son en realidad un objeto JSON, el cual es transformado a XML y a su vez es convertido a un documento clínico bajo el estándar HL7 CDA Versión 2. Este estándar establece que para ser desplegados sus documentos clínicos es necesario un navegador web que soporte el lenguaje de transformación XSLT para convertir dichos documentos en HTML y así ser mostrados en el navegador. 55 P á g i n a

69 Capítulo 4.- Metodología de solución Figura 32.- Pantalla para escanear un tag y obtener un objeto JSON. Para desplegar el documento se realizó la combinación de un archivo XSLT y el documento clínico (XML). Esto dió como resultado una página web en HTML que puede ser desplegada en el objeto WebView (ver Figura 33) propio de la API de Android (mismo que no soporta el XSLT). Figura 33.- Pantalla para mostrar los documentos clínicos. 56 P á g i n a

70 Capítulo 4.- Metodología de solución Para finalizar con esta sección se describirá la función de Modificar registro. Dicha función es similar a la de Nuevo registro, a diferencia del primero se tienen que obtener los datos clínicos contenidos en el tag NFC para después mostrarse en una plantilla similar a la de Nuevo registro y sean modificados. Cabe mencionar que para poder guardar los cambios se debe utilizar el mismo tag NFC. Para validar que sea el mismo tag se utiliza el UID que debe coincidir al momento de obtener los datos y después al intentar guardarlos. Todo este proceso se muestra en las pantallas mostradas en la Figura 34. Figura 34.- Proceso para modificar un registro Diseño de la Base de datos El diseño de la base de datos se baso en las funciones de la aplicación Emertag. En la Figura 35 se puede observar el diagrama Entidad-Relación de la base de datos Emertag, que se compone de cuatro tablas: Persona: Esta tabla fue definida como un catálogo para almacenar los datos de los prestadores de servicios médicos. Cuenta: Almacena el Id de usuario y contraseña de los prestadores de servicios médicos, así también el tipo de cuenta que puede tener dos valores posibles: administrador y usuario. Registro: En esta tabla se almacenan las actividades que realizan los prestadores de servicios médicos con los datos de los pacientes, es por ello que se requieren el id de ambos. Las actividades almacenadas son: alta de paciente y modificación de los datos del paciente. Los campos de fecha (que incluye hora, día, mes y año) y la actividad realizada es utilizada para que el administrador pueda consultarlos en la Bitácora. Paciente: Esta tabla se almacenan los datos del paciente (NSS y nombre completo) cuando un usuario realiza alguna actividad con sus datos. 57 P á g i n a

71 Capítulo 4.- Metodología de solución Figura 35.- Modelo Entidad-Relación de la base de datos Emertag Proceso 4 En esta sección se describirá la forma en que son gestionados los datos del paciente en la aplicación Emertag. Para una mejor descripción este proceso se explicará en dos partes. La primera parte consiste a partir de que se obtienen los datos hasta el momento en que son guardados en el tag NFC que corresponde con la función de Nuevo usuario de la interfaz de usuario. La segunda parte abarca a partir del momento en que un tag es escaneado hasta que es mostrado en el dispositivo que tiene correspondencia con la función escanear de la interfaz de usuario Conversión a un objeto JSON En el transcurso de esta sección se describirá la forma en que los datos del paciente obtenidos por medio de la aplicación Emertag, son convertidos a un objeto JSON, para que posteriormente sean almacenados en un tag NFC. Lo anterior se muestra de manera gráfica en la Figura P á g i n a

72 Capítulo 4.- Metodología de solución Figura 36.- Método para convertir los datos del paciente a un objeto JSON. En la Figura 31 se puede observar la pantalla que el prestador de servicios médicos utiliza para poder capturar los datos del paciente. Estos datos pueden considerados como texto plano sin ningún formato o estructuración. Es por ello que se procedió a convertir dicho texto plano a un objeto JSON, que es un formato de estructuración de datos ligero (JSON, 2012). Pero para obtener un objeto correctamente estructurado, se realizó un mapeo de los datos del paciente (nombre, apellidos, etc.) con las etiquetas del documento clínico que se obtuvo en el proceso 2 (sección 1.2.2), lo cual se muestra en la Tabla 7. Tabla 7.- Equivalencia de los datos del paciente con el estándar HL7 CDA V2. Datos del paciente NSS Institución Nombre Apellido paterno Apellido materno Genero Fecha de nacimiento Teléfono Ocupación Calle Número exterior Número interior Colonia Estado Municipio Antecedentes heredo familiares Antecedentes personales patológicos Antecedentes personales no patológicos Etiquetas HL7 CDA clinicaldocument id custodian given family family administrativegendercode birthtime telecom jobcode streetname buildingnumber housenumber aditionallocator state county section1, title, text section2, title, text section3, title, text En un documento clínico HL7 CDA V2 se debe indicar el nombre del prestador de servicios médicos que manipula la información del paciente. Entonces es por ello que también se incluye esta información y se muestra en la Tabla P á g i n a

73 Capítulo 4.- Metodología de solución Tabla 8.- Equivalencia de los datos del prestador de servicios médicos con el estándar HL7 CDA V2. Datos del prestador de servicios médicos Titulo Nombre Apellido paterno Apellido materno Etiquetas HL7 CDA assignedperson suffix given family family Adicionalmente, se agrego una etiqueta llamada time dentro para ambos conjuntos de datos. Para el paciente significa la fecha en que fue capturada la información. Para el prestador de servicios médicos significa la última fecha que han sido manipulados los datos del paciente (crear o modificar). En la Figura 37 se muestra un ejemplo de cómo la información en texto plano es estructurada con el formato JSON. Figura 37.- Ejemplo de la conversión de los datos del paciente a un objeto JSON. Cabe mencionar que para realizar la conversión mostrada en la Figura 37 se utilizo la API ORG.JSON (JSON, 2013). Dicha API convierte objetos Java a su equivalente en JSON. Para lograr la estructura apropiada para el objeto JSON se realizó la concatenación de objetos Java. 60 P á g i n a

74 Capítulo 4.- Metodología de solución Conversión de JSON a HL7 CDA V2 En la sección anterior se describió el proceso para convertir los datos del paciente en un objeto JSON (ver Figura 36) que se almacena en un tag NFC. Para convertir dicho objeto a un documento clínico se debe siguió un método diferente el cual es mostrado en la Figura 38. Figura 38.- Método para convertir un objeto JSON a un documento clínico HL7 CDA V2. El método consiste primero, en obtener el objeto JSON del tag NFC. Después el objeto se transforma a un documento XML equivalente el cual se puede observar en la Figura 39. De igual manera se utilizó la API ORG.JSON (JSON, 2013) para realizar la transformación entre el formato JSON y XML. 61 P á g i n a

75 Capítulo 4.- Metodología de solución Figura 39.- Documento XML obtenido a partir del objeto JSON. Una vez que se la información del paciente se encuentra en formato XML, se obtienen los valores y se agregan a la plantilla del documento clínico generado en el Proceso 2. La obtención de los valores se realiza con las clases propias de Android y la adición de los datos a la plantilla clínica se realiza por medio de concatenación de cadenas. En la Figura 40 se muestra parte del documento clínico con la información del paciente. 62 P á g i n a

76 Capítulo 4.- Metodología de solución Figura 40.- Documento clínico HL7 CDA V2 con los datos del paciente. Al obtener el documento clínico con la información del paciente, ya puede ser desplegado en el dispositivo móvil Proceso 5 El proceso 5 es el último proceso de la metodología de solución y de la fase 2. En este proceso se describe la forma en que la aplicación Emertag escribe y obtiene los datos del tag NFC. Cabe recordar que el tipo de tag NFC elegido es el Mifare Classic 1Kb el cual es soportado por Android. Por medio de la API de Android es posible realizar la escritura y lectura de datos en el tag NFC de dos formas: 1. Utilizando el estándar NDEF (Formato de Intercambio de Datos NFC) establecido por el NFC Forum. 2. Escribiendo o leyendo los datos de manera manual en el tag utilizando un formato personalizado. Con el formato NDEF se pueden realizar gestión de los datos con los tags NFC de manera sencilla y rápida. El inconveniente de usar este formato es que la información puede ser fácilmente accedida y modificada por alguna otra aplicación o persona. Debido a que los datos del paciente deben estar protegidos ante tal escenario, se optó por la segunda opción. En las siguientes secciones se explica la forma en que se desarrollo dicho formato personalizado aprovechando las características de autentificación que los tag Mifare Classic ofrecen. 63 P á g i n a

77 Capítulo 4.- Metodología de solución Tag Mifare Classic El tag Mifare Classic es una tarjeta inteligente sin contacto que cumple con el ISO/IEC Tipo A (NXP, 2013). Es utilizado en aplicaciones de transporte público, controles de acceso, credenciales para empleados, credenciales estudiantiles, etc. (NXP, 2013). Además es importante señalar que ofrece un sistema de autentificación por claves, el cual es totalmente configurable. Existen varios tamaños de memoria para este tipo de tag, siendo el de mayor tamaño el de 4Kb, pero para el desarrollo de la aplicación y explicación de esta sección solo se contempló el de 1Kb. Antes de explicar como la aplicación Emertag graba y recupera los datos del tag Mifare Classic 1Kb es necesario explicar cómo se encuentra estructurada su memoria, la autenticación de tres pasos y los bits de acceso Estructura de la memoria Conocer como se encuentra estructurada la memoria de un tag Mifare Classic de 1Kb es de vital importancia para poder almacenar datos en ella. Como el lector puede observar en la Figura 41 la memoria se encuentra divida en 16 sectores. Cada sector se compone de 4 bloques, los cuales tienen una longitud de 16 bytes cada uno. Figura 41.- Estructura de la memoria interna del tag Mifare Classic 1Kb. El cuarto bloque de cada sección contiene las llaves de acceso y los bits de configuración. Como se puede observar en la Figura 41 una llave de acceso es un valor de 6 bytes. Cada sector tiene dos llaves que son nombradas llave A y llave B. Las llaves son utilizadas para que un lector se autentique en un sector y posteriormente para realizar operaciones con los datos contenidos en cada bloque de dicho sector. Las llaves pueden ser estándares o personalizadas. 64 P á g i n a

78 Capítulo 4.- Metodología de solución Para poder acceder a cualquiera de los bloques de un sector es necesario que un lector realice la autentificación de tres pasos (explicada en la sección ) en conjunto con el tag. Una vez que un lector este autentificado podrá realizar lectura o escritura de los datos de los bloques, siempre apegándose a la política descrita en los bits de acceso. Debido a que cada sector puede tener su propia configuración la autentificación se debe realizar individualmente. Los bits de acceso pueden ser cambiados según se muestra en (NXP, 2013) donde establece políticas de autentificación y acceso a los bloques. Los bloques de datos del sector 0 no son utilizados por la aplicación Emertag, por lo que la cantidad máxima de datos disponibles para escribir es de 720 bytes Autenticación de tres pasos La autenticación de tres pasos se realiza de la siguiente forma: 1. El lector especifica el sector que desea acceder y elije el tipo de clave A o B. 2. La tarjeta lee la llave secreta y las condiciones de acceso para el sector elegido. Entonces la tarjeta envía un Número como desafío al lector (paso 1). 3. El lector calcula la respuesta utilizando la llave secreta y una entrada adicional. La respuesta es transmitida a la tarjeta junto con un desafío aleatorio. 4. La tarjeta verifica la respuesta del lector comparándolo con su propio desafío y después calcula la respuesta para el desafío del lector, para después transmitirla. 5. El lector verifica la respuesta de la tarjeta comparándola con su propio desafío. Una vez que el primer desafío aleatorio ha sido transmitido entre la tarjeta y el lector, la comunicación es encriptada Formato personalizado Una vez que se ha explicado ciertos aspectos sobre el tag Mifare Classic 1Kb, en esta sección se describirá el formato personalizado utilizado en la aplicación Emertag. Para comenzar cuando un tag Mifare Classic es fabricado se almacena la siguiente configuración: 1. Se puede realizar la autentificación con la llave A o B. 2. La llave A y B es la llave por defecto (todos los bits a 1). 3. Se puede escribir y leer con cualquier llave todos los bloques, a excepción de los bloques del sector 0 que requiere la llave B para realizar cualquier acción. Partiendo de esto, se optó por cambiar la configuración de acceso de todos los sectores de modo que solo se utilice la llave B para realizar cualquier operación. Adicionalmente la llave B fue cambiada en todos los sectores. De esta forma si alguna otra aplicación intenta autentificarse en algún sector del tag necesita conocer la llave B personalizada. Sin la autentificación dicha aplicación no podrá realizar ni escritura ni lectura de los datos contenidos en el tag. 65 P á g i n a

79 Capítulo 5. Pruebas. En este capítulo se describen las pruebas de la aplicación Emertag. Se evaluó la funcionalidad de dicha aplicación por medio del estándar IEEE (IEEE, 1998). Para ello se realizó un plan de pruebas donde se detalla las características que se probaron, los casos de estudio, las requisitos para realizarla, quien las realizó, etc. Después de realizar los casos de estudio se corrigieron los errores encontrados.

80 Capítulo 5.- Pruebas 5.1 Plan de pruebas Introducción El plan de pruebas que se presenta en ésta sección fue realizada según el estándar IEEE (IEEE, 1998). La finalidad del plan de pruebas es definir los elementos que son parte de estas, así también es un instrumento para documentar de forma detallada las mismas. Los elementos del plan de pruebas que fueron contemplados son los siguientes: Elementos de la prueba. Características probadas. Características excluidas. Enfoque. Criterio de éxito/fracaso de las pruebas. Criterios de suspensión y requerimientos de reanudación. Documentos entregables. Tareas de pruebas. Requisitos ambientales. Responsabilidades. Riesgos y contingencias. Aprobación. Nomenclatura. Conjunto de datos aleatorios. En esta sección se evaluarán ciertas características de la aplicación Emertag, producto obtenido de la metodología para el manejo de información clínica con apego a la NOM-168, la cual fue mostrada en el capítulo 4. Es por ello las características probadas están relacionadas a dicha metodología y a la forma de manejar (capturar, guardar y mostrar) la información clínica. Para probar la característica de capturar la información clínica de los pacientes fue necesario generar un conjunto de datos aleatorios, los cuales se obtuvieron de (Keen, 2013). En (Keen, 2013) se pueden obtener datos aleatorios tomando como fuente la información de distintos países, donde se podrá observar que no hay datos para nuestro país Elementos de la prueba Antes de llevar a cabo las pruebas es necesario cumplir con un conjunto de requerimientos los cuales se listan a continuación: Instalación de la aplicación Emertag en algún dispositivo móvil con tecnología NFC y con un tamaño de pantalla soportada por la misma. El registro de al menos un usuario de la aplicación Emertag. Deberá contarse con al menos 5 tags Mifare Classic 1Kb con el formato personalizado de la aplicación Emertag. 67 P á g i n a

81 Capítulo 5.- Pruebas Conjunto de datos generados de forma aleatoria para la captura de información de los pacientes. Adicionalmente los casos de prueba se deben realizar con el siguiente formato: Caso de prueba: identificador_caso_de_prueba Resultado: aprobada/no aprobada Desarrollo de la prueba: En esta parte de los casos de prueba se debe describir el proceso que se siguió para realizar la prueba. Al principio de esta sección es conveniente que se escriba una breve descripción del caso de prueba. Es recomendable que se describa cada paso que se realice en el desarrollo de la prueba y que se incluyan imágenes de los mismos. Las imágenes deberán incluirse de una forma secuencial y que cuenten con una buena resolución. Observaciones: En la parte de las observaciones se debe escribir de forma detallada todas las incidencias o errores que se encuentren al realizar el caso de prueba. Así también es importante que se incluyan las recomendaciones de quien realice la prueba. Responsable de la prueba: nombre_del_responsable Cargo: cargo_del_responsable Características probadas Las características de funcionalidad evaluadas de la aplicación Emertag se dividieron en tres categorías: administrador, usuario y características adicionales. El motivo de dicha clasificación es para establecer una mejor organización de este documento. A continuación se describen cada una de las categorías. Administrador: 1. Inicio de sesión: el administrador debe ser capaz de iniciar sesión con el usuario y contraseña por defecto. 2. Alta de usuarios: se probó la agregación de nuevos usuarios (datos personales y de cuenta) por parte del administrador. 3. Modificación de usuarios: la aplicación debe permitir modificar los datos personales y de cuenta de usuarios existentes. 4. Baja de usuarios: el administrador debe ser capaz de dar de baja las cuentas de los usuarios inactivos. 5. Consulta de la bitácora: consiste en permitir consultar la bitácora de cambios de los usuarios por NSS o por nombre del paciente. 68 P á g i n a

82 Capítulo 5.- Pruebas Usuario: 1. Inicio de sesión: los usuarios debidamente registrados deben poder iniciar sesión en la aplicación Emertag. 2. Aplicación del formato personalizado: debe aplicar el formato personalizado a un tag Mifare Classic 1Kb. 3. Captura de la información clínica: los usuarios deben poder capturar la información clínica de algún paciente. 4. Modificación de la información clínica: debe permitir la modificación de los datos de un paciente contenidos en un tag. 5. Despliegue de la información clínica: debe mostrar la información almacenada en un tag Mifare Classic 1Kb. Características adicionales: 1. Seguridad de los datos de los pacientes: los datos almacenados por la aplicación no deben ser accedidos por alguna otra aplicación Características excluidas 1. Rendimiento de la aplicación. 2. Usabilidad de la interfaz de usuario. 3. Diseño de la interfaz de usuario. 4. Adaptabilidad de la interfaz de usuario. 5. Veracidad y completes de la información clínica Enfoque Las pruebas se realizaron con la finalidad de comprobar la funcionalidad de la aplicación móvil Emertag con relación al manejo de la información clínica. Dicha información debe ser guardada, modificada y recuperada en el tag NFC. También la aplicación debe guardar la información de forma que no pueda ser alterada por personas o aplicaciones no autorizadas Criterio de éxito/fracaso de las pruebas Para cada una de las pruebas existen criterios de éxito específicos los cuales se apegan a la metodología presentada en el Capítulo 4. A continuación se listan los criterios de éxito tomados en cuenta. Si la información clínica sea la contemplada en la sección Si la información clínica es convertida a un objeto JSON. Si el objeto JSON recuperado al leer un tag NFC cumple con el estándar HL7 CDA V2. Si la información desplegada es la misma que fue recuperada al leer el tag NFC. 69 P á g i n a

83 Capítulo 5.- Pruebas Si la aplicación es capaz de escribir, modificar y recuperar datos del tag Mifare Classic 1Kb. Si los datos clínicos almacenados en el tag no pueden ser accedidos por alguna otra aplicación móvil. En caso de que alguno de los criterios anteriores no se cumpla se indicará que la función de la aplicación móvil no se cumplió y se procederá a corregir la aplicación Criterios de suspensión y requerimientos de reanudación Las pruebas pueden ser suspendidas en los siguientes criterios: En caso de que la batería del dispositivo móvil esté a punto de agotarse o se agote. Cuando el sistema Android se vuelva inestable o no responda a los comandos del usuario. Para la reanudación de la pruebas es necesario que la situación que provocó la interrupción de las mismas sea resuelta Documentos entregables de las pruebas Plan de pruebas. Reporte de resultados Tareas de pruebas En la Tabla 9 se muestran las tareas que se siguieron para llevar a cabo las pruebas a la aplicación Emertag. Tabla 9.- Tareas del plan de pruebas. Tarea Habilidades Responsabilidad 1.-Diseño del plan de pruebas Conocimiento del estándar I.S.C. Salvador Escorcia IEEE García 2.- Ejecución del plan de Conocimiento del I.S.C. Salvador Escorcia pruebas funcionamiento de la García aplicación Emertag 3.- Depuración de errores Conocimiento del lenguaje I.S.C. Salvador Escorcia Java y experiencia en el García desarrollo de aplicaciones móviles para Android 4.0 o superior 4.- Reporte de resultados I.S.C. Salvador Escorcia García 70 P á g i n a

84 Capítulo 5.- Pruebas Requisitos ambientales En esta sección se mencionan los requisitos de hardware y software necesarios para que las pruebas se realizaran, los cuales se presentan a continuación: Hardware o Dispositivo móvil con soporte para la tecnología NFC (Nexus 7 o Samsung Galaxy S3). o Tags Mifare Classic 1Kb. Software o Dispositivo móvil con Android 4.0 o superior. o Aplicación Emertag. o Java SDK 1.7. o Eclipse Responsabilidades El I.S.C. fue el encargado de realizar cada una de las tareas y pruebas mencionadas en el actual plan de pruebas. Así también fue quien elaboró la documentación y corrección de los errores encontrados Riesgos y contingencias Los errores encontrados en las funcionalidades probadas de la aplicación Emertag fueron documentados para que posteriormente se realice la corrección de los mismos. Lo anterior se realizó con el fin de mejorar el funcionamiento de la aplicación Aprobación La aprobación del presente plan de pruebas estuvo a cargo del Dr. Juan Gabriel González Serna y el Dr. Máximo López Sánchez Nomenclatura Cada prueba debe tener un identificador único para hacer referencia a la misma. Es por ello y por lo establecido en la sección Características probadas, que a continuación se establece la forma en que deben ser nombradas cada una de las pruebas: Si la prueba está relacionada al administrador, el nombre de la prueba debe incluir la palabra administrador al inicio. Así mismo si la prueba es del usuario el nombre de la misma debe iniciar con la palabra usuario. Para el caso de los nombres de las pruebas referentes a las características adicionales, deberán iniciar con la palabra adicional. De esta forma se pueden agrupar las pruebas. 71 P á g i n a

85 Capítulo 5.- Pruebas Para identificar la característica que se probó, se estableció la siguiente relación de nombres: o c1 - Inicio de sesión (administrador). o c2 - Alta de usuarios. o c3 - Modificación de usuarios. o c4 - Baja de usuarios. o c5 - Consulta de bitácora. o c6 - Inicio de sesión (usuario). o c7 - Aplicación del formato personalizado. o c8 - Captura de la información clínica. o c9 - Modificación de la información clínica. o c10 - Despliegue de la información clínica. o c11 - Seguridad de los datos del paciente. Adicionalmente se agregó un identificador numérico de dos dígitos al final del nombre de la prueba, en el supuesto que se realicen varias pruebas para probar la misma característica. Cada uno de los elementos anteriores deben ir separados por un guión bajo. Para una mejor comprensión de la nomenclatura explicada se muestra el siguiente ejemplo: administrador_c1_01 - Con este nombre se hace referencia a la primera prueba sobre la característica de inicio de sesión del administrador Conjunto de datos aleatorios Para los casos de pruebas donde es necesario contar con datos de pacientes, se generó un conjunto de datos de forma aleatoria obtenidos de (Keen, 2013). En (Keen, 2013) se ofrece de manera gratuita la generación de datos en base a bancos de datos de ciertos países, de los cuales se eligió el país de España debido a que México no figura entre los países en (Keen, 2013). Dicho datos para ser generados se deben establecer ciertos criterios de restricción y selección los cuales se describen en los siguientes puntos: 1. El Número de Seguridad Social debe ser una cadena alfanumérica de 10 letras o números. 2. El nombre de la institución será una cadena de texto de máximo 5 caracteres, esto simulando las siglas de las instituciones prestadoras de servicios médicos (por ejemplo: IMMS, ISSSTE, UMF, etc.). 3. El nombre y apellidos fueron generados de forma aleatoria obtenidos de (Keen, 2013). 4. El género fue generado aleatoriamente solo con la restricción de que podía variar entre la letra M y F para establecer el género masculino y femenino respectivamente. 5. El teléfono fue generado aleatoriamente con la restricción que deberían ser sólo 10 dígitos. 6. La ocupación fue generada de forma aleatoria por (Keen, 2013) sin ninguna otra restricción. 7. La calle, el número externo e interior fueron generados de forma aleatoria por (Keen, 2013) tomando como referencia datos de España. 8. La colonia fue generada a partir de palabras aleatorias. 72 P á g i n a

86 Capítulo 5.- Pruebas 9. El estado (o entidad federativa) fue generado aleatoriamente por el sitio tomando como referencia las regiones y ciudades autónomas de España. 10. Para generar los datos de Municipio se tomaron en cuenta las ciudades de España (Keen, 2013). 11. En el caso de los antecedentes heredo familiares, antecedentes personales patológicos y antecedentes personales no patológicos como son bloques donde el médico puede escribir libremente se eligió la generación de palabras aleatoriamente estableciendo como limite la cantidad de 5 palabras y al menos una. Lo anteriormente descrito se puede observar en la Figura 42 que muestra las opciones que se utilizaron para generar los datos de los pacientes. Figura 42.- Generación de datos aleatorios de pacientes desde (Keen, 2013). Una vez que se generaron los datos se eligieron los cinco primeros registros de un conjunto de un total de 100 para simular los datos de los pacientes. En la Tabla 10 se pueden observar los datos de los pacientes que se utilizaran para los casos de prueba que requieran de ellos. Tabla 10.- Tabla de los datos de los pacientes. Campo Paciente 1 Paciente 2 Paciente 3 Paciente 4 Paciente 5 NSS 851SP15WOX 819ID93KAH 747DM07SBH 333FZ47AYN 674KB01BDZ Institución XXTOA XGPXH PVCUN JCYCZ MCBHK Nombre Edward Audrey Aquila Leslie Jenette 73 P á g i n a

87 Capítulo 5.- Pruebas Ape. Paterno Peters Blair York Wood Walton Ape. Materno Hoffman Rosa Sims Copeland Quinn Genero M M M M M Fecha de 15/02/ /02/ /06/ /03/ /05/1924 nacimiento Teléfono Ocupación a vel tincidunt quis id Calle At Av. Sagittis Avenue Ac St. Eu Rd. Sed St. No. Exterior No. Interior Colonia sociosqu tellus aliquam urna Cras Estado Castilla y León Madrid Cantabria Galicia Melilla Municipio Palencia Fuenlabrada Santander Ourense Melilla Antecedentes heredo familiares Antecedentes personales patológicos Antecedentes personales no patológicos eu lacus. Quisque eu nibh vulputate mauris sagittis lobortis augue scelerisque mollis. Phasellus lacinia vitae, sodales at, velit. consectetuer euismod est arcu eu enim. Etiam imperdiet pellentesque eget, dictum enim nisl elementum purus, sem magna nec quam. Aliquam erat volutpat. Nulla egestas Etiam Etiam laoreet, libero et non nisi. Aenean consequat nec, mollis vitae, 5.2 Casos de pruebas Caso de prueba: administrador_c1_01 Resultado: aprobado Desarrollo de la prueba: En esta prueba se llevó a cabo el inicio de sesión del administrador con el usuario (administrador) y contraseña ( ) por defecto. Al realizar la prueba mostrada en las imágenes, se comprobó que el inicio de sesión por parte del administrador fue exitoso. 74 P á g i n a

88 Capítulo 5.- Pruebas Observaciones: No se suscito algún inconveniente durante el caso de prueba. Responsable de la prueba: Cargo: Autor Caso de prueba: administrador_c2_01 Resultado: no aprobado Desarrollo de la prueba: En esta prueba se probó la funcionalidad del administrador para dar de alta usuarios. La prueba comenzó a partir de que el administrador inicio sesión. Los datos capturados son los siguientes: Titulo: Ing. Nombre: Salvador. Apellido paterno: Escorcia. Apellido materno: García. seo11c@cenidet.edu.mx. Teléfono: Usuario: seo11c. Contraseña: seo11c. 75 P á g i n a

89 Capítulo 5.- Pruebas Como se puede observar en las imágenes, al tratar de guardar los datos del nuevo usuario se encontró con un inconveniente, el cual consistió en que en el campo usuario no acepta números cuando sí deberían ser permitidos. Para continuar con el caso de uso se cambió el nombre del usuario sin números y de esta forma el usuario fue registrado. Por lo anterior el caso de prueba fue considerado como no aprobado. Observaciones: La aplicación no acepta números en el nombre de usuario, cuando en realidad sí debería aceptarlos. El nombre del correo electrónico no se observa en su totalidad una vez escrito. Es necesario cambiar el tamaño del campo de entrada. Responsable de la prueba: Cargo: Autor Caso de prueba: administrador_c3_01 Resultado: aprobado Desarrollo de la prueba: En esta prueba se comprobó la funcionalidad de Modificación de usuarios por parte del administrador. La prueba se realizó sobre el usuario producto del caso de prueba administrador_c2_01. Los datos que fueron cambiados son los siguientes: Titulo: Se cambió Ing. por I.S.C. Se cambió seo11c@cenidet.edu.mx por salvador.escorcia@gmail.com. Teléfono: Se cambió el número por Usuario: Se cambió el usuario seo por sescorcia. Contraseña: Se cambió la contraseña seo11c por sescorcia. 76 P á g i n a

90 Capítulo 5.- Pruebas En las imágenes anteriores se muestran los pasos que se siguieron para comprobar la funcionalidad de modificación de los datos de los usuarios. Debido a que no se presentó ningún inconveniente el caso de prueba se consideró aprobado. Observaciones: No se suscitó algún inconveniente durante el caso de prueba. Responsable de la prueba: Cargo: Autor 77 P á g i n a

91 Capítulo 5.- Pruebas Caso de prueba: administrador_c4_01 Resultado: aprobado Desarrollo de la prueba: La función evaluada en este caso de prueba es la Baja de usuarios por parte del administrador. La prueba se realizó sobre el mismo usuario dado de alta en el caso de prueba administrador_c2_01. Este caso de prueba fue aprobado, esto debido a que el usuario fue dado de baja sin ningún inconveniente. Observaciones: No se suscitó algún inconveniente durante el caso de prueba. Responsable de la prueba: Cargo: Autor 78 P á g i n a

92 Capítulo 5.- Pruebas Caso de prueba: administrador_c5_01 Resultado: no aprobado Desarrollo de la prueba: En el presente caso de prueba se comprobó la función del administrador de Bitácora de cambios. En esta función el administrador puede consultar las modificaciones (alta y modificación) que se realizan a los datos del paciente contenidos en un tag. La Bitácora de cambios permite consultar dichos cambios por medio del Número de Seguridad Social y nombre del paciente. A continuación se muestran las imágenes de las búsquedas realizadas utilizando los datos del Paciente 1 y Paciente 2. Al realizar las búsquedas por medio del NSS se observó que la aplicación obtuvo de manera satisfactoria los resultados. Más en cambio al intentar buscar por el nombre del Paciente 1 y Paciente 2 no se obtuvieron resultados. 79 P á g i n a

93 Capítulo 5.- Pruebas Observaciones: La aplicación no realizó la búsqueda por medio del nombre de los pacientes, pero si por medio del NSS. Es necesario depurar la aplicación para corregir este error. Responsable de la prueba: Cargo: Autor Caso de prueba: usuario_c6_01 Resultado: aprobado Desarrollo de la prueba: En esta prueba se probó la funcionalidad de la aplicación para iniciar sesión como usuario. Como se puede observar en las imágenes el usuario registrado por el administrador inicio sesión de forma correcta. Observaciones: No se suscito algún inconveniente durante el caso de prueba. Responsable de la prueba: Cargo: Autor Caso de prueba: usuario_c7_01 Resultado: aprobado 80 P á g i n a

94 Capítulo 5.- Pruebas Desarrollo de la prueba: En el presente caso de prueba se comprobará la correcta aplicación del formato personalizado a un tag Mifare Classic 1Kb. La aplicación de dicho formato es necesaria para que el usuario pueda realizar las demás tareas que tiene asociadas. El resultado de la prueba fue satisfactorio puesto que la aplicación no mando algún mensaje de error. Observaciones: No se suscitó algún inconveniente durante el caso de prueba. Una vez que el botón de formatear ha sido presionado no es deshabilitado. No existe un botón de navegación para regresar a la pantalla principal ya sea en el menú o en alguna parte de la pantalla. Para realizar dicha acción sólo se cuenta con el botón atrás del dispositivo el cual no siempre se encuentra visible en todos los dispositivos. Responsable de la prueba: Cargo: Autor Caso de prueba: usuario_c8_01 Resultado: aprobado Desarrollo de la prueba: Este caso de prueba consiste en el registro de los datos de los pacientes en un tag Mifare Classic 1Kb. Los datos que fueron tomados en cuenta se muestran en la Tabla 10 y corresponden a los del Paciente 1. En el transcurso de esta prueba se encontró que en el campo calle no permite usar puntos, por lo cual no se puede usar abreviaciones. 81 P á g i n a

95 Capítulo 5.- Pruebas Después al momento de guardar los datos la aplicación regresó un mensaje que el tag no tenía suficiente espacio, esto debido al poco espacio del tag Mifare Classic 1Kb. Para resolver el inconveniente del espacio se omitieron algunas palabras de los campos de antecedentes personales patológicos y no patológicos. Con esto se simula el hecho de resumir por parte de los prestadores de servicios médicos. Después de ello se guardó la información correctamente en el tag. 82 P á g i n a

96 Capítulo 5.- Pruebas Observaciones: Es necesario comprobar el motivo por el cual en el campo calle no admite el uso de puntos y corregirlo. Al momento de que aparece la pantalla para escribir la información en el tag, es redundante que el usuario deba apretar el botón Escribir. Una vez que el tag fue escrito correctamente la aplicación debería mostrar un botón para regresar a la pantalla principal. Responsable de la prueba: Cargo: Autor Caso de prueba: usuario_c9_01 Resultado: aprobado Desarrollo de la prueba: En este caso de prueba se comprobó la funcionalidad de la aplicación Emertag para permitir modificar los datos contenidos en un tag. Para probar que todos los campos permiten la modificación de los datos se cambiaran los datos contenidos en el tag que corresponde al Paciente 1 por los datos del Paciente 2 según se mostró en la Tabla P á g i n a

97 Capítulo 5.- Pruebas Para realizar la prueba primero se escaneó el tag del Paciente 1. Enseguida se cambiaron los datos por los del Paciente 2. Al intentar guardar los datos la aplicación mostró un mensaje indicando que el tag no contaba con suficiente espacio, por lo que se procedió a quitar algunas palabras de las secciones de antecedentes, como si un prestador de servicios médicos resumiera las mismas. Después de lo anterior la información fue guardada en el tag. Observaciones: Al momento de escanear un tag y al escribir la información es redundante el hecho de presionar un botón para que la aplicación pueda leer el tag Mifare Classic 1Kb. Después de escribir las modificaciones en el tag, no existe un botón para regresar al menú principal. Responsable de la prueba: Cargo: Autor 84 P á g i n a

98 Capítulo 5.- Pruebas Caso de prueba: usuario_c10_01 Resultado: aprobado Desarrollo de la prueba: El presente caso de prueba consiste en probar la funcionalidad de mostrar los datos clínicos del paciente contenidos en un tag. Para realizar esta prueba se utilizó el tag del Paciente 2. Al realizar la prueba mostrada en las imágenes, se comprobó que la aplicación Emertag fue capaz de leer los datos almacenados en un tag y mostrarlos al usuario. Observaciones: No se suscitó algún inconveniente durante el caso de prueba. Responsable de la prueba: Cargo: Autor Caso de prueba: adicional_c11_01 Resultado: aprobado Desarrollo de la prueba: En el presente caso de prueba se comprobó la seguridad de los datos almacenados en un tag con la aplicación Emertag. Dicha seguridad debe consistir en que los datos de los pacientes no puedan ser leídos por medio de alguna otra aplicación. Entonces como requisito para realizar ésta prueba se instaló la aplicación NFC TagInfo que se encuentra en el Google Play y se utilizó el tag del Paciente 2. A continuación se muestran las imágenes que muestran la secuencia de pasos que se siguieron para intentar leer los datos del paciente. 85 P á g i n a

99 Capítulo 5.- Pruebas Lo primero que se realizó fue escanear el tag Mifare Classic 1Kb con la aplicación NFC TagInfo. Ésta aplicación permite conocer datos del tag, como el tipo, marca, tamaño de memoria, permisos de lectura, los datos contenidos en el tag en distintos formatos, etc. Al intentar conocer los datos que guarda el tag del Paciente 2, se observó que la aplicación fue incapaz de acceder a los mismos. El mismo resultado se obtuvo al tratar de conocer las condiciones de acceso del banco de memoria del tag. La única información que se obtuvo del tag fue referente al tipo de tag y sus características, pero no los datos que contiene. Observaciones: No se suscitó algún inconveniente durante el caso de prueba. Responsable de la prueba: Cargo: Autor 86 P á g i n a

100 Capítulo 5.- Pruebas 5.3 Depuración de errores En la sección anterior se observó que de los casos de prueba realizados solo dos no fueron satisfactorios. Dichos casos son los siguientes: administrador_c2_01 y administrador_c5_01. En esta sección nombrada Depuración de errores se describe el proceso de la corrección de los errores que ocasionaron que dichos casos no se aprobaran Corrección del caso de prueba administrador_c2_01 El inconveniente encontrado consistía que el nombre de usuario no permitió el uso de caracteres numéricos en el nombre de usuario. La corrección de dicho error se realizó modificando la validación de dichos campos, puesto que sólo aceptaba letras. Al cambiar dicha validación fue posible ingresar usuarios como los siguientes: abcd123, qwer1234, poiu2222, etc. Adicionalmente se añadió la validación para la contraseña de un usuario puesto que debe contener una longitud mayor de 6 y menor de 128 caracteres. Lo anteriormente mencionado se puede observar en el caso de prueba administrador_c2_02. Caso de prueba: administrador_c2_02 Resultado: aprobado Desarrollo de la prueba: En esta prueba se probó la funcionalidad del administrador para dar de alta usuarios. La prueba comenzó a partir de que el administrador inicio sesión. Los datos capturados son los siguientes: Titulo: Ing. Nombre: Elizabeth. Apellido paterno: Cadenas. Apellido materno: Castrejón. elicc@cenidet.edu.mx. Teléfono: Usuario: elicc11c. Contraseña: elicc11c. 87 P á g i n a

101 Capítulo 5.- Pruebas Observaciones: El error y observaciones anotadas en el caso de prueba administrador_c2_01 fueron corregidos. Responsable de la prueba: Cargo: Autor Corrección del caso de prueba administrador_c5_01 Al realizar el caso de prueba administrador_c5_01 se encontró que la aplicación no realizaba la búsqueda de los registros por medio del nombre del paciente. Al depurar la aplicación se descubrió que la causa del problema se debía a que al momento de guardar los datos del paciente en la base de datos, el campo de apellido paterno no se almacenaba y en su lugar se guardaba el apellido materno. Esto debido por un error de escritura al escribir el código de la aplicación Emertag. Dicho error fue corregido y para comprobar la funcionalidad se realizó la búsqueda del Paciente 1 y Paciente 2 repitiendo su apellido materno. Caso de prueba: administrador_c5_02 Resultado: aprobado Desarrollo de la prueba: En el presente caso de prueba se comprobó la función del administrador de Bitácora de cambios. En esta función el administrador puede consultar las modificaciones (alta y modificación) que se realizan a los datos del paciente contenidos en un tag. La Bitácora de cambios permite consultar dichos cambios por medio del Número de Seguridad Social y nombre del paciente. A continuación se muestran las imágenes de las búsquedas realizadas utilizando los datos del Paciente 1 y Paciente P á g i n a

102 Capítulo 5.- Pruebas En seguida se muestran los mismos resultados para la búsqueda por nombre tomando en cuenta que los registros almacenados de los Paciente 1 y Paciente 2 tienen el apellido materno almacenado en ambos apellidos. Cabe mencionar que este error fue corregido y por cuestiones de tiempo se probó la funcionalidad con los registros almacenados. Observaciones: Se realizó correctamente los dos tipos de búsquedas en la sección de Bitácora. Responsable de la prueba: Cargo: Autor 89 P á g i n a