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:

jueves, 9 de mayo de 2019

Blockchain: ¿una tecnología que revolucionará la salud?

Hace un tiempo hablamos de los chatbots y de su potencial en el sistema sanitario, hoy le toca el turno a una tecnología que se dió a conocer con la aparición del Bitcoin y las criptomonedas pero que está empezando a tomar velocidad en otros ámbitos: blockchain

Un problema común que enfrentan los sistemas de atención sanitaria es lograr que la información esté disponible en distintas plataformas, pero de un modo que se garantice la integridad de los datos y se proteja la privacidad del paciente.
Las Historias Clínicas Electrónicas (HCE) han dado un paso en la dirección de la estandarización de datos clínicos, sin embargo, la gran mayoría de los sistemas hospitalarios todavía no pueden compartir sus datos con facilidad. Atender un paciente del Hospital X en el Hospital Y suele implicar hacerlo sin contar con el total de sus antecedentes anteriores, peor aún si hablamos de personas de distintas ciudades. La información crítica a menudo se encuentra fragmentada y dispersa en múltiples instalaciones, lo que cuesta dinero y a veces incluso vidas.
Al mismo tiempo, la historia clínica almacenada no está exenta de ser alterada. De la misma manera que con las historias clínicas de papel una hoja podía ser reemplazada sin que nadie se enterase, lo mismo puede ocurrir en una HCE, ya que el dato del estudio de laboratorio que el paciente se hizo en el verano del 92’ no tiene conexión con su tomografía de tórax actual.
El uso de blockchain puede ofrecer una solución interesante a estos problemas. Al usar blockchain para la información clínica, se obtiene al mismo tiempo un set universal de herramientas criptográficas que asegura la integridad de los datos, brinda auditoría estandarizada y pauta “normas” formales para el acceso a los datos.
Blockchain se creó con el fin de servir como registro de transacciones financieras. El concepto simplificado es básicamente que cada parte que interviene en una transacción tiene su identificador único que sirve de sello para firmar sus operaciones.
En una primera transacción entre dos partes como empresa A y empresa B; los montos intercambiados, la fecha y hora, y los identificadores de las partes son procesados por un algoritmo y se genera un “bloque” de información particular, llamémoslo Bloque 1. Este Bloque 1 sólo puede formarse usando esos datos iniciales y ningún otro más. Entonces el Bloque 1 es distribuido al resto de los nodos de la red financiera para su resguardo. Al realizarse una siguiente operación, los contenidos del Bloque 1 junto con los nuevos montos, fecha y hora y los identificadores de las partes, se utilizan en el algoritmo para generar el Bloque 2. El Bloque 3 se generará usando los datos de la transacción más el Bloque 2, y así sucesivamente. Es decir, dado que el Bloque 3 solo puede ser generado usando los datos del Bloque 2 y este sólo puede generarse con los datos del Bloque 1, la información se encuentra encadenada y cada parte es inmutable o la cadena no sería la misma.
Esta técnica crea una cadena de contenido en donde cada segmento nuevo es un anexo al anterior, inmutable y firmado por las partes involucradas. De ahí el nombre “blockchain”: cadena de bloques.
Eso está muy bien para el sistema financiero, pero ¿cómo se relaciona eso con el sistema sanitario?
Reemplacemos operaciones de compra-venta con códigos propios en una HCE; cada vez que se pide un análisis de sangre, médico y paciente tienen su identificador único. La orden del análisis, los participantes y la fecha y hora serían guardados como un bloque más en la cadena de ese paciente en particular. Al tener dependencias con los registros pasados y futuros, alterar una pieza de información sin ser detectado se vuelve imposible sin alterar todos los registros de la cadena y de los nodos de la red.
Investigadores del MIT Media Lab están trabajando en una solución de este estilo y han hecho un estudio piloto usando información de las historias clínicas del Hospital Beth Israel. Los resultados son interesantes y se está planteando expandir las pruebas a una red mayor de hospitales.
Blockchain propone redefinir cómo se organiza la información y nuestra idea sobre la confianza entre las partes.
Sin embargo, su uso en el sistema sanitario depende de la creación de una infraestructura técnica adecuada. Hospitales, clínicas, organizaciones gubernamentales y demás organizaciones del sistema deben estar dispuestos a colaborar para crear, prototipar y probar los conceptos fundamentales que harán las bases para las historias clínicas del futuro.
Por Guido Giunti*
(*) Guido Giunti es médico especializado en Salud Digital, con experiencia en innovación aplicada al paciente. Fue Investigador en Informática Médica en el Hospital Italiano de Buenos Aires y co-fundador del evento TEDx de la Universidad de Buenos Aires, Argentina. También fue Colaborador en iMedicalApps.com y editor del Journal of Medical Internet Research – Serious Games. Actualmente, es Medical Advisor en la empresa de intervenciones digitales Salumedia Tecnologías, España y se encuentra realizando su doctorado en el uso de tecnologías persuasivas y gamification para generar hábitos saludables en pacientes crónicos en la Universidad de Oulu, Finlandia. Su trabajo e investigación está financiado por el programa de investigación e innovación Horizonte 2020 de la Unión Europea, en virtud del acuerdo de subvención Marie Skłodowska-Curie nº 676201.

