Glosario compartido por todos los cursos del c@mpus virtual.


All Categories

Page:  1  2  3  (Next)
  ALL

E-HEALTH

:
HIPAA
Health Insurance Portability and Accountability Act (USA)
http://www.hhs.gov/ocr/privacy/hipaa/understanding

HL7

:
Representa algo que ha sucedido, está sucediendo, o puede suceder en el futuro, gracias a la combinación de de varias entidades. Es una de las seis clases que configura el núcleo del HL7 RIM.

Eng.- Act
Ver: HL7 RIM, Entidad, Rol, Participante.
:
Es un evento donde participan con un rol determinado una serie de entidades (agentes habilitados). Está enlazada con otras actuaciones y puede formar un conjunto relacionado de actuaciones, en función de:
  1. Su propósito.
  2. Los Puntos de Actuación donde se realizan.
  3. Una serie temporal acotada que definirá los sucesivos estados de la Actuación: aceptación de la solicitud, ciclo de tramitación y autorización del expediente; diseño del presupuesto, reserva de recursos, contrataciones y control de ejecución.
  4. Los Ítems transaccionales manipulados en cada Actuación.

Ver: Actuación, Entidad, Rol, Participante.

:
Representa un objeto de dominio (real o virtual) que forma parte de una organización. Es una de las seis clases que configura el núcleo del HL7 RIM.

Eng.- Entity
Ver: HL7 RIM, Actuación, Rol y Participante.
:
HL7 CDA (HL7 Clinical Document Architecture): Estándar de HL7 que define la estructura y el modelo de información para el intercambio de documentos clínicos. CDA es el núcleo de la historia clínica electrónica global de un Paciente.

Establece la composición de cualquier documento clínico, como el Informe de Alta Hospitalaria, el Informe de Resultados de una analítica o de una imagen diagnóstica, o bien, un Resumen de Situación Clínica.

La estructura XML de un documento CDA, define una cabecera y un cuerpo con unas secciones que facilitan la visualización de su contenido a través de cualquier navegador con una personalización del formato para los usuarios.

También define unas entradas en XML, no visibles para el usuario, que facilitan el procesamiento de su contenido y recuperación a través de queries muy precisas.

:
HL7 Common Terminology Services (CTS): Es un estándar que define una interfaz de programación de aplicación (API) que puede ser usada por cualquier software cuando necesita acceder a un contenido de terminología.

Esta restringido a los servicios que requiere el diseño, la implementación y el despliegue de HL7 V3. No especifica como tienen que ser implementados su repertorio de servicios. Su propósito principal es definir una interfaz normalizada para usar y administrar terminologías.

:
HL7 EHR-S FM (Electronic Health Record Functional Model): Este estándar facilita un modelo funcional para los sistemas de historia clínica electrónica orientados a la continuidad asistencial. Su propósito es optimizar la calidad, seguridad y eficiencia de la atención al Paciente.

Su nivel de especificación permite a los desarrolladores centrar su oferta de historia clínica en un conjunto de requisitos funcionales de relevancia clave para los usuarios clínicos. HL7 anima a todos los agentes del sector a participaren el desarrollo de perfiles que aporten soluciones a dominios específicos. Actualmente están disponibles perfiles sobre Emergencias, Pediatría, Atención Primaria, etc.

:
Fast Healthcare Interoperability Resources (FHIR, pronunciado "Fire") define un conjunto de "Recursos" que representan conceptos clínicos con un determinado nivel de granularidad. Los recursos se pueden gestionar de manera independiente, o bien de manera agregada en documentos complejos.

Esta flexibilidad ofrece soluciones coherentes para una serie de problemas de interoperabilidad. Las definiciones básicas de los recursos se han construido a través de una rigurosa captura de requisitos, análisis formal de escenarios y un amplio mapeo con estándares relevantes.

Una capa de gestión de flujos de trabajo proporciona la ayuda para el diseño, la adquisición y la integración de soluciones. FHIR está diseñado para el entorno web; los recursos están estructurados en un XML simple, con un protocolo basado en HTTP REST donde cada recurso tiene el URL predecible. Siempre que sea posible, se utilizan estándares de Internet abiertos para la representación de datos.

