NTE INEN-ISO 13606-1 - Servicio Ecuatoriano de Normalización
Anuncio
Quito – Ecuador NORMA TÉCNICA ECUATORIANA NTE INEN-ISO 13606-1 TO Primera edición 2014-01 TR AC INFORMÁTICA SANITARIA. COMUNICACIÓN DE LA HISTORIA CLÍNICA ELECTRÓNICA PARTE 1: MODELO DE REFERENCIA (ISO 13606-1:2008, IDT) EX HEALTH INFORMATICS. ELECTRONIC HEALTH RECORD COMMUNICATION. PART 1: REFERENCE MODEL. (ISO 13606-1:2008, IDT) _____________________________________ Correspondencia: Esta Norma Técnica Ecuatoriana es una traducción idéntica de la Norma Internacional ISO 13606-1:2008 DESCRIPTORES: Informática sanitaria, comunicación, historia, clínica, electrónica ICS: 35.240.80 105 Páginas © ISO 2008 Todos los derechos reservados © INEN 2014. NTE INEN-ISO 13606-1 2014-01 Prólogo nacional EX TR AC TO Esta Norma Técnica Ecuatoriana NTE INEN-ISO 13606-1 es una traducción idéntica de la Norma Internacional ISO 13606-1:2008, “Health informatics. Electronic health record communication. Part 1: reference model.”, la fuente de la traducción es la norma adoptada por AENOR. El comité nacional responsable de esta Norma Técnica Ecuatoriana y de su adopción es el Comité Interno del INEN © ISO 2008 Todos los derechos reservados © INEN 2014 2014-3946 i -5- ISO 13606-1:2008 ÍNDICE Página PRÓLOGO............................................................................................................................................... 6 INTRODUCCIÓN .................................................................................................................. 7 1 OBJETO Y CAMPO DE APLICACIÓN ........................................................................... 28 2 NORMAS PARA CONSULTA ........................................................................................... 28 3 TÉRMINOS Y DEFINICIONES ........................................................................................ 28 4 ABREVIATURAS ................................................................................................................ 33 5 5.1 5.2 CONFORMIDAD ................................................................................................................. 33 Conformidad del Sistema de HCE ...................................................................................... 33 Conformidad de los Países miembros ................................................................................. 34 6 6.1 6.2 6.3 6.4 6.5 MODELO DE REFERENCIA ............................................................................................ 34 Índice a los Paquetes............................................................................................................. 34 Paquete: Paquete del EXTRACT ........................................................................................ 36 Paquete: Paquete de DEMOGRAPHICS ........................................................................... 51 Paquete: Paquete de SUPPORT .......................................................................................... 59 Tipos de datos primitivos ..................................................................................................... 67 TR AC TO 0 ANEXO A (Informativo) PERFIL UML ........................................................................................... 68 EX ANEXO B (Informativo) RELACIÓN CON OTRAS NORMAS ................................................... 70 ANEXO C (Informativo) EJEMPLO CLÍNICO .............................................................................. 83 ANEXO D (Informativo) EQUIVALENCIA ENTRE DECLARACIONES DE REQUISITOS ................................................. 96 BIBLIOGRAFÍA ................................................................................................................................. 102 ISO 13606-1:2008 -6- PRÓLOGO ISO (Organización Internacional de Normalización) es una federación mundial de organismos nacionales de normalización (organismos miembros de ISO). El trabajo de preparación de las normas internacionales normalmente se realiza a través de los comités técnicos de ISO. Cada organismo miembro interesado en una materia para la cual se haya establecido un comité técnico, tiene el derecho de estar representado en dicho comité. Las organizaciones internacionales, públicas y privadas, en coordinación con ISO, también participan en el trabajo. ISO colabora estrechamente con la Comisión Electrotécnica Internacional (IEC) en todas las materias de normalización electrotécnica. Las normas internacionales se redactan de acuerdo con las reglas establecidas en la Parte 2 de las Directivas ISO/IEC. TO La tarea principal de los comités técnicos es preparar normas internacionales. Los proyectos de normas internacionales adoptados por los comités técnicos se envían a los organismos miembros para votación. La publicación como norma internacional requiere la aprobación por al menos el 75% de los organismos miembros que emiten voto. AC Se llama la atención sobre la posibilidad de que algunos de los elementos de este documento puedan estar sujetos a derechos de patente. ISO no asume la responsabilidad por la identificación de cualquiera o todos los derechos de patente. La Norma ISO 13606-1 fue preparada por el Comité Técnico ISO/TC 215 Informática sanitaria. TR La Norma ISO 13606 consiste en las siguientes partes, bajo el título general Informática sanitaria. Comunicación de la historia clínica electrónica: − Parte 1: Modelo de referencia EX − Parte 2: Especificación del intercambio de arquetipos − Parte 3: Arquetipos de referencia y listas de términos – Parte 4: Seguridad – Parte 5: Mensajes para el intercambio -7- ISO 13606-1:2008 0 INTRODUCCIÓN 0.1 Prólogo La meta global de la Norma ISO 13606 es definir una arquitectura de información rigurosa y estable para comunicar parte o toda la Historia Clínica Electrónica (HCE, EHR Electronic Health Record) de un único sujeto de la asistencia (paciente). Esto es para dar soporte a la interoperabilidad de los sistemas y componentes de los datos de la HCE que es necesario comunicar (acceso, transferencia, añadir o modificar) a través de mensajes electrónicos o como objetos distribuidos: – preservando el significado clínico original pretendido por el autor; – reflejando la confidencialidad de los datos según la pretensión del autor y del paciente. TO La Norma ISO 13606 no pretende especificar la arquitectura interna o el diseño de base de datos de los sistemas o componentes de la HCE. Tampoco pretende prescribir los tipos de aplicaciones clínicas que podrían pedir o contribuir a los datos de la HCE en configuraciones, dominios o especialidades concretos. Por esta razón, el modelo de información propuesto se denomina el Extracto de la HCE, y podría utilizarse para definir un mensaje, un documento o esquema XML, o un interfaz de un objeto. El modelo de información en esta parte de la Norma ISO 13606 es un Punto de Vista de Información ISO RM-ODP del Extracto de HCE. TR AC La Norma ISO 13606 considera que la HCE ha de ser la historia de salud y provisión de asistencia persistente longitudinal y potencialmente multiempresa o multinacional, relativa a un único sujeto de la asistencia (el paciente), creada y almacenada en uno o más sistemas físicos a fin de informar sobre la asistencia sanitaria futura del sujeto y proporcionar un registro medico-legal de la asistencia prestada. Dado que un servicio o sistema de HCE necesitará interactuar con otros muchos servicios o sistemas que proporcionan terminología, conocimiento médico, directrices, flujos de trabajo, seguridad, registros de personas, facturación etc. la Norma ISO 13606 sólo ha abordado aquellas áreas en la que se requiere una traza permanente de tales interacciones en la propia HCE, y requiere características específicas en el modelo de referencia para permitir su comunicación. EX La Norma ISO 13606 puede ofrecer una contribución práctica y útil para el diseño de sistemas de HCE, pero se diseñará principalmente como un conjunto común de interfaces o mensajes externos construidos por lo demás sobre sistemas clínicos heterogéneos. Esta parte de la Norma ISO 13606 es la primera de una serie de cinco en ser publicada. En esta parte de la Norma ISO 13606 la dependencia respecto al resto de partes de esta serie se indica explícitamente donde es necesario 0.2 Enfoque técnico La Norma ISO 13606 se ha diseñado sobre la experiencia práctica obtenida con la implementación de su predecesora europea, la Norma ENV 13606, otras normas y especificaciones relativas a la HCE, los sistemas comerciales y los pilotos de demostración en la comunicación de todo o parte de las HCE de los pacientes, y en quince años de hallazgos de investigación en este campo. La Norma ISO 13606 está construida sobre la Norma ENV 13606, actualizándola a fin de proporcionar una especificación más rigurosa y completa, para conciliar los nuevos requisitos identificados, para incorporar medios robustos de aplicar los modelos genéricos a los dominios clínicos individuales, para habilitar la comunicación utilizando mensajes HL7 versión 3. Se proporciona también una correspondencia con la norma experimental existente para dar soporte a los implementadores de los sistemas conformes existentes. El enfoque técnico para producir la Norma ISO 13606 ha tenido en cuenta diversas áreas contemporáneas de requisitos. a) Además de una comunicación tradicional basada en mensajes entre sistemas clínicos aislados, en ocasiones la historia clínica electrónica se implementará como un componente middleware (un servidor de historias) utilizando tecnología de objetos distribuidos y/o servicios web. b) Los “Clientes” de tales servicios de historias no serán sólo otros sistemas de historias clínicas electrónicas sino también otros servicios middleware tales como componentes de seguridad, sistemas de flujos de trabajo, servicios de soporte de alertas y decisión y otros agentes de conocimiento médico. ISO 13606-1:2008 -8- c) Existe un amplio interés internacional en este trabajo, y esta parte de la Norma ISO 13606 ha sido redactada conjuntamente entre CEN e ISO con aportaciones significativas de la mayoría de los estados miembros. d) Se ha considerado un objetivo importante la correspondencia con HL7 versión 3, para habilitar la conformidad con esta parte de la Norma ISO 13606 dentro del entorno de HL7 versión 3. e) Las aportaciones de I+D sobre las que estaba basada la Norma ENV 13606 han avanzado desde 1999 y se han tenido en cuenta nuevas e importantes contribuciones a este campo. La Fundación openEHR, que integra redes de I+D en Europa y Australia, es un ejemplo. Dada la diversidad de sistemas de HCE implantados, la Norma ISO 13606 ha establecido la mayoría de las características de la comunicación de la HCE opcionales más que obligatorias. Sin embargo, se requiere algún grado de prescripción para obtener tratamientos seguros de los Extractos HCE por los sistemas receptores de HCE, lo que se refleja en las propiedades obligatorias dentro de los modelos en las Partes 1, 2, y 4 de esta serie, y a través de las listas de términos normativos (definidas en la Parte 3 de esta serie). AC 0.3 El enfoque de un modelo dual TO En la práctica, la Norma ISO 13606 será adoptada junto con otras normas de informática sanitaria que definen aspectos particulares de la representación de los datos de salud. El anexo B explica como puede usarse la Norma ISO 13606 junto a normas complementarias clave, que incluyen al modelo de información de referencia (RIM, Reference Information Model) de HL7 Versión 3, las Normas EN 14822-1, EN 14822-2 y EN 14822-3, la Especificación Técnica CEN/TS 14822-4 (GPIC), y los proyectos de Normas prEN 12967 (HISA) y prEN13940 (CONTSYS). TR El desafío para la interoperabilidad de la HCE es concebir un enfoque generalizado para representar cualquier tipo concebible de estructura de datos de historia clínica de forma consistente. Se necesita satisfacer los registros que surjan de cualquier profesión, especialidad o servicio, mientras reconoce que los conjuntos de datos clínicos, los conjuntos de valores, las plantillas, etc., requeridos por los diferentes dominios sanitarios serán diversos, complejos y cambiarán frecuentemente con el avance de la práctica y el conocimiento clínico. Este requisito es parte del ampliamente reconocido desafío de la informatica sanitaria de interoperabilidad semántica. EX El enfoque adoptado por la Norma ISO 13606 distingue un modelo de referencia, definido en esta parte de la Norma ISO 13606 y utilizado para representar las propiedades genéricas de la información de la historia clínica, y los arquetipos (conforme a un modelo de arquetipos, definidos en la Parte 2 de esta serie), que son metadatos utilizados para definir patrones para las características específicas de los datos clínicos que representan los requisitos de cada profesión, especialidad o servicio particular. El Modelo de Referencia representa las características globales de los componentes de la historia clínica, como se agregan, y la información de contexto requerida para cumplir los requisitos éticos, legales y de procedencia. Este modelo define el conjunto de clases que forman los componentes básicos genéricos de la HCE. Refleja las características estables de una historia clínica electrónica, y podrían estar embebidas en un entorno de HCE distribuido (federado) como mensajes o interfaces específicos (como se especifica en la Parte 5 de esta serie). Este modelo de información genérico necesita complementarse con un método de comunicación y compartición formal de la estructura organizativa de las clases predefinidas del fragmento HCE que corresponde a conjuntos de componentes de la historia realizados en situaciones clínicas particulares. Estas efectivamente son combinaciones pre-coordinadas de jerarquías de RECORD_COMPONENT designadas que se acuerdan dentro de una comunidad a fin de asegurar la interoperabilidad, la consistencia y la calidad de los datos. Un Arquetipo es la definición formal de combinaciones prescritas de las clases componentes-básicos definidas en el Modelo de Referencia para dominios u organizaciones clínicas particulares. Un arquetipo es una expresión formal de un distinto, concepto a nivel dominio, expresado en la forma de restricciones sobre los datos cuyas ocurrencias son conformes con el modelo de referencia. Para un EHR_Extract como está definido en esta parte de la Norma ISO 13606, una ocurrencia de arquetipo especifica (y efectivamente limita) una jerarquía concreta de subclases de RECORD_COMPONENT, que definen o limitan sus nombre y otros valores de atributos relevantes, la opcionalidad y la multiplicidad en cualquier punto de la jerarquía, los tipos de datos y rangos de valores que los valores de los datos ELEMENT pueden tomar, y otras limitaciones. -9- ISO 13606-1:2008 Esta parte de la Norma ISO 13606 reconoce que los arquetipos podrían utilizarse para dar soporte en el futuro a la comunicación entre algunos sistemas de HCE, o podrían utilizarse como una especificación de conocimiento por algunos interfaces externos al sistema de HCE al realizar la correspondencia de partes de una HCE con un EHR_EXTRACT, o podría no utilizarse en absoluto entre algunos sistemas de HCE. Por tanto la Norma ISO 13606 da soporte al uso de arquetipos, pero no los hace obligatorios. En la Parte 2 de esta serie está definida una especificación para la comunicación de arquetipos. 0.4 Fundamentos de requisitos para esta parte de la Norma ISO 13606 TO Esta reconocido desde principios de los años noventa que se requiere una representación genérica para la comunicación entre sistemas de la información arbitraria de la historia clínica, y en Europa esto ha conducido a una sucesión de proyectos de I+D patrocinados por la UE, y dos generaciones de normas de informática sanitaria del CEN antes de esta misma. Estos proyectos y normas han tratado de definir las características genéricas de la información de la HCE y de plasmar esta en modelos de información y modelos de mensajes que podrían proporcionar un interfaz normalizado entre sistemas clínicos. La visión de tal trabajo ha sido habilitar sistemas clínicos diversos y especializados para intercambiar todo o partes de la HCE de una persona de forma normalizada que pueda de forma rigurosa y genérica representar los valores de datos y la organización contextual de la información en cualquier sistema en origen. Un objetivo complementario ha sido conciliar la naturaleza desarrollada del conocimiento médico y la diversidad inherente a la práctica clínica. AC Durante este periodo han tenido lugar muchas investigaciones sobre los requisitos de los usuarios y empresas para la HCE, que han tratado de abarcar las necesidades de información de las diversas especialidades a través de la atención primaria, secundaria y terciaria, entre profesiones y a través de los países. Estos requisitos han sido depurados y analizados por grupos de expertos, principalmente en Europa, a fin de identificar la información básica que es necesario conciliar dentro de una arquitectura de información de la HCE para: TR – capturar fielmente el significado original pretendido por el autor de una anotación o un conjunto de anotaciones en la historia; – proporcionar un marco apropiado a las necesidades de los profesionales y empresas para analizar e interpretar las HCE sobre una base individual o de población; EX – incorporar los constructos médico-legales necesarios para dar soporte a la comunicación segura y relevante de las anotaciones de la HCE entre profesionales que trabajan en el mismo sitio o en diferentes sitios. Este trabajo incluye los proyectos GEHR[41,48,57], EHCR-SupA[36-38], Synapses[42,43], I4C y Nora, y el trabajo desarrollado por Swedish Institute for Health Services Development (SPRI). Estas publicaciones de requisitos clave están relacionadas en la Bibliografía [51]. Recientemente estos requisitos se han consolidado en el plano internacional dentro de una Especificación Técnica de ISO, ISO/TS 18308[9]. En este modelo de referencia los requisitos contextuales clave de la HCE para tal fidelidad están relacionados con un conjunto de clases de componentes básicos lógicos, con atributos adecuados propuestos para cada nivel en la jerarquía del extracto HCE. Se ha adoptado la Especificación Técnica ISO/TS 18308 como el conjunto de requisitos de referencia para sustentar las características de este modelo de referencia de las comunicaciones de la HCE, y en el anexo D se proporciona una correspondencia de estas declaraciones de requisitos con los constructos del modelo de referencia. 0.5 Visión general de la jerarquía del registro del extracto de la HCE La información en una historia clínica es intrínsicamente jerárquica. Las observaciones, motivaciones y propósitos clínicos pueden tener una estructura simple o más compleja. Generalmente están organizadas por cabeceras, y contenidas en “documentos” tales como notas de consulta, notas e informes. Usualmente estos documentos están almacenados en carpetas, y un paciente puede tener más de una carpeta dentro de la empresa sanitaria (por ejemplo médica, de enfermería, obstétrica). ISO 13606-1:2008 - 10 - El modelo de referencia del extracto HCE necesita reflejar esta estructura y organización jerárquicas, cumpliendo requisitos publicados a fin de ser fiel al contexto clínico original y para asegurar que se preserva el significado cuando las historias se comunican entre sistemas clínicos heterogéneos. Para hacer esto, el modelo subdivide formalmente la jerarquía de la HCE en partes en las que se ha probado que proporcionan una correspondencia consistente con las formas en que se organizan las HCE individuales dentro de sistemas de HCE heterogéneos. Estas partes se resumen en la tabla 1. Tabla 1 – Componentes jerárquicos principales del Modelo de Referencia del Extracto HCE SECTION ENTRY CLUSTER ELEMENT No aplicable Atención a diabetes, esquizofrenia, colecistectomía, pediatría, St Mungo’s Hospital, Carpeta del GP, Episodios 2000-2001, Italia. AC TR COMPOSITION Ejemplos El contenedor de más alto nivel de parte o toda la HCE de un único sujeto de la asistencia, para la comunicación entre un sistema proveedor de la HCE y un receptor de la HCE. La organización de alto nivel dentro de una HCE, que la divide en compartimentos relativos a la asistencia prestada para una única condición, por un equipo o institución clínica, o durante un tiempo fijado tal como un episodio de asistencia. El conjunto de información grabada en una HCE por un agente, como resultado de un único encuentro clínico o una sesión de documentación de la historia. Datos de la HCE dentro de una COMPOSITION perteneciente a una cabecera clínica, que usualmente refleja el flujo de información reunido durante un encuentro clínico, o estructurado para una más beneficiosa lectura futura. La información registrada en una HCE como resultado de una acción clínica, una observación, una interpretación clínica o un propósito clínico. Esto se conoce también como declaración clínica. Los medios de organizar las estructuras de datos multiparte anidadas tales como las series temporales, y para representar las columnas de una tabla. El nodo hoja de la jerarquía de la HCE, que contiene un único valor de datos. EX FOLDER Descripción TO Componente de la jerarquía HCE EHR_EXTRACT Nota de evolución, formulario de resultado de pruebas de laboratorio, informe radiológico, impreso de derivación, visita clínica, nota clínica, informe de alta, evaluación funcional, revisión de diabetes. Razón para el encuentro, antecedentes, antecedentes familiares, información de alergias, síntomas subjetivos, hallazgos objetivos, análisis, plan, tratamiento, dieta, postura, examen abdominal, examen de la retina. Un síntoma, una observación, un resultado de una prueba, un medicamento prescrito, una reacción alérgica, un diagnóstico, un diagnóstico diferencial, un recuento de leucocitos, una medición de la tensión. Resultados de un audiograma, la interpretación de un electroencefalograma, diagnósticos diferenciales ponderados. Presión sanguínea sistólica, ritmo cardiaco, nombre de medicamento, síntoma, peso del cuerpo. Un EHR_EXTRACT contiene datos de la HCE como COMPOSITION, organizados opcionalmente por una jerarquía FOLDER. Las COMPOSITION contienen ENTRY, contenidas opcionalmente dentro de una jerarquía SECTION. Las ENTRY contienen ELEMENTS, contenidas opcionalmente dentro de una jerarquía CLUSTER. TR AC TO - 11 - EX Figura 1 – Diagrama de la jerarquía del Extracto de la HCE (parte 1) ISO 13606-1:2008 - 12 - AC TO ISO 13606-1:2008 TR Figura 2 – Diagrama de la jerarquía del Extracto de la HCE (parte 2) EHR_EXTRACT EX 0.6 Descripción de las clases principales del Modelo de Referencia El EHR_EXTRACT se utiliza para representar parte o toda la información de la historia clínica extraída de un sistema proveedor de HCE para los propósitos de comunicación a un receptor de HCE (que podría ser otro sistema de HCE, un repositorio de datos clínicos, una aplicación cliente o un servicio de middleware tal como un componente de directrices electrónico), y para dar soporte a la inclusión fiel de los datos comunicados en el sistema receptor. La clase EHR_EXTRACT contiene atributos para identificar al sujeto de la asistencia al que pertenece esta historia, el sistema proveedor de HCE del que ha sido extraída y el identificador de la HCE de tal sujeto en ese sistema, y opcionalmente el agente responsable de su creación. El EHR_EXTRACT contiene los datos de la HCE, en tres partes: 1) un conjunto de COMPOSITION; 2) opcionalmente, un directorio de FOLDER que proporciona una agrupación y organización de alto nivel de las COMPOSITION; 3) opcionalmente, un conjunto de descriptores demográficos para cada una de las personas, organizaciones, dispositivos o componentes de software que están identificados dentro de (1) y (2) más arriba. Este enfoque permite a tales entidades referenciarse unívocamente a través de un identificador dentro del cuerpo de la HCE, sin la repetición cada vez de los detalles descriptivos, y también asegura que cualquier EHR_EXTRACT puede interpretarse aisladamente si el sistema receptor no tiene acceso a los servicios necesarios para decodificar los identificadores de entidad utilizados por el Proveedor de HCE. - 13 - ISO 13606-1:2008 En la Parte 4 de esta serie está definido un mecanismo formal para incluir la información de política de acceso dentro del EHR_EXTRACT. Su intención es informar al Receptor de la HCE sobre los deseos del sujeto de la asistencia y de los proveedores sanitarios sobre como gestionar las peticiones futuras de acceso a los datos. TO El EHR_EXTRACT también contiene un resumen del filtro o criterios de selección con el que fue creado este EHR_EXTRACT. Esto puede o no corresponder directamente a los criterios de la petición de HCE, y proporciona un registro del tipo de subconjunto que es este EHR_EXTRACT en la HCE global almacenada por el proveedor de HCE. Esto podría tener importancia si el EHR_EXTRACT se mantiene intacto por el proveedor de HCE o por el receptor de HCE, y subsiguientemente es accedido por agentes que no tienen acceso a la petición original de la HCE. Por ejemplo esta clase puede especificar si este EHR_EXTRACT está limitado a la versión más reciente de cada COMPOSITION (tal como se requiere para la mayoría de los propósitos de atención clínica) o si incluye todas las versiones históricas (que podrían requerirse por motivos legales). Podría especificarse el máximo nivel de sensibilidad de los datos (que implica que existen datos más sensibles que este nivel y han sido filtrados), o que se han excluido objetos multimedia para limitar su tamaño total. Si el EHR_EXTRACT se creó seleccionando categorías particulares de datos clínicos (por ejemplo, solo datos de laboratorios) esto puede indicarse a través de una lista de los arquetipos que fueron incluidos en el criterio de selección. Existe una opción para incluir criterios adicionales (expresados como cadenas); esto puede utilizarse para proporcionar información adicional legible por humanos sobre este EHR_EXTRACT o puede utilizarse para información de limitaciones legible por ordenadores acordada localmente. RECORD_COMPONENT AC Las clases de componentes básicos principales que se utilizan para construir la jerarquía de datos de la HCE dentro de un EHR_EXTRACT son tipos de RECORD_COMPONENT. Esta es una clase abstracta, la superclase de todos los nodos concretos en la jerarquía de la HCE: FOLDER, COMPOSITION, SECTION, ENTRY, CLUSTER, ELEMENT, y también la superclase para otros dos nodos de clase abstracta: CONTENT e ITEM. TR RECORD_COMPONENT define las propiedades de la información que son comunes a todos estos componentes básicos, incluyendo: EX – el identificador único que fue emitido para este nodo de la HCE por el sistema de HCE en el cual fue committed por primera vez (su sistema generador de HCE); otros titulares de este RECORD_COMPONENT necesitan guardar el valor de este atributo para asegurar que cualesquiera extractos subsiguientes son siempre identificados de forma consistente; – el nombre clínico, utilizado en su sistema generador de HCE para etiquetar esta parte de los datos de la HCE; – opcionalmente un concepto codificado normalizado en el que el nombre tiene correspondencia para dar soporte a la interoperabilidad semántica de las ocurrencias de HCE equivalentes incluso si estas han recibido nombres clínicos distintos por sistemas de HCE diferentes; – el identificador del nodo del arquetipo con el que es conforme este RECORD_COMPONENT, a utilizar por los sistemas de HCE habilitados para arquetipos o sí los arquetipos han sido utilizados al hacer la correspondencia de los datos en el formato del EHR_EXTRACT; – un código de sensibilidad y referencias a las políticas de control de accesos que debería utilizar el Receptor de HCE para gobernar el acceso futuro a los datos; – soporte para enlaces entre cualesquiera componentes de la historia. Al generar un EHR_EXTRACT conforme con esta parte de la Norma ISO 13606 el sistema proveedor de HCE podría, en algunas situaciones, necesitar introducir un RECORD_COMPONENT en la jerarquía que no tiene una correspondencia directa con ningún dato original en el sistema de HCE. El atributo sintetizado de RECORD_COMPONENT permite al sistema proveedor de HCE que exporta indicar que se ha creado un RECORD_COMPONENT con este propósito dentro del EHR_EXTRACT. ISO 13606-1:2008 - 14 - Las anotaciones en las historias clínicas a menudo se refieren a otras anotaciones preexistentes, y se incluyen como "copias". Un ejemplo común de esto es un informe de alta, que podría incluir copias de diversas partes del registro de hospitalización tales como las circunstancias del ingreso, los diagnósticos más importantes, las principales intervenciones y tratamientos. En la mayoría de los casos es necesario que el EHR_EXTRACT contenga estos RECORD_COMPONENT referenciados explícitamente por su valor, de forma que cada COMPOSITION pueda ser interpretada por el Receptor de HCE. Sin embargo, desde el punto de vista médico-legal también es importante comunicar que esas anotaciones son copias, y que se generan de una parte diferente de la HCE del sujeto. El atributo opcional original_parent_ref puede utilizarse para representar la rc_id del RECORD_COMPONENT padre original si los datos son una copia. Cualquier RECORD_COMPONENT puede incluir datos de auditoría sobre cuando y quien fue grabado en su sistema generador de HCE. Cada versión revisada de un RECORD_COMPONENT puede documentar el estado de la versión, la razón para la revisión y el identificador de la versión precedente. Sin embargo, por razones de protección de datos se recomienda que no se comuniquen las versiones previas (erróneas) de una HCE como parte de la atención clínica compartida habitual, sino sólo en circunstancias en las que la transferencia de la HCE se hace por razones legales. FOLDER EX TR AC TO Es importante que cada RECORD_COMPONENT sea única y consistentemente identificado a través de múltiples EHR_EXTRACT, de forma que se mantengan válidas las referencias hacia o entre ellos. Ejemplos de tales referencias son los enlaces semánticos, la revisión y la confirmación. El atributo rc_id es del tipo de datos Instance Identifier (II), que incorpora un OID de ISO, actualmente se considera internacionalmente que II es el tipo de datos más apropiado para identificadores persistentes que se requiere que sean únicos globalmente. Es improbable que los sistemas de HCE actuales tengan claves primarias o identificadores internos que se correspondan directamente con ocurrencias II globalmente únicas. Sin embargo, un sistema proveedor de HCE que dispone de un OID organizativo podría utilizar sus referencias internas para construir extensiones locales únicas a ese OID y de ese modo construir valores de rc_id globalmente únicos. Alternativamente, podría crear rc_id completamente nuevos y retener un registro de la correspondencia de ellos con cada identificador interno, de forma que cualesquiera EHR_EXTRACT que generase utilizarían valores rc_id consistentes. También es improbable que un sistema Receptor de HCE sea capaz de utilizar los valores rc_id recibidos como sus claves primarias internas para los datos, dado que cualquier base de datos utiliza un enfoque ligeramente diferente para generar y utilizar tales claves. El receptor de HCE por tanto también podría necesitar mantener un registro de la correspondencia de los valores rc_id importados con sus claves primarias, de forma que las referencias futuras a aquellos RECORD_COMPONENT puedan asignarse apropiadamente, y pueda crear EHR_EXTRACT que reutilice aquellos valores rc_id para los datos exportados. Un enfoque alternativo para los sistemas de HCE es almacenar explícitamente los valores rc_id junto con los datos clínicos, y tratarlos como parte de los datos “útiles” y no tratar de utilizarlos como claves primarias. Debería destacarse que los rc_id no funcionan como una clave primaria equivalente dentro de un EHR_EXTRACT, es decir, están permitidos valores duplicados de rc_id si cada ocurrencia de hecho se refiere a la misma pieza de datos clínicos dentro del sistema proveedor de HCE. Esta clase se utiliza para representar las organizaciones de más alto nivel de los datos de la HCE dentro del EHR_EXTRACT, por ejemplo para agrupar las COMPOSITION por episodio, equipo de atención, especialidad clínica, condición clínica o intervalo temporal. A nivel internacional, este tipo de estructura de organización se utiliza de forma variable: en algunas empresas y sistemas el concepto carpeta se trata como una compartimentación informal de toda la historia clínica, en otras puede representar una parte legal significativa de la HCE relacionada con los servicios proporcionados por una empresa o un equipo. En el EHR_EXTRACT, las FOLDER son una jerarquía opcional. Las FOLDER pueden contener otras FOLDER para formar un sistema de directorios completo, y pueden incluir cualquier información pertinente sobre sus grabaciones o revisión dentro del sistema Proveedor de HCE. Las FOLDER referencian a las COMPOSITION a través de una lista de identificadores únicos, más que conteniéndolos físicamente. Esto permite a cualquier COMPOSITION aparecer con más de una FOLDER, que es un requisito que han indicado algunos fabricantes y jurisdicciones. En algunas situaciones las FOLDER podrían crearse específicamente para organizar el EHR_EXTRACT, o contener solo un subconjunto seleccionado de los datos en la correspondiente carpeta en el sistema proveedor de HCE. En tales circunstancias las FOLDER dentro del EHR_EXTRACT no tendrán una correspondencia directa con aquellas en el sistema proveedor de HCE que contribuye, es decir habrán sido resumidas. - 15 - ISO 13606-1:2008 Una FOLDER puede utilizarse para agrupar un conjunto de COMPOSITION que comprendan los registros individuales realizados por los miembros de un equipo multidisciplinar durante un único encuentro clínico. En situaciones como esta en las que una FOLDER representa un intervalo de asistencia, puede confirmarse. Este enfoque debería utilizarse para comunicar que los contenidos de la FOLDER son un registro completo de ese intervalo de asistencia. Esto también proporciona una indicación al receptor de HCE de que no debería añadir COMPOSITION adicionales a esta FOLDER. Dado que los sistemas de carpeta se utilizan de forma variable dentro de los sistemas de HCE, esta norma internacional no puede prescribir como se gestionarían dentro del sistema del receptor de HCE: es decir no se requiere que el receptor de HCE explícitamente los utilice dentro de su sistema de HCE. Sin embargo, si una FOLDER ha sido confirmada se conservaría una copia intacta para referencias futuras y su posible comunicación a partir de ahora. COMPOSITION TO La COMPOSITION representa el conjunto de RECORD_COMPONENT compuestos (creado) durante una sesión clínica de usuario o una sesión de documentación de la historia, para su grabación dentro de una HCE. Ejemplos comunes de esto incluyen una nota de consulta, una nota de evolución, un informe o una nota, un informe de investigación, un formulario de prescripción y un conjunto observaciones junto a la cama de enfermería. Las COMPOSITION documentan la fecha y la hora o intervalo del encuentro clínico, y la jurisdicción legal en que fueron compuestos los registros. TR AC El compositor es el agente (parte, dispositivo o software) responsable de la creación, resumen u organización de la información grabada en una HCE. Este agente toma la responsabilidad de su inclusión en esa HCE, incluso si no es el generador de ella o incluso si no es el grabador de la misma. El contenido de la COMPOSITION se atribuye fundamentalmente a esta persona. El que se cambie o no el compositor cuando se realiza una revisión es opcional. En general las aplicaciones utilizan el nombre del compositor para etiquetar los datos de la COMPOSITION para su uso en la atención clínica. Puede haber ocasiones en la que no hay un único compositor principal (por ejemplo una teleconsulta multiprofesional, o una conferencia sobre un caso); en tales casos el papel de compositor podría no estar especificado formalmente incluso aunque esté declarado cada participante y papel clínico: por lo tanto el compositor es opcional. Cada COMPOSITION tiene la condición de incluir los detalles y ubicaciones de cualesquiera otros participantes involucrados en el encuentro clínico o en la sesión de documentación de la historia. Algunos podrían haber participado desde diferentes ubicaciones (por ejemplo por teléfono, o a través de una videoconsulta). EX La COMPOSITION es la clase contenedora principal para los datos de la HCE en el propio extracto, para asegurar que se utiliza una jerarquía de contenedores consistente dentro de todos los Extractos: el EHR_EXTRACT contiene un conjunto de COMPOSITION junto con datos de auditoría sobre la grabación de cada una en el sistema Proveedor de HCE. Una COMPOSITION se utiliza siempre para comunicar actualizaciones de versión en los sistemas de HCE, incluso si las actualizaciones se refieren a partes de esa COMPOSITION. Si han de comunicarse múltiples versiones de los datos de la HCE dentro de un EHR_EXTRACT, serán como un conjunto de COMPOSITION distintas, referenciando cada una a la versión precedente y referenciando de forma colectiva a un identificador del conjunto de la versión. Opcionalmente cada COMPOSITION también documenta cualquiera de las confirmaciones (por ejemplo las firmas digitales) que le pertenecen a ella o a cualquiera de sus contenidos. Contribución La Contribución es el conjunto de COMPOSITION grabadas por un usuario en un momento del tiempo en la HCE de un sujeto de la asistencia. Algunas aplicaciones clínicas incluyen pantallas complejas capaces de presentar simultáneamente múltiples partes de una HCE (por ejemplo a través de paneles de pestañas). Al salvar la pantalla, un usuario podría en realidad estar grabando datos a más de una parte de la HCE del paciente (por ejemplo la adición de una nueva nota de consulta y la revisión de una anotación de medicación almacenada en cualquier otro sitio en la HCE). La Contribución se refiere a todos los cambios y actualizaciones grabadas en esa HCE durante esa sesión del grabador. Todas las COMPOSITION comprendidas en una Contribución pueden identificarse de forma colectiva proporcionando un valor común al atributo contribution_id. ISO 13606-1:2008 - 16 - SECTION Usualmente las anotaciones en la historia relativas a una única sesión clínica se agrupan bajo cabeceras que representan fases o subtópicos dentro del encuentro clínico, o ayuda con la presentación y la navegación. Usualmente las cabeceras clínicas reflejan el flujo de trabajo clínico durante una sesión de asistencia, y también podrían reflejar los procesos de motivación del autor principal. La mayoría de las investigaciones ha demostrado que las cabeceras se utilizan de diferente forma por los diferentes grupos profesionales y especialidades, y que las cabeceras no se utilizan de forma suficientemente consistente para dar soporte al tratamiento automático seguro de la HCE. Por lo tanto en esta parte de la Norma ISO 13606 se tratan como un contenedor opcional (informal) para la navegación, filtrado y legibilidad por humanos. Las SECTION pueden utilizarse para representar la jerarquía de contenedores de cabeceras clínicas utilizada dentro del sistema proveedor de HCE para agrupar y organizar anotaciones dentro de una COMPOSITION. Cada SECTION puede contener SECTION y/o ENTRY adicionales. ENTRY TO La ENTRY es la clase contenedor para la estructura de datos del ITEM que representa la información adquirida y registrada para una única observación o un conjunto de observaciones (batería o series temporales), una única declaración clínica tal como una porción de la historia del paciente o una deducción o una aseveración, o una única acción que podría pretenderse o ha sido realmente realizada. La clase ENTRY asocia esta estructura del ITEM con un conjunto de atributos de contexto para facilitar la interpretación segura: AC – la información en una ENTRY puede ser sobre alguien distinto del paciente (por ejemplo un familiar): la ENTRY define el sujeto de la información; TR – la información en una ENTRY puede haber sido proporcionada o es atribuida a un individuo concreto: la ENTRY define el proveedor de la información; – otros participantes podrían necesitar estar asociados con una ENTRY particular; EX – la ENTRY puede representar el estado de desarrollo de un acto clínico (por ejemplo solicitado, realizado, informado, cancelado), y opcionalmente puede tener un identificador que la enlace con un sistema de flujo de trabajo; – la ENTRY puede utilizar una señal para avisar al receptor de HCE que la estructura de datos incluye alguna indicación sobre hallazgos u opiniones con dudas, y que es necesario tener cuidado al utilizar los datos para su tratamiento automatizado. La ENTRY contiene una estructura de datos representada por la utilización de CLUSTER y ELEMENT. Es importante resaltar que la ENTRY no puede contener posteriores ENTRY. El conjunto de contextos definidos al nivel de ENTRY (por ejemplo el sujeto de la información) se aplica a toda la estructura de datos y no se puede anular. ITEM, CLUSTER y ELEMENT El ITEM puede representar tanto los datos vigentes que describen la observación, la deducción, o la acción, y opcionalmente los detalles que describen el método de examen, el estado físico del paciente, o los detalles que dan soporte al proceso de razonamiento clínico tal como la referencia a directrices electrónicas, sistemas de soporte a la decisión, o cualquier otra referencia de conocimiento. El atributo item_category proporciona un medio opcional de distinguir estas diferentes partes de una estructura de datos, como una ayuda para el análisis o el filtrado automatizado de los ITEM en una ENTRY. El conjunto de códigos para este atributo está definido en la Norma ISO 13606-3. La información en un ITEM (CLUSTER o ELEMENT) podría originarse en una fecha/hora distinta de la actividad de asistencia o su registro. El atributo obs_time permite la representación de una única fecha u hora o un intervalo, hasta cualquier nivel de granularidad. Esto permitiría, por ejemplo, fechar una operación sólo con el año, el comienzo de un síntoma a un mes y un año, un periodo de empleo como un rango preciso de fechas o un intervalo de años, el estampillado de fecha/hora preciso de una arritmia, u organizar una angiografía como una serie temporal de imágenes. - 17 - ISO 13606-1:2008 La información en un ITEM podría ser resaltada por el autor como excepcional o digna de atención. Esta parte de la Norma ISO 13606 no define un conjunto de códigos para este atributo: para especificar el grado de énfasis o el tipo de excepción puede utilizarse cualquier terminología acordada. El CLUSTER soporta la representación de estructuras de datos complejas necesarias para representar los valores de datos reales en una observación multiparte (anidada), una declaración clínica, o una instrucción. Esto puede ser necesario representarlo como una tabla, un árbol o una serie temporal. Los ejemplos específicos incluyen un registro de ECG, un recuento sanguíneo, un examen de reflejos del tobillo, la prescripción de una perfusión intravenosa de un medicamento. La clase ELEMENT representa el nodo hoja dentro de la jerarquía de la HCE. Cada ocurrencia de esta clase tendrá un único valor de los datos. (Aquí se consideran ejemplos de valores de datos únicos un ratio, un intervalo o un término coordinado). Los ejemplos de ELEMENT podrían incluir el motivo de consulta, el peso del cuerpo y el pulso. Un ELEMENT puede tener un valor de datos nulo, por ejemplo si un valor no es conocido. Valor de los Datos – texto y términos codificados; AC – magnitudes que incluyen ratios, intervalos y duraciones; TO Cada ELEMENT contiene un valor de datos, para representar los valores reales de la ocurrencia. Este es uno de los Tipos de Datos CEN (CEN/TS 14796) para: – fechas y horas; – gráficos y otros tipos MIME (por ejemplo imágenes, señales). EX TR Se reconoce que, en el momento de la producción de esta parte de la Norma ISO 13606, el ISO/TC 215 está desarrollando un nuevo conjunto de tipos de datos en informatica sanitaria. Una vez que sean publicados, el CEN puede decidir anular la Especificación Técnica CEN/TS 14796 en favor de esta nueva norma. Al hacer esto, será necesario proporcionar una correspondencia con la nueva norma de tipos de datos, y será necesario utilizar esta correspondencia para adoptar los nuevos tipos datos en la Norma ISO 13606-1. A fin de dar un soporte a la adopción de esta parte de la Norma ISO 13606 internacionalmente más amplio que la jurisdicción de la Especificación Técnica CEN/TS 14967, el conjunto de tipos de datos de atributos utilizado realmente en este modelo de referencia (más que el valor del dato de ELEMENT) está explícitamente incluido en esta parte de la Norma ISO 13606 en un paquete de soporte. Estos también se deberían anular a favor de los tipos de datos ISO una vez publicados. NOTA Los tipos de datos básicos tales como el Boolean y el Integer se asume que siguen la Norma ISO/IEC 11404 y no están definidos aquí. 0.7 Descripción de las otras clases principales del modelo de referencia AUDIT_INFO Es un requisito médico legal para documentar y comunicar cuando y por quien fueron introducidos los datos de la HCE en un sistema HCE. Si se producen modificaciones, también es importante seguir los cambios en los datos de la HCE, y comunicarlos dentro de un EHR_EXTRACT. La clase AUDIT_INFO se utiliza para representar estos datos de auditoría: a) para cualquier RECORD_COMPONENT, como un registro permanente de su grabación en su sistema generador de HCE; b) para cualquier COMPOSITION, como un registro de su grabación dentro del sistema proveedor de HCE que ha generado este EHR_EXTRACT. ISO 13606-1:2008 - 18 - Por lo tanto una COMPOSITION podría tener hasta dos conjuntos de datos de auditoría, uno relativo a su sistema generador de HCE (denominado “feeder_audit”) y otro a su subsiguiente grabación dentro del sistema proveedor de HCE (denominado “committal”), si estos fuesen diferentes. Sin embargo esta parte de la Norma ISO 13606 no requiere ni da soporte a la comunicación de una acumulación indefinida de conjuntos de datos de auditoría para todo sistema en el que se grabó una COMPOSITION. Esto se hace así pues un conjunto acumulado de datos de auditoría sin el dato clínico real para mostrar los detalles de cada cambio no se considera de valor clínico. Si se requiere comunicar la historia completa de los cambios, se necesita incluir cada versión de la COMPOSITION en el EHR_EXTRACT. Para la grabación, la clase AUDIT_INFO representa el estampillado de la grabación, identifica al grabador, y al sistema de HCE en el que fueron grabados los datos. El estampillado refleja cuando se consolidó este RECORD_COMPONENT dentro de un sistema de HCE y por tanto pasa a formar parte de la HCE del sujeto de la asistencia. El grabador es responsable de incluir este RECORD_COMPONENT en la HCE, pero podría no ser responsable de decidir sobre el contenido clínico que se está grabando. TO Los atributos committer y time committed son opcionales, para permitir la posibilidad de que algunos datos sean importados de sistemas heredados en los que para los datos clínicos generados no se conocen los valores. Sin embargo, estos atributos se requiere que tengan valores no nulos para la asociación de grabación AUDIT_INFO, dado que representan el momento y la parte responsable de autoría de los datos clínicos que se incluyen en un sistema de HCE conforme con esta parte de la Norma ISO 13606. TR AC Para revisión, la clase AUDIT_INFO representa el estado de la versión, una razón opcional para la revisión, la identidad de la versión inmediatamente anterior que fue la base de esta revisión, y un identificador que es común a todas las versiones – de forma que las versiones no secuenciales realizadas sobre sistemas de HCE diferentes pueden todavía estar relacionadas entre sí. Un atributo opcional version status indica si la versión actual fue, en el momento de su grabación, un borrador (es decir, con la intención de ser sustituido en un futuro cercano), una actualización de una versión borrador anterior, una corrección de una versión anterior errónea, o COMPOSITION o ENTRY vacías que sean el borrado lógico de su predecesor (por ejemplo si el predecesor fue salvado en una HCE equivocada). Si no se proporciona un estado, se asume que esta es la versión (primera) definitiva. EX Los sistemas de HCE varían en la granularidad de los datos de HCE en los que se permite la grabación y la revisión, y es bastante probable que todos los RECORD_COMPONENT dentro de una parte de una jerarquía de HCE (por ejemplo dentro de una COMPOSITION) compartan los mismos datos de auditoría. La norma por tanto solo requiere la representación de esta información si es diferente a aquella del RECORD_COMPONENT padre. FUNCTIONAL_ROLE Esta clase se utiliza para representar los detalles de quien y cuando un agente individual ha contribuido a la atención sanitaria o a la historia clínica de un sujeto de la asistencia. Esta clase identifica: – la función que se llevó a cabo en la situación documentada; – la identidad del agente que realiza la función; – el modo en que se realizó tal participación (por ejemplo en persona, por teléfono); – la instalación sanitaria en la que estaba presente el agente; – el tipo de ubicación del servicio, departamento o establecimiento en el que el agente realizó tal papel. Pueden omitirse algunas de estas informaciones si el realizador no estaba actuando dentro de una instalación sanitaria, por ejemplo si un sujeto de la asistencia introduce datos desde su domicilio. - 19 - ISO 13606-1:2008 ATTESTATION_INFO La Confirmación es el proceso de certificar y registrar la responsabilidad legal para una unidad de información particular. La confirmación de parte de una HCE es un mecanismo por el cual el confirmador puede proporcionar su autoridad de que tales contenidos son, en su opinión, correctos. Esto significa que el o ella está satisfecho de que los contenidos son un reflejo justo y fiel de los procesos que documentan, y no falta a la verdad de forma deliberada. Confirmar una parte de una HCE no modificará su contenido o interpretación, más que añadiendo solidez a su autenticidad. (Cualquier cosa que añada una opinión, un nuevo punto de vista o perspectiva sería tanto una revisión o un nuevo conjunto de anotaciones con un enlace a esta). Claramente cualquier modificación de una parte de una HCE a través de una revisión no puede automáticamente arrastrar cualesquiera confirmaciones previas – si es necesario el confirmador original sería invitado a reconfirmar que continua conforme ahora que ha sido modificado o el revisor confirmaría la nueva versión, o ambos, o ninguno de ellos. Durante muchos años ha habido mucho debate sobre que información es necesario conservar en los sistemas electrónicos: TO a) para verificar la autorización del confirmador (desde una simple señal para indicar que ha sido autenticado de forma normal en tal sistema, hasta un hash complejo de la clave digital del usuario, la fecha y la hora, y parte o todo lo documentado que se está firmando, y opcionalmente enviado a un servicio de notaria de una tercera parte de confianza); AC b) como un registro legal permanente de lo que fue confirmado (desde una adición no específica al registro de la base de datos que está siendo firmado, hasta los ficheros XML de salida con una hoja de estilo como proxy para mostrar como fue presentado, hasta los mapas de bits de cada pantalla como fueron presentados realmente para la firma). TR La Confirmación puede llevarse a cabo por más de una persona, en momentos diferentes al de la grabación, y en algunos servicios sanitarios podría no requerirse siempre. El confirmador también será en ocasiones el grabador, pero podría no ser, por ejemplo, si una secretaria médica es quien teclea los datos. EX Esta parte de la Norma ISO 13606 reconoce que en algunas situaciones será apropiado comunicar la evidencia detallada de una confirmación, y en otras simplemente confirmar que los datos fueron confirmados en el sistema proveedor de HCE y comunicar solo el nombre del firmante y la fecha de confirmación. La clase ATTESTATION_INFO representa los siguientes datos sobre una confirmación: – la fecha y hora en que ocurrió; – la persona que hizo esta confirmación, como una referencia a la clase FUNCTIONAL_ROLE descrita más arriba; – la lista de RECORD_COMPONENT que fueron confirmados; – opcionalmente la razón para, o la importancia legal de esta confirmación; – opcionalmente la firma electrónica (como datos encapsulados, o como referencia a ella) que verifica la confirmación; – opcionalmente los datos encapsulados, o una referencia a ellos, que representan la imagen visual que realmente vio el confirmador; en la actualidad en algunos países de la UE se requiere la conservación de esta imagen en la HCE además de los datos en su formato procesable. Las Confirmaciones relativas a una FOLDER están contenidas por esa FOLDER; aunque esto no será común. Más comúnmente, todas las COMPOSITION o las ENTRY individuales en una COMPOSITION se confirmarán; todas las confirmaciones pertenecientes a una COMPOSITION o cualquiera de sus contenidos están contenidos en la COMPOSITION. ISO 13606-1:2008 - 20 - RELATED_PARTY Ocasionalmente este es el caso en el que la HCE describe la salud o un evento de atención sanitaria sobre alguien que no es el sujeto de la asistencia. El ejemplo más común es la historia familiar, pero en ocasiones podría registrarse en una HCE información sobre el amigo del sujeto de la asistencia, su pareja, su pareja sexual, su empleador, su hijo, etc. y esto es necesario que sea distinguido de forma no ambigua de la mayoría de la información de la HCE sobre el sujeto de la asistencia. La ENTRY incluye un atributo “subject_of_information”, que utiliza la clase RELATED_PARTY para representar un sujeto de información que no es el sujeto de la asistencia. Esta clase puede utilizarse: a) para identificar a una persona en los términos de su relación con el sujeto de la asistencia, como un término codificado o una descripción en texto; b) opcionalmente para identificar a la persona a través de un identificador, y para proporcionar un conjunto de descripción demográfica para esa persona dentro del paquete de demográficos del EHR_EXTRACT. AC TO Se reconoce que, por razones de protección de datos, no es común enlazar la HCE de un sujeto de la asistencia con la de otro (por ejemplo, si un miembro de la familia también es un paciente en la misma empresa), pero esto ocurrirá ocasionalmente en la provisión de terapias genéticas o familiares, y en ocasiones en atención primaria. Esta parte de la Norma ISO 13606 no da soporte formalmente a un enlace entre las HCE de sujetos de la asistencia diferentes, aunque esta clase puede utilizarse para proporcionar identificadores que son los identificadores reales por los que otra persona es conocida en el sistema proveedor de HCE, si tal uso se permite. LINK EX TR Un usuario puede desear crear enlaces semánticos ad hoc entre cualesquiera puntos arbitrarios en una HCE, por ejemplo para indicar la evolución de una condición, la probable causa histórica de un problema, o una respuesta a una petición previa, para indicar causa y efecto, para seguir la evolución de las órdenes desde la petición hasta su finalización, o para formar redes de enlaces para problemas clínicos y episodios. Se requiere en estas situaciones un mecanismo a disposición del compositor para señalar desde cualquier nodo en su formulario de pantalla actual o documento electrónico hacia cualquier componente de la HCE previo, y para etiquetar el enlace con un término clínico apropiado. En ocasiones una ubicación en la HCE puede actuar como una especie de distribuidor de enlaces, por ejemplo la declaración formal de una condición clínica podría utilizarse como un punto de anclaje para todas las anotaciones históricas y subsiguientes relacionadas con tal condición (por ejemplo en una historia orientada a problemas). Tales enlaces podrían ser creados por el usuario como un puntero desde una nueva anotación en la historia a una preexistente, o podría crearse como una nueva declaración de una relación clínica entre dos o más anotaciones preexistentes (apuntando a cada una de ellas desde una entrada actual que justifique la relación). Para tal funcionalidad pueden imaginarse un amplio rango de interfaces de usuario final, pero la tarea de esta norma internacional es proporcionar unos medios genéricos y seguros para comunicar la existencia de tales enlaces a los diversos sistemas de HCE. A veces esto podría requerir la comunicación del enlace destino así como el enlace origen, debido a que un compositor considera que cualquier receptor futuro necesita ser consciente de ambas entradas, por ejemplo si un procedimiento o una prescripción de un medicamento ha tenido complicaciones. La clase LINK que está asociada con RECORD_COMPONENT permite representar cualquier número de enlaces etiquetados desde un componente origen a cualquier número de destinos (referenciando sus identificadores únicos). Están disponibles 2 atributos para etiquetar cada LINK: a) una categoría de enlace de granularidad gruesa, que es necesario que sea uno de los diferentes valores definidos en la Parte 3 de esta serie; b) una etiqueta opcional de granularidad fina; en la Parte 3 de esta serie se proporciona una lista de términos informativa, pero pueden utilizarse otras terminologías. - 21 - ISO 13606-1:2008 Una característica extra importante es el atributo Boolean follow_link que, si es verdad, indica que el compositor pretende que cualquier EHR_EXTRACT que incluya la COMPOSITION que contiene el origen necesita incluir también la COMPOSITION que contiene el destino, y viceversa. El sistema receptor necesitará indicar la existencia de esta información adicional a los usuarios que accedan a los datos que se encuentren en uno de los extremos de estos LINK. 0.8 Discusión sobre temas de representación particulares Representación de los papeles y responsabilidades en el EHR _EXTRACT Realizar un acto de asistencia en un servicio sanitario moderno puede implicar a un gran número de actores, con diferentes papeles y responsabilidades, con la posible necesidad de representar a cada uno de ellos en una HCE del paciente. El enfoque adoptado en la mayoría de las arquitecturas genéricas de HCE, incluyendo esta parte de la Norma ISO 13606, es diferenciar esto en tres amplias categorías. Actores que juegan un papel en el proceso de asistencia sanitaria AC TO Usualmente este conjunto incluirá una parte central que es la persona principal en relación con el paciente durante tal acto (por ejemplo durante una intervención con fórceps en un país industrializado será normalmente un obstetra), y una serie de partes relacionadas que pueden estar proporcionando o siendo partes de apoyo de la asistencia (por ejemplo matronas), están involucrados en la toma de decisiones (por ejemplo un anestesista), son observadores (por ejemplo estudiantes de medicina), o están presentes para dar apoyo o co-representar al paciente (por ejemplo el marido de la paciente). Estos actores podrían no estar todos presentes: por ejemplo, las políticas de un adjunto a cargo de la atención pueden seguirse debido a que el paciente está al cuidado de su equipo, incluso aunque el mismo no esté con el paciente en tal ocasión. Algunos actores podrían estar documentando la revisión de un caso o una planificación de cuidados que involucre a uno o más profesionales pero en el que el paciente no esté presente. Actores que contribuyen al proceso de documentar la asistencia en la HCE EX TR Esto usualmente será un subconjunto de aquellos involucrados en la atención (y más comúnmente, el actor principal), pero podría incluir personas que no fueron parte de la prestación de la atención (por ejemplo una secretaria o un transcriptor) y puede (y más en el futuro) incluir a la persona que es el sujeto de su asistencia. Es importante reconocer que los diferentes actores a menudo cumplimentarán diferentes registros de eventos y también pueden confirmarlos independientemente. Actores que confirman la validez de la documentación de la HCE La analogía con los formatos de papel es que este es el firmante de una nota o de un informe. Más comúnmente el acto de firmar un documento combina dos intenciones: confirmar que el documento es correcto (por ejemplo que está libre de errores tipográficos y omisiones) y para el firmante confirmar que está de acuerdo con el contenido (por ejemplo para validar una prescripción). En la mayoría de estas situaciones el status o experiencia del firmante es importante. Algunos de los actores descritos en un acto de atención no firmarán ellos mismos las anotaciones que describen su contribución a la asistencia: muchos trabajos sanitarios se realizan a través de la delegación. Por ejemplo, la documentación de registros médicos realizada por un médico residente en un pase de visita raramente es revisada por el médico adjunto y casi nunca es refrendada. La mayoría de las observaciones de un gráfico de monitorización no están firmadas individualmente. Esta práctica podría cambiar con los sistemas electrónicos, pero probablemente siempre existirá algún nivel de delegación y confianza dentro de los equipos de asistencia. Claramente existe un amplio rango de papeles potenciales y responsabilidades que podrían necesitar representarse en una HCE, y como los patrones del servicio sanitario evolucionan esto podría cambiar en el futuro. El objetivo de la arquitectura del EHR_EXTRACT es permitir la definición en una COMPOSITION de cualquier número de actores y papeles: tanto para toda la COMPOSITION o más en concreto para sus ENTRY individuales. El enfoque adoptado en esta parte de la Norma ISO 13606 (como en otras arquitecturas de HCE tales como la Norma ENV 13606 y el HL7 CDA), es: ISO 13606-1:2008 - 22 - – para especificar un pequeño número de papeles que es necesario comunicar de forma no ambigua para asegurar una interpretación segura de los EHR_EXTRACT por parte de un sistema receptor, y que probablemente se presentarán frecuentemente; – para permitir otras participaciones ad hoc a definir por los servicios sanitarios, los sistemas u ocurrencias de HCE individuales a los niveles de COMPOSITION o ENTRY; – para permitir añadir a la HCE cualquier número de confirmaciones, para firmar FOLDER o COMPOSITION o para permitir la confirmación solo de partes de las COMPOSITION. Más abajo se discuten algunos papeles específicos que han sido definidos en este modelo de referencia. Sujeto de la asistencia TO Se asume que cada HCE, y por tanto cada EHR_EXTRACT, será acerca de la salud y la atención sanitaria de una persona, que es también en términos de protección de datos el interesado. Esto tiene importantes implicaciones para los datos contenidos en esa HCE que podrían referirse a un interesado diferente (como en el caso de la historia familiar); esto se discute más abajo en sujeto de la información. A menudo se citan varias excepciones “casos especiales” a la norma de que cada HCE es sobre un interesado. AC Embarazo: aquí la práctica usual es que la historia de la madre contenga todo el registro de la atención al embarazo que incluye los datos de su hijo o hijos hasta su nacimiento, momento en el que cualquier información relevante se copia en las nuevas historias de estos bebés. TR Intervenciones in útero: en algunas situaciones se crea una nueva historia antes de que nazca un niño, ya que quizás se requieran cuidados sanitarios relevantes. En tales situaciones la nueva historia se está creando para el feto como un apoyo para permitir una separación de los datos de la historia de la madre, y anticipando la nueva historia legal para el niño. Dependiendo de la edad del feto, y de la legislación de cada país, tanto el niño como la madre sería el interesado legal, pero en cualquier caso todavía existe un único sujeto de la asistencia identificable para cada historia. EX Embarazos múltiples en que cada feto tiene su propia historia: Se cita a menudo como una situación en la que las acciones sanitarias podrían realmente “pertenecer” a dos o más sujetos de la asistencia. En estas situaciones parecería lógico que el EHR_EXTRACT de cada niño contenga una copia de las COMPOSITION relevantes, más que promover una unión compleja entre dos o más historias para referenciar una única COMPOSITION contenida en una de estas historias. (Por supuesto, dentro de los sistemas de HCE locales pueden hacerse declaraciones de enlace más complejas, que permitan a los usuarios introducir los datos una vez y añadirlos lógicamente a ambas historias). Gemelos siameses: sí, han existido discusiones sobre tales casos raros! De Nuevo en este caso parece lógico y seguro para cada gemelo tener una copia de las COMPOSITION relevantes, siempre que se creen HCE separadas, mejor que extractos interconectados de la historia que podrían ser gestionados por los sistemas receptores de forma no segura. Donación de órganos: Puede ser apropiado almacenar algunos resultados de pruebas relativos al donante de un órgano en la HCE de la persona que recibe el órgano donado – tal como el estado viral del donante y en el futuro la historia genética del donante – dado que desde este momento la persona será un mosaico genético. Por esta razón, el sujeto de la información o alguna información en la HCE puede ser “donante”. El identificador del sujeto de la asistencia en el EHR_EXTRACT hará referencia a una instantánea de información demográfica contenida por el Proveedor de la HCE, para permitir la correspondencia del paciente con el repositorio de demográficos del Receptor de la HCE, y/o para referenciar el EHR_EXTRACT con el sujeto de la asistencial individual incluso si los servicios demográficos externos no están disponibles. El sujeto de la asistencia se define como la raíz del modelo, en la clase EHR_EXTRACT. - 23 - ISO 13606-1:2008 Compositor Este actor es la persona que realmente ha compuesto las palabras, términos, figuras y valores, etc. que se representan en la COMPOSITION. El compositor jugará casi siempre un papel principal en la recopilación de información, thinking o interpretando aspectos de la asistencia sanitaria que está siendo documentada. Algunas veces, sin embargo, el o ella pueden ser un miembro júnior del equipo que escribe las notas en nombre de un equipo. Incluso así, serán las palabras o frases del compositor las que perfilen la documentación. Por tanto el atributo Composer representa la parte que compone los datos en una COMPOSITION, con independencia de quien la grabó o quien la confirma. La COMPOSITION se verá como atribuida ante todo a esta persona. Es opcional cambiar el compositor cuando se hace una revisión, y dependerá de la extensión del cambio así como de si el equipo revisor quiere y está en posición de asumir la responsabilidad de la COMPOSITION revisada como su compositor. Para etiquetar los datos de COMPOSITION con propósitos de representación generalmente las aplicaciones utilizarán el nombre del compositor. (El papel de los miembros del equipo distintos del compositor puede añadirse como otras participaciones, tanto para toda la COMPOSITION como para ENTRY individuales). Grabador AC TO En muchas situaciones la persona que compone el texto no es la persona que lo teclea. Un ejemplo común son las cartas e informes dictados, que pueden ser tecleados por una secretaria o un transcriptor. Un miembro júnior del equipo clínico podría también definirse como el grabador si él en realidad solo actúa como el amanuense para otro (que compone) colega senior del equipo. En algunos de trascripción el texto tecleado se comprueba por el compositor, y el mismo lo graba en la HCE del paciente. En algunos escenarios varios miembros del equipo clínico trabajan en colaboración para prestar un servicio de asistencia, y cualquier de ellos sería capaz de documentar (y confirmar) sus propias partes de la asistencia en la historia del paciente. Sujeto de la información TR Podrían surgir otras situaciones en las que el grabador no es responsable de la entrada de los datos, por ejemplo cuando un dispositivo de medición está alimentando directamente a una aplicación clínica. En estas situaciones pueden utilizarse los atributos information_provider u other_participations de ENTRY para suplementar el conjunto definido de actores. EX Se necesita este atributo para identificar a la persona a la que hace referencia la información en una ENTRY si no es el sujeto de la asistencia, por ejemplo si la información es sobre un miembro de la familia, tal como el padre o la madre del paciente. Esto se considera como un atributo importante de "seguridad" para suplementar cualquier significado implicado por un nombre o arquetipo de componente, particularmente si las historias se comunican a través de países y con diferentes idiomas. En algunos contextos las partes solo podrían especificarse de forma precisa si están registradas en el servicio local de demográficos y han dado su consentimiento para ser identificados en esta HCE del paciente. Esto surgirá de forma creciente en campos clínicos como la genética del cáncer que gestiona pacientes dentro de su contexto familiar. La situación más común es aquella en la que el paciente está describiendo la salud de otros. La asociación subject_of_information de ENTRY se refiere a la clase RELATED_PARTY, que permite la relación de tal sujeto con el paciente para ser definido como un término codificado, y opcionalmente también a través de un identificador de partes (que probablemente enlace con el servicio de demográficos dentro del sistema de HCE). Este enfoque permitirá reutilizar los arquetipos con diferentes sujetos de la asistencia, y el tratamiento no ambiguo de ENTRY de la HCE para distinguir los datos sobre el paciente de los datos sobre otras partes. Proveedor de la información La mayoría de la información documentada en una HCE se originará en el paciente o en uno de los participantes en el acto de asistencia. Sin embargo a veces pueden añadirse ENTRY cuyos valores de datos se hayan originado por alguna otra parte, por ejemplo un familiar o cuidador que podría estar con el paciente o ver a solas de forma confidencial al médico del paciente. Otras partes clínicas podrían proporcionar al compositor información indirectamente (por ejemplo por teléfono). ISO 13606-1:2008 - 24 - La asociación info_provider de la ENTRY se refiere a la clase FUNCTIONAL_ROLE, que permiten representar su función y modo de contribución (por teléfono, en persona, etc.). Como con el sujeto de la información, la parte podría o no estar formalmente identificada, dependiendo del consentimiento y si estuviese registrado en el servicio local de demográficos. La identificación formal de los proveedores de la información proporciona una vía para el compositor para atribuir algunas ENTRY en esa COMPOSITION a otros clínicos o a otros dispositivos (otra vía es el atributo other_participations). Demográficos Una historia clínica electrónica se puede referir a un amplio rango de ocurrencias específicas de entidades, tales como el sujeto de la asistencia, los variados agentes sanitarios y otros que han tenido un papel en la prestación de asistencia sanitaria, los dispositivos que han medido parámetros del cuerpo o administrado tratamientos, y las organizaciones que han asumido responsabilidades por la asistencia. Muchas de estas entidades se multiplican dentro de una HCE dada, y en cualquier empresa podrían definirse dentro de un servidor de demográficos. TO En este modelo de referencia se ha tomado un enfoque equivalente: entidades específicas se definen una vez dentro de un paquete de extracto demográfico, y se referencia como necesarias a lo largo del resto del EHR_EXTRACT por un identificador de ocurrencias dedicado. El identificador de ocurrencias utilizado en el EHR_EXTRACT podría ser, pero no necesariamente, uno de los identificadores por los que se conoce cada entidad en el sistema Proveedor de HCE. AC El objetivo de esta parte del modelo es proporcionar una descripción suficiente y necesaria de cada entidad para dar soporte a la interpretación humana de la HCE, y una correspondencia demográfica para habilitar al receptor de HCE para identificar las correspondientes entidades dentro de su propio servidor demográfico. Si se requiere un intercambio más detallado de información demográfica, se recomienda el uso de una norma alternativa apropiada, tal como la Especificación Técnica CEN/TS 14796. Revisión TR Todo el paquete DEMOGRAPHIC_EXTRACT es opcional, y no es necesario comunicar todos los detalles demográficos de cada entidad si es conocido que tanto el Proveedor de HCE como el Receptor de HCE comparten o pueden acceder a un servicio común de demográficos – por ejemplo dentro de una empresa, una región o un servicio de salud. EX La revisión es un área importante y potencialmente complicada. Además de los requisitos medico-legales, bien conocidos, para seguimiento y revisiones de atributos, los siguientes requisitos funcionales han sustentado el enfoque decidido: 1) la amplísima mayoría de las peticiones de partes o de toda la HCE justificarán la generación de un EHR_EXTRACT que contenga las versiones más actualizadas posibles de los RECORD_COMPONENT contenidos en ella; 2) incluso en tales situaciones, puede ser importante conocer que los RECORD_COMPONENT comunicados han sido objeto de una corrección; 3) existirá una necesidad no muy frecuente de transferir versiones seriadas de los RECORD_COMPONENT para propósitos clínicos, por ejemplo para explicar un error; 4) existe la necesidad de ser capaz de transferir una HCE completa, que incluya todas las versiones de los componentes revisados, por ejemplo cuando la asistencia está siendo legalmente transferida entre empresas; 5) la COMPOSITION debería fijar la comunicación de grabación y la revisión en el EHR_EXTRACT, incluso aunque los cambios hechos a través de una revisión solo podrían afectar a unos pocos de sus componentes contenidos; 6) la evolución de las FOLDER a lo largo del tiempo puede necesitar también de una gestión de revisiones similar, aunque usualmente esto estará dentro de los sistemas de HCE y probablemente un registro de auditoría de la FOLDER sólo se incluye de forma ocasional en un EHR_EXTRACT; - 25 - ISO 13606-1:2008 7) en muchos casos podría no ser legal comunicar errores que han sido corregidos: los componentes revisados no deberían por tanto “contener” los datos originales que han sido corregidos, incluso si están marcados como borrados lógicos. Por ejemplo, los datos erróneos corregidos a petición de un paciente no es necesario comunicarlos de acuerdo con las Directivas de la UE y la mayoría de las legislaciones nacionales de protección de datos; 8) en algunos casos, por ejemplo si así lo determinasen los tribunales, los datos podrían ser físicamente borrados de un sistema de HCE. En tales casos podría ser apropiado algunas veces mantener un RECORD-COMPONENT vacío en el mismo punto en la jerarquía, para indicar cuándo y por qué tuvo lugar el borrado. Existen una variedad de técnicas para seguimiento de versiones o modificaciones dentro de las bases de datos, cualquiera de los cuales podría utilizarse dentro de sistemas de HCE concretos. El enfoque de esta parte de la Norma ISO 13606 es especificar una forma estructurada en que puedan cumplirse los requisitos clínicos y médico-legales necesarios dentro de un EHR_EXTRACT, sin determinar el uso en estos sistemas de HCE de ninguna metodología de versionado particular. La comunicación de consultas de HCE AC TO La clase AUDIT_INFO contiene un conjunto de atributos que definen el sistema de HCE, el grabador y la hora de grabación que define el origen de cualquier RECORD_COMPONENT dentro del sistema de HCE en el que fue creado por primera vez. Es necesario incluir este conjunto de datos dentro del EHR_EXTRACT siempre que este RECORD_COMPONENT se comunica. Si el RECORD_COMPONENT es una revisión o una versión previa, es necesario proporcionar también un conjunto adicional de descripciones y referencias a las versiones previas. Por tanto siempre es posible conocer si ha sido revisado un RECORD_COMPONENT, cuando, porqué, por quien y en que sistema de HCE. La identidad de la versión previa es conocida, pero sólo es posible acceder a la versión previa si el receptor de HCE tiene los privilegios necesarios y el proveedor de HCE está preparado para facilitarla. TR Los usuarios frecuentemente requieren vistas de ciertos tipos de anotaciones o agrupaciones de más alto nivel, que pueden obtenerse informaticamente filtrando la HCE longitudinal para ciertas clases de información (en el futuro esto podría ser por arquetipo). Ciertos atributos o valores de los datos podrían utilizarse para ordenar el filtrado resultante en una vista de usuario adecuada, por ejemplo por fechas, alfabéticamente o descendiente por el tamaño del valor. EX No existen características específicas requeridas en las anotaciones subyacentes de la HCE para dar soporte a esto, y la lógica para obtener cada vista usualmente reside en una aplicación clínica, no en cada HCE individual. El resultado de realizar la consulta normalmente no se almacena en la HCE ni se comunica, por lo que el modelo de referencia de comunicaciones de la HCE no necesita representarlo. Ejemplos podrían ser un gráfico de presión sanguínea a lo largo del tiempo o una lista de la medicación prescrita en los 30 días anteriores. Algunas vistas o filtros podrían derivar de una consulta "personalizada" que ha sido compuesta específicamente para su uso dentro de una HCE de un sujeto de la asistencia concreto. En tales casos puede ser deseable almacenar los parámetros de la consulta dentro de la HCE del paciente para el beneficio de clínicos en el futuro. El alcance para el que esto sea útil para compartir en el futuro entre empresas y sistemas depende de lo interoperable que sea la especificación de la consulta. Dado que el lenguaje para especificar las definiciones y restricciones de arquetipos (Lenguaje de Definición de Arquetipos – ADL, Archetype Definition Language) ha sido normalizado (en la Parte 2 de esta serie), y la comunidad de directrices está avanzando hacia especificaciones interoperables, parece probable que emergerá una especificación de consulta de HCE genérica. Todavía no existe una convención normalizada para especificar una consulta relativa a la HCE, pero es probable que esas especificaciones serán un conjunto de datos de valores de cadena o pares nombre valor. Tal especificación puede representarse dentro de las subclases de ITEM, CLUSTER y ELEMENT, con valores de los datos del tipo STRING. Por tanto los arquetipos ENTRY pueden utilizarse para definir la representación de cualesquiera de las consultas a la HCE que sea necesario comunicar. Esto tiene la ventaja de que puede definirse más de una especificación de interrogación para su uso en los sistemas sanitarios, y refinarse en el tiempo, sin que se requiera ninguna modificación de esta parte de la Norma ISO 13606. Más abajo se proporciona un ejemplo ilustrativo. ISO 13606-1:2008 - 26 - ENTRY Consulta Gráfico Presión Sanguinea CLUSTER: Especificación de Consulta ELEMENT: Sintaxis de Consulta: <EHR_OQLv1> ELEMENT: Cadena de Consulta: “Select…. where Cluster.meaning = <Presión Sanguinea> and containing.Entry.subject_of_information = <Paciente> and containing.Composition.Clinical_Session.session_time.start > (now>-365days)” ELEMENT: primera fecha autorizada: 20 Febrero 2003 Comunicación de la información de presentación TO NOTA La sintaxis de la cadena de consulta en el ejemplo anterior es solo a modo ilustrativo, y no es conforme con ninguna sintaxis conocida. En el caso de tal consulta almacenada en la historia la sintaxis tendría que seguir cualquier esquema identificado en la sintaxis de consulta ELEMENT. AC Por diversas razones, generalmente no se considera apropiado incluir en la comunicación de la HCE detalles de cómo se presentaron en pantalla originalmente los datos clínicos en el momento de su captura. TR 1) las pantallas de captura de datos a menudo no se corresponden directamente con las pantallas de presentación de datos, incluso dentro de una aplicación clínica, por lo que no es demasiado útil clínicamente para otro profesional sanitario conocer como era la pantalla justo antes de salvarla; EX 2) a menudo los datos clínicos pueden representarse en más de una forma (por ejemplo en pantallas de resumen, pantallas de detalle), y los diferentes usuarios podrían buscar presentaciones diferentes más o menos adaptadas a su situación; 3) el sistema receptor de HCE podría no ser capaz de mostrar exactamente las pantallas soportadas por el sistema proveedor de HCE; 4) los profesionales sanitarios del receptor de HCE probablemente tienen sus propias aplicaciones a través de las cuales desean ver tanto los datos importados como los datos creados localmente. Sin embargo, hay dos escenarios en los que la presentación precisa de la información podría ser importante para comunicar junto con los datos de la HCE: a) si existe la necesidad para propósitos medico-legales de capturar la apariencia de la pantalla y la forma en que estaban organizados los datos (por ejemplo para mostrar que datos vio realmente el clínico al firmar los datos); b) si una presentación concreta de los datos incluye una información valiosa sobre su interpretación, tal como un diagrama o un gráfico. En ambos casos, el atributo attested_view de ATTESTATION_INFO puede utilizarse para incluir una representación de datos encapsulados para cualquier nivel de granularidad de los datos de la HCE. Este atributo puede utilizarse, por ejemplo, para incluir la vista de un documento CDA release 1 ó release 2 de HL7 versión 3. - 27 - ISO 13606-1:2008 Más que la presentación, las pruebas sobre requisitos clínicos han mostrado más frecuentmente la necesidad de resaltar parte de los datos como son los dignos de mención, anormales o inesperados. En tales situaciones el requisito es usualmente indicar que los datos se deberían destacar apropiadamente para el usuario final más que establecer si es necesario mostrarlos en negrita o en letra roja. El atributo énfasis del ITEM permite comunicar esto como un valor codificado. Comunicación de datos multimedia El requisito para incluir y comunicar datos multimedia dentro de las HCE, por ejemplo los resultados de estudios de imagen diagnóstica, está fuera de cuestión. Los profesionales sanitarios de todas las disciplinas y especialidades desean estar totalmente informados cuando realizan decisiones de asistencia, y los mismos pacientes de forma creciente desean ser capaces de ver y entender sus propios problemas de salud, incluyendo los formatos visuales tales como las imágenes. Los usuarios posteriores de informes multimedia podrían incluir aquellos que ofrecen opiniones suplementarias del especialista sobre un estudio y aconsejando sobre el subsiguiente plan de atención, o aquellos que necesitan revisar estudios anteriores al interpretar uno nuevo (potencialmente en otro lugar o en otro país). TO Dentro de una HCE, pueden incluirse datos de un amplio rango de tipos de media como el valor del dato específico de un ELEMENT. Por tanto pueden representarse estructuras de datos multimedia más complejas a través de combinaciones de clases ELEMENT opcionalmente contenidas en CLUSTER, tales como tablas, listas o árboles. Las estructuras de datos particulares o los informes multimedia pueden representarse como ENTRY o COMPOSITION específicas, y pueden arquetiparse. AC La opción tipo de datos para los datos encapsulados (código corto ED), tal como está definido en la Especificación Técnica CEN/TS 14796, permite representar cualquier tipo de datos MIME. 0.9 Comparación entre la Norma ISO 13606-1 y la Norma EN 13606-1 TR En febrero de 2007, CEN publicó EN 13606-1, que es la versión europea de esta parte de la Norma ISO 13606 y que es de aplicación jurídica a las organizaciones miembro europeas. Esta Norma ISO 13606-1, es materialmente idéntica a su equivalente europea. Hay varias áreas de diferencias menores entres ambos documentos, que no afectan a su adopción, implementación o conformidad, pero que se resumen aquí para el beneficio de aquellos lectores que tengan ambos documentos. EX La Norma ISO 13606-1 se diferencia de la Norma EN 13606-1 en las siguientes capítulos normativos: – la redacción del capítulo 1 "Objeto y Campo de Aplicación" ha sido modificada (extendida) para incluir la siguiente frase al final del segundo párrafo: "o como representación de datos de la HCE dentro de un sistema de historia distribuida (federada); – la redacción del apartado 5.2 "Conformidad de los Estados Miembros" ha sido modificada para hacerla más acorde al contexto de ISO y se ha retitulado como Conformidad de los Países Miembros; – el valor del atributo rm_id de la clase EHR_EXTRACT se ha cambiado de la Norma "EN 13606-1" a la Norma "ISO 13606-1". La introducción se ha editado para clarificar (sin alterar) las responsabilidades del receptor sobre las FOLDERs y los LINKs, y las circunstancias en las que la identidad del compositor de una COMPOSITION revisada podría cambiar si es revisada. Se han hecho los siguientes cambios editoriales: – se han cambiado las referencias a norma europea por norma internacional a lo largo de todo el documento; – se han cambiado las referencias a la Norma EN 13606 por la Norma ISO 13606 a lo largo de todo el documento; ISO 13606-1:2008 - 28 - – donde resultaba apropiado se han modificado las referencias a Europa o Prenormas Europeas para una audiencia internacional; – algunas definiciones de términos que no era conformes a las regulaciones de ISO se han modificado desde el punto de vista editorial pero sin ser materialmente refraseadas, es decir, manteniendo sin cambios su interpretación técnica; – se han eliminado algunos llamativos errores tipográficos menores y algunas inconsistencias en el uso de términos dentro del documento. Esta sección de la introducción no tiene un equivalente en la Norma EN 13606-1, ya que el contenido exacto de la Norma ISO 13606-1 no era conocido cuando se publicó aquél. 1 OBJETO Y CAMPO DE APLICACIÓN Esta parte de la Norma ISO 13606 especifica la comunicación de parte o de toda la historia clínica electrónica (HCE) de un único sujeto de la asistencia identificado entre sistemas de HCE, o entre sistemas de HCE y un repositorio centralizado de datos de la HCE. TO También puede utilizarse para la comunicación de la HCE entre un sistema o repositorio de HCE y las aplicaciones clínicas o los componentes de middleware (tales como los componentes de soporte a la decisión) que necesitan acceder o proporcionar datos de la HCE o como la representación de datos de HCE dentro de un sistema de registro distribuido (federado). TR AC Esta parte de la Norma ISO 13606 se utilizará de forma predominantemente para dar soporte a la atención directa prestada a individuos identificables, o para dar soporte a los sistemas de monitorización de poblaciones tales como los registros de enfermedades o la vigilancia de salud pública. Los usos de las historias clínicas para otros propósitos tales como la docencia, la auditoría clínica, la administración e informado, la gestión de servicios, la investigación y la epidemiología, que a menudo requieren la anonimización o la agregación de historias individuales, no son el foco de esta parte de la Norma ISO 13606 pero dichos usos secundarios podrían hallar útil este documento. EX Esta parte 1 de la serie multiparte, ISO 13606, en una especificación punto de vista de información como se define en la Norma ISO/IEC 10746-1 [13]. Esta parte de la Norma ISO 13606 no pretende especificar la arquitectura interna o el diseño de base de datos de los sistemas de HCE. 2 NORMAS PARA CONSULTA Las normas que a continuación se indican son indispensables para la aplicación de esta norma. Para las referencias con fecha, sólo se aplica la edición citada. Para las referencias sin fecha se aplica la última edición de la norma (incluyendo cualquier modificación de ésta). CEN/TS 14796:2004 Informática sanitaria. Tipos de datos. 3 TÉRMINOS Y DEFINICIONES Para los fines de este documento, se aplican los términos y definiciones siguientes: 3.1 clase abstracta: Un padre común virtual a dos o más clases; la clase abstracta nunca se instancia. 3.2 control de accesos: Medios para asegurar que a los recursos de un sistema de tratamiento de datos solo pueden acceder entidades autorizadas de formas autorizadas. [ISO/IEC 2382-8:1998, definición 08.04.01] INFORMACIÓN COMPLEMENTARIA Documento: NTE INEN-ISO 13606-1 TÍTULO: INFORMÁTICA SANITARIA. COMUNICACIÓN DE LA Código: ICS HISTORIA CLÍNICA ELECTRÓNICA PARTE 1: MODELO DE 35.240.80 REFERENCIA (ISO 13606-1:2008, IDT) ORIGINAL: Fecha de iniciación del estudio: 2013-11-25 REVISIÓN: La Subsecretaría de la Calidad del Ministerio de Industrias y Productividad aprobó este proyecto de norma Oficialización con el Carácter de Por Resolución No. Publicado en el Registro Oficial No. Fecha de iniciación del estudio: Fechas de consulta pública: 2013-11-27 al 2013-12-12 Comité Interno del INEN: Fecha de iniciación: 2013-12-13 Integrantes del Comité Interno: Fecha de aprobación: 2013-12-13 INSTITUCIÓN REPRESENTADA: DIRECCION EJECUTIVA COORDINACIÓN GENERAL TÉCNICO DIRECCIÓN DE NORMALIZACIÓN DIRECCIÓN DE VALIDACIÓN Y CERTIFICACIÓN DIRECCIÓN DE METROLOGÍA DIRECCION DE REGLAMENTACIÓN DIRECCIÓN DE NORMALIZACIÓN AC Eco. Agustín Ortiz (Presidente) Ing. José Luis Pérez Ing. Paola Castillo Ing. Tatiana Briones TO NOMBRES: EX TR Ing. Laura González Ing. Bolívar Cano Ing. Gonzalo Arteaga (Secretaría Técnica) Otros trámites: Compromiso Presidencial N° 20549 del 08 de junio del 2013, para el fortalecimiento de normas del Instituto Ecuatoriano de Normalización – INEN La Subsecretaría de la Calidad del Ministerio de Industrias y Productividad aprobó este proyecto de norma Oficializada como: Voluntaria Registro Oficial No. 158 de 2014-01-09 Por Resolución No. 13532 de 2013-12-20 TO AC TR EX Instituto Ecuatoriano de Normalización, INEN - Baquerizo Moreno E8-29 y Av. 6 de Diciembre Casilla 17-01-3999 - Telfs: (593 2)2 501885 al 2 501891 - Fax: (593 2) 2 567815 Dirección Ejecutiva: E-Mail: direccion@inen.gob.ec Dirección de Normalización: E-Mail: normalizacion@inen.gob.ec Regional Guayas: E-Mail: inenguayas@inen.gob.ec Regional Azuay: E-Mail: inencuenca@inen.gob.ec Regional Chimborazo: E-Mail: inenriobamba@inen.gob.ec URL:www.inen.gob.ec