Leído en eHealthReporter

miércoles, 8 de mayo de 2019

FORBES HEALTHCARE SUMMIT

Forbes Argentina se complace en anunciar este año la segunda edición de Forbes Healthcare Summit en nuestro país. Un encuentro que una vez más convocará a empresarios, CEOs, funcionarios públicos, expertos de la industria, médicos e investigadores. Una mirada amplia y profunda sobre los desafíos sobresalientes de la industria de la Salud en la Argentina.

8 de mayo - 15h - Sheraton Hotel & Convention Center (Auditorio)

Inscribite aquí, cupos limitados.


Más información en summitforbes@forbesargentina.com

domingo, 5 de mayo de 2019

El Gobierno presentó el nuevo sistema de identidad digital para realizar trámites

La plataforma, que estará conectada con la base de Renaper, podrá ser adoptada por organizaciones públicas y privadas para validar la identidad a distancia.
El ministro de Modernización, Andrés Ibarra, y su par de Interior, Obras Públicas y Vivienda, Rogelio Frigerio, presentaron esta tarde el nuevo Sistema de Identidad Digital (SID), una plataforma que permitirá validar la identidad de los argentinos a través del reconocimiento facial.
Para esto, el usuario sacará una foto de su rostro o de su Documento Nacional de Identidad para que la información sea comparada con la base del Registro Nacional de las Personas (Renaper).
“Esto que estamos presentando hoy marca un antes y después en todo el ecosistema de servicios digitales; es un hito importantísimo en pos de simplificarle la vida a la gente. Argentina necesita más y mejor empleo, y la manera de crearlo es con una economía dinámica y pujante, sin filas, demoras ni idas y vueltas innecesarias, dónde la tecnología juega un rol fundamental”, destacó Ibarra durante el acto de presentación que se realizó en el Salón de los Pueblos Originarios de Casa Rosada.
Por su parte, Frigerio indicó: “El Sistema de Identidad Digital es la primera herramienta tecnológica desarrollada por el Estado, que mediante la validación de la identidad por rostro le permitirá al ciudadano acceder a servicios públicos y privados sin necesidad de trasladarse a una oficina. Son hechos concretos que le hacen más fácil la vida a la gente, ahorrando tiempo y achicando distancias”.
Además, el director del Renaper, Juan José D’Amico, destacó la conformación de “una mesa de trabajo y consulta con los organismos interesados para ir adaptando el sistema a sus necesidades”.
“La etapa de pruebas finalizó con buenos resultados y estamos muy contentos de poder lanzarlo oficialmente porque creemos que abre grandes posibilidades y beneficios tanto para organismos, empresas y principalmente para todos los ciudadanos”, remarcó.
El sistema estará integrado a la web o aplicación de la entidad donde las personas accederán para obtener alguno de sus servicios. En determinado momento se le solicitará al ciudadano una foto de su DNI y una selfie, datos que serán enviados directamente al Renaper para que los valide y en menos de 7 segundos el solicitante podrá continuar con su trámite en línea.
Asimismo, esta nueva herramienta se suma a otros dos servicios que Renaper ya tiene en funcionamiento, uno de validación de datos personales y vigencia de DNI y otro de verificación por huella digital que actualmente tienen un tráfico de más 700 mil transacciones por día.
En ese sentido, y con el objetivo de asegurar los datos de los usuarios, se trabajó de manera conjunta con la Agencia de Acceso a la Información Pública.
Los primeros en implementarlo serán el sector financiero y fintech, que ya finalizaron la etapa de pruebas impulsada por el Banco Central de la República Argentina y que corresponde a su política de bancarización e inclusión financiera.
Este tipo de herramientas ayuda a evitar el fraude a la vez que garantiza a los clientes la seguridad de que sus datos son validados por el Estado en tiempo real.
Se espera que el aplicativo permita a los ciudadanos abrir una caja de ahorros y solicitar préstamos de modo completamente virtual. La plataforma también es susceptible de ser utilizada para la generación de clave fiscal, sistemas de billeteras electrónicas y cualquier trámite que hoy requiera una validación de identidad.
En el ámbito público se implementará la solución en Salud para el empadronamiento de pacientes, en Desarrollo Social para el cobro de programas sociales, en Seguridad para el control de fronteras, migraciones y espectáculos de todo tipo. Asimismo, se podrá utilizar para la renovación del Pasaporte o DNI, o para cualquier otro trámite que implique la validación de identidad.
El aplicativo también se utilizará en la plataforma Mi Argentina, la ventanilla única digital para trámites con el Estado. Esta plataforma -que ya cuenta con más de 400.000 usuarios- permite crear un perfil digital, donde el ciudadano puede hacer un seguimiento de sus trámites, solicitar turnos y recibir alertas de vencimientos, fechas de cobro, entre otras cosas.

Jornadas de Interoperabilidad en Salud JIOS 2019, en Gral. Roca, provincia de Río Negro.

El 28 y 29 de marzo se realizaron las Jornadas de Interoperabilidad en Salud JIOS 2019, en Gral. Roca, provincia de Río Negro.

FECLIR (Federación de Clínicas y Sanatorios Privados de Río Negro) y HL7 Argentina organizaron las jornadas con el fin de escuchar y tomar conocimiento del estado de los sistemas de información de salud de la zona y el grado de interoperabilidad utilizado en cada uno de ellos. En el transcurso de los dos días, se expuso sobre Introducción a la Interoperabilidad, Mensajería HL7 y CDA. Durante el taller de FHIR los participantes pudieron interactuar con los recursos y nuevos servicios que éste ofrece. Participaron profesionales de instituciones privadas y públicas de Río Negro, Neuquén y San Luis, respectivamente.

Luego de las jornadas hubo un intercambio importante de consultas respecto a CDA y FHIR por inquietudes respecto al uso, por donde comenzar, como planificar una implementacion que incluya intercambio de información de salud entre distintos actores que brindan distintos tipos de servicio, etc.

Bienvenidas las inquietudes, consultas y desafíos en pos de una mejora de la disposición de información para una mejor salud de la población !!












sábado, 20 de abril de 2019

INTERPRETACIÓN DE ESTÁNDARES Y GUÍA PARA SU ADECUACIÓN

var_47
block_img_2
INTERPRETACIÓN DE ESTÁNDARES Y GUÍA PARA SU ADECUACIÓN
block_img_2
block_img_2
Actividad de actualización
MODALIDAD: VIRTUAL
Material de lectura en campus virtual
Talleres por sistema de videoconferencia
Resolución de casos prácticos
CONTENIDOS
Interpretación de estándares
Guía para su adecuación
El impacto de esta adecuación en la atención de los pacientes
MÁS INFO
En el sitio web del ITAES. Contáctese telefónicamente al (+5411) 2122-6162 int.12, o por correo electrónico a capacitacion@itaes.org.ar
var_47
ITAES - Instituto Técnico para la Acreditación de Establecimientos de Salud
 Blanco Encalada 2923 (C1428DDW) -  CABA - Argentina
Líneas rotativas: (+5411) 2122-6162 / 2129-8253 
info@itaes.org.ar  - www.itaes.org.ar

sábado, 23 de marzo de 2019

HL7 FHIR 4


FHIR  (recursos rápidos de interoperabilidad de la atención médica) ahora son normativos, y la nueva edición trae miles de otras actualizaciones.

Health Level Seven anunció el miércoles que ya está disponible una nueva versión de su especificación de interoperabilidad.

¿Por qué  es importante?

Muchos en la industria de la salud han estado esperando ansiosamente la cuarta versión de FHIR 4 porque los cambios futuros ahora serán compatibles con versiones anteriores.

"Las aplicaciones que implementan las partes normativas de R4 ya no corren el riesgo de ser no conformes con el estándar", dijo el Director de Producto de FHIR, Grahame Grieve, en el blog de FHIR.

Grieve también señaló que, además de la plataforma base, varias piezas clave de FHIR también son normativas, incluida la API RESTful, los formatos XML y JSON, la capa de terminología, el marco de conformidad, así como los recursos para el paciente y la observación.

LA TENDENCIA MAS GRANDE

Las API abiertas y FHIR son consideradas como críticas para hacer que los datos de salud sean más interoperables. Los Centros de Servicios de Medicare y Medicaid y la Oficina del Coordinador Nacional de Informática de la Salud han dicho lo mismo. Cuando Apple lanzó sus registros de salud hace un año, incorporó FHIR, y casi 150 hospitales se han registrado para respaldar la herramienta.

Al mismo tiempo, los fabricantes de EHR como Allscripts, athenahealth, Cerner, eClinicalWorks, Epic y Meditech tienen programas para desarrolladores que usan FHIR y API abiertas para permitir que terceros puedan escribir software que use sus plataformas de registros de salud electrónicos. (La Ley de Curaciones del Siglo 21 requiere que las EHR certificadas tengan API abiertas).

Algunos de esos desarrolladores han estado pidiendo una versión única de FHIR y, si bien R4 no lo resuelve por completo, es un paso en la dirección correcta.

En el registro

"R4 es la culminación de 18 meses de un extenso trabajo para finalizar las partes básicas de la especificación e incorporar los cambios y las solicitudes de mejora recibidas de los socios de implementación en todo el mundo", dijo Grieve. "R4 es la culminación de 18 meses de un extenso trabajo para finalizar las partes básicas de la especificación e incorporar los cambios y las solicitudes de mejora recibidas de los socios de implementación en todo el mundo".

Referencias

viernes, 22 de marzo de 2019

lunes, 18 de marzo de 2019

La sanidad digital en España, a examen.



El pasado mes de febrero se celebró la IV Jornada de la Asociación de Salud Digital que, bajo el título “Transformación digital en salud: compromisos y realidades”, mostró una visión general del estado de la sanidad digital en España, a partir de una variada colección de interesantes ponencias.
Javier Mur, del IESE presentó un interesantísimo trabajo sobre los distintos modelos de compra de medicamentos y un algoritmo para determinar el más adecuado, en función de las características de la enfermedad y del propio fármaco.
Jaime del Barrio, presidente de la Asociación de Salud Digital, a quien ya entrevistamos en A un clic de las TIC  dirigió una mesa redonda en la que participaronn José Martínez Olmos y José Javier Castrodeza, ambos exdirectores generales de sanidad, sobre el estado de la sanidad digital en España. La conclusión fue que, en lo que a los prestadores de salud pública se refiere, está todo por hacer.
Durante el encuentro  pudimos conocer hasta tres nuevas iniciativas dispuestas a medir el grado de digitalización de la sanidad española, adicionales al “Termómetro sobre la madurez digital del sector salud que ya dábamos a conocer el pasado mes de noviembre. Es una cuestión clave porque, aunque desde este y otros medios venimos alertando de que este grado de digitalización es “bajo”, es importante medirlo con parámetros objetivos, ya que lo que se mide es lo que se puede gestionar.
Las tres iniciativas mencionadas son:
  1. El Dictamen europeo sobre digitalización del sector sanitario, elaborado por el Comité de las Regiones de la Unión Europea, que el consejero de sanidad de Murcia se encargó de presentar en el evento y en el que me detendré a continuación.
  2. El informe “Transformación digital en salud en España”, actualmente en elaboración por parte de la Asociación de Salud Digital, del que escribiré próximamente.
  3. El estudio “La historia clínica digital como motor de transformación del sistema sanitario”, que está elaborando Fundación COTEC, en colaboración con Telefónica Empresas, del que también nos haremos eco en este blog.



Respecto al dictamen europeo, considero importante destacar los siguientes siete puntos:

  1. Llama la atención sobre “los grandes volúmenes de datos de salud que actualmente se almacenan en sistemas separados” y la necesidad de que la transformación digital centre los esfuerzos tanto en la interoperabilidad que reduzca estos silos de información como en la explotación que permita obtener información de salud útil a partir de dichos datos, con respeto siempre a la privacidad de los ciudadanos. Algunas de las medidas que el dictamen promueve son eliminar las trabas a la interoperabilidad y crear un formato europeo de intercambio electrónico de registros sanitarios, si bien ya existe un amplio número de estándares de intercambio de información sanitaria, de los que la industria se ha ido dotando en los últimos lustros.
  2. El dictamen alude al equilibrio necesario entre la protección de la privacidad de los ciudadanos y las oportunidades derivadas del acceso a los datos de los pacientes en cuanto a la obtención de conocimiento médico y la oportunidad de descubrir mejores tratamientos.
  3. En este ámbito, el dictamen también le da una alta importancia al campo de la genómica y  aboga por “la posibilidad de que los estudios genéticos de ciudadanos europeos dispongan por razones clínicas de una identificación única” de cara a su posterior almacenamiento seguro (para ello se propone utilizar blockchain) y su explotación en redes de conocimiento europeas en las que la compartición de datos y la inteligencia artificial sean herramientas clave para generar nuevo conocimiento.
  4. En el ámbito de la experiencia del paciente, el informe defiende un “enfoque multidisciplinar e integrado de los cuidados, y el intercambio electrónico de datos entre los pacientes, sus cuidadores y los proveedores de cuidados”. Para ello, pone como prerrequisito mejorar la alfabetización digital de los ciudadanos y los profesionales sanitarios. Y destaca que, una vez conseguido esto, la aplicación masiva de la mHealth generará múltiples efectos positivos. Por un lado, en la salud de los pacientes, su experiencia en la recepción de los servicios sanitarios y en la sostenibilidad del sistema. Y, por otro lado, también hará este más igualitario, al acercar la sanidad tanto a personas con dificultades de movilidad, como a las que viven en regiones más aisladas y con mayores dificultades de acceso a los servicios sanitarios presenciales. Eso sí, las tecnologías sanitarias, como las app de salud deben ser validadas y, por ello, el dictamen aplaude el nuevo Reglamento sobre Evaluación de tecnologías sanitarias de la Unión Europea y promueve un “proceso de acreditación, certificación o marcado con validez en Europa”.
  5. El dictamen califica tanto de lento como de heterogéneo el grado de adopción de la transformación digital en sanidad en los distintos países y territorios de Europa . Se destaca que “algunos estados miembros han realizado grandes inversiones para desarrollar los historiales clínicos electrónicos e impulsar plataformas digitales”, lo cual debe reaprovecharse para la consecución de una auténtica historia clínica electrónica europea.
  6. Preocupa también la mejora de la capacidad de autocuidado de los pacientes  y la alfabetización en salud. También cómo evitar la infoxicación y los bulos de salud, sobre los que recientemente escribía mi compañera Ana Siles. En ambos casos, la transformación digital de la sanidad puede jugar un papel muy importante.
  7. En el ámbito de la financiación, el dictamen se felicita por las nuevas propuestas de financiación que se están poniendo en marcha desde la Unión Europea para el período 2021-2027, entre ellas el Programa Europa Digital para dicho periodo, dotado con 9.200 millones de euros.