http://hl7.org/implement/standards/fhir/ (portal de referencia de FHIR)
http://wiki.hl7.org/index.php?title=FHIR
http://wiki.hl7.org/index.php?title=Resource
http://en.wikipedia.org/wiki/Representational_state_transfer
http://www.healthintersections.com.au/?p=1699 (discusión sobre FHIR como vehículo de CDA R3)

Ver: REST


:
Health Level 7 International es una “Organización de Desarrollo de Estándares” (SDOs), para el ámbito de la salud. Fundada en 1987 sin fines de lucro está acreditada por ANSI desde 1994.

Opera a nivel internacional y su misión es proveer estándares globales para los dominios: clínico, asistencial, administrativo y logístico, con el fin de lograr una interoperabilidad real entre los distintos sistemas de información en el área de la salud.
:
HL7 PHR-S FM (Personal Health Record Functional Model): Es el primer estándar de la industria que especifica la funcionalidad de un sistema de historia clínica de uso personal para el Paciente. Define las reglas para intercambiar información de salud entre diferentes sistemas PHR y entre PHR y sistemas de historia clínica electrónica.

Actualmente hay varios perfiles en desarrollo orientados a resolver temas de comunicación entre las administraciones de salud, proveedores asistenciales y usuarios consumidores de servicios de salud. También con las entidades aseguradoras y sus afiliados.

:
HL7 RIM (Reference Information Model): Representa como una “Tabla Periódica de Elementos” para construir cualquier artefacto de interoperabilidad basado en mensajería V3, en documentos clínicos CDA y en modelos de dominio de información clínica. HL7 RIM es un modelo estático construido con la notación Unified Modeling Language (UML) del Object Management Group (OMG).

A través de una escala de abstracción variable y unos mecanismos de restricción, facilita la definición de los objetos que participan en un escenario de interoperabilidad con un modelo de información específico para cada dominio concreto.

http://vico.org/HL7_RIM/index.html
:
Services-Aware Interoperability Framework (SAIF) es una especificación desarrollada por HL7. Su propósito es alinear SOA con su repertorio de estándares: mensajes, documentos clínicos y servicios. En el futuro, todos los modelos funcionales de servicios HL7 estarán definidos siguiendo el esquema SAIF.

Ver: HL7 SOA
:
HL7 Service-Oriented Architecture (Guía práctica de SOA para sistemas de salud): HL7 en colaboración con el Object Management Group (OMG), ha desarrollado una guía práctica para la utilización de SOA en sistemas de salud en el marco del Healthcare Services Specification Project (HSSP).

Ver: HL7 SAIF

:
HL7 SPAIN es una asociación profesional sin fines de lucro que representa a HL7 en España desde2004. Su misión es difundir el conocimiento delos estándares HL7 y apoyar su implementación en los sistemas de información de salud que operan en España. Con más de 70 afiliados, entre los que están las principales empresas del sector y la gran mayoría de las administraciones de salud de las comunidades autónomas.

:
HL7 V2 es el estándar internacional de mensajería para el intercambio electrónico de datos en los ámbitos clínico, asistencial, económico y logístico, más ampliamente utilizado en el mundo de la salud.

La última versión incorpora esquemas basados en XML y un progresivo alineamiento con la metodología de desarrollo de la versión HL7 V3.

:
HL7 V2 (XML) es una especificación orientada a que los mensajes V2 sean procesados por internet a través de un esquema XML en lugar de los clásicos caracteres de barras verticales. También incrementa los niveles de validación para reducir errores en la construcción y en el envío/recepción del mensaje.

:
HL7 V3 (Metodología basada en modelos de referencia): Es más que otro tipo de mensajería, es un nueva manera de abordar la interoperabilidad clínica con el apoyo de modelos de información de referencia y una metodología de desarrollo.

A partir de un escenario concreto (Evento, Aplicación Emisora y Receptora, etc.), construimos un artefacto de interoperabilidad (mensaje / documento / servicio), en base a un modelo restringido que procede, con sucesivas especializaciones, de un único núcleo, el RIM (Reference Information Model).

Este modelo común, da consistencia a todas las posibles extensiones que requieren los distintos dominios de implantación y abre la vía para llegar a una interoperabilidad semántica.

:
Nivel de involucración de una entidad que interviene en una actuación jugando un rol que le habilita para actuar y determina sus responsabilidades como participante. Es una de las seis clases que configura el núcleo del HL7 RIM.

Eng.- Participation
Ver: HL7 RIM, Entidad, Actuación, Rol.
:
Ubicación (real o virtual) que forma parte de una organización donde Agentes habilitados (Entidades), pueden actuar gracias a una serie de recursos dispuestos a tal fin. Pueden determinarse restricciones sobre el tipo de actuaciones y roles para cada tipo de punto de actuación.

Eng.- Place
Ver: HL7 RIM, Actuación.
:
1.- Categoría que habilita (scopes) a una entidad para poder participar en una actuación.
2.- Responsabilidad que juega (play) una entidad cuando participa en una actuación
Es una de las seis clases que configura el núcleo del HL7 RIM.

Eng.- Role
Ver: HL7 RIM, Entidad, Participante, Actuación.

INTEROPERABILIDAD

:
Un arquetipo es una definición formal de una estructura de información basada en un modelo de referencia que sirve para documentar cualquier aspecto relacionado con la salud de las personas.

La definición de un arquetipo se fundamenta en definir restricciones sobre las propiedades y clases del modelo de referencia. Su semántica vendrá dada por la anotación del arquetipo con códigos terminológicos.

http://www.itaca.upv.es/view.php

Eng.- Archetype

:
Es el uso compartido y controlado de información entre dos (o más) sistemas, aplicaciones o servicios (Entidades). La integración significa que una entidad puede extraer u obtener información de la otra, pero no implica que el receptor pueda hacer uso de esta información.
:
La Interoperabilidad va más allá de la integración en el sentido de que los sistemas, aplicaciones o servicios que intercambian información pueden llegar a compartir el significado de lo que reciben. La interoperabilidad puede implicar la identificación de componentes y las relaciones correspondientes en cada sistema, transformándolos sintácticamente a un mismo formato, estructuralmente a una misma granularidad, y semánticamente a un mismo significado que a partir de ese momento compartirán.

:
Es como un tipo de estructura de datos, parecido a una cadena (string), una serie de bytes (array), un registro o un objeto. Puede ser interpretado como un conjunto de datos, como la descripción de un comando que debe ser invocado por el receptor, o como la descripción de un evento que ha ocurrido en el emisor.

Un mensaje genérico contiene dos partes, una cabecera y un cuerpo. La cabecera contiene meta-datos acerca del mensaje, quien lo ha enviado, a donde se dirige, etc.; esta información es usada por el esquema de mensajería y es prácticamente ignorada por las aplicaciones que utilizan el artefacto “mensaje”.

El cuerpo contiene los datos a transmitir y que las aplicaciones tienen como objetivo intercambiar. Normalmente es ignorado por el esquema de mensajería. En términos generales, cuando un integrador se refiere a un mensaje , está indicando a la serie de datos que contiene el cuerpo de dicho mensaje.

La arquitectura de mensajería asíncrona es muy potente para resolver las necesidades de integración en la ingente diversidad de escenarios de interoperabilidad. Pero si acotamos dichos escenarios a un ámbito determinado, como los sistemas de salud, podemos llegar a reducir mucho esta dispersión, clasificarla en dominios, llegar a normalizar todos los eventos que se producen en cada dominio, e identificar qué Actores son los involucrados para compartir la información generada por cada evento en un dominio concreto.

Este trabajo de especificación es el que realizan organizaciones desarrolladoras de estándares como HL7 INTERNATIONAL, con sus plataformas de mensajería V2 y V3, y organizaciones evaluadoras de estándares como IHE (Integrating Healthcare Enterprise), con su framework de interoperabilidad y perfiles de integración para los dominios de Imagen Diagnóstica y Laboratorio entre muchos otros.

Eng.- Message

:
Tecnología que facilita una comunicación asíncrona de alta velocidad entre dos aplicaciones con un intercambio electrónico de datos fiable. Las aplicaciones se comunican enviando paquetes de datos que denominamos “Mensajes”.

Las vías por las que circulan los mensajes se llaman “Canales”. También denominadas “Colas”, son caminos virtuales que utilizan las aplicaciones para la transmisión de mensajes.

Un canal se comporta como una colección de cadenas de mensajes que es compartido por múltiples sistemas y puede ser usado de manera concurrente por distintas aplicaciones.

El programa “Emisor”, es la aplicación que envía el mensaje registrando dicho mensaje en un canal. El programa “Receptor”, es la aplicación que recibe el mensaje leyendo (y borrando), el canal de transmisión.

Eng.- Messaging


Page:  1  2  3  (Next)
  ALL