Servicio de Terminología (TS) de OpenHIE

El componente de Servicios de Terminología (Terminology Services, TS) de la Arquitectura de OpenHIE proporciona una fuente centralizada para los estándares y definiciones del HIE, lo que incluye terminologías, ontologías, diccionarios, sistemas de códigos y conjuntos de valores. Otros componentes del HIE pueden utilizar estos estándares y definiciones para normalizar los datos clínicos y lograr una agregación y una presentación de informes coherentes.

Al utilizar los servicios de terminología, un HIE puede lograr la interoperabilidad semántica de sus datos. La interoperabilidad semántica (o interoperabilidad de significado) permite una información y agregación de datos clínicos precisa y coherente. También permite el intercambio preciso de información entre miembros de la comunidad de proveedores,

incluidos laboratorios, clínicas, farmacias, hospitales y centros de diagnóstico por imagen, lo que permite mejorar las decisiones de atención al paciente.

Los beneficios del uso de un Servicio de Terminología incluyen:

• Datos estándar: el uso de una terminología común es vital para compartir conocimientos en varias ubicaciones. Los sistemas de códigos nacionales e internacionales y los conjuntos de valores deben estar fácilmente disponibles para su validación, comparación y agregación con los datos locales.

• Mejora de la atención: una recogida de datos precisa y coherente mejora el análisis de la atención al paciente. La comparación de los datos de los pacientes dentro de una misma población y entre distintas poblaciones conduce a una prestación de cuidados más coherente.

• Mejores informes: las representaciones estandarizadas de los elementos de datos generan informes coherentes y precisos.

• Atención coordinada: el análisis coherente y comparable de los datos de utilización de la asistencia médica conduce a decisiones más informadas sobre la asignación de recursos.

Consulte también “Requisitos no funcionales”.

Requisitos del flujo de trabajo de TS de OpenHIE

Un Servicio de Terminología expone un conjunto de funciones en tiempo de ejecución (servicios) que dan soporte a otros componentes de OHIE. Estas funciones del Servicio de Terminología suelen ser acciones que se encuentran en los flujos de trabajo primarios de OHIE (consulte el siguiente ejemplo). Se han identificado cuatro funciones primarias. Dependiendo de los flujos de trabajo específicos que se requieran en una implementación, es posible que no se necesiten todas estas funciones, pero un Servicio de Terminología que cumpla con OHIE debe soportar todas estas características.

Para ser un componente de TS de OHIE, la aplicación de TS debe ser capaz de soportar los flujos de trabajo de OHIE que se enumeran a continuación. Las implementaciones pueden admitir solo los flujos de trabajo necesarios para apoyar su caso de uso. Todas las funciones requeridas a continuación deben implementarse utilizando las especificaciones asociadas del Servicio de Terminología HL7 FHIR, p. ej., Recursos y Operaciones. Estos flujos de trabajo también se ajustan al Suplemento del Marco Técnico de la Infraestructura IHE: especificación para compartir conjuntos de valores, códigos y mapas (Sharing Value Sets, Codes, and Maps, SVCM).

N.º	Flujos de trabajo de TS (descritos en detalle en la parte posterior de este documento)	Recomendación o requisito
TSWF-1	Verificar la existencia del código	Requisito
TSWF-2	Verificar la pertenencia del código	Requisito
TSWF-3	Ampliar el conjunto de valores	Requisito
TSWF-4	Consultar el mapa conceptual	Requisito
TSWF-5	Consultar el sistema de códigos	Requisito
TSWF-6	Consultar el conjunto de valores	Requisito

TSWF 7	Buscar código	Requisito
TSWF-8	Traducir código	Requisito

Requisitos funcionales de TS de OpenHIE

N.º	Requisitos funcionales de TS	Recomendación o requisito
TSF-1	El TS deberá permitir la importación de sistemas de códigos locales (p. ej., códigos de laboratorio locales) y estándar (p. ej., Logical Observation Identifiers Names and Codes [LOINC]).	Requisito
TSF-2	El TS deberá permitir la exportación de sistemas de códigos locales (p. ej., códigos de laboratorio locales) y estándar (p. ej., LOINC).	Requisito
TSF-3	El TS deberá permitir el versionado de los sistemas de códigos, es decir, almacenar y poner a disposición varias versiones de un sistema de códigos a través de los servicios de terminología.	Recomendación
TSF-4	El TS deberá soportar el versionado de conjuntos de valores para almacenar y hacer disponibles múltiples versiones de un conjunto de valores a través de los servicios de terminología.	Recomendación
TSF-5	El TS deberá permitir la importación de definiciones de conjuntos de valores. El formato de importación puede variar desde un archivo de texto que contenga una lista de códigos hasta un recurso de conjunto de valores de FHIR en formato XML o JSON.	Requisito
TSF-6	El TS deberá permitir la exportación de definiciones de conjuntos de valores. El formato de exportación puede variar desde un archivo de texto que contenga una lista de códigos hasta un recurso de conjunto de valores de FHIR en formato XML o JSON.	Requisito
	El TS deberá permitir la importación de expansiones de conjuntos de valores. El

TSF-7	formato de importación puede variar desde un archivo de texto que contenga una lista de códigos hasta un recurso de conjunto de valores de FHIR en formato XML o JSON.	Requisito
TSF-8	El TS deberá permitir la exportación de expansiones de conjuntos de valores. El formato de exportación puede variar desde un archivo de texto que contenga una lista de códigos hasta un recurso de conjunto de valores de FHIR en formato XML o JSON.	Requisito
TSF-9	Permitir la importación de relaciones entre códigos (es decir, mapas conceptuales). El formato de importación puede variar desde un archivo de texto que contenga los códigos de origen y destino hasta un recurso de Mapa Conceptual de FHIR en formato XML o JSON.	Requisito
TS -10	Permitir la exportación de relaciones entre códigos (es decir, mapas conceptuales). El formato de exportación puede variar desde un archivo de texto que contenga los códigos de origen y destino hasta un recurso de Mapa Conceptual de FHIR en formato XML o JSON.	Requisito
TSF-11	Ofrecer servicios que permitan la recuperación de un código y de información adicional sobre el código, como su definición y estado, desde un sistema de códigos particular (y la versión del sistema de códigos, si se proporciona).	Requisito
TSF-12	Ofrecer servicios que permitan la validación de un código (es decir, si el código existe) con respecto a un sistema de códigos particular (y la versión del sistema de códigos, si se proporciona).	Requisito
TSF-13	Ofrecer servicios que utilicen mapas conceptuales para recuperar un código de destino dado un código fuente dentro del mapa conceptual.	Requisito