Help
Login
Busy
Search
MAIS - Datasets

 
Concept locked
Concept locked
Select Target
Select Concept
De-inherit concept

Select object
 
Edit
Filter
Edit
true50
Documento Clinico
Id mais-dataelement-1 Version 2013-02-10
Status Draft Version Label
Description

Qué
Clase – Categoría de alto nivel

 Tipo – Categoria de nivel más fino o granular

 Especialidad – Tipo de Servicio

 Tipo de Cuidado - Modo de cuidado

 Título – legible para humanos

 Confidencialidad


Quién
Paciente
Profesionales de Salud Y Cuidado 

Dónde
Ubicación

Cuándo
Fecha Evento
Fecha Creación

Técnicos
Formato
Lenguaje
Identificador
Source
Los metadatos son generados por el sistema que crea el documento
Rationale

Requerimientos para Metadatos, Traducido por Diego Kaminker

http://abiesuk.blogspot.com.ar/2013/07/metadata-for-clinical-documents-and.html


Los metadatos se necesitan para permitir la búsqueda y la recuperación en portales clínicos y de pacientes, pero tienen un uso más amplio y valor para la interoperabilidad en salud. En los portales, los médicos, pacientes u otras personas autorizadas pueden obtener items de información sobre pacientes individuales de múltiples y diversos sistemas de origen.


Los portales contienen típicamente items a dos niveles distintos de granularidad, a los cuales nos podemos referir como enunciados clínicos y documentos clínicos. Tienen diferentes usos, pero comparten requerimientos comunes para los metadatos. Nos referimos como ‘ítems’ a ambos: documentos y enunciados clínicos.


Un enunciado clínico es una instancia de un tipo de datos clínico. Piense en ellos como lineas separadas en una nota, con existencia independiente, que puede ser seleccionado y combinado in formas diferentes para generara maneras distintas de mirar a los datos. Ejemplos: diagnósticos, medicación , procedimientos, resultados de tests, etc. Los enunciados clinics pueden ser utilizados como vienen para compilar listas o combinaciones de de datos  de multiples orígenes. En portales para médicos o pacientes, se pueden mostrar los enunciados clínicos por fecha u origen.


Un documento clínico es una composición electrónica discreta, acerca de una paciente identificado, preparado para ser leído o utilizado por un ser humano, como un documento en papel, como un reporte o carta. Algunos ejemplos de documentos clínicos podrían ser documentos PDF, paginas webs, imágenes medicas, audio y video.


Los enunciados clínicos y los documentos clínicos se diferenciantanto en propósito como en granularidad. Ambos comparten algunas propiedades como persistencia, coherencia, completitud, legibilidad, integridad, y potencial para autenticación. Difieren en su propósito y su granularidad.. Idealmente, deberían utilizar los mismos metadatos para permitir su recuperación. Los requerimientos para los metadatos incluyen información sobre qué es el ítem, quién lo creó, cuándo, y con qué propósito.



Porqué son importantes los metadatos

Los metadatos son información sobre un item que se utiliza a posteriori para encontrarlo. Está limitada inevitablemente por lo que puede ser provisto por los sistemas de origen.


Los metadatos soportan que la información se comparta horizontal y verticalmente, soportando así el cuidado de la salud conjunto centrado en el paciente. Permite compartir la información horizontalmente a través de toda la red de cuidado del paciente, que incluye no solo a los sectores de salud, sociales y al voluntariado sino también amigos, y familiares. También soporta interoperabilidad vertical para agregar datos para gerenciamiento y análisis centralizado.


Los metadatos son primariamente usados para búsqueda fuera de la organización de origen y no para soportar transacciones de negocios locales. En consecuencia, los metadatos no incluyen información específica de las transacciones, a pesar que los items especificos de las transacciones muchas veces forman parte de los registros clínicos.

information, even though transaction-specific items are routinely found within clinical records.  


Los metadatos utilizados para búsqueda deben ser genéricos, mientras que los datos que participan en las transacciones son específicos de acuerdo a su contexto.

Mucha de la discusión acerca de este trabajo ha sido para explicar que la información que alguna gente define como importante es esencial para las transacciones, pero no es metadato. Aún más, cuando alguien usa un portal, no podemos asumir que alguien va a extraer items específicos, ni que los items allí encontrados serán completos o actualizados ( a pesar que cada item estará actualizado al momento de su creación)


Sin embargo, los metadatos deben ser completos, estandarizados, y sin ambigüedades. Si un item contiene un valor para un elemento de metadatos pero otro item que contiene información similar no lo contiene, cualquier búsqueda encontrará el último item pero no el primero. Esto puede ser peligroso y conlleva un riesgo clínico.

Es mucho mejor, entonces especificar un pequeño subconjunto de elementos obligatorios de metadatos que uno mayor pero con elementos opcionales.


Requerimientos

Los requerimientos definidos aquí son obligatorios, y no se permiten multiples instancias. Cada metadato de un item se relaciona exactamente a un paciente, un creador y una fecha de creación. Las versiones posteriores podrán relajar estas reglas, pero es mejor comenzar con especificaciones estrictas: la calidad de la información es fundamental.


Por conveniencia, hemos dividido los items de metadatos en seis grupos: Qué, Cuándo, Quién, Donde, metadatos técnicos y extensiones opcionales.


Qué

Este metadato incluye QUÉ es el item (su definición). Por ejemplo, si queremos especificar un “Resumen de Internación de Paciente en Urología”. 

Hay seis dimensiones de relevancia:


Clase – Categoría de alto nivel

Tipo – Categoria de nivel más fino o granular

Especialidad – Tipo de Servicio

Tipo de Cuidado - Modo de cuidado

Título – legible para humanos

Confidencialidad


Un par de ejemplos:


 Enunciado clínico: Peso del paciente registrado en su casa



Clase = hallazgo

Tipo = peso

Especialidad = iniciado por el paciente

Tipo de Cuidado = paciente (solo)

Título = registro de peso

Confidencialidad = N (normal)


Documento Clínico: resumen de alta de internación en urología


Clase = correspondencia

Tipo = resumen final de alta

Especialidad = urología

Tipo de Cuidado = internación

Título = Resumen de Internación en Urología

Confidencialidad = N


Clase (código requerido) describe el tipo general de ítem utilizando una clasificación a grandes rasgos


Es muy importante encontrar y revisar todos los registros aplicables y no perder items relevantes a los cuales se haya dado un nombre un poco distinto o una categoría distinta de nivel mas granular. Estas consideraciones apuntan a utilizar un pequeño conjunto de códigos conocidos por todos y bien entendidos, mutuamente exclusivos, para no perder información importante.


Ejemplos de códigos de clase para enunciados clínicos : problema (incluyendo diagnóstico y alergia), medicación, procedimiento, hallazgo, historia, episodio de cuidado realizado,episodio de cuidado propuesto, historia familiar, datos demográficos.


Ejemplo de códigos de clase para documentos clínicos: notas clínicas, correspondencia, orden, reporte e imagen.


Tipo (código requerido) describe el ítem a un nivel más fino de granularidad. Esto describe el tipo de item con más detalle, pero debe excluir la información sobre la especialidad clínica o tipo de cuidado, ya que estos se describen en Especialidad y Tipo De Cuidado.


La lista de tipos posibles para enunciados clínicos y documentos clínicos es larga. Para documentos clínicos el Tipo es absorbido por una clase (ejemplo los informes de alta son correspondencia clínica)


Sin embargo, esto no se cumple para enunciados clinicos. En los enunciados clínicos la clase puede ser utilizada para distinguir eventos que han sido planificados de eventos que han tenido lugar, para información sobre el paciente o sobre otros (historia familiar) o para indicar hallazgos negativos (en los hallazgos negativos la absorción funciona al revés: saber que alguien no tiene cáncer de hígado no implica necesariamente que no tenga cáncer ni que no tenga un problema de hígado)


Especialidad (código requerido) representa la especialidad o servicio responsable. Es deseable que esto sea definido tan precisamente como sea posible.


Tipo de Cuidado (código requerido) representa el tipo de evento tal como ‘internación’, ‘ambulatorio’, ‘domiciliario’


Título (requerido) representa el título del item en una forma legible para un ser humano, con posibilidad de ser mostrado en un navegador. Por ejemplo “Informe de Internación de Urología - Hospital Santa María”


Confidencialidad (código requerido) representa el nivel de sensibilidad del item. El valor por omisión es ‘normal’. Esto puede ser útil para soportar el control de acceso.


Cuándo


FechaDeCreación (requerido) es la fecha en la cual el item fue creado. Esto debe ser registrado como fecha/hora, con precisión a nivel de segundos, para que los items puedan ser listados en orden estricto cronológico o orden cronológico inverso. 


FechaDeEvento (requerido) representa la fecha del evento con el que se relaciona este ítem. Usualmente es el mismo o anterior a FechaDeCreación (a menos que el evento sea ‘Turnos Previstos’. Para eventos que tienen duración, el creador debe seleccionar la fecha más apropiada. FechaDeEvento no debe ser registrada con más precisión que la que se conoce.


Quién 


Paciente

Cada documento o enunciado clínico se refiere exactamente a un paciente identificado. Esto permite que los ítems sean recuperados por paciente. El metadato acerca de la identidad del paciente es lo mínimo requerido para identificar al paciente correcto.


En los sistemas en los que no se puede asumir un identificador común conocido por todos los que buscan datos, se necesita incluir uno o mas identificadores, nombres, sexo y fecha de nacimiento.


Debe recordarse que los metadatos son recabados en origen y la información en los portales de paciente generalmente puede no estar actualizada. Los metadatos no pueden alterarse una vez que se crea un ítem, aún si los datos del paciente se modifican (ejemplo…el nombre)


IdPaciente (requerido) es el identificador del paciente en el item original. Items sin identificador de paciente no son permitidos. El IdPaciente es idealmente un identificador común como el número de documento, pero otros identificadores pueden ser usados mientaras estén asociados con un esquema de identificación único. Esta flexibilidad extra permite extensión a otros países, o con sistemas que no permitan manejar el número de documento.


NombrePaciente (requerido) debe ser el nombre actual del paciente tal como se registró en el ítem. Es usado para chequeo por humanos (egile) Notar que la gente puede escribir su nombre de maneras distintas y puede cambiarlo a voluntad. Todavía hay discusiones sobre incluir el nombre del paciente como metadato.


Sexo (código requerido) es el género tal como se registró para propósitos de búsqueda de paciente.


FechaDeNacimiento (requerida) se usa para búsqueda de paciente. Dada la larga vida de los metadatos usados para la búsqueda, no hace falta la hora exacta, aún cuando el paciente sea un neonato.


Profesionales de Salud y Cuidado

IdCreador (requerido) es un identificador único para el autor u organización responsable de crear este ítem


NombreCreador (requerido) es el nombre (texto libre) de la organización o persona u organización responsable.



Creador es un nombre un poco confuso, pero no hemos encontrado uno mejor. En metadatos el que busca desea saber quien es el responsable del item. Cuando busca, es mas importante saber de que equipo clínico proviene determinado item, que quien lo escribió. El autor debe estar incluido en el item. En algunos casos el Creador puede ser el paciente.


No necesitamos saber el destino previsto del item, pero a veces esta información estará presente en el propio item


Donde


Ubicación (requerido) es el identificador de la persona responsable de la creación del item


Técnicos

Lenguaje (código requerido) registra el lenguaje original en el que fue escrito el item (ISO 639 format).


Formato (código requerido) especifica el formato preciso del item. Especifica si es un documento clínico o un enunciado, y detalles más finos para ayudar al procesamiento.


UUID (requerido) un identificador universal único para cada documento clinico o enunciado. Puede ser una URL


OriginaID (requerido) es un identificador asignado por el creador. Puede ser usado cuando el creador necesita referenciar un item explicitamente , pero no conoce su UUID


Extensiones


A pesar que no soportamos opcionalidad, hay ocasiones en las que es importante y justificado proveer un mecanismo de extension. El uso de tags opcionales lo facilita.


Tag (codigo opcional) provee una manera de marcar un item mas precisamente, especifica al caso de uso. Un codigo de servicio provee un elemento adicional de flexibilidad. Esto provee un lugar para agregar un campo adicional para aplicaciones especificas.


Reconocimientos

Mucho de esto se construyó sobre las bases del Proyecto Sintero, fondeado por el Wellcome Trust 2009-11 [1].  Esto fue generado a partir de experiencias en la arquitectura de registros clinics de pacientes y estándares de interoperabilidad en salud [2].  Hay también influencias de e-Government Metadata Standard (e-GMS) [3], ebXML registry [4], HL7 CDA [5] and IHE XDS [6].

/
<<  !<<  (r) 
-
/
-
/
/
false
Usage (1)
Busy
/
Template Path (Card/Conf) Project
CDA recordTarget 2013-02-10T00:00:00 hl7:recordTarget (0…*) MAIS
Busy
 
 
true50
Dataset MAIS-Conceptos
Id mais-1 Version 2013-02-10
Status Draft Version Label
false
Description
ASIP Santé Sandbox dataset: Electrocardiogram Report
false
Usage (…)
Busy Retrieving…
Busy