Cda 03-cabecera

Curso introductorio a CDA

Tema 3Cabecera

03/05/2023 Tema 3. Cabecera 2

Contenido

• Introducción a la cabecera CDA• Clase ClinicalDocument• Actos relacionados con el documento• Participantes en el documento


• La cabecera (header) es la primera parte de cualquier documento CDA

• Todos los documentos CDA tiene una cabecera• Contiene el contexto del contenido del documento

clínico• Identifica el documento y describe su tipo• Contiene los datos demográficos del paciente

sujeto del documento, los participantes (autor, informante, etc.), los actos relacionados con el documento así como su autentificación

Introducción


Introducción

• La cabecera está formada por tres tipos de elementos– Los atributos de la clase ClinicalDocument que

provienen del RIM– Los actos relacionados con la clase

ClinicalDocument (aquí se incluyen otros documentos, un documento es un acto en CDA)

– Los participantes asociados a la clase ClinicalDocument como el propio paciente, personal sanitario, etc.


¿Dónde en el modelo del CDA?

Clinical DocumentParticipations Related Documents

Paciente


ClinicalDocument

• Los atributos provenientes del RIM se muestran en la figura

• Estos atributos de la clase ClinicalDocument identifican el documento, describen el contenido, indican fechas y horas relevantes y define el nivel de confidencialidad


Clinical DocumentIdentificación del documento

• Los atributos id, setId y versionNumber se utilizan para identificar a los documentos

• El atributo id (tipo de datos II) representa el identificador único del documento. Dos documentos con el mismo valor de id deben ser idénticos en contenido<setId root = "2.16.840.1.113883.2.10.1.4.3"extension = “3456734"/>


Clinical DocumentIdentificación del documento

• Los documentos puede versionarse. El atributo setId sirve para identificar una serie de versiones de un documento

• Todas las versiones tienen el mismo setId (pero distinto Id)

• Se complementa con el atributo versionNumber, el cual contiene el número de versión

• Si se genera una nueva versión de un documento D, entonces la nueva versión tiene el mismo setId que D pero distinto número de versión (por ejemplo incrementado en 1)


Clinical DocumentDescripción del documento

• Los atributos code y title sirven para describir el documento

• code (tipo CE) especifica el tipo particular de documento clínico utilizando un sistema de codificación. HL7 recomienda el uso de códigos LOINC aunque no es obligatorio


Clinical DocumentDescripción del documento

• Title (tipo ST) es una descripción textual del tipo de documento (por ejemplo: historia clínica resumida, consulta de emergencia extra hospitalaria, etc.)

• Si el titulo está presente (no es obligatorio) debe incluirse en la representación orientada a los humanos del documento


Clinical DocumentFechas y horas

• El atributo effectiveTime (tipo TS) contiene la fecha y hora de creación del documento. Si el documento es una versión posterior de otro, debemos registrar en este documento la fecha de creación del documento original (la primera versión)


Clinical DocumentConfidencialidad

• El atributo confidentialityCode (tipo CE) especifica el nivel de confidencialidad del documento.

• HL7 sugiere tres códigos para este atributo. El nivel de confidencialidad se propaga al resto de documento, salvo que en alguna sección se defina otro nivel

Code codeSystem displayName

N 2.16.840.1.113883.5.25 Normal (sólo personas autorizadas)R 2.16.840.1.113883.5.25 Restringido (sólo prestadores de salud

autorizados)V 2.16.840.1.113883.5.25 Muy Restringido (sólo con permiso especial)


Clinical Document Idioma

• El atributo language (tipo CS) especifica el idioma en que fue escrito el documento

• Se sigue la norma RFC-3066 que utiliza a su vez la norma ISO-639 de código de idiomas e ISO-3166 de códigos de países

• Ejemplo: español de Uruguay: es-UY


Clinical DocumentElementos de infraestructura

• Estos elementos son parte de la infraestructura XML utilizada en CDA. No aparecen en la clase ClinicalDocument

• Son comunes a todas la representaciones XML en HL7 version 3, no únicamente en CDA

• De hecho estos elementos XML pueden aparecen en cualquier especialización de una clase del RIM que aparezca en CDA

• Los dos más importantes son typeId y templateId


Clinical Document typeId

• Es de tipo II y representa el tipo de artefacto HL7

• En ClinicalDocument es un valor fijo, por tanto es el mismo en cualquier documento CDA válido:– root = "2.16.840.1.113883.1.3" (es el OID que

referencia a los modelos de HL7 registrados).– extension = "POCD_HD000040" (es el identificador

único de la Descripción Jerárquica de CDA Release 2)


Clinical Document templateId

• Es de tipo II, identifica la plantilla de validación que se debe aplicar a este documento

• Las plantillas generalmente se definen en guías de implementación. Contienen una serie de restricciones adicionales que un documento CDA debe satisfacer

• Las plantillas se pueden aplicar a nivel de documento, sección y entrada codificada


Actos relacionados

• Existen diversos actos relacionados con el documento CDA que se describen en la cabecera. Básicamente aportan contexto al contenido del documento

• Incluye información sobre documentos anteriores relacionados, el servicio prestando que dio lugar al documento, el encuentro entre el paciente y el profesional sanitario, las peticiones relacionadas y los consentimientos del paciente


RelatedDocument

• Los documentos CDA pueden ser reemplazados, ampliados o transformados

• CDA nos permite expresar la relación del documento con versiones previas

• El atributo typeCode de RelatedDocument contiene el tipo de relación (reemplazo, ampliación o transformación)

• Existen limites en cuanto al número y tipos de relaciones que puede tener un documento

<relatedDocument typeCode='REPL'> <parentDocument> <id root='…' extension='…'/> </parentDocument></relatedDocument>

Ejemplo de reemplazo


documentationOf

• Nos permite representar los servicios clínicos recibidos por el paciente (clase ServiceEvent) que el CDA documenta e identificar los ejecutores del acto (performer + AssignedEntity)

• Como puede observarse el classCode de ServiceEvent puede ser cualquier tipo de acto (encuentro, procedimiento, observación, etc.)

• Cada ServiceEvent puede estar ejecutado por una o varias personas con un rol determinado (atributo functionCode de performer). El atributo typeCode nos permite distinguir entre el ejecutor principal y los ejecutores secundarios


inFulfillmentOf

• Un documento CDA puede ser el resultado de una petición. Por ejemplo, puede contener el resultado de una petición de prueba de imagen médica

• La relación InfulfillmentOf permite relacionar el documento con la o las peticiones clínicas que dieron como resultado la creación del documento

• El atributo code de la clase Order indica el tipo de petición (procedimiento de imagen, prueba de laboratorio, tipo de encuentro, etc.)

• El atributo priorityCode indica la prioridad de la petición (rutinario, urgente, etc.)


authoritation

• Un documento CDA puede documentar un acto clínico. En algunos casos es necesario disponer un consentimiento informado del paciente antes de realizarlo

• La clase Consent nos permite documentar que disponemos del consentimiento y detallar su tipo


componentOf

• Los servicios clínicos recibidos por el paciente generalmente se proporcionan dentro de un encuentro. La relación componentOf nos permite documentar este encuentro

• Como puede observarse en el diagrama solo se puede incluir un encuentro al cual podemos asociar su responsable principal, participantes y ubicación


Participantes y roles

• Además de actos relacionados, el contexto del documento puede incluir distintos tipos de participantes que juegan distintos roles a la hora de crear el documento

• Estos participantes pueden ser personas, organizaciones e incluso dispositivos médicos o software

• A continuación veremos los más importantes


Paciente

• El paciente es la persona más importante asociada al documento clínico• La clase PatientRole representa la persona con el rol de paciente• Como puede observarse en el diagrama, todo documento CDA requiere

al menos un paciente (podría haber varios por ejemplo en caso de terapia grupal)


Paciente

• Está representado como una relación entre una persona (como paciente) y una organización (como prestadora de atención sanitaria)

• Se define en el encabezado y se propaga a todo el documento sin posibilidad de ser modificado

• La clase Patient contiene diversos atributos demográficos del paciente

• Los atributos addr y telecom de patientRole representan la dirección y número de teléfono (o cualquier otra tipo de número o dirección de telecomunicaciones) usada por la persona en su rol de paciente


Autor

• El autor de un documento CDA puede ser tanto una persona como un dispositivo

• Debe haber al menos un autor en un documento CDA, como se puede observar en el diagrama

• Los autores crean la información contenida en el documento de acuerdo a su conocimiento

• Se propaga a todas las secciones a menos que expresamente se cambie


Autor: ejemplo<author> <time value="20162805153000"/> <assignedAuthor> <id root="2.45.840.1.144533.2.11.1.3" extension=“123456"/> <telecom value="tel:9085555"></telecom> <assignedPerson> <name> <prefix>Dra.</prefix> <given>Laura</given> <given qualifier="IN">M.R.</given> <family>García</family> </name> </assignedPerson> <representedOrganization> <id root="2.45.840.1.14453.2.12.1"/> <name>Hospital Pereira Rossell</name> </representedOrganization> </assignedAuthor></author>


Registrador de la información

• El registrador de la información (dataEnterer) es la persona que registro la información en el documento clínico. Nótese que el registrador no crea la información únicamente la transcribe a partir de un origen (un documento en papel, una transcripción de audio, un sistema informático, etc.)


Proveedores de información (informantes)

• Un informante es una persona que provee información relevante sobre el paciente. Puede ser el propio paciente, un familiar o cualquier persona que ha sido testigo de los hechos que le han ocurrido al paciente

• El objetivo es registrar la identidad de la persona que proporcionó la información

• Se utiliza la clase AsignedEntity cuando el informante es un profesional sanitario de la organización que proporciona la atención sanitaria

• RelatedEntity se utiliza cuando el informante tiene alguna relación formal o informal con el paciente


Destinatarios

• Al igual que hay orígenes de la información (autores) hay destinatarios de ésta

• CDA permite detallar varios destinatarios que pueden ser tanto una persona como una organización


autentificador• Existen dos tipos de firmantes de un documento CDA: autentificador legal

(legalAuthenticator) y autentificador (authenticator)• El primero además de firmar tiene la responsabilidad legal del contenido del documento• El segundo atestigua por medio de su firma que la información contenida en el

documento es correcta• En CDA únicamente las personas pueden firmar un documento aunque lo pueden hacer

en representación de una organización• Como puede observarse en el diagrama como máximo puede haber un autentificador

legal pero múltiples autentificadores


Otros participantes

• CDA proporciona un mecanismo para registrar cualquier otro participante que no se puede representar por medio de las estructuras descritas anteriormente

• El atributo functionCode permite describir el rol que jugó el participante


Material desarrollado por:

• José Alberto Maldonado Segura (HL7 CDA especialista certificado)• David Moner Cano (HL7 CDA especialista certificado)

http://www.veratech.es

http://www.veratech.es/

Technology

Cda 03-cabecera