Health Level-7 o HL7 se refiere a un conjunto de estándares internacionales para la transferencia de datos clínicos y administrativos entre las aplicaciones de software que utilizan diversos proveedores de servicios médicos
Para gestionar la acumulación de datos de producción, InterSystems IRIS permite a los usuarios controlar el tamaño de la base de datos purgando periódicamente los datos. Esta purga puede aplicarse a mensajes, registros, procesos de negocio y alertas gestionadas.
Consultad la documentación para obtener más detalles sobre la configuración de la tarea de purga:
https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=EGMG_purge#EGMG_purge_settings
Trabajar en TI para el sector salud como un desarrollador joven, especialmente en InterSystems TrakCare, te hace darte cuenta rápidamente de una cosa: no se trata solo de mensajes HL7 o integraciones backend. Una gran parte de lograr que TrakCare funcione sin problemas en los hospitales depende de cómo se configura, personaliza y da soporte desde el lado de la aplicación.
Ahí es donde entramos personas como yo: desarrolladores tecno-funcionales que entendemos tanto la tecnología como su impacto en los flujos de trabajo reales del hospital.
Hola comunidad,
En este artículo, os voy a presentar mi aplicación iris-fhir-bridge.
Perfilando Documentos CCD con la Herramienta CCD Data Profiler de LEAD North
¿Alguna vez has abierto un CCD y te has encontrado con una pared de XML enredada? No estás solo. Aunque los CCD son un formato central para el intercambio de datos clínicos, son notoriamente densos, prolijos y poco amigables para la vista humana. Para los desarrolladores y analistas que intentan validar su estructura o extraer información significativa, navegar estos documentos puede sentirse más como arqueología que como ingeniería.
Contexto:
Esta guía proporciona una visión general de cómo diseñar e implementar una interfaz API REST para consultar los datos demográficos de un paciente desde un sistema de Registro Electrónico de Pacientes (EPR) utilizando HealthConnect. El proceso implica enviar una solicitud de consulta con el número de identificación del paciente, recuperar la respuesta del sistema EPR, extraer los datos demográficos requeridos del mensaje HL7 y enviarlos como una respuesta JSON al proveedor. El diagrama del proceso de alto nivel se muestra a continuación (Captura de pantalla 1).
InterSystems IRIS for Health y HealthConnect son las plataformas tecnológicas líderes en interoperabilidad sanitaria. Si te dedicas a la implementación de soluciones para interconectar sistemas en el sector de la salud, te interesará este curso.
¡Muy buenas a todos! Os paso un ejemplo de resolución de problemas a la hora de implementar transformaciones de datos que es muy interesante: estaba trabajando en un transformación de datos (DTL) de mensajes HL7 pero no paraba de obtener errores del tipo ERROR #5002... MAXSTRING. El problema era que la mayor parte de acciones en la interfaz gráfica de DTL utilizan el tipo de datos %String al trabajar con segmentos de un mensaje HL7.
Un %String tiene un límite de 3,641,144 caracteres, y mi OBX5.1 tenía 5,242,952 caracteres de longitud, como en el ejemplo proporcionado. Por supuesto, el administrador del sistema PACS dijo que se necesitaban archivos de ultra alta calidad, incluyendo resolución 4K, por lo que no pudimos lograr que el proveedor comprimiera o reformateara estos archivos a jpg comprimido o algo similar.
.png)
Inicialmente, este proveedor envía un ORU^R01 en la versión 2.3, y el EHR espera un MDM^T02 también en la versión 2.3. Además, necesitábamos realizar las siguientes transformaciones:
Ejemplo de estructura de mensaje recibido (cada "..." quedaría reemplazado con datos de más de 5 MB):
MSH|^~\&|VENDOR||||20241017125335||ORU^R01|1|P|2.3|
PID|||203921||LAST^FIRST^^^||19720706|M||||||||||100001|
PV1||X||||||||GI6|||||||||100001|
ORC|RE||21||SC||1|||||||||||
OBR|1||21|21^VENDOR IMAGES|||20241017123056|||||||||1001^GASTROENTEROLOGY^PHYSICIAN|||||Y||||F||1|
OBX|1|PR|100001|ch1_image_001.bmp|...^^^^^^^|BMP|||||F|
OBX|2|PR|100001|ch1_image_003.bmp|...|BMP|||||F|
OBX|3|PR|100001|ch1_video_01thumbnail.bmp|...|BMP|||||F|
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
OBX||||||||||||
Las herramientas y métodos de prueba habituales no estaban a la altura para manejar mensajes tan grandes. Cuando usaba este ejemplo reemplazando los datos con ..., la interfaz gráfica de DTL de arrastrar y soltar funcionaba bien, pero al insertar los datos reales, todo se venía abajo.
Finalmente, descubrí que tenía que usar un bloque de código con ObjectScript y los tipos de datos Stream para poder trabajar correctamente con estos mensajes grandes.
Comparto mi clase final de DTL para cualquiera que venga después de mí y pueda encontrar esto útil:
Class OrdRes.VendorMDM Extends Ens.DataTransformDTL [ DependsOn = EnsLib.HL7.Message ]
{
Parameter IGNOREMISSINGSOURCE = 1;
Parameter REPORTERRORS = 1;
Parameter TREATEMPTYREPEATINGFIELDASNULL = 0;
XData DTL [ XMLNamespace = "http://www.intersystems.com/dtl" ]
{
<transform sourceClass='EnsLib.HL7.Message' targetClass='EnsLib.HL7.Message' sourceDocType='2.3:ORU_R01' targetDocType='2.5:MDM_T02' create='new' language='objectscript' >
<assign value='source.{MSH}' property='target.{MSH}' action='set' />
<assign value='"MDM"' property='target.{MSH:MessageType.MessageCode}' action='set' />
<assign value='"T02"' property='target.{MSH:MessageType.TriggerEvent}' action='set' />
<assign value='"2.5"' property='target.{MSH:VersionID.VersionID}' action='set' />
<assign value='source.{MSH:DateTimeofMessage}' property='target.{EVN:2}' action='set' />
<assign value='source.{PIDgrpgrp().PIDgrp.PID}' property='target.{PID}' action='set' />
<assign value='source.{PIDgrpgrp().PIDgrp.PV1grp.PV1}' property='target.{PV1}' action='set' />
<assign value='source.{PIDgrpgrp().ORCgrp().ORC}' property='target.{ORCgrp().ORC}' action='set' />
<assign value='source.{PIDgrpgrp().ORCgrp().OBR}' property='target.{ORCgrp().OBR}' action='set' />
<assign value='source.{PIDgrpgrp().ORCgrp().NTE()}' property='target.{ORCgrp().NTE()}' action='set' />
<assign value='"Endoscopy Image"' property='target.{TXA:DocumentType}' action='set' />
<assign value='"AU"' property='target.{TXA:DocumentCompletionStatus}' action='set' />
<assign value='"AV"' property='target.{TXA:DocumentAvailabilityStatus}' action='set' />
<assign value='source.{PID:18}' property='target.{TXA:12.3}' action='set' />
<code>
<![CDATA[
set OBXCount=source.GetValueAt("PIDgrpgrp(1).ORCgrp(1).OBXgrp(*)")
For k1 = 1:1:OBXCount
{
// if OBX-1 is empty then it is assumed the rest of the segment will be empty too, so disregard it.
If source.GetValueAt("PIDgrpgrp(1).ORCgrp(1).OBXgrp("_k1_").OBX:SetIDOBX") '= ""
{
// create new stream to read source OBX
set srcOBXStream=##class(%Stream.GlobalCharacter).%New()
// get stream data from source OBX
set tSC=source.GetFieldStreamRaw(srcOBXStream,"PIDgrpgrp(1).ORCgrp(1).OBXgrp("_k1_").OBX")
// get the positions of needed delimitters:
set p1=srcOBXStream.FindAt(1,"|") // 0>p1="OBX"
set p2=srcOBXStream.FindAt(p1+1,"|") // p1>p2=OBX-1
set p3=srcOBXStream.FindAt(p2+1,"|") // p2>p3=OBX-2
set p4=srcOBXStream.FindAt(p3+1,"|") // p3>p4=OBX-3
set p5=srcOBXStream.FindAt(p4+1,"|") // p4>p5=OBX-4
set p6=srcOBXStream.FindAt(p5+1,"^") // p5>p6=OBX-5.1
set p7=srcOBXStream.FindAt(p6+1,"|") // p6>p7=OBX-5.2 -> OBX 5.*
// if no OBX-5.2 then there will not be the `^` and p6 and p7 will be `-1`
// when that is the case, find p7 starting at `p5+1` and make p6 = p7
if (p6 < 0) {
set p7=srcOBXStream.FindAt(p5+1,"|") // p5>p7=OBX-5
set p6=p7
}
set p8=srcOBXStream.FindAt(p7+1,"|") // p7>p8=OBX-6
set tStream=##class(%Stream.GlobalCharacter).%New()
// renumber OBX-1 to OBX
set tSC=tStream.Write("OBX|"_k1_"|")
// set OBX2-2 to "ED"
set tSC=tStream.Write("ED|")
// copy source OBX-3 to target OBX-3
set tSC=srcOBXStream.MoveTo(p3+1)
set tSC=tStream.Write(srcOBXStream.Read(p4-p3-1))
set tSC=tStream.Write("|")
// copy source OBX-4 to target OBX-4
set tSC=srcOBXStream.MoveTo(p4+1)
set tSC=tStream.Write(srcOBXStream.Read(p5-p4-1))
// copy source OBX-6 to OBX-5.3 & OBX-5.4
set tSC=srcOBXStream.MoveTo(p7+1)
set docType=srcOBXStream.Read(p8-p7-1)
set tSC=tStream.Write("|^^"_docType_"^"_docType_"^")
// copy source OBX-5.1 to target OBX-5.5
// can only set up to 3,641,144 chars at once, so do while loop...
set startPos=p5+1
set remain=p6-p5-1
// characters to read/write in each loop, max is 3,641,144 since .Write limit is a %String
set charLimit=3000000
while remain > 0 {
set tSC=srcOBXStream.MoveTo(startPos)
set toRead = charLimit
if toRead > remain {
set toRead=remain
}
set tSC=tStream.Write(srcOBXStream.Read(toRead))
set remain=remain-toRead
set startPos=startPos+toRead
}
set tSC=tStream.Write("|")
set obxSegment=##class(EnsLib.HL7.Segment).%New()
set obxSegment.SegType="2.5:OBX"
set tSC=obxSegment.StoreRawDataStream(tStream)
set tSC=target.setSegmentByPath(obxSegment,"OBXgrp("_k1_").OBX")
}
}
]]></code>
</transform>
}
}
Para desarrollar y probar esto, utilicé los plugins de VSCode para InterSystems porque las herramientas de prueba de integración no podían manejar el tamaño del mensaje.
También añadiré que, para enviar HL7 sobre HTTPS a InterConnect de Epic, fue necesario crear una clase HTTP personalizada y enviar el tipo de contenido personalizado x-application/hl7-v2+er7.
Buenos días,
En una integración que estamos haciendo entre dos sistemas recibos un ORU_R01 con los datos de un monitor. Lo recibimos mediante una llamada a nuestro webservice en formato XML.
🙂 Buenos días comunidad.
Me gustaría compartir con ustedes, en este artículo, una manera muy práctica, de obtener información relevante de todos los Namespaces de un Entorno. ¿Para qué?. Pues por ejemplo para uno de los casos de uso que más nos encontramos los desarrolladores con respecto a Healtshare: el desafío de necesitar crear 1 servicio, y la odisea de ir entorno a entorno, namespace a namespace, buscando si el puerto XYZAB está libre o no... 🙃
Esta demostración tiene una producción de interoperabilidad con 16 elementos.
La primera parte de esta demostración consiste en enviar un archivo HL7 SIU que será transmitido a los otros 2 flujos HL7 (HTTP y TCP), y transformado y transmitido al servidor Kafka. Los flujos HTTP y TCP transformarán los mensajes HL7 del mismo modo antes de enviarlos también a Kafka.
Recientemente hemos subido a OpenExchange una pequeña aplicación que desarrollé hace un tiempo (y que @Jose-Tomas.Salvador mejoró y refinó) que suelo utilizar cuando necesito generar grandes volúmenes de mensajería HL7.
En este artículo vamos a ver como podemos utilizar el servicio de mensajería instantanea de WhatsApp desde InterSystems IRIS para enviar mensajes a diferentes destinatarios. Para ello deberemos crear y configurar una cuenta en Meta y configurar un Business Operation para enviar los mensajes que deseemos.
Veamos con más detalle cada uno de estos pasos.
Este es posiblemente el punto más enrevesado de toda la configuración, ya que deberemos configurar una serie de cuentas hasta poder disponer de la funcionalidad de mensajería.
Hola soy nuevo en HL7 y de momentos lo veo muy grande por sus versiones, sin embargo mi consulta es si es posible aplicar el HL7 a informacion de infraestructura de establecimientos de salud como personal, mobiliarios, cartera de servicios que ofrecen y otros.
Me pueden sugerir lectura para resolver mi duda.
De antemano Muchas gracias
¡Hola comunidad!
Quiero compartir con vosotros una solución interesante que os permitirá realizar pruebas de integración para vuestras aplicaciones sanitarias. Permitidme presentar Pandora, un software de pruebas de servidores FHIR diseñado por Fyrstain, que ofrece soluciones de vanguardia para pruebas de interoperabilidad sanitaria.
Hola a todos,
Me pregunto si es posible llamar a un BO desde una enrutador HL7 de acuerdo con un parámetro del mensaje HL7
Quiero decir,
De acuerdo con la identidad del laboratorio, quiero llamar a otro proceso TCP para recuperar información sobre análisis de sangre.
Estamos creando el BO usando este patrón.
LAB.BO.TCP. + nombre del laboratorio.
El nombre del laboratorio se almacena en la tabla de consulta T_LABORATORIOS
Intenté asignar el nombre a una variable y ponerlo en la instrucción "send", pero no funciona.
HL7 (Health Level 7) es un conjunto de especificaciones técnicas para el intercambio informatizado de datos clínicos, financieros y administrativos entre Sistemas de Información Hospitalaria (HIS). Estas especificaciones se integran de diversas formas en el conjunto de Normas oficiales americanas (ANSI) e Internacionales (ISO).
La L7 de HL7 indica que es una norma que opera en la capa 7, es decir, en la capa de aplicación, del modelo OSI. Esto significa que HL7 no tiene que tener en cuenta las consideraciones de seguridad en el intercambio, ni las de transporte de mensajes (de eso se encargan capas de nivel inferior como SSL/TLS para la seguridad o TCP para el transporte de datos, por ejemplo). Para ser más precisos, la capa 7 soporta las comunicaciones para los procesos y aplicaciones de usuario final y la presentación de datos para las aplicaciones de software orientadas al usuario. Al ser la capa más alta del modelo OSI, y la más cercana al usuario final, la capa 7 proporciona funciones específicas de la aplicación, como identificar la comunicación de los partners y la calidad del servicio entre ellos, determinar la disponibilidad de recursos, considerar la privacidad y la autenticación del usuario, y sincronizar la comunicación, así como conectar la aplicación con los niveles inferiores del modelo OSI.
Volviendo a la norma HL7, la versión 2 de HL7 (también conocida como Pipehat) se creó originalmente en 1989, pero se sigue utilizando y actualizando con frecuencia, lo que ha dado lugar a las versiones 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.5.1, 2.6, 2.7, 2.7.1, 2.8, 2.8.1, 2.8.2 y 2.9. Las normas v2.x son compatibles con versiones anteriores (por ejemplo, un mensaje basado en la versión 2.3 será entendido por una aplicación que admita la versión 2.6) y, en versiones superiores, se puede ver que se reservan algunos campos para ello.
A pesar de tener más de 30 años, HL7v2 sigue siendo la norma de interfaz sanitaria más utilizada con diferencia, según el portal HL7.org que indica:
Con el tiempo, las normas de la interfaz HL7 han logrado ayudar en gran medida a los proveedores sanitarios y a las organizaciones tecnológicas:
La norma se redactó a partir del supuesto de que un acontecimiento en el mundo real de la atención sanitaria crea la necesidad de que los datos fluyan entre los sistemas. El evento del mundo real se denomina el evento desencadenante.
Un evento desencadenante es un mensaje, o un bloque de datos intercambiado, que describe un evento que ya sucedió. La norma HL7v2 define los mensajes (y su contenido) enviados entre las entidades participantes en el ciclo de vida de la atención sanitaria. Hay varios tipos de mensajes HL7v2. Algunos de ellos se presentan en la siguiente tabla:
| Tipo | Contenidos |
|---|---|
| ADT | Admisión, descarga y transferencia |
| ORM | Entrada de pedidos |
| ORU | Resultado de observación |
| ORL | Resultado de la orden de laboratorio |
| MDM | Gestión de documentos médicos |
| DFT | Transacciones financieras detalladas |
| BAR | Registro de la cuenta de facturación |
| SIU | Información de horarios no solicitada |
| RDS | Dispensación de farmacia/tratamiento |
| RDE | Pedido codificado de farmacia/tratamiento |
| ACK | Mensaje de agradecimiento |
| CRM | Información sobre ensayos clínicos |
Según se actualizaba la norma y se incrementaban las versiones, aparecieron nuevos tipos de mensajes y algunos de ellos dejaron de utilizarse. Así, distintas versiones de la norma HL7v2 tienen un número diferente de mensajes soportados (que va en aumento). Por ejemplo, hay más de 200 mensajes HL7 diferentes disponibles para su uso en mensajes HL7 en la versión 2.8.
Ahora veamos los segmentos con más detalle.
Un segmento es una agrupación lógica de campos de datos. Los segmentos de un mensaje pueden ser obligatorios u opcionales. Pueden aparecer solo una vez en un mensaje o puede permitirse su repetición. A cada segmento se le asigna un nombre[...] Cada segmento se identifica mediante un código único de tres caracteres conocido como el ID del segmento.
En un mensaje HL7, cada segmento del mensaje contiene una categoría específica de información, por ejemplo, información del paciente o datos de la visita del paciente. Los diferentes tipos de mensajes HL7 contienen diferentes segmentos HL7. Para ser precisos, el tipo de mensaje determina los tipos de segmentos que se esperan en el mensaje. Al mismo tiempo, cada mensaje tiene como primer segmento el MSH, el cual incluye un campo que identifica el tipo de mensaje. Los tipos de segmento que se utilizan en un tipo de mensaje concreto se especifican mediante la notación gramatical de segmentos utilizada en las normas HL7. Por ejemplo, hay más de 170 segmentos en los mensajes HL7 de la versión 2.8.
En general, los segmentos tienen campos separados por el delimitador compuesto. Un campo puede tener subcompuestos (componentes) separados por el delimitador subcompuesto, y los subcompuestos pueden tener subsubcompuestos (subcomponentes) separados por el delimitador subsubcompuesto. Los delimitadores predeterminados son: salto de línea para el separador de segmentos, barra vertical (|) para el separador de campos, signo de intercalación (^) para el separador de componentes, ampersand (&) para el separador de subcomponentes y almohadilla (#) para el separador de truncamiento predeterminado. La virgulilla o "tilde de la ñ" (~) es el separador de repeticiones predeterminado. Cada segmento comienza con una cadena de 3 caracteres que identifica el tipo de segmento.
Para ser lo más flexibles posibles y lograr un consenso, los comités de HL7 se vieron obligados a definir muchos campos de segmentos como opcionales. El inconveniente de esta decisión es que no se puede estar seguro de que una información concreta vaya a estar presente en un mensaje determinado. Esta es una de las razones por las que un mismo mensaje puede variar significativamente de un proveedor a otro.
Además, como los mensajes HL7 se utilizan para comunicar todo tipo de información relacionada con la atención sanitaria a una variedad de sistemas distintos, a veces los mensajes HL7 deben contener datos personalizados que no pueden incluirse en ningún segmento definido para su tipo de mensaje. Por ello, la norma HL7 permite a los proveedores de sistemas crear un segmento Z con campos personalizados para transmitir estos datos.
Por costumbre, todos los segmentos personalizados comienzan con la letra Z. Por ejemplo, se podría crear un segmento ZPD para incluir información demográfica personalizada de los pacientes. Los segmentos Z pueden colocarse en cualquier parte de un mensaje HL7, sin embargo, normalmente se sitúan como el último segmento de un mensaje. Las aplicaciones que procesan mensajes HL7 normalmente se configuran para ignorar los segmentos Z de HL7 que no saben cómo manejar.
El bloque básico utilizado para crear o restringir el contenido de un campo de datos[...] A cada campo se le asigna un tipo de dato que define el dominio de valores del campo, es decir, los posibles valores que DEBE tomar. El tipo de datos DEBERÁ tener un tipo extraído de la lista de tipos de datos definidos[...] Los tipos de datos pueden ser primitivos o compuestos. Los tipos de datos primitivos consisten en una serie de caracteres como se especifica en el tipo de datos. Los tipos de datos compuestos están formados por un conjunto de componentes que a su vez están asignados a un tipo de datos, que de nuevo pueden ser tipos de datos primitivos o compuestos. En el caso de los tipos de datos compuestos, los componentes de un componente se denominan subcomponentes, y únicamente DEBERÁN tener asignados tipos de datos primitivos.
Cada campo definido en la norma tiene su tipo de dato. Pueden ser, por ejemplo, strings, tiempo, dinero, fecha, dirección, matrices y muchas otras cosas.
Además de los valores de los campos, definidos por los usuarios, también existen tablas de valores, definidas por la norma. Enumeran todos los valores válidos para los campos que utilizan esa tabla. Hay 4 tipos diferentes de esas tablas:
En los siguientes artículos, veremos algunos de los mensajes, sus segmentos y campos, y veremos algunos ejemplos.
Esto es todo por el momento. Si tenéis alguna pregunta o duda, podéis escribirla en los comentarios de esta publicación.
A lo largo de los años, me he encontrado con la necesidad de crear varios mensajes HL7 basados en un solo mensaje entrante. Por lo general, toman la forma de un pedido o son el resultado de un laboratorio. Cada vez que he afrontado el reto, he intentado empezar de cero, con la convicción de que el intento anterior podría haberse hecho mejor.
Recientemente, volvió a surgir la necesidad y pude crear una solución de la que no me avergonzaba. Mi principal preocupación era que siempre me encontraría enterrado en un BPL, o usaría ObjectScript e intentaría editar mensajes usando el método SetValueAt para la clase de mensaje HL7.
Problema
Cuando el Sistema A procesa múltiples pedidos para un solo paciente, el resultado vendrá en un solo mensaje con ORCgrp repetido con los segmentos OBR y OBX contenidos en este. El sistema B solo puede recibir un único OBR por mensaje.
Recibo un query del analizador (QBP^Q11) al que le contesto con un ACK (RSP^K11) y un OML^O33. Hata aquí, todo correcto, pero el analizador me envia un ACK(ORL^O34) al que desde ENSEMBLE, por defecto, se le contesta con otro ACK (ACK^O33). Es este último ACK que yo no quiero enviar, pero no hay manera de quitarlo.
¿Se puede evitar enviar los ACK's por defecto en ENSEMBLE?
Gracias
Hola Desarrolladores,
Nunca será más fácil crear una esquema relacional de tu repositorio FHIR que te permita construir sistemas analíticos y de soporte a las decisiones:
Fácil de usar HL7v2 a FHIR, CDA a FHIR, FHIR a HL7v2 como un Servicio.
El objetivo de este proyecto es ofrecer una API REST que pueda convertir fácilmente varios formatos de salud. Publica el formato deseado en el cuerpo REST, obtén la respuesta en el nuevo formato.
SaaS Offer : https://aws.amazon.com/marketplace/pp/prodview-q7ryewpz75cq2
Video : https://youtu.be/lr2B7zSFkds
Clona este repositorio
git clone https://github.com/grongierisc/iris-healthtoolkit-service.git
Docker
docker-compose up --build -d
POST http://localhost:32783/api/hl7/fhir
POST http://localhost:32783/api/fhir/hl7/adt
POST http://localhost:32783/api/fhir/hl7/oru
POST http://localhost:32783/api/fhir/hl7/vxu
POST http://localhost:32783/api/cda/fhir
GET http://localhost:32783/api/fhir/metadata
ADT_A01, ADT_A02, ADT_A03, ADT_A04, ADT_A05, ADT_A06, ADT_A07, ADT_A08, ADT_A09, ADT_A10, ADT_A11, ADT_A12, ADT_A13, ADT_A17, ADT_A18, ADT_A23, ADT_A25, ADT_A27, ADT_A28, ADT_A29, ADT_A30, ADT_A31, ADT_A34, ADT_A36, ADT_A39, ADT_A40, ADT_A41, ADT_A45, ADT_A47, ADT_A49, ADT_A50, ADT_A51, ADT_A60
BAR_P12
MDM_T02, MDM_T04, MDM_T08, MDM_T11
OMP_O09
ORM_O01
ORU_R01
PPR_PC1, PPR_PC2, PPR_PC3
RDE_O11
SIU_S12, SIU_S13, SIU_S14, SIU_S15, SIU_S16, SIU_S17, SIU_S26
VXU_V04
El proyecto funciona con el diagrama dinámico: SDA.
El SDA (Summary Document Architecture) es el Formato de Datos Clínicos de InterSystems.
Las correspondencias SDA <-> FHIR se pueden consultar aquí, y las de CDA -> SDA aquí.
Me permito adjuntar un documento que describe un producto que he desarrollado llamado NiPaRobotica Pharmacy. Se trata de una interfaz que desarrollé, que acepta solicitudes para dispensar a farmacias y convierte las líneas de pedido en diálogos de dispensación que se envían a los robots de las farmacias. Implementé la interfaz en 3 farmacias de hospitales, dos de las cuales tenían 6 robots que se organizaron de tal manera que las rampas de dispensación canalizaban los medicamentos hasta los mostradores de los farmacéuticos que atendían en las ventanillas a 1 200 pacientes al día. Los robots disminuyeron el tiempo promedio de espera de 2 a 1 hora.
Después, implementé la interfaz en 6 sitios construidos específicamente en lugares cercanos a las viviendas de los pacientes con enfermedades crónicas como tuberculosis, VIH, diabetes, epilepsia, hipertensión y asma. El propósito de este proyecto fue "Llevar los medicamentos al paciente". Estos sitios cuentan con 6 Unidades de Dispensación Farmacéutica (PDU) similares a los cajeros automáticos, que disponen de una interfaz que permite al paciente comunicarse con un centro de asistencia telefónica farmacéutica. En el interior de cada PDU hay un gran robot que contiene varios miles de medicamentos. Mi aplicación envía una instrucción de dispensación al robot, que dispensa el artículo en una banda transportadora que lleva el medicamento hasta situarlo debajo de una impresora. A la impresora llega el contenido de una etiqueta farmacéutica con el nombre del paciente, las instrucciones de administración y otras notas. La impresora coloca y pega la etiqueta al envase del medicamento. El artículo se desplaza un poco más y una esponja presiona la etiqueta para fijarla con mayor firmeza al envase. La banda transportadora pasa el artículo a un contenedor de la PDU y, una vez que se suministran todos los artículos, el paciente puede abrir una ventanilla de la PDU y recoger los artículos. Lo más importante de este proyecto es que eliminó la necesidad de que los pacientes tengan que faltar al trabajo, recorrer largas distancias hasta la clínica donde se hace el seguimiento de su estado de salud, recoger sus medicamentos y volver a casa. Ubicar estos sitios en los vecindarios donde viven los pacientes permite que puedan acudir a cualquiera de estos sitios y recoger sus medicamentos en el camino hacia o de vuelta del trabajo.
Desde el final de la época victoriana se han producido muy pocos cambios en el mundo de las farmacias. Los ingredientes ahora son más especializados y, en muchos casos, permiten salvar vidas. La penicilina, las vacunas, los analgésicos, las terapias contra el cáncer y las inmunoterapias han modificado nuestra capacidad de tratar enfermedades que históricamente habrían sido letales para los pacientes. Sin embargo, el proceso de dispensación de esos medicamentos ha permanecido estancado en las profundidades de las farmacias de los hospitales o de las farmacias de barrio que venden más cachivaches que medicamentos. La aplicación puede hacer mucho más que transferir las solicitudes de dispensación desde la aplicación farmacéutica a los robots, y estas funciones se detallan en el documento. La aplicación ha sido modificada para admitir los mensajes FHIR relacionados con el inventario, las solicitudes y respuestas sobre medicamentos y los certificados de los mismos. El documento viene en formato PDF.
En este artículo demostraré lo siguiente:
¡Hola desarrolladores!
Os traemos un nuevo vídeo, ya disponible en el Canal de YouTube de la Comunidad de Desarrolladores en inglés.
Es la grabación de una de las ponencias realizadas en la Convención Anual de InterSystems del año pasado, así que el idioma del vídeo es el inglés. Pero recordad que podéis activar los subtítulos en inglés, por si os resulta más fácil entender el vídeo leyendo el texto.
En el vídeo, @Patrick Jamieson nos enseña cómo buscar recursos FHIR con una variedad de opciones de consulta:
¡Hola Comunidad!
Os traemos un nuevo vídeo, ya disponible en el Canal de YouTube de la Comunidad de Desarrolladores en inglés.
Es la grabación de una de las ponencias realizadas en la Convención Anual de InterSystems del año pasado, así que el idioma del vídeo es el inglés. Pero recordad que podéis activar los subtítulos en inglés, por si os resulta más fácil entender el vídeo leyendo el texto.
Posiblemente te hayas encontrado con esto y no supiste cómo evitarlo; o tal vez ni siquiera te diste cuenta...
Pero cuando se tienen componentes empresariales de la Producción de Interoperabilidad TCP (por ejemplo, un business service HL7), probablemente tienes (dependiendo de tu configuración de StayConnected) muchas entradas en el Registro de Eventos (Event log) de tipo Info. Cada entrada registraría una conexión o desconexión.
Por ejemplo:
¡Hola Comunidad!
Hemos grabado el webinar que hicimos ayer y lo hemos subido al canal de YouTube de la Comunidad de Desarrolladores en español. Si os perdisteis el webinar o lo queréis volver a ver con más detalle, ya está disponible la grabación!
Ricardo Paiva es un experto en interoperabilidad o, lo que es lo mismo, en la integración inteligente de procesos de negocio. Así que, si queréis saber cómo puede FHIR convivir e integrarse con otros protocolos... ¡no os perdáis el vídeo!
¡Hola Comunidad!
Os traemos un nuevo vídeo, ya disponible en el Canal de YouTube de la Comunidad de Desarrolladores en inglés.
Es la grabación de una de las ponencias realizadas en la Convención Anual de InterSystems del año pasado, así que el idioma del vídeo es el inglés. Pero recordad que podéis activar los subtítulos en inglés, por si os resulta más fácil entender el vídeo leyendo el texto.
¡Hola Comunidad!
Os traemos un nuevo vídeo con subtítulos en español: Cómo trabajar con Perfiles FHIR y recursos de compatibilidad cuando se crean aplicaciones FHIR en InterSystems IRIS for Health:
⏯ Cómo trabajar con Perfiles FHIR en InterSystems IRIS for Health
Demo lista para usar de un servidor FHIR con IRIS for Health 2020.2:
Clona este repositorio
git clone https://github.com/grongierisc/FHIR-HL7v2-SQL-Demo.git
Docker
docker-compose up --build -d
Puedes utilizar la configuración de postman en misc/fhirhl7v2demo.postman_collection.json
Utiliza UX en http://localhost:4201
Inicio de sesión/Contraseña: SuperUser/password
3 pasos para utilizarla:
Haz clic en la flecha izquierda que está entre IRIS y la ambulancia.
Esto abre las siguientes ventanas:
Desde aquí se pueden importar muestras desde este directorio en el repositorio de Git:
sampleFiles
Elige uno y haz clic en enviar.
Desde aquí puedes hacer clic en Message Trace:
Selecciona el primero:
Aquí puedes ver la transformación preparada entre HL7v2, SDA y FHIR.
Haz clic en la flecha entre IRIS y el FHIR client:
El pequeño swagger te da la oportunidad de consultar en FHIR el repositorio lleno desde el mensaje HL7v2 o desde el FHIR client.
Por ejemplo :
Haz clic en la flecha que está entre IRIS y SQL client:
Desde aquí se pueden ver todos los recursos FHIR en una estructura relacional de SQL. Debe quedar claro que esta estructura SQL puede cambiar sin previo aviso. Dicha estructura no está documentada y su uso no tiene el respaldo de InterSystems.
¡Hola desarroladores!
Os traemos el noveno episodio de Data Points, el podcast de InterSystems en inglés.
Es la segunda parte de la entrevista con @Russell.Leftwich. En ella, @Adam.Coppola6950charla con Russ sobre algunas de las tecnologías de InterSystems que desempeñan un papel en los conceptos comentados en la parte 1 y también comentan las aplicaciones más modernas de FHIR.
Tras la entrevista con Russ, se une a la charla @Jenny Ames, para hablar sobre los FHIR Dev Days, el evento sobre FHIR más importante del mundo. ¡Dadle al play!