Curso HL7 CDA - Salud.uy

1. Curso introductorio a CDA
Tema 3
Cabecera

2. Contenido
• Introducción a la cabecera CDA
• Clase ClinicalDocument
• Actos relacionados con el documento
• Participantes en el documento
12/09/2016 Tema 3. Cabecera 2

3. • 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
12/09/2016 Tema 3. Cabecera 3
Introducción

4. 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.
12/09/2016 Tema 3. Cabecera 4

5. ¿Dónde en el modelo del CDA?
12/09/2016 Tema 3. Cabecera 5
Clinical DocumentParticipations Related Documents
Paciente

6. ClinicalDocument
12/09/2016 Tema 3. Cabecera 6
• 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

7. Clinical Document
Identificació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
12/09/2016 Tema 3. Cabecera 7
<
setId root = "2.16.840.1.113883.2.10.1.4.3"
extension = “3456734"
/>

8. Clinical Document
Identificació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)
12/09/2016 Tema 3. Cabecera 8

9. Clinical Document
Descripció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
12/09/2016 Tema 3. Cabecera 9

10. Clinical Document
Descripció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
12/09/2016 Tema 3. Cabecera 10

11. Clinical Document
Fechas 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)
12/09/2016 Tema 3. Cabecera 11

12. Clinical Document
Confidencialidad
• 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
12/09/2016 Tema 3. Cabecera 12
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)

13. 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
12/09/2016 Tema 3. Cabecera 13

14. Clinical Document
Elementos 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
12/09/2016 Tema 3. Cabecera 14

15. 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)
12/09/2016 Tema 3. Cabecera 15

16. 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
12/09/2016 Tema 3. Cabecera 16

17. Actos relacionados
12/09/2016 Tema 3. Cabecera 17
• 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

18. 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
12/09/2016 Tema 3. Cabecera 18
<relatedDocument typeCode='REPL'>
<parentDocument>
<id root='…' extension='…'/>
</parentDocument>
</relatedDocument>
Ejemplo de reemplazo

19. 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
12/09/2016 Tema 3. Cabecera 19

20. 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.)
12/09/2016 Tema 3. Cabecera 20

21. 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
12/09/2016 Tema 3. Cabecera 21

22. 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
12/09/2016 Tema 3. Cabecera 22

23. 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
12/09/2016 Tema 3. Cabecera 23

24. 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)
12/09/2016 Tema 3. Cabecera 24

25. 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
12/09/2016 Tema 3. Cabecera 25

26. 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
12/09/2016 Tema 3. Cabecera 26

27. Autor: ejemplo
12/09/2016 Tema 3. Cabecera 27
<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>

28. 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.)
12/09/2016 Tema 3. Cabecera 28

29. 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
12/09/2016 Tema 3. Cabecera 29

30. 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
12/09/2016 Tema 3. Cabecera 30

31. 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
12/09/2016 Tema 3. Cabecera 31

32. 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
12/09/2016 Tema 3. Cabecera 32

33. 12/09/2016 Tema 3. Cabecera 33
Material desarrollado por:
• José Alberto Maldonado Segura (HL7 CDA especialista certificado)
• David Moner Cano (HL7 CDA especialista certificado)
http://www.veratech.es