Buscar este blog

Seguidores

Vistas a la página totales

jueves, 16 de mayo de 2019

Mobile access to Health Documents (MHD)


Resultado de imagen para IHE MHD
Perfil de acceso móvil a documentos de salud (MHD).  El perfil de IHE MHD (Mobile access to Health Documents) y  HL7 FHIR están trabajando juntos para revisar y mejorar las transacciones de documentos clinicos.
MHD define una interfaz HTTP simple para un entorno de uso compartido de documentos. El perfil MHD está destinado a cualquier sistema que prefiera la tecnología HTTP RESTful simplificada en lugar de la tecnología más robusta utilizada en XDS. Define transacciones a enviar un conjunto de documentos y metadatos desde el dispositivo móvil a un receptor de documentos, encuentre los metadatos del conjunto de envío de documentos en función de los parámetros de consulta; encuentre entradas de documentos que contengan metadatos basados ​​en parámetros de consulta, y recuperar una copia de un documento específico.
Estas transacciones aprovechan el contenido del documento y dan formato a los conceptos de metadatos independientes de XDS, pero los simplifican para el acceso a entornos restringidos, como dispositivos móviles u otros sistemas con recursos limitados. El perfil MHD no reemplaza XDS. Se puede usar para permitir que los dispositivos móviles u otros sistemas con recursos limitados accedan a un intercambio de información de salud XDS. La siguiente figura muestra una forma posible de implementar MHD con un entorno de intercambio de documentos (que puede, pero no necesariamente, estar basado en XDS). Esta elección de implementación no es obligatoria y reconocemos que se implementarán otras arquitecturas.
MHD define una interfaz estandarizada para los documentos de salud (es decir, una interfaz de programación de aplicaciones (API)) para uso en dispositivos móviles, de modo que la implementación de aplicaciones móviles sea más consistente y reutilizable. Las transacciones definidas aquí aprovechan los conceptos de metadatos agnósticos del contenido del documento y del formato de XDS, pero los simplifican para el acceso en entornos restringidos que incluyen dispositivos móviles. El perfil MHD no reemplaza XDS. Los dispositivos móviles y otros sistemas con recursos limitados pueden usar MHD para acceder a un repositorio XDS. La siguiente figura muestra una forma posible de implementar MHD dentro de un entorno de intercambio de documentos (que puede ser, pero no necesariamente, basado en XDS). Esta elección de implementación no es obligatoria y reconocemos que se implementarán otras arquitecturas.

XDS Profile ha separado el Registro de documentos y el Repositorio de documentos para satisfacer las necesidades de las arquitecturas de implementación entre empresas y permitir la solidez, la seguridad, la privacidad y la interoperabilidad. El perfil de MHD ha simplificado las interacciones de manera más consistente con el uso dentro de un solo dominio de políticas. Las transacciones MHD no están vinculadas específicamente a XDS; Algunas de las implementaciones del sistema previstas pueden interactuar directamente con un EHR organizacional o un PHR multinacional.

El Perfil MHD es compatible con un amplio conjunto de casos de uso y funcionalidad de XDS a la vez que mantiene la tecnología lo más simple posible. MHD se centra en un subconjunto útil de los casos de uso de XDS y no intenta reproducir la escalabilidad, la flexibilidad, la privacidad o la seguridad total admitida por la infraestructura más robusta de XDS. Los siguientes son ejemplos de entornos que pueden elegir el perfil MHD sobre el perfil XDS:

Los dispositivos médicos, como los dirigidos por el dominio de dispositivos de atención al paciente (PCD) o la organización Continua, envían datos en forma de documentos.
Los quioscos utilizados por los pacientes en los departamentos de registro del hospital, donde se anticipa que un miembro del personal del hospital revisará, editará y aprobará el documento antes de ingresar al sistema hospitalario.
Publicación de PHR en un área de preparación para su posterior importación en un EHR o HIE.
Aplicación del paciente o proveedor que está configurada para conectarse de manera segura a un PHR para enviar un documento de historial médico. (Por ejemplo, BlueButton +)
Dispositivo de medición electrónico que participa en un flujo de trabajo XDW y extrae documentos de historial médico de un HIE.
Un consultorio médico de medicina general con capacidades de TI mínimas que utilizan una aplicación móvil para conectarse a un HIE o EHR.

Las aplicaciones específicas para dispositivos móviles y con recursos limitados son una plataforma emergente para software que mejora la atención médica. El Perfil MHD no se limita a dispositivos móviles, ya que utiliza el término "móvil" solo como una agrupación para aplicaciones móviles, dispositivos móviles o cualquier otro sistema que esté limitado por recursos y plataformas. Estas restricciones pueden llevar al implementador a utilizar una tecnología de interfaz de red más simple. Existen numerosas implementaciones implementadas de Intercambio de documentos que necesitan una tecnología de interfaz de red más simple, por ejemplo, aquellas alojadas por un Intercambio de información de salud (HIE), un registro de salud electrónico de gran proveedor de salud (EHR) o un registro de salud personal (PHR).

MHD define una interfaz estandarizada para los documentos de salud (es decir, una interfaz de programación de aplicaciones (API)) para uso en dispositivos móviles, de modo que la implementación de aplicaciones móviles sea más consistente y reutilizable. En este contexto, los dispositivos móviles incluyen tabletas, teléfonos inteligentes y dispositivos integrados, incluidos los dispositivos de salud en el hogar. Este perfil también es aplicable a sistemas más capaces donde las necesidades son simples, como extraer el último resumen para su visualización. Los aspectos críticos del "dispositivo móvil" son que tiene recursos limitados, un entorno de programación simple (por ejemplo, JSON, JavaScript), una pila de protocolos simple (por ejemplo, HTTP) y una funcionalidad de visualización simple (por ejemplo, un navegador HTML). El objetivo es, en parte, evitar cargar al cliente con bibliotecas adicionales, como las que son necesarias para procesar SOAP, WSSE, MIME-Multipart, MTOM / XOP, ebRIM y XML de profundidad múltiple.

MHD define un par de actores y una transacción para enviar o enviar nuevas "entradas de documentos" desde el dispositivo móvil a un sistema receptor. Otro conjunto de actores y transacciones se utiliza para consultar una lista de "entradas de documentos" que tienen metadatos específicos, y para recuperar un documento.

MHD aprovecha los conceptos de metadatos de XDS, pero simplifica los requisitos de transacción para el acceso desde dispositivos móviles. El perfil MHD no reemplaza XDS. Más bien, permite el acceso simplificado desde dispositivos móviles a un entorno de administración de documentos XDS (o similar) que contiene información de salud.


Referencias
http://hl7.org/fhir
https://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)
https://www.forcare.com/blog/ihe-and-fhir
https://www.slideshare.net/HINZ/hay-introduction-to-hl7-fhir

lunes, 13 de mayo de 2019

Como Machear pacientes utilizando la lógica basada en MPI en FHIR R4


Un Master Patient Index (MPI) es un servicio que se utiliza para administrar la identificación de pacientes en un contexto donde existen múltiples bases de datos de pacientes. Las aplicaciones de atención médica y el middleware utilizan el MPI para hacer coincidir a los pacientes entre las bases de datos y para almacenar los nuevos detalles de los pacientes a medida que se encuentran. Las MPI son aplicaciones altamente especializadas, a menudo adaptadas en gran medida a la mezcla particular de pacientes de la institución. Los IPM también se pueden ejecutar a nivel regional y nacional.

Para pedirle a un MPI que coincida con un paciente, los clientes usan la operación "$ match", que acepta un recurso del paciente que puede estar parcialmente completado. Los datos proporcionados se interpretan como una entrada de MPI y se procesan mediante un algoritmo de algún tipo que utiliza los datos para determinar las coincidencias más adecuadas en el conjunto de pacientes. Tenga en cuenta que diferentes algoritmos de coincidencia de MPI tienen diferentes entradas requeridas. La operación de $ coincidencia genérica no especifica ningún algoritmo en particular, ni un conjunto mínimo de información que debe proporcionarse al solicitar que se realice una operación de coincidencia de MPI, pero muchas implementaciones tendrán un conjunto de información mínima, que puede ser declarada en su definición de la operación de coincidencia $ especificando un perfil en el parámetro de recurso, que indica qué propiedades se requieren en la búsqueda. El recurso del paciente enviado a la operación no tiene que estar completo, ni necesita pasar la validación (es decir, los campos obligatorios no necesitan ser rellenados), pero tiene que ser una instancia válida, ya que se utiliza como el Datos de referencia para emparejar contra.


Referencias
https://www.hl7.org/fhir/operation-patient-match.html
https://www.ihs.gov/hie/masterpatientindex/
https://www.ehealthontario.on.ca/images/uploads/standards_docs/FHIR-PCR-Specification/site/pcr-Patient-match.xml.html


sábado, 11 de mayo de 2019

USUARIA: X FORO IT SALUD ARGENTINA - 11 de junio 2019


Si no puede visualizar correctamente esta imagen, haga click aquí

YoutubeFlickrTwitterFacebookInstagramLinkedInRegistrarseMás Informaciònwww.segurinfo.orgwww.usuaria.org.arForum IT SaludUsuaria

Mañanas de Estándares en Salud "GRATUITAS", PARTICIPE


El miércoles 15/05/2019  próximo se hace otra edición de las Mañanas de Estándares en Salud del MS, se pueden inscribir en forma presencial o virtual
Presencial Inscripción a la Jornada Mañana de Estándares
Link  https://www.surveymonkey.com/r/1505presencial

Virtual Inscripción a la Jornada Mañana de Estándares
Link https://es.surveymonkey.com/r/1505virtual

CUMPLE AÑOS DE HL7LATAM BLOG

Queríamos comentarles que el blog de HL7LATAM cumplió un año que durante ese periodo tuvo 28.216 vistas y se hicieron 530 publicaciones. El objetivo sigue siendo el que nos habíamos propuesto desde HL7LATAM de difundir el estándar HL7 y la IM en latinoamerica.

El blog lo leyeron
de Argentina 6400
de Estados Unidos 5439
de México 3181
de Brasil 1764
de Chile 1037
de Uruguay 931
de España 869
de Colombia 849
de Bolivia 780
de Perú 426

¿Qué es un PMO?

Project Management Office o PMO es el departamento o la figura dentro de la organización encargada de definir unos criterios comunes para gestionar y coordinar los proyectos, con un alcance y responsabilidad variable en función de la organización.


Aunque en empresas grandes la Project Management Office (PMO) suele ser un departamento, en empresas más pequeñas esta puede estar formada por una única persona, o incluso ser parte del trabajo de uno de los directores de proyectos.

¿Formas de integrar la Project Management Office en la organización?
Existen básicamente dos formas de integrar la Project Management Office dentro de la estructura de la organización:

Con relación jerárquica con los directores de proyectos. En este caso la PMO se establece como un departamento que engloba y gestiona a los directores de proyectos. Esta forma de integración es la que da más autoridad a la PMO, y mayor capacidad para actuar y asumir funciones.
PMO jerarquica

Sin relación jerárquica con los directores de proyectos. En este caso la Project Management Office (PMO) no gestiona directamente los directores de proyectos, sino que actúa como un ente independiente y externo a estos.
PMO no jerarquica

No existe una forma mejor de integrar la Project Management Office (PMO) en la organización, sino que la forma de integrarla va a depender de los objetivos y funciones que esta deba asumir. De esta forma, una Project Management Office (PMO) sin relación jerárquica sobre los directores de proyecto tendrá una capacidad limitada de gestionarlos, quedando su capacidad limitada a especificar procesos y auditar su aplicación.



¿Qué funciones tiene una PMO?   
De forma genérica la Project Management Office (PMO) es la responsable de coordinar y establecer unas pautas comunes en la gestión de proyectos dentro de la organización, lo cual puede realizarse de forma más o menos extensa, e incluir más o menos responsabilidades y funciones, entre las que podríamos destacar:

Definir los procesos de gestión y seguimiento de proyectos en la organización, de tal forma que se establezca un marco de trabajo común para todos los directores de proyecto.
Auditar y supervisar la aplicación de los procesos de gestión de proyectos definidos, aplicando la mejora continua para ir adaptando y mejorando estos a lo largo del tiempo.
Actuar como consultor y formador para los directores de proyectos.
Gestionar los propios directores de proyectos, asignándolos a cada proyecto y garantizando que estos cumplen con las necesidades de la organización. En este caso la Project Management Office (PMO) sería un departamento que englobaría a los directores de proyectos, por lo que necesariamente estaríamos hablando de una relación jerárquica con estos.
Integrar y balancear los recursos de los proyectos para optimizar su resultado en conjunto. Esto es muy importante en organizaciones multiproyecto donde se ejecutan varios proyectos en paralelo y se comparten recursos.
Resolver conflictos entre proyectos fijando prioridades.
Ventajas para la organización
Crear una oficina de gestión de proyectos o PMO e integrarla en una organización en funcionamiento no es simple, y normalmente implica tener que hacer frente a numerosos conflictos, y una inversión de recursos y tiempo. Consecuentemente tenemos que estar seguros de que esta va a ser beneficiosa para los resultados de la organización antes de su implementación.


Entre los principales beneficios que una Project Management Office puede aportar a cualquier organización se podrían destacar las siguientes:

Iguala los procesos de gestión de proyectos, facilitando el seguimiento de estos por parte de la dirección, e independizando en parte el resultado del proyecto de la persona que lo dirige. En este sentido el riesgo de fracaso en proyectos se ve reducido.
Optimiza el número de profesionales necesarios para dirigir el conjunto de proyectos, reduciendo el coste de esta actividad. Esto es posible porque a medida que se definen, mejoran e implementar en la organización los procesos de gestión de proyectos adecuados, esta gestión se ve simplificada, siendo posible que cada director de proyectos asuma un número de proyectos mayor.
Optimiza la asignación de los directores de proyectos en base a su perfil, asignando aquellos con más experiencia y formación a los proyectos más críticos o de mayor tamaño, y los más noveles a los que no lo son.
Mejora la planificación y coordinación de los recursos para reducir la duración media de los proyectos, permitiendo así reducir el tiempo de facturación e incrementar el resultado económico de la empresa. Esto se consigue en gran medida implementando los conceptos de gestión por cadena crítica.
Facilita colectar, y reaprovechar la información y conocimientos generados en los proyectos para permitir la implementación de procesos de mejora.
Establece criterios objetivos para resolver los conflictos entre proyectos, de acuerdo a criterios objetivos de priorización y a la política de la organización.
Junto con las ventajas también existe una desventaja, ya que una Project Management Office (PMO) implica un gasto de recursos que debe verse compensado por las ventajas que esperamos obtener. Por tanto, su implementación e integración en la organización debe ser analizada, sobretodo en organizaciones pequeñas, o que trabajen con pocos proyectos en paralelo, o con poca interacción entre ellos.

Dificultades habituales en la implementación de la PMO
Como cualquier proceso de cambio organizativo, la implementación de una Project Management Office (PMO) no está exenta de problemas y dificultades. Como resumen podemos destacar las siguientes:

La resistencia al cambio de la propia organización, representada por la típica frase “eso siempre lo hemos hecho así”.
Introducir los cambios sin afectar negativamente a los proyectos en curso. Lo que muchas veces implicará un periodo de coexistencia entre las dos formas de trabajar.
Cambios en las responsabilidades o el grado de libertad de las personas, cosas que no siempre son bien aceptadas.
Falta de conocimientos dentro de la propia organización para poder llevar a cabo esta tarea con recursos internos.
Existe una serie de consejos que facilitan el hacer frente a estas dificultades, algunos de los cuales son totalmente necesarios para poder afrontar un cambio de este tipo:

La implementación de la Project Management Office (PMO) debe ser una actividad promovida y totalmente apoyada por la dirección de la organización. La cual debe implicarse activamente en el proceso.
Suele ser más efectivo y simple plantear una implementación en diferentes fases, incrementando las funciones y autoridad de la Project Management Office (PMO) de forma progresiva.
Es totalmente necesario disponer de personas con los conocimientos y experiencia necesarias como para poder llevar a cabo este proceso, y poder gestionar la Project Management Office (PMO) una vez implementada. Por ello puede ser necesario implementar cambios organizativos para situar las personas adecuadas en el lugar adecuado, la contratación de perfiles específicos, o buscar la ayuda de una empresa de consultoría.

Referencias: