guia de implementacion de cda -...

DIVISIÓN DE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIONES

MINISTERIO DE SALUD www.minsal.cl

DOCUMENTO GUÍA DE IMPLEMENTACIÓN DE CDA – lABORATORIO

VERSIÓN 1.3

UNIDAD DEPARTAMENTO INTEGRACIÓN Y SIDRA

PÁGINAS Página 1 de 93

GUIA DE IMPLEMENTACION DE

CDA INFORME DE LABORATORIO

DEPARTAMENTO DE INTEGRACIONES Y SIDRA

DIVISIÓN DE TECNOLOGÍAS DE LA INFORMACIÓN Y

COMUNICACIONES

OCTUBRE 2018

http://www.minsal.cl/




VERSIÓN 1.3



1 Control de cambios

Versión Fecha Descripción del cambio





VERSIÓN 1.3



2 Equipo elaborador

Elaborado por

Cecilia Brown Jefa Departamento de Interoperabilidad y SIDRA

División TIC MINSAL

Gabriela Villavicencio Jefe de Proyecto Historia Clínica Compartida,


Juan José Ortega Referente Clínico


Carlos Nuñez Profesional,

FONASA

Ignacio Pineda Profesional,

CORFO – SALUD + DESARROLLO

Cesar Galindo Profesional

CENS

Jorge Mansilla Profesional

CENS

Javier Navarrete Profesional

CENS

Fernando Portilla Profesional

CENS

Revisado por Pablo Orefice Asesor MINSAL






VERSIÓN 1.3



3 Listado de participantes laboratorio

NOMBRE INSTITUCIÓN REPRESENTANTE





VERSIÓN 1.3



4 Tabla de contenidos

1 Control de cambios 2

2 Equipo elaborador 3

3 Listado de participantes laboratorio 4

4 Tabla de contenidos 5

5 Introducción 8

6 Audiencia 9

7 Gobernanza y mantención 10

8 Sobre esta guía 11

9 Antecedentes generales de un CDA 12

9.1 Que es un CDA 12

9.2 Niveles CDA 12

9.2.1 Nivel 1 12

9.2.2 Nivel 2 13

9.2.3 Nivel 3 13

9.3 Características generales de un CDA 13

9.4 Elementos de un CDA 14

9.4.1 Estructura de un CDA 14

9.4.2 Modelo de referencia de la información (RIM, Reference Information Model) 16

10 Glosario 18

11 Vocabulario de conformidad 20

12 Cardinalidad 21

13 Estructura de documentos CDA - laboratorio 22

13.1 Expresión NULL FLAVOR 22

13.2 Elemento raíz 23

13.2.1 ClinicalDocument 23

13.3 Cabecera 23

13.3.1 Clinical Document/realmCode 24

13.3.2 ClinicalDocument/typeId 25

13.3.3 ClinicalDocument/templateId 25

13.3.4 ClinicalDocument/id 25





VERSIÓN 1.3



13.3.5 ClinicalDocument/code 27

13.3.6 ClinicalDocument/title 27

13.3.7 ClinicalDocument/effectiveTime 28

13.3.8 ClinicalDocument/confidentialityCode 28

13.3.9 ClinicalDocument/languageCode 29

13.3.10 ClinicalDocument/setId/versionNumber 29

14 Cabecera datos de participantes 31

14.1 Record Target 31

14.1.1 Paciente 31

Sexo Biológico: 33

Fecha de nacimiento 34

Pueblos Indígenas 34

País de Nacimiento del Paciente 35

14.2 Ejecutante/Emisor (Autor) 38

14.3 Custodio 39

14.4 Solicitante del Informe 40

14.5 Validador del Informe 41

14.6 Datos de la toma del examen 42

15 Cuerpo del CDA 44

15.1 Secciones del Cuerpo 44

15.2 Estructura del Cuerpo 44

15.3 Descripción de las secciones 48

15.3.1 Identidad de Género 48

Entradas Codificadas 48

Identidad de Género del Paciente 49

15.3.2 Análisis de un Test Simple Resultado Único 50

Entrada Codificada de Resultado Simple 52

15.3.3 Test Simple Resultados Múltiples (Panel) 59

Entrada Codificada de Resultados Múltiples 61

Para cada entrada individual: 61

15.3.4 Batería Sobre Espécimen Único 67

Entrada Codificada Batería de Pruebas 69





VERSIÓN 1.3



16 Referencias 79

17 Ejemplo CDA 80





VERSIÓN 1.3



5 Introducción

La situación sanitaria en Chile plantea avances con respecto a la informatización de la

Ficha Clínica de los pacientes, permitiendo la recolección de datos, valoraciones e

informaciones de cualquier índole, sobre la situación y la evolución clínica de un paciente

a lo largo del proceso asistencial. Los Servicios de Salud han informatizado algunos de

sus procesos productivos para responder a los diferentes requerimientos de información,

tanto internos como externos, mediante el desarrollo de sistemas de información

heterogéneos, que soportan las necesidades propias de los establecimientos.

Dichos avances han demostrado solventar las necesidades locales, sin embargo, no

poseen la capacidad de interoperar con otros servicios ni estructuras centrales

convirtiéndolas en islas de información, generando dificultad en la recolección de datos y

falta de calidad de acceso a la información debido a la poca estandarización.

Este documento tiene como propósito lograr la interoperabilidad en los diferentes niveles

definiendo la manera en la que se deberá construir un documento CDA, tanto a nivel de

cabecera como de cuerpo para ser usado dentro del proyecto de Historia Clínica

Compartida en Chile.





VERSIÓN 1.3



6 Audiencia

La audiencia para este documento son los arquitectos, desarrolladores o los

implementadores de los sistemas de información en salud de la red asistencial pública y

privada. La finalidad de este documento es apoyar la correcta creación, validación y

consulta de documentos clínicos.

Este documento está basado con los conceptos de CDA, particularmente el CDA Release

2. Se asume que el lector está familiarizado con RIM (Reference Information Model) del

estándar HL7 v3 y XML (eXtensible Markup Language) del W3C. También se asume que

existe un conocimiento básico del estándar HL7 CDA Release 2.

Pese a los requerimientos antes mencionados, éste documento es descrito de la manera

más simple posible, de tal forma que permita la comprensión de personas no expertas

en el estándar HL7, en el desarrollo y manipulación del CDA.

Además, se deberá considerar la lectura de la “Guía de Implementación de OID para

HCC” para el entendimiento completo del presente documento.





VERSIÓN 1.3



7 Gobernanza y mantención

La mantención y el gobierno de la información que incorpora este documento estará a

cargo del Ministerio de Salud de Chile, siendo esta la primera versión y pudiendo ser

actualizada cada vez que se considere necesario.

Las actualizaciones de este documento serán publicadas oficialmente por el Ministerio de

Salud en su sitio oficial y será comunicada a todos los implicados en el consumo del

presente documento.





VERSIÓN 1.3



8 Sobre esta guía

Este documento está diseñado para proporcionar detalles sobre la construcción de CDA

para el dominio de exámenes de laboratorio Algunas partes de ésta guía han sido

extraídas de la normativa de HL7, Clinical Document Architecture (CDA) Release 2.0.

[1], y de las especificaciones los TF de Document Cross Sharing Lab de IHE. Las

referencias se pueden consultar en el apartado de Referencias de este documento.

Esta Guía no pretende ser una referencia completa de los esquemas de CDA, este

documento debe ser usado en complemento a las especificaciones de la normativa para

la implementación y el desarrollo de CDAs, este documento pretende proporcionar un

nivel común de comprensión en los asuntos relacionados con el CDA R2 estándar

relacionados con los proyectos de Chile y en este caso específico para exámenes de

laboratorio. La normativa debe ser seguida en todos los casos y cualquier desviación de

la especificación es un error.





VERSIÓN 1.3



9 Antecedentes generales de un CDA

9.1 Que es un CDA

El estándar HL7 CDA (Clinical Document Architecture) o en español, Arquitectura de

Documentos Clínicos, es un estándar de marcado XML, cuyo objetivo es establecer las

especificaciones de codificación, estructura y semántica de documentos clínicos

electrónicos. El fin de respetar este estándar es poder realizar el intercambio y la

interoperabilidad de la información entre diferentes actores o sistemas de información en

salud.

9.2 Niveles CDA

Una de las características que hacen a un CDA escalable en su estructura, es que puede

tener diferentes niveles de implementación. Cada nivel le agrega un grado de

interoperabilidad semántica al intercambio de los documentos clínicos. Existen tres

niveles, los cuales se pueden ver a continuación.

9.2.1 Nivel 1

CDA compuesto por dos secciones principales, una cabecera, la cual levanta información

referente al contexto del encuentro médico, además de proveer la metadata que

describe el documento clínico. Y el cuerpo del documento, que es una sección no

estructurada, la cual puede contener contenido en texto, html, pdf, documentos,

imágenes, o cualquier otro tipo de archivo





VERSIÓN 1.3



9.2.2 Nivel 2

Nivel 1 + más cuerpo del documento compuesto por bloques de texto libre, donde a

cada uno de estos bloques se les llama secciones y las cuales deben poseer un código

identificatorio, el cual puede ser, por ejemplo, un código LOINC o SNOMED CT

9.2.3 Nivel 3

Nivel 2 + más secciones y entradas, donde estas últimas corresponden a entries

codificadas de acuerdo a algún vocabulario terminológico, como, por ejemplo, SNOMED-

CT, LOINC, CIE-10, etc. Hay distintos tipos de entry para la representación de

diagnósticos, procedimientos, medicamentos, entre otros.

9.3 Características generales de un CDA

Un documento CDA posee las siguientes características que lo hacen valorable a la hora

de la implementación de sistemas información en salud:

Persistencia: Un documento clínico continúa existiendo sin ninguna alteración o

modificación, por un periodo de tiempo, definido según la reglamentación y

leyes locales.

Administración: Un documento clínico es mantenido, por una organización

encargada de su cuidado.

Autenticación: Un documento clínico posee la capacidad de poder ser

registrado o firmado por el representante legal, asegurando la integridad y

exactitud de la información clínica contenida en el documento.





VERSIÓN 1.3



Contexto: Un documento clínico cuenta una historia acerca de la atención que

se entregó a un paciente. Esta contiene información acerca de los participantes

de la atención, donde fue practicada y cuando.

Integridad: La autenticación es aplicada a todo el documento y no a porciones

del documento, sin contexto.

Legible: Debe ser un documento legible por el ser humano.

9.4 Elementos de un CDA

9.4.1 Estructura de un CDA

Un documento CDA está compuesto de dos partes que son la Cabecera y el Cuerpo.

Cada una de ellas posee una estructura determinada, cuya complejidad depende de la

cantidad de datos y el formato de estos, que se desean notificar en el documento

Ilustración 1Estructura de un CDA





VERSIÓN 1.3



Cabecera del documento: esta sección posee un conjunto de datos, con el fin

de contextualizar el documento clínico, guardando información tales como

quién creó el documento, cuando y donde.

La cabecera en principio organiza la información con la metadata para manejar

e indexar el documento. En términos prácticos, es en este conjunto de

secciones que se describe dentro de la notificación de un encuentro clínico el

Quién, qué, dónde y cuándo, con mayor o menor detalle sea el caso.

Como estructura del estándar la cabecera debe poseer algunos elementos

básicos que deben ser considerados como requeridos como lo son:

o id del documento

o Tipo de Documento

o Descripción del objeto al cual se le realiza el acto clínico (recordTarget)

o Autor

o Custodio del documento

Cuerpo del documento: El cuerpo del documento tiene como finalidad el

informar sobre las componentes clínicas que se obtienen durante el desarrollo

del acto clínico sobre el recordTarget. Dado que puede contener la descripción

de una serie de elementos clínicos diversos, es que la distribución de esta

información se separa en elementos de datos denominados Secciones.

Cada sección es considerada por el estándar para ser legible por el ser

humano, lo que le da la condición a dicha sección de ser Nivel 2. La estructura

de cada sección queda especificada en un template.

Si a una sección se le desea entregar más que solo texto narrativo, sino que

características que le permitan ser procesable, entonces se le agregan

entradas por cada elemento codificado que se desee agregar. Esto describe

una sección en Nivel 3





VERSIÓN 1.3



Ilustración 2Estructura en bloques del Documento Clínico en CDA

9.4.2 Modelo de referencia de la información (RIM, Reference Information Model)

El Modelo HL7 RIM de por sí, permite llevar la interpretación de un acto clínico a un

documento informáticamente realizable. Esto se genera gracias al hecho que considera

los elementos propios de un encuentro médico. En la siguiente imagen se observa una

figura simplificada, obtenida desde el RIM, en la cual se pueden apreciar las 6 principales

clases, Entity, Role, RoleLink, Participation, Act, ActRelationship, que componen un

documento clínico:





VERSIÓN 1.3



Ilustración 3RIM esquema simplificado

Para que esto tenga sentido en el estándar, es que cada uno de los participantes con sus

roles y sus actos relacionados deben ser descritos de una manera específica, de manera

que permita universalizar la forma de cómo se realizan las notificaciones. El modelo

precisamente lo que hace es desarrollar con mayor detalle dicha descripción, la cual se

puede ver en el siguiente diagrama, a diferencia del anterior, con más detalles sobre

cada actor, acto y relación.

Ilustración 4 Modelo RIM en CDABoone K. (2011). The CDA book. Springer. 10.1007/978-0-85729-336-7





VERSIÓN 1.3



10 Glosario

Analito: Componente de interés de análisis

Batería: Conjunto de exámenes que se realiza sobre una sustancia particular

Cabecera del CDA: conjunto de datos, con el fin de contextualizar el documento

clínico, determinando información tal como quién creó el documento, cuando y

donde.

CDA: Clinical Document Architecure, (Arquitectura de Documento Clínico), es un

estándar de marcado XML, cuyo objetivo es establecer las especificaciones de

codificación, estructura y semántica de documentos clínicos.

Cuerpo del CDA: El cuerpo del documento tiene como finalidad el informar sobre

las componentes clínicas que se informan en el documento, y que son parte de los

datos levantados durante el desarrollo del acto clínico sobre el objeto del acto

(comúnmente un paciente)

HCC: Historia Clínica Compartida, proyecto de MINSAL que tiene como propósito

generar un registro documental de encuentros clínicos a modo de poder configurar

la historia sanitaria de un paciente a nivel nacional, y que esta información pueda

ser visualizada por cualquier otro prestador que participe de la atención de dicho

paciente, con los permisos y restricciones correspondientes

HL7: Health Level Seven International, es una organización sin fines de lucro, la

cual provee un conjunto de estándares para facilitar el intercambio electrónico de

información clínica.

Interoperabilidad: capacidad de dos o más sistemas de información y aplicaciones

de software de intercambiar información y que esta sea comprensible y procesable

Interpretación: Forma universal mendiante se categoriza un resultado o un rango

de valores en una prueba de laboratorio

Método: Forma tecnológica y científica mediante la cual se desarrolla una prueba

de laboratorio

OID: Identificador de objeto (Object Identifier) es un identificador global único.





VERSIÓN 1.3



RIM: Modelo de referencia de información (Reference Information Model), es un

modelo que permite llevar la interpretación semántica de un acto clínico a un

modelo computable.

UUID: Identificador Único Universal (Universal Unique Identifier), utilizado para

identificar un objeto unívocamente.

XML: eXtensible Markup Language, traducido como "Lenguaje de Marcado

Extensible" o "Lenguaje de Marcas Extensible", es un metalenguaje que permite

definir lenguajes de marcas desarrollado por W3C.





VERSIÓN 1.3



11 Vocabulario de conformidad

Para determinar el grado de requerimiento que los elementos de datos deben tener

respecto a la necesidad de ser implementados en los documentos clínicos, y a ciertos

atributos que dichos elementos poseen, es que se declara un vocabulario de conformidad

que indica la obligatoriedad u optatividad de cada uno de los elementos.

Para elementos de cabecera y atributos de secciones del cuerpo

DEBE: Obligatorio

PUEDE: Elemento Opcional

Para Secciones, Subsecciones y Entradas

R: Requerido

R2: Requerido de existir el dato

O: Optativo





VERSIÓN 1.3



12 Cardinalidad

La cardinalidad obedece a la determinación del grado de repetitividad que algún

elemento de dato puede tener dentro de la estructura del documento clínico. La notación

incluye además la determinación de obligatoriedad del dicho dato en la conformación del

Documento Clínico en el estándar

[1..1]: Elemento no repetitivo y requerido

[0..1]: Elemento no repetitivo y optativo

[1..*]: Elemento repetitivo las veces que se estime necesario y requerido

[0..*]: Elemento repetitivo las veces que se estime necesario y optativo

[1..n]: Elemento repetitivo un máximo de n veces y requerido

[0..n]: Elemento repetitivo un máximo de n veces y optativo





VERSIÓN 1.3



13 Estructura de documentos CDA - laboratorio

TIPO DE IDENTIFICACIÓN

Para identificar objetos o elementos dentro del documento clínico, se requiere de un

sistema que provea unívocamente de estos id. En el caso de la estructura del un CDA

existen dos posibles formas para llevar a cabo este proceso, o por medio de

identificadores universales o identificadores locales.

La identificación de elementos universales como lo es un sistema de codificación, un

catálogo, etc, se realiza por medio de un sistema denominado OID (Object Identifier),

que en base a un número compuesto construye el identificador de los objetos asignando

su id desde un valor raíz. Sobre la conformación de los OID para el proyecto HCC,

referirse al documento “OID para HCC”.

Cuando lo que se requiere es un identificador local para un objeto como un documento

interno, un id de documento de proceso, etc. lo que se puede generar en un identificador

por medio de UUID (Universal Unique Identifier). Este identificador es generado por un

software y corresponde a un número de 16 bytes y se expresa mediante 32 dígitos

hexadecimales divididos en 5 grupos separados por guiones, por ejemplo: 550e8400-

e29b-41d4-a716-446655440000. Para hacerlo único se describen algunas reglas para la

composición de este identificador.

13.1 Expresión NULL FLAVOR

Se utiliza para identificar que la información no existe y porque esta no está disponible,

y cumple la misma función que el NULL en una base de datos.





VERSIÓN 1.3



Para identificar porque el dato no se encuentra disponible se usa un sistema de código

que describe ese atributo

NI : No hay información

NK : No aplicable

UNK : Desconocido

13.2 Elemento raíz

13.2.1 ClinicalDocument

El elemento raíz correspondiente es . Este elemento, debe estar

bajo el namespace”urn:hl7-org:v3”, indicando que lo que se describe en el código será

un documento clínico con una hoja de estilo definida para el CDA. El formato de esta

etiqueta se ve en el siguiente esquema:

:

13.3 Cabecera

Para el caso Informe de Laboratorio, en función de los elementos de datos definidos en

las mesas de trabajo, ajustado a los requisitos para cumplir el estándar es que se llegó a

la siguiente designación de elementos de datos propios de la cabecera.

Elemento Cardinalidad Descripción





VERSIÓN 1.3



realmCode 0..1 Descripción de la zona geográfica en donde será aplicado el CDA.

typeId 1..1 Especificación de los elementos de datos de CDA.

templateId 1..1 Identificación del Template del CDA.

Id 1..1 Valor de Identificación unívoco e irrepetible del documento creado.

code 1..1 Identificador en código del tipo de documento que se genera.

title 0..1 Título Visible para el lector del documento.

effectiveTime 1..1 Fecha y hora de creación del CDA.

confidentialityCode 1..1 Nivel de confidencialidad del documento.

languageCode 1..1 Tipo de lenguaje usado en el documento clínico.

setId/versionNumber 1..1 Identificación y número de la versión de documento.

recordTarget 1..1

Identificación y datos del contexto sobre el acto clínico del paciente atendido. Se considera la

descripción del paciente, su eventual custodio y centro de atención.

Author 1..2

Autor del documento que para motivos de este

documento vendría a ser el ejecutor. Además se considera agregar aquí a quien emite el informe en caso de ser alguien distinto al autor.

Custodian 1..1 Detalle de la Organización responsable de custodiar los documentos clínicos generados.

informationRecipient 1..1 Se entiende como el solicitante del examen, siendo por lo común el medico que referenció la realización de este.

Aunthenticator 1..1 Identifica a quien valida al documento emitido.

documentationOf 1..1 Define hora de toma y recepción de la muestra.

Tabla 13-1Elementos de la Cabecera

13.3.1 Clinical Document/realmCode

Este valor identifica la realidad bajo la cual el documento tiene alcance. El elemento

ClinicalDocument/realmCode podrá estar presente y de estarlo, su código deberá

corresponder al de Chile.





VERSIÓN 1.3



13.3.2 ClinicalDocument/typeId

Dentro del RIM, modelo de referencia de HL7 v.3, este elemento referencia una

estructura fija del esquema del CDA normativo de HL7 V.3 la cual debe ser incluida para

dar conformidad al estándar CDA. Consta de dos atributos obligatorios, este valor no es

opcional y debe ser registrado para todo documento CDA.

13.3.3 ClinicalDocument/templateId

Con el objetivo de determinar el formato xml del CDA, debe especificarse un valor en la

raíz del elemento templateId indicando la identificación del template usado. Para estos

efectos, se ha definido el siguiente OID para identificar el tipo de documento

"2.16.840.1.113883.2.22.0.100.110.21" correspondiente a Template Cabecera CDA

Labortorio, el cual puede ser revisado en la Guía de OID para HCC.

13.3.4 ClinicalDocument/id

Este elemento corresponde a la identificación única del documento por lo que debe ser

declarada. Su uso permite que los documentos que se intercambien entre distintos

sistemas no colisionen por su identificación. El elemento id contiene un único elemento

root, bajo el siguiente formato:





VERSIÓN 1.3



Debe contener un atributo root, que declara el identificador del documento

creado.

Este identificador se debe crear en formato OID y con el propósito de garantizar

que el código sea único por cada documento. Se debe seguir la siguiente regla de

construcción:

o Raíz OID Chile: 2.16.840.1.113883.2.22, seguido de

o Rama Organización: 0, seguido de

o ID Organización Padre (Servicio de Salud, Clínica), seguido de

o ID Organización Hijo (Hospital, Centro de Salud, Sucursal si es el caso),

seguido de

o ID Objeto Documento: 100, seguido de

o Fecha de generación (timestamp, formato AAAAMMDDhhmmss)

▪ AAAA: Año

▪ MM: Mes

▪ DD: Día

▪ hh: Hora

▪ mm: minuto

▪ ss: segundo

o ID Aplicación (número asignado a cada aplicación de manera interna de

cada organización/establecimiento)

Ejemplo:





VERSIÓN 1.3



13.3.5 ClinicalDocument/code

La identificación del tipo de documento CDA se realiza a través del elemento

ClinicalDocument/code, (para este caso un informe de laboratorio). Este elemento debe

ser incluido en la cabecera y debe contener los siguientes atributos:

El atributo @code del elemento , indicará la identificación del tipo de

documento, según codificación en LOINC.

@code debe contener el valor 11502-2, que corresponde a un documento del

tipo “Laboratory Report” en LOINC.

El atributo @codeSystem debe ser “2.16.840.1.113883.6.1” que identifica el

sistema de codificación como LOINC mediante su OID.

Debe ser agregado el atributo @displayName que describe en texto el tipo de

documento. En este caso se ha cotejado el documento en LOINC ya referido como

el más cercano a la descripción de un documento de Reporte de Laboratorio.

13.3.6 ClinicalDocument/title

El documento debe tener un título de documento, el cual debe ser indicado en el

elemento ClinicalDocument/title

Este título debe ser acorde con el tipo de documento expresado en el elemento @code.

Informe de laboratorio

http://www.minsal.cl/about:blank




VERSIÓN 1.3



13.3.7 ClinicalDocument/effectiveTime

Se debe indicar la fecha de creación del documento en el elemento

ClinicalDocument/effectiveTime

La fecha se debe indicar en el atributo @value,

La fecha además se debe indicar al menos precisión de segundos bajo el formato:

AAAAMMDDhhmmss.

En donde

AAAA: Año

MM: Mes

DD: Día

hh: Hora

mm: minuto

ss: segundo

13.3.8 ClinicalDocument/confidentialityCode

El documento debe declarar un nivel de confidencialidad en el elemento

ClinicalDocument/confidentialityCode.

El set de valores para este atributo debe ser el siguiente:

Código Descripción Uso

N Normal Reglas de acceso normales.(Sólo personas autorizadas con una necesidad sanitaria o similar podrán consultar la información





VERSIÓN 1.3



R Restringido Reglas adicionales exigidas. Sólo podrán acceder a él profesionales sanitarios que estén tratando al paciente

V Muy Restringido Sólo podrán acceder a esta información aquellos con autorización expresa del paciente, o bajo una situación de emergencia.

Tabla 13-2Valores para el atributo confidentialityCode

El atributo @code debe contener algunos de los valores indicados en el set

anterior

El atributo @codeSystem debe ser de valor “2.16.840.1.113883.5.25”. que

obedece al OID de HL7 asociado a codificadores de V3, en particular el de

Confidencialidad

13.3.9 ClinicalDocument/languageCode

Debe especificarse el lenguaje en el cual se escribe el documento:

El valor de @code de lenguaje deberá estar en este formato: nn-CC

nn debe ser un código perteneciente a la ISO-639-1

CC podrá estar presente como una composición del valor nn del @code, y de

estarlo debe ser un código perteneciente a la ISO-3166, indicando la

particularidad del lenguaje.

Dado que el documento se usará para la realidad chilena se debe usar como CC el

valor “cl”.




VERSIÓN 1.3



Para nuevas versiones de un documento, el setId debe tener el mismo valor que el

elemento ClinicalDocument/id, del mismo documento, y el @value del número de

versión debe ser 1.

Cuando se requiera reemplazar o modificar algún documento previo, el dede

hacer referencia al ClinicalDocument/id del documento anterior y el versionNumber

deberá ser incrementado en 1.

Todo documento debe contar con un setId y un versionNumber





VERSIÓN 1.3



14 Cabecera datos de participantes

14.1 Record Target

14.1.1 Paciente

Los datos del paciente deben ser indicados en el documento y deben agregarse bajo el

nodo ClinicalDocument/recordTarget/patientRole

El Paciente se dividirá en 3 secciones para su descripción: 1) Rol del paciente: Información Administrativa 2) Información del Paciente: Información Personal

3) Alcance: Información del Prestador al cual acude (Laboratorio).

A continuación, se presenta la estructura para la información del Paciente, donde se

debe respetar el orden de los elementos de acuerdo al siguiente cuadro, con la finalidad

que el documento esté conforme a la normativa de HL7 V3 CDA r2.

1) Rol del Paciente:

Identificador: Se debe determinar un identificador para la persona, en cuya

extensión se indicará el número de documento y en el @root el tipo de documento

y su procedencia.





VERSIÓN 1.3



o El tipo de documento debe ser identificado según lo indicado en la Tabla

Maestra de tipo de Documento.

o Para la definición de la raíz el elemento @root debe contener un OID que

identifica unívocamente el tipo de documento y su país de procedencia. La

generación de este OID debe ser acorde al formato indicado en la Guía de

OID para HCC

o El elemento @extension, debe contener el valor de identificación que el

documento posee para dicha persona

Tipo de documento ID

Certificado de Nacimiento 666784

Tarjeta de Ciudadanía 679000

Licencia de conducir 687600

Pasaporte diplomático 688000

Número de Historia Clínica 778200

Número de Pasaporte 808078

Identificador individual único

nacional 787300

Número de Seguro Social 838300

Sin documento de

identificación personal 836873

Rol Único Nacional Provisorio 787380

Tabla 14-1Identificacion de tipo de documento e ID de este

2) Información del Paciente

El nombre del paciente debe estar especificado en el documento.

Debe ingresar al menos un nombre del paciente. En caso de tener más de un

nombre, se puede ingresar los demás en el mismo elemento. Además, se debe

considerar que el primer nombre corresponderá al registrado al momento de





VERSIÓN 1.3



nacer. Para ingresar los nombres, se debe usar el elemento name/given como

un texto libre.

o Se puede ingresar un nombre social el cual debe ser asociado mediante el

atributo qualifier. Este atributo se debe agregar dentro del elemento

given, con valor CL, que corresponde a “nombre deseado por el paciente”.

o Se debe ingresar un Primer Apellido, siendo este solamente uno, y debe

ser ingresado en el elemento name/family.

o Se puede ingresar un Segundo Apellido, siendo este solamente uno el cual

debe ir en el elemento name/family, pero siempre debe ir posterior al

Primer Apellido.

Daniel Esteban Daniela

Montillo Cortéz

Sexo Biológico:

Este corresponde al sexo con el cual el paciente fue registrado al momento de nacer. El

elemento debe estar especificado en el documento.

Este debe ser descrito por un código que identifica al sexo en el atributo @code.

Se debe utilizar un sistema de codificación para identificar la procedencia del

código usado. Esta codificación debe ser la descrita en la tabla “Sexo” de la

Norma Técnica 643, cuya identificación en el elemento @codeSystem debe ser el

OID "2.16.840.1.113883.2.22.0.100.90.5".

Debe contener un texto que describa la glosa del sexo codificado, en

@DisplayName.





VERSIÓN 1.3



Fecha de nacimiento

Debe indicarse Fecha de nacimiento.

La fecha de nacimiento debe ser descrita en el atributo @value del elemento

.

Debe seguir el formato AAAAMMDDhhmmss en donde

o AAAA: Año

o MM: Mes

o DD: Día

o hh: Hora

o mm: minuto

o ss: segundo

Pueblos Indígenas

Se puede describir la etnia del paciente en el elemento ethnicGroupCode

En caso de definir la Etnia se debe considerar el código según tabla “Pueblo

Indígena” de la Norma Técnica 643 en el atributo @code.

Se deberá especificar la representación de dicho valor en el elemento

@displayName.

Se debe especificar el sistema de codificación por medio del siguiente OID

"2.16.840.1.113883.2.22.0.100.90.7", el cual identifica la Tabla Maestra Pueblo

Indígena generada para este documento, en @CodeSystem.





VERSIÓN 1.3



País de Nacimiento del Paciente

Se puede indicar el país en el cual el paciente nació

En caso de notificar país de nacimiento esto debe ser hecho en el elemento

birthplace/place/addr .

Para la determinación del país se debe usar la descripción de una dirección en

donde solo se deberá usar la etiqueta country con el nombre del país de origen.

Chile

3) Alcance: Identificación del Laboratorio

La identificación del Laboratorio debe ser notificada y debe hacerse en

recordTarget/patientRole/providerOrganization

La identificacion del laboratorio debe registrarse en el elemento por medio

del atributo @root. El valor de root debe ser el OID correspondiente al laboratorio

segun la guía “Guía de Implementación de OID para Historia Clínica Compartida”

Se debe identificar el nombre del establecimiento

Se debe identificar la dirección del laboratorio determinando, calle, número,

comuna y ciudad en el elemento addr

o Calle deberá ser indicada en el elemento streetNameBase

o Número deberá ser notificado en el elemento houseNumber





VERSIÓN 1.3



o La ciudad deberá ser indicada en el elemento city

o La comuna deberá ser notificada en el elemento prescint

o La región podrá ser indicada en el elemento state

Se debe identificar a la organización por medio de su número OID generado. La

generación de un OID para identificar a un establecimiento se indica en el

documento Guía de OID para HCC.

Laboratorio Clínico, El Clínico Calle los Loros No 123 Valparaíso Valparaíso Valparaíso

Un paciente finalmente debiera quedar definido como sigue a continuación





VERSIÓN 1.3



Calle los Vencedores

No 33 Casa 22 Valparaíso Valparaíso Región de Valparaíso

Chile

Daniel Esteban

Daniela Montillo Cortéz

Chile

Laboratorio Clinico, El Clinico Calle los Loros No 123

Valparaíso Valparaíso





VERSIÓN 1.3



14.2 Ejecutante/Emisor (Autor)

Cada autor participante se define a través de un elemento , el cual para cada

documento que se genere debe estar declarado. En el contexto de un examen de

laboratorio se entiende que el autor del documento será el Ejecutante de la Prueba, por

lo que autor y ejecutante convivirán en este elemento de dato.

En caso que el documento sea emitido por un segundo participante (distinto del

ejecutor), este se debe ingresar en esta sección también.

Dado lo anterior, es que para el informe de laboratorio se considerará cardinalidad 1...2.

Para ambos personajes se sigue el siguiente contexto:

Deberá definirse el momento de la autoría en el atributo @value del elemento

time.

Para identificar al author mediante el elemento id, se debe cumplir el mismo

formato que el especificado en la identificación del paciente

Debe designarse nombre al autor del documento. Esto deberá seguir el mismo

formato de nombre que del paciente con las siguientes excepciones

o No será aplicable el Nombre Social

o Deberá agregarse como primer elemento del nombre el elemento

, cuyo valor contenido debe ser equivalente el título Profesional

del Ejecutante/Emisor (Dr., Tecnólogo Médico, etc)





VERSIÓN 1.3



Tecnólogo Médico Juan Cortes

14.3 Custodio

Se debe indicar el centro que se hace responsable del almacenamiento del documento

original. Esto se realiza a través del elemento custodian. El elemento debe contener los

siguientes datos:

Debe haber un identificador del centro en

/ClinicalDocument/custodian/assignedCustodian/representedCustodianOrganizatio

n/id.

La forma como se declara la identificación deberá ser con el mismo formato

utilizado para declarar el id de una organización.

Dado que el documento será almacenado por el repositorio de MINSAL, será este

el custodio de la información, por tanto, su identificación en @root debe ser el

OID de identificación de MINSAL que corresponde a

2.16.840.1.113883.2.22.2.0.100.

Debe declararse el Nombre del centro, en

custodian/assignedCustodian/representedCustodianOrganization/name, que en

este caso Corresponde a MINSAL.





VERSIÓN 1.3



14.4 Solicitante del Informe

Debe existir un receptor del informe, quien comúnmente es el médico que ha solicitado

dicho informe, lo cual deberá ser indicado en el elemento

/ClinicalDocument/informationRecipient/intendedRecipient.

Al notificar el receptor del informe se debe definir lo siguiente

Se debe generar la etiqueta informationRecipient (dominio de envío y

recepción del documento) y en el elemento @typeCode se debe identificar la

categoría de quien recibe el documento. En este caso dado que el informe será

derivado a un “destinatario principal”, es decir al médico que solicitó el informe, el

valor de @typeCode, debe ser siempre PRCP (Principal Recipient).

Debe ser identificado el receptor por medio de la etiqueta intendedRecipient

o Deberá ser declarado un identificador de la persona por medio del

elemento id el cual deberá seguir las mismas reglas especificadas en la

identificación del paciente.

o Nombre

▪ El nombre del Acompañante deberá contener el mismo formato que

el determinado para el paciente. Sin embargo, para poder ser

Repositorio Ministerio de Salud (MINSAL)





VERSIÓN 1.3



ingresados sus elementos de datos estos deben ser contenidos en

una subetiqueta informationRecipient

Doctor Cirujano Felipe

Medorn Rojas

14.5 Validador del Informe

El validador del informe de laboratorio, debe ser declarado en authenticator definiendo

los siguientes elementos:

Debe identificar fecha y hora de la validación, la cual debe ser contenida en el

elemento @value, en el formato explicado para la definición de la fecha y hora de

creación del documento.

Debe indicar el tipo de firma que valida el documento según tabla 0535 de HL7

La entidad que valida debe ser declarada bajo la etiqueta assignedEntity en

donde se debe identificar a la persona mediante la entrada id, que deberá seguir

las mismas reglas de identificación declaradas en el id del paciente.

Para identificar el nombre del validador se deberá crear la sección

assignedPerson dentro de assignedEntity, en donde se deberá seguir el

mismo formato que en el nombre del paciente con las siguientes diferencias:

o No será aplicable el Nombre Social.





VERSIÓN 1.3



o Debe agregarse como primer elemento del nombre el elemento ,

cuyo valor contenido debe ser equivalente el título Profesional del

Ejecutante/Emisor (Dr., Tecnólogo Médico, etc)

Tecnólogo Médico Patricia DiMAria Andrade

14.6 Datos de la toma del examen

Se deben definir los siguientes elementos:

Identificación interna del laboratorio de la muestra.

Hora de toma de la muestra.

Hora de recepción de la muestra.

Lo anterior se declara dentro del elemento encargado de determinar datos sobre el acto

/ClinicalDocument/documentationOf/serviceEvent, cuyo classCode deberá ser

declarado como OBS (observación). Deberá contener los siguientes elementos:

Id que debe identificar a la muestra como identificador interno del laboratorio.





VERSIÓN 1.3



o @root del identificador debe ser el OID

2.16.840.1.113883.2.22.0.5000.1234.120 que determina un número de

muestra de organización privada Laboratorio

o @extension debe contener el valor interno de identificación de la muestra

effectiveTime contendrá los valores de las horas del evento en donde:

o La etiqueta low debe contener el @valor con la fecha y hora de la toma de

la muestra

o La etiqueta high debe contener el @valor con la fecha y hora de la

recepción de la muestra

o El formato de fecha/hora debe ser el mismo que el especificado para la

fecha y hora de la creación del documento





VERSIÓN 1.3



15 Cuerpo del CDA

15.1 Secciones del Cuerpo

Requerido/Optativo Sección Definición templateId

O Antecedentes

Sociales y Hábitos

Antecedentes del estilo de vida

del paciente además de elementos normativos como el

sexo registral y el nivel de instrucción

2.16.840.1.113883.2.22.0.100.110.5

R2 Análisis de un

Test Simple Resultado único

Resultado de un examen que

basado en un analito se obtiene un único resultado

2.16.840.1.113883.2.22.0.100.110.28

R2 Test Simple

Resultados múltiples

Resultado de un examen de

Test Simple con Resultados Múltiples

2.16.840.1.113883.2.22.0.100.110.29

R2 Batería sobre espécimen único

Resultados de un set de

exámenes realizado sobre un espécimen mediante una batería con múltiples exámenes sobre distintos analitos

2.16.840.1.113883.2.22.0.100.110.30

Tabla 15-1Secciones del cuerpo

15.2 Estructura del Cuerpo

El cuerpo del Documento se estructura en secciones, cada una de las cuales tiene

contenido afín al propósito de dicha sección.

En general, una sección contendrá información suficiente para describir el/los elementos

de datos que se desean informar, como también para entregar información computable

suficiente para poder estructurar dicha información. Es por esto que una sección deberá

contener como base los siguientes elementos:





VERSIÓN 1.3



TemplateId: Valor OID que determina la identificación del template en particular

para la sección tratada. Estos identificadores son OID registrados bajo el nombre

de la sección descrita en esta guía.

Código: El código contiene información relativa a la referencia de la sección,

indicando su procedencia mediante un código LOINC, el nombre de la sección y el

sistema de codificación sobre el cual se ha determinado el tipo de sección que

para nuestro caso será LOINC como fuera indicado.

Texto Narrativo: Parte de la sección que es usada para narrativa del autor y que

permite legibilidad humana.

Entradas: Solo serán requeridas en caso de que se especifique necesidad de

codificar ciertos elementos de información.

Elementos de datos dentro de la sección.

Además, cada sección de descripción de Resultado de Laboratorio debe indicar la

siguiente información según la tabla que sigue:

Elemento Descripción Req/Opt

Analito descripción del analito analizado R

Valor Valor de la Medición R

Método Método por el cual se ejecutó el análisis R2

Tipo de Muestra Origen sobre el cual se realiza el análisis del analito R

Unidad de Medida Unidad en la cual se expresa el resultado R

Rango(s) de Referencia

Simple o único es el rango que permite determinar el estado del resultado para su interpretación

R

Interpretación Valor estándar para una conclusión del resultado obtenido. La interpretación puede estar presente tanto en el resultado del analito como en el rango

R2

Estado del analito valor estándar para determinar la fiablidad del resultado R2

Observaciones Comentarios respecto al resultado O

Tabla 15-2 Elementos de descripción de resultados de Laboratorio

La descripción de cada análisis realizado debe ser codificada en el Sistema de

Codificación LOINC, al igual como el grupo de examen al cual pertenece.

Para términos de esta guía se consideran las siguientes especialidades con su respectivo

Código LOINC.





VERSIÓN 1.3



Elemento LOINC

Estudios de Banco de Sangre 18717-9

Estudios de Células 18718-7

Estudios Químicos 18719-5

Estudios de Coagulación 18720-3

Estudios de Monitoreo de Drogas Terapeuticas 18721-1

Estudios de Fertilidad 18722-9

Estudios Hematológicos 18723-7

Estudios HLA 18724-5

Estudios de Microbiología 18725-2

Estudios de Serología 18727-8

Estudios Toxicológicos 18728-6

Estudios de Uroanálisis 18729-4

Análisis de Gases Sanguíneos 18767-4

Recuento de Células + Estudios Diferenciales 18768-2

Pruebas de susceptibilidad Microbial 18769-0

Estudios de Patologías Moleculares 26435-8

Estudios de Laboratorio 26436-6

Estudios Químicos Específicos 26437-4

Estudios Citológicos 26438-2

Tabla 15-3 Especialidades con código LOINC

Cabe destacar que tanto Analito, como Unidad de Medida, Método y Tipo de Muestra son

datos que se reflejan en el código LOINC que representa el análisis que se está

detallando.

La estructura general de cuerpo se muestra a continuación:





VERSIÓN 1.3



La estructura de cada una de las secciones requeridas por el CDA se describe a

continuación





VERSIÓN 1.3



15.3 Descripción de las secciones

15.3.1 Identidad de Género

Template ID 2.16.840.1.113883.2.22.0.100.110.5

Descripción General

Esta sección describe la identidad de Género del paciente. Se

entiende por identidad de género el sexo que el paciente siente lo representa mejor

Código Loinc Requerido Descripción

29762-2 O Estilo de Vida, vida ocupacional, factores de riesgo,

data administrativa, religiosa, definición sexual, etc.

Entrada Requerido Descripción

Identidad de Género O Determinación de la Identidad de Género del

Paciente.

Esta sección debe contener información en texto narrativo que indique la identidad de

género que declara el paciente posee.

Hábitos del paciente: Tabaquismo Alcoholismo Drogas Deportes Extremos

Antecedentes Sociales del paciente: …

Adicional a lo anterior esta sección puede contener información en entradas codificadas

Entradas Codificadas

Esta sección puede contar con dos entradas codificadas las cuales se registrarán si el

médico considera oportuno el hacer indicación de estos datos, o si el paciente considera

apropiado notificar dichos datos.





VERSIÓN 1.3



Identidad de Género del Paciente

Esta entrada debe ser desarrollada sin repetición dado que tiene cardinalidad

0..1.

Una entrada puede ser desarrollada según la siguiente clasificación de declaración

de acto que se desea notificar:

o Acto: Declaración de una entrada sin una clasificación específica y con

definición más ambigua.

o Encuentro: Declaración de una entrada que indica las codificaciones

correspondientes a un acto de encuentro médico.

o Procedimiento: Declaración de una entrada que indica procedimientos

específicos hechos al paciente.

o Observación: Declaración de una entrada que indica entradas respecto a

una observación clínica realizada sobre el paciente.

o Administración de substancia: Declaración de una entrada que indica

elementos relacionados sobre la administración de sustancias y

medicamentos a un paciente.

o Suministro: Declaración de una entrada que indica insumos entregados a

un paciente durante el desarrollo del encuentro médico.

o Organización: Declaración de una entrada que determina factores de

procesos desarrollados durante la actividad clínica que vivió el paciente.

La declaración de esta entrada debe ser en base a un acto indicado como

observation, debido a está relacionada con una declaración personal del paciente

y no representa una actividad clínica de por sí.

El acto debe ser indicado por medio de classCode el cual siempre deberá

contener un valor OBS por ser la declaración de un acto como tal.

La declaración de actos clínicos en una entrada debe ir siempre acompañada por

la definición de un moodCode. Este, indica la temporalidad de la declaración

hecha.





VERSIÓN 1.3



Dado que el registro del sexo ya fue realizado, para este documento moodCode

siempre debe contener el valor EVN, indicando que este es un evento ya

ocurrido.

La entrada deberá contener un código en el tag code que contendrá lo siguiente

elementos:

o Debe contener un @code el cual debe indicar el valor codificado del sexo

registral que se desea indicar para el paciente.

o Debe contener un @displayName cuyo valor deberá indicar la glosa del

código seleccionado según Tabla Maestra.

o Debe contar con un codeSystem en donde se indica el identificador OID

para el sistema de codificación usado.

▪ El Sistema de codificación deberá ser el especificado en la Tabla

Maestra de Identidad de Género cuyo OID corresponde a

2.16.840.1.113883.2.22.100.90.6.

o Puede indicar el nombre del sistema de codificación en el elemento

codeSystemName, cuyo valor sería “Tabla Maestra de Identidad de

Género”.

La entrada para Sexo Registral queda como se muestra a continuación:

15.3.2 Análisis de un Test Simple Resultado Único

Template ID 2.16.840.1.113883.2.22.0.100.110.28


Esta sección describe los resultados correspondientes a un estudio

de analito simple con resultado único. Esta descripción contendrá los elementos necesarios para identificar adecuadamente al analito, el método, los valores de referencia (simples o múltiples), las interpretaciones y los valores de resultado.





VERSIÓN 1.3




Según Especialidad. R2 Observación del resultado de una prueba simple.


Resultados Examen O

Entrada codificada del resultado del examen, su

valor, interpretación y relación con exámenes anteriores

Subsección Requerido Descripción

Tipo de Analito y examen R Descripción del analito y el tipo de procedimiento

realizado

Esta sección debe indicar el conjunto de datos correspondientes al resultado de una

observación simple con resultado único según los datos mencionados anteriormente.

Texto Narrativo describiendo Nombre del Analito U. de Medida Valor Metodo Tipo de Muestra Rango/Rangos de Referencia Interpretacion Estado Analito Observaciones

Para la sección:

@code debe contener el valor del código LOINC que represente la Especialidad a

la cual el análisis pertenece según tabla indicada con anterioridad.

Debe considerar un @displayName que indique una descripción similar a la

especificada por LOINC.

Debe identificar el OID de LOINC que es 2.16.840.1.113883.6.1 en el valor de

@codeSystem.

Puede declarar el nombre del sistema de codificación en el valor de

@codeSystemName.





VERSIÓN 1.3



La declaración del resultado del examen debe ser desarrollada en subsección Tipo de

analito y Examen que debe considerar lo siguiente:

debe ser desarrollado con el siguiente formato:

o Debe darse un valor a @code y debe ser el código correspondiente al

analito desarrollado en el formato de análisis determinado.

o Debe darse el OID del sistema de Codificación que en este caso es LOINC

(2.16.840.1.113883.6.1), en el valor de @codeSystem .

o Se debe indicar el nombre asignado por LOINC en el valor de

@displayName.

Se debe desplegar la información del análisis en texto libre a continuación,

conteniendo la información indicada al comienzo de este apartado.

Se puede agregar una entrada codificada para esta subsección. Las entradas

tienen carácter computable por lo que la finalidad de estas es favorecer la

capacidad de computo de los documentos. Lo legible queda en la sección de texto.

Debe cumplir con las indicaciones siguientes:

Entrada Codificada de Resultado Simple

La entrada debe comenzar con la etiqueta en donde @typeCode debe

llevar el valor DRIV indicando que este resultado es la derivación de un análisis.

Se debe declarar el tipo de actividad que la entrada reportará, en este caso se

indicará un acto que es propio de laboratorios cuando notifican el resultado de un

examen. Para cumplir esto debe declarar una etiqueta que debe contener

lo siguiente:

o Debe llevar un elemento @classCode cuyo valor debe ser siempre “ACT”

y su temporalidad debe ser expresada en el valor de @moodCode como

“EVN”, es decir ya ocurrido.





VERSIÓN 1.3



La determinación del análisis con todas sus características debe ser declarada en

un código bajo lo cual debe ser abierta una etiqueta con contenido:

o Debe declarar el código LOINC del análisis en el valor de @code

o Debe declarar el OID del sistema de codificación que en este caso es LOINC

(2.16.840.1.113883.6.1), en el valor de @codeSystem.

o Puede desplegar el nombre largo de LOINC para el código expresado.

Se puede indicar el estatus del análisis por medio del elemento statusCode cuyo

valor en @code debe representar el estado del acto según siguiente codificación

de HL7 para ACT, en donde salvo excepciones el valor deberá ser el de

completed.

o New: Nuevo

o Active: Activo

o Held: Sostenido sin avance

o Completed: Completado

o Cancelled: Cancelado

o Suspended: Suspendido

o Nullified: Anulado

o Obsolete: Obsoleto

Se puede determinar el tipo de muestra por medio de la entrada

specimen/specimenRole/specimenPlayingEntity, según los siguientes

requerimientos:





VERSIÓN 1.3



o debe estar declarado y en el valor de @typeCode debe ir el

de SPC declarando que el espécimen es genérico para pruebas de

laboratorio en seres humanos.

o debe ser declarado indicando el rol que cumple el

origen de la muestra y debe especificarse la clase de este en el valor

@classCode en donde puede ser de los siguientes tipos:

Código Descripción

SPEC Espécimen, rol jugado por espécimen que es tal de facto.

ALQT Alíquota, una porción del espécimen original, usado para testeo o transporte.

ISLT Aislado, para microorganismos que han sido aislados.

Tabla 15-4 Códigos specimenRole

Se debe especificar la entidad como tal ante lo cual se debe usar el elemento

, la que deberá contener el elemento .

o Code debe definir en @code el valor del código del espécimen.

o El sistema de codificación debe ser Snomed (2.16.840.1.113883.6.96) y

su OID debe ser explicitado en el valor de @codeSystem.

o Se puede describir el nombre completo expresado en Snomed en el valor

de @displayName.

El resultado de la prueba se debe especificar en una relación a la entrada que se

debe especificar en , la cual debe tener como @typeCode

el valor COMP que implica que la relación a describir en la entrada no es

semántica sino de valor.

o Para especificar la relación se debe declarar una observación en

la cual debe definir los siguientes valores:





VERSIÓN 1.3



▪ @classCode el cual siempre contendrá el valor OBS indicando es

una observación.

▪ @moodCode el cual siempre contendrá el valor EVN indicando que

es una observación ya ocurrida.

o La observación debe ser referenciada a el análisis realizado por lo que se

declara en lo mismo que se especificó al momento de codificar el

tipo de prueba.

o Adicional se puede explicitar un en el mismo formato antes

indicado.

o Se puede indicar la fecha y hora de realización de la prueba por medio del

elemento indicando en @value esta indicación en el

mismo formato que se especificó en la fecha y hora de creación del

documento.

o Se debe expresar el valor del resultado en el elemento el cual

debe contener los siguientes elementos:

▪ Un indicador del tipo de dato el cual debe ser especificado en

@xsi:type, según HL7 V3 Data Types

▪ @value debe contener el valor medido.

▪ @unit debe especificar el tipo de unidad de medida.

o Se puede codificar la interpretación correspondiente al análisis del valor del

examen contra el rango existente para dicho examen. La cardinalidad es de

0..*. y debe ser indicada en el elemento .

▪ Debe tener @code en donde debe especificarse el código según el

Value Set de HL7 FHIR 3.0 observation interpretation.

▪ El @codeSystem debe ser el anteriormente mencionado identificado

en su OID 2.16.840.1.113883.5.83.

Se pueden declarar más relaciones indicando resultados anteriores por lo que la

cardinalidad de las es de 1..*.





VERSIÓN 1.3



o El formato de estas relaciones que contienen resultados anteriores debe

ser similar al del resultado de la prueba sin el código de interpretación

(interpretationCode) y @moodCode ahora lleva el valor “REFR”.

La entrada puede contener la descripción de los rangos válidos o de referencia

para la prueba realizada en el siguiente formato:

o Dado que una prueba puede ser multirango la cardinalidad de este

elemento será 0..*

o Se deberá declarar el elemento cuyo @typeCode

como valor debe ser REFV indicando que es un valor de referencia al

resultado.

o Se debe declarar que el rango es observado por lo que el elemento

debe especificarse así:

▪ @classCode debe ser OBS pues es una observación.

▪ @moodCode debe ser EVN.CRT pues es un hecho desarrollado.

o El rango se especifica dentro de en donde @xsi:type por lo

común será IVL_PQ, lo que implica que es un rango de cantidad física.

o y expresan el rango con @valor y @unit como fuera

explicado anteriormente.

o Estos elementos deben conjugarse para armar los diferentes rangos que

solo deben ser numéricos.

A continuación, se muestra un ejemplo de entrada codificada para esta sección.





VERSIÓN 1.3







VERSIÓN 1.3



15.3.3 Test Simple Resultados Múltiples (Panel)

Template ID 2.16.840.1.113883.2.22.0.100.110.29


Esta sección desarrolla los resultados de una prueba sobre un mismo elemento cuyo resultado puede ser múltiple según los tipos de analitos estudiado. Cada analito debe indicar su valor, método, rangos de referencia, interpretación y observaciones.


Según Especialidad. R2 Descripción de un estudio simple con múltiples

resultados.


Resultados Examen O Entrada codificada del resultado del análisis de un analito de los múltiples para el examen completo.

Subsección [1..1] Requerido Descripción

Tipo de Analitos y resultados R Descripción de los analitos y el tipo de

procedimiento realizado.

Texto Narrativo describiendo Tipo Analito Valor U. de Medida Metodo Tipo de Muestra Rango/Rangos de Referencia Interpretacion Estado Analito Resultados Previos Observaciones

Esta sección debe indicar el conjunto de datos correspondientes al resultado de una

observación simple con múltiples resultados según los datos mencionados

anteriormente. La sección debe estar construida de la siguiente manera:

@code debe contener el valor del código LOINC que represente la Especialidad a

la cual el análisis pertenece según tabla indicada con anterioridad.

Debe considerar un @displayName que indique una descripción similar a la

especificada por LOINC-





VERSIÓN 1.3



Debe identificar el OID de LOINC que es 2.16.840.1.113883.6.1 en el valor de

@codeSystem.

Puede declarar el nombre del sistema de codificación en el valor de

@codeSystemName

La declaración del resultado del examen debe ser desarrollada en una subsección

indicando el tipo de análisis y todos los resultados sobre cada analito considerado, que

debe considerar lo siguiente:

debe ser desarrollado con el siguiente formato:

o Debe darse un valor a @code y debe ser el código correspondiente al

analito desarrollado en el formato de análisis determinado.

o Debe darse el OID del sistema de Codificación que en este caso es LOINC


o Se debe indicar el nombre asignado por LOINC en el valor de

@displayName.

o Puede indicar el nombre del sistema de codificación en

@codeSystemName.

Se debe desplegar la información del análisis en texto libre a continuación,

conteniendo la información indicada al comienzo de este apartado para cada

resultado de cada analito estudiado.

Se puede agregar una entrada codificada para esta subsección. Las entradas

tienen carácter computable por lo que la finalidad de estas es favorecer la

capacidad de computo de los documentos. Lo legible queda en la sección de texto.

Deberá cumplir con las indicaciones siguientes:





VERSIÓN 1.3



Entrada Codificada de Resultados Múltiples

Para resultados múltiples se deben declarar tantas entradas codificadas como

resultados de analitos existan desarrollados.

Se recomienda que el orden de las entradas identificando a cada analito, sea el

mismo que el declarado en el texto libre.

Para cada entrada individual:

La entrada debe comenzar con la etiqueta en donde @typeCode debe

llevar el valor DRIV indicando que este resultado es la derivación de un análisis.

Se debe declarar el tipo de actividad que la entrada reportará en este caso se

indicará un acto que es propio de laboratorios cuando notifican el resultado de un

examen. Para cumplir esto se debe declarar una etiqueta que debe

contener lo siguiente:

o Debe llevar un elemento @classCode cuyo valor deberá ser siempre

“ACT” y su temporalidad deberá ser expresada en el valor de

@moodCode como “EVN”, es decir ya ocurrido.

La determinación del análisis con todas sus características debe ser declarada en

un código bajo lo cual debe ser abierta una etiqueta con contenido:

o Debe declarar el código LOINC del análisis en el valor de @code.

o Debe declarar el OID del sistema de codificación que en este caso es LOINC


o Puede desplegar el nombre largo de LOINC para el código expresado.

Se puede indicar el estatus del análisis por medio del elemento statusCode cuyo

valor en @code debe representar el estado del acto según siguiente codificación

de HL7 para ACT, en donde salvo excepciones el valor deberá ser el de

completed.

o New: Nuevo

o Active: Activo

o Held: Sostenido sin avance





VERSIÓN 1.3



o Completed: Completado

o Cancelled: Cancelado

o Suspended: Suspendido

o Nullified: Anulado

o Obsolete: Obsoleto

Se puede determinar el tipo de muestra por medio de la entrada

specimen/specimenRole/specimenPlayingEntity, según los siguientes

requerimientos:

o debe estar declarado y en el valor de @typeCode debe ir el

de SPC declarando que el espécimen es genérico para pruebas de

laboratorio en seres humanos.

o debe ser declarado indicando el rol que cumple el

origen de la muestra y debe especificarse la clase de este en el valor

@classCode en donde puede ser de los siguientes tipos:

Código Descripción

SPEC Espécimen, rol jugado por espécimen que es tal de facto.

ALQT Alíquota, una porción del espécimen original, usado para testeo o transporte.

ISLT Aislado, para microorganismos que han sido aislados.

Tabla 15-5 Códigos specimenRole

Se debe especificar la entidad como tal ante lo cual se debe usar el elemento

, la que deberá contener el elemento .

o Code deberá definir en @code el valor del código del espécimen.

o El sistema de codificación deberá ser Snomed (2.16.840.1.113883.6.96)

y su OID debe ser explicitado en el valor de @codeSystem.





VERSIÓN 1.3



o Se podrá describir el nombre completo expresado en Snomed en el valor de

@displayName.

El resultado de la prueba se debe especificar en una relación a la entrada que se

debe especificar en , la cual debe tener como @typeCode

el valor COMP que implica que la relación a describir en la entrada no es

semántica sino de valor.

o Para especificar la relación se debe declarar una observación en

la cual debe definir los siguientes valores:

▪ @classCode el cual siempre contendrá el valor OBS indicando que

es una observación.

▪ @moodCode el cual siempre contendrá el valor EVN indicando que

es una observación ya ocurrida.

o La observación debe ser referenciada a el análisis realizado por lo que se

declara en lo mismo que se especificó al momento de codificar el

tipo de prueba.

o Adicional se puede explicitar un en el mismo formato antes

indicado.

o Se puede indicar la fecha y hora de realización de la prueba por medio del

elemento indicando en @value esta indicación en el

mismo formato que se especificó en la fecha y hora de creación del

documento.

o Se debe expresar el valor del resultado en el elemento el cual

debe contener los siguientes elementos:

▪ Un indicador del tipo de dato el cual debe ser especificado en

@xsi:type, según la definición de HL7 V3 Data Types





VERSIÓN 1.3



▪ @value debe contener el valor medido.

▪ @unit debe especificar el tipo de unidad de medida.

guia de implementacion de cda -...

Documents