Buscar este blog

Google+ Followers

Seguidores

Vistas a la página totales

martes, 31 de julio de 2018

The Sounds of IBM: IBM Q

¿Qué es un qubit?


Un cúbit o bit cuántico (quantum bit o qubit). Si la computación clásica se rige por el sistema binario, compuesto de bits, la cuántica lo hace a través de qubits. Un qubit es un contenedor de información que se puede describir con dos números. 

Las partículas que han interactuado en algún momento retienen un tipo de conexión y pueden enredarse en pares, en un proceso conocido como correlación. Conocer el estado de espín de una partícula entrelazada, arriba o abajo, le permite a uno saber que el giro de su compañero está en la dirección opuesta. Aún más sorprendente es el conocimiento de que, debido al fenómeno de la superposición, la partícula medida no tiene una sola dirección de giro antes de ser medida, sino que está simultáneamente en un estado tanto de giro como de giro hacia abajo. El estado de giro de la partícula que se mide se decide en el momento de la medición y se comunica a la partícula correlacionada, que asume simultáneamente la dirección de giro opuesta a la de la partícula medida. Este es un fenómeno real (Einstein lo llamó "acción espeluznante a distancia"), cuyo mecanismo no puede, hasta ahora, ser explicado por ninguna teoría, simplemente debe ser tomado como dado. El enredo cuántico permite que los qubits que están separados por distancias increíbles interactúen entre sí de forma instantánea (sin limitarse a la velocidad de la luz). No importa cuán grande sea la distancia entre las partículas correlacionadas, permanecerán enredadas siempre que estén aisladas.


"Uno puede decir de un bit que es 01, y solamente necesitas un número. Para un qubit, se necesitan dos números. Entonces, un qubit, en estado general, tiene una combinación lineal de 0 y 1. Delante del estado 0 del qubit, tiene un número, y delante del 1 tiene otro número. Esos números pueden ser positivos o negativos, pueden incluso ser números complejos".


Referencias
https://www.infotechnology.com/internet/Que-es-Qubit-la-alternativa-argentina-y-legal-a-Netflix-20150325-0003.html
https://whatis.techtarget.com/definition/qubit

Computación Cuántica

La computación cuántica y un nuevo récord mundial en simulaciónUn grupo de investigadores en Australia logró una potencia de 60 qubits en una computadora clásica. El procesamiento y almacenamiento de datos podría mejorar y alcanzar dimensiones impensadas en el futuro.
La computación cuántica es un paradigma de computación distinto al de la computación clásica. Se basa en el uso de cúbits en lugar de bits, y da lugar a nuevas puertas lógicas que hacen posibles nuevos algoritmos.

Científicos de la Universidad de Melbourne, en Australia, establecieron recientemente un nuevo récord mundial en simulación de computación cuántica, logrando una potencia de 60 qubits en una computadora clásica. El resultado es revelador y ha demostrado la capacidad de procesamiento posible, que equivale a la de alrededor de 18.000 Petabytes (o más de 1.000 millones de laptops).

La investigación fue encabezada por Lloyd Hollenberg, titular de la cátedra Thomas Baker de la Universidad de Melbourne. El profesor, líder del equipo de físicos, es director adjunto del Centro de Computación Cuántica y Tecnología de Comunicaciones. 

Comprender las implicancias de estos resultados es complejo. Interviene la física y la matemática y vale la pena intentarlo porque es el futuro de la computación. Se trata de una mejora a dimensiones impensadas de la forma en la que hoy se almacena y procesa la información. 

La potencia de los ordenadores cuánticos, al igual que la de los ordenadores convencionales, se mide en unidades de procesamiento, que no son más que átomos individuales. En el caso de los ordenadores cuánticos, se mide en bits cuánticos o qubits. A mayor cantidad de qubits, más rápido funcionan.

Referencias

Mirth Connect

Mirth es un motor con interfaz HL7 de plataformas cruzadas de código abierto que permite el envío bidireccional de mensajes HL7 entre sistemas y aplicaciones sobre múltiples capas de transporte. Utilizando un bus framework de servicio empresarial y una arquitectura orientada a canales, Mirth permite el filtrado de mensajes, el transformado  y el enrutamiento de los mismos en base a una reglas definidas por el usuario

Para integrar los servicios con los sistemas HL7 se debe implementar una capa de adaptación para transformar los mensajes entre el dominio de la aplicación y el del dominio de HL7. Mirth hace que este paso sea fácil proporcionando el framework para la conexión de sistemas dispares con los protocolos establecidos en los adaptadores y las herramientas de transformación de mensajes.
Mirth utiliza una arquitectura basada en canales para conectar los sistemas con otros sistemas HL7. Los canales consisten en terminales (de entrada y de salida), filtros, y transformadores. Múltiples filtros y una cadena de transformadores se pueden asociar con un canal. La interfaz web de Mirth permite la reutilización de filtros y transformadores en múltiples canales. 
Los terminales se utilizan para configurar las conexiones y los detalles de los protocolos. Los terminales de entrada se utilizan para designar el tipo de “listener” para los mensajes de entrada, como por ejemplo TCP/IP o un servicio web. Los terminales de salida se utilizan para designar el destino de los mensajes de salida, como por ejemplo a una aplicación servidora, una cola JMS, o una base de datos. 

 Características
Amplia variedad de conectores. Mirth puede configurarse para escuchar y enviar mensajes HL7 y conectar una variedad de protocolos:
Bases de datos (MYSQL, Postgres, Oracle, MS SQL, ODBC)
Archivos (sistema de archivos locales y remotos)
JMS 
FTP/SFTP
SOAP (sobre HTTP)
Plataforma cruzada. Mirth soporta la mayoría de sistemas operativos (aquellos que soporten la máquina virtual de Java en su versión 1.5).
Creación o utilización de filtros y perfiles de validación. El sistema de filtrado de Mirth permite elegir el tipo de mensajes que se aceptan y se encaminan. Múltiples destinatarios se pueden seleccionar automáticamente especificando los filtros HL7.
Creación o utilización de transformadores. Una interfaz de Mirth permite la creación de transformadores y mapeos de datos HL7. Simplemente seleccionando y arrastrando con el puntero del ratón fragmentos de mensajes HL7 creamos mapeos, o utilizar una variedad de funciones para hacer consultas en la bases de datos, enviar correos electrónicos. Las transformaciones disponibles son las siguientes:
Transformador de mapeo: Mapea los datos desde los mensajes entrada hasta las variables.
Transformador de script: Ejecuta scripts definidos en los mensajes (por ejemplo, JavaScript, Python, Tcl).
Generador de mensajes HL7: construye mensajes HL7 a partir de una fuente de datos.
Transformador XSLT: Ejecuta transformaciones XLS sobre mensajes de entrada HL7 v3 o XML.
Todos los mensajes y transacciones se registran en una base de datos interna. Se puede configurar para que se genere de forma automática respuestas de reconocimiento HL7 (ACK).
Motor ESB robusto. Mirth está basado en el motor Mule ESB para proporcionar velocidad, estabilidad y seguridad en un entorno flexible. 

Referencias:
http://www.mirthproject.org/

Guía de implementación HL7 CDA R2: IHE para Consolidación Historia Clínica.

El estándar de arquitectura de documentos clínicos (C-CDA®) consolidado de HL7 es un estándar de documentos basado en XML que especifica la estructura y semántica de los documentos clínicos como resúmenes de altas e informes de imágenes que se intercambian entre los proveedores de atención médica y los pacientes. Una de las seis características de un documento C-CDA es la legibilidad humana. El proceso por el cual estos documentos se hacen legibles para el ser humano se llama renderización. Uno de los requisitos de C-CDA es que todo el contenido clínico relevante de un documento C-CDA debe estar presente (y, por lo tanto, renderizable) en forma humana legible.

Actualmente, muchos médicos se sienten frustrados con la usabilidad de los documentos C-CDA porque se basan en el sistema EHR basado en documentos C-CDA que se envían / ​​reciben. Luego, los proveedores deben buscar y clasificar todos los datos para encontrar la información clínica esencial y relevante que desencadenó el evento clínico para el cual se creó el documento C-CDA. Los proveedores de EHR, por numerosas y admirables razones, generalmente brindan más información de la que los médicos quieren, a veces incluyendo el historial médico completo del paciente. Un espectador que haga que la información relevante sea más fácil de ver le ahorrará tiempo a los médicos y se asegurará de que no pierdan la información que necesitan para tomar decisiones.

La transformación digital es un tema recurrente en los medios generalistas o especializados de todo el mundo. Todos los sectores y ámbitos sociales se ven impactados con mayor o menor intensidad por una ola transformadora de la cual los principales diarios, revistas y sitios web de información de todo el mundo dan cuenta. Por supuesto, la transformación digital también ha llegado al sector hospitalario. A veces, incluso, sin que los propios actores sean muy conscientes del impacto y profundidad de los cambios que vienen. En este sentido, hay que entender la dimensión real del concepto de transformación digital.

Referencias
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=258
https://www.scribd.com/document/270920476/Anexo-12-Documento-de-Tecnico-de-Mensajeria-Hl7-v3-Historia-Clinica-Electronica-Compartida-2015c002
http://www.minsa.gob.pe/renhice/documentos/Pre2Jor/02%20Diego%20L%C3%B3pez%20-%20Documentos%20Cl%C3%ADnicos%20Electr%C3%B3nicos%20CDA.pdf
https://issuu.com/arcangelrafaellauraserafin/docs/6.1_sistemas_de_informacion_en_salu
http://www.hl7latam.org/HL7LATAMNews/N4/N4.pdf
http://www.hl7spain.org/wp-content/uploads/2011/06/GuiaElementosMinimosCDA.pdf
http://hiba.hospitalitaliano.org.ar/infomed/index.php?contenido=ver_curso.php&id_curso=18989#.W16r7dJKhEY
http://www.achisa.cl/campus2/?lang=es
https://www.youtube.com/watch?v=OZ5w3vBMJqE
https://www.healthdataanswers.net/hl7-c-cda-rendering-tool-challenge/

Cobertura Universal de Salud (CUS)



Es sistema de atención basado en relacionamiento con los pacientes y la comunidad, donde el paciente va a estar identificado, como en los otros subsistemas de cobertura –privado y de las obras sociales-, y este es el concepto de cobertura universal que permitirá que todos los habitantes del país con sólo tener el documento de identidad estén identificados y sepamos cuál es su cobertura.

El Objetivo de la CUS es el de garantizar el derecho a la salud para unas 15 millones de personas sin prepaga ni obra social. El programa pretende poner al alcance del paciente del sector público un trato equivalente al brindado en el sector privado: turnos online y telefónicos, línea 0800 para derivaciones y acceso a atención primaria y especializada, evitándose las habituales colas de madrugada en los hospitales y previniendo el malestar que ello genera a los profesionales y enfermos. 


El plan pretende ir reduciendo el modelo actual, basado en el uso de papel, haciendo que cada paciente tenga una historia clínica digitalizada, con acceso desde cualquier punto del país. Lo que permitirá esto es que los argentinos puedan atenderse en urgencias, además de recibir tratamientos o cirugías en cualquier parte, sin necesidad de trasladarse. 




Otro de los puntos importantes por los que se impulsó este programa tiene que ver con dar una solución a la población socialmente más vulnerable, que trabaja en la informalidad, está desocupada o no tiene acceso a obras sociales por no contar con recursos para ello. La prueba piloto del plan comenzó la semana pasada en la ciudad de Guaymallén, en Mendoza, y se prevé que se extienda en los próximos meses a todo el país. 




El empadronamiento al nuevo sistema se realizará presentando solo el DNI. Al ser parte del programa, los pacientes tendrán un médico de cabecera asignado, lo que permitirá hacer un seguimiento particularizado del estado de salud de cada uno. Con respecto a la distribución de medicamentos, el CUS reemplaza al programa Remediar, por lo que los remedios serán entregados en los mismos puntos pero con la cobertura del nuevo plan. 

Desde el Gobierno aseguraron que las prestaciones no se cobrarán, desmintiendo versiones de la oposición. Además, afirmaron que solamente se pagará cuando el paciente tenga cobertura privada y se atienda en un hospital público, caso en el que se le va a realizar el cobro correspondiente a su prepaga u obra social. 

Cabe destacar que la inversión, que cuenta con aportes del Gobierno nacional, rondaría los US$ 1.000 millones del Fondo Solidario de Redistribución perteneciente a las obras sociales sindicales, y será administrado por la 

Superintendencia de Servicios de Salud. La creación del plan que ahora comenzó a implementarse se oficializó en agosto del año pasado mediante el Decreto 908/2016, en el cual se informó que se pretende “garantizar el acceso a la salud de toda la población, afianzando los principios de equidad y solidaridad”.

CURSOS VIRTUALES EN ESPAÑOL DE HL7, FHIR, MIRTH CONNECT, DE HL7

Los cursos virtuales de comienzan:
Introducción a HL7 el 13 de septiembre
Introducción a FHIR el 20 de septiembre
Introducción a Mirth Connect el 27 de septiembre.
Para mayor información ingresar a:http://hl7.org.ar/
Informes e inscripción: info@hl7.org.ar

Creación de un nuevo recurso HL7 FHIR Patient Resource


Para crear un nuevo recurso para el paciente en un servidor FHIR usamos los recursos REST, esto permite crear nuevos recursos de una de dos maneras: HTTP POST y HTTP PUT. HTTP PUT se usa cuando conocemos el identificador de un recurso determinado y HTTP POST se usa cuando el servidor genera el identificador. En el caso de HL7 FHIR, todos los identificadores de recursos se generan en el servidor, por lo que no podemos usar HTTP PUT y debemos usar HTTP POST. De acuerdo con la documentación HL7 FHIR para la creación de recursos, simplemente PUBLICAMOS el documento JSON en el recurso raíz. Suena bastante simple, podemos probar esto fácilmente usando cualquier cantidad de herramientas:

1) CURL - Utilidad de línea de comandos que le permite realizar solicitudes HTTP
2) Advanced REST Client: una extensión de Google Chrome que le permite realizar solicitudes HTTP con una interfaz de usuario agradable.

Comenzaré con Advanced REST Client, ya que es más fácil trabajar con él. Vamos a ser mediante la creación de un recurso de muestra del paciente en JSON:


  "resourceType" : "Patient",
  "text" : { 
    "status" : "generated",
    "div" : ""
  },
  "identifier": [{
    "use" : "usual",
    "label" : "MRN",
    "system" : "urn:oid:0.1.2.3.4.5.6.7",
    "value" : "654321"
  }],
  "name" : [{
    "use" : "official",
    "family" : ["Donald"],
    "given" : ["Duck"]
  }],
  "gender": {
    "coding" : [{
      "system" : "v3/AdministrativeGender",
      "code" : "M",
      "display" : "Male"
    }]
  },
  "maritalStatus" : {
    "coding" : [{
      "system" : "v3/MaritalStatus",
      "code" : "M",
      "display" : "Married"
    }]
  },
  "birthDate": "1944-11-17",
  "deceasedBoolean" : false, 
  "active": "true" 
}

Para crear nuestro recurso Patient en el servidor usamos Eel "Cliente de servicios Web RESTful", que es un pluging del google Chrome Advanced REST Client, permite enviarlo por correo postal al servidor de chispa accesible al público. Inicie el cliente REST avanzado e ingrese la siguiente URL:

http://spark.furore.com/fhir/Patient?_format=application%2fjson%2bfhir

Haga clic en el botón de radio "POST" y pegue el JSON anterior en la sección "Carga útil". Cambia el tipo de contenido a "aplicación / json" en el cuadro combinado y luego presiona el botón "Enviar". Si todo va bien, debería ver la URL del recurso recién creado en el encabezado de respuesta de la ubicación:
Puede verificar que, de hecho, se puede acceder al paciente recién creado haciendo una solicitud GET para el URI de recursos:

 Una cosa que debería mencionar aquí es que dejé la propiedad text.div vacía. Creo que se supone que HTML debe ir allí, que produce una representación humana comprensible de este recurso. No me molesté con eso por el momento, ya que esto es solo un pico y realmente no necesito esta funcionalidad.

Ahora que sabemos cómo crear un recurso para el paciente, tenemos que ver cómo podemos buscar los existentes que podemos usar en lugar de crear siempre uno nuevo.



Referencias
http://blogs.infor.com/healthcare/2018/04/fhir-way-finish-line.html
https://www.3mhisinsideangle.com/blog-post/learned-hl7-fhir-clinician-without-losing-mind/
https://www.intersystems.com/pulse-blog/tag/fhir/

¿Cómo mapear un mensaje HL7 V2.X a FHIR?


Vermos como mapear un mensaje ORU HL7 versión 2.4 (técnicamente un ORU ^ R01 que contiene un resultado de radiología) y generar un mensaje FHIR que para enviar a un servidor FHIR, que luego guardará la Observación en su base de datos.

Para mantener las cosas razonablemente simples (aunque sean realistas), tendremos un solo segmento OBX con el resultado. En la práctica, es probable que tengamos varios segmentos OBX, cada uno de los cuales sería un recurso de observación separado en nuestro mensaje (más segmentos NTE y otros). Y tenga en cuenta que algunos de los segmentos no se utilizan; solo estamos sacando los datos que necesitamos para completar nuestro mensaje. Si estuviéramos planificando una transformación de '2 vías', es decir, manteniendo la capacidad de recrear el mensaje v2 del FHIR, entonces probablemente necesitaríamos capturar más datos, y probablemente también necesitemos algunas extensiones.

En esta publicación, vamos a considerar la creación del mensaje FHIR que contiene la observación de Radiología (y los recursos de apoyo); podemos considerar los aspectos de arquitectura y flujo de trabajo de procesar el mensaje posteriormente en otra publicación.

Y recuerde que HL7 v2 se puede usar de muchas maneras diferentes (si ha visto una implementación de v2 ...) por lo que este análisis es altamente específico para este caso de uso.

Aquí hay una muestra de cómo se vería el mensaje v2:

MSH|^~\&|Amalga HIS|BUM|New Tester|MS|20111121103141||ORU^R01|2847970-201111211031|P|2.4|||AL|NE|764|ASCII|||
PID||100005056|100005056||Dasher^Mary^""^^""|""|19810813000000|F||CA|Street 1^""^""^""^34000^SGP^^""~""^""^""^""^Danling Street 5th^THA^^""||326-2275^PRN^PH^^66^675~476-5059^ORN^CP^^66^359~-000-9999^ORN^FX^^66^222~^NET^X.400^a@a.a~^NET^X.400^dummy@hotmail.com|123456789^WPN^PH^^66|UNK|S|BUD||BP000111899|D99999^""||CA|Bangkok|||THA||THA|""|N
PV1||OPD   ||||""^""^""||||CNSLT|||||C|VIP|||6262618|PB1||||||||||||||||||||||||20101208134638
PV2|||^Unknown|""^""||||""|""|0||""|||||||||||||||||||||||||||||HP1
ORC|NW|""|BMC1102771601|""|CM||^^^^^""|||||||||""^""^^^""
OBR|1|""|BMC1102771601|""^Brain (CT)||20111028124215||||||||||||||||||CTSCAN|F||^^^^^ROUTINE|||""||||||""|||||||||||^""

Dentro del 7Edit con el mapeo en arbol lo vemos asi:

Con mas detalle vemos los segmentos en el arbol
Para mapear este mensaje ORU, necesitamos utilizar varios recursos de FHIR, para este mensaje necesitamos usar los recursos:

  • MessageHeader
  • Observation
  • Patient (sujeto de la observación)
  • Provider (es el que realiza la observación)


En el siguiente dibujo vemos como es la estructura de un bundle (empaquetado) de FHIR
Message1
Como base del análisis, haremos las asignaciones que están en la especificación FHIR (en la parte superior de cada página de recursos hay pestañas para el contenido, ejemplos, definiciones formales, asignaciones y perfiles)

Así que aquí es cómo podemos crear cada recurso, con algunas notas sobre las elecciones que debemos hacer.

Bundle

El Bundle o paquete es un conjunto de unidades atómicas (recursos), y el ID del paquete es un ID global único (por ejemplo, un UUID) que representa el mensaje FHIR como un todo. Esto es distinto de la ID de MessageHeader, que es importante cuando se trata de errores que ocurren durante la mensajería (consulte las especificaciones para una discusión sobre esto).

MessageHeader
Un mensaje FHIR es un paquete de recursos, con el recurso MessageHeader como primer recurso (y una etiqueta en el paquete). Hay una buena asignación entre MSH y MessageHeader:
ElementV2 segmentDescription
IdentifierMSH-10Message Control ID
TimestampMSH-7Message Date/time
EventMSH-9.2observation-provideDerived from the second component of the Message Type field. Its value comes from HL7 table 3
Source.nameMSH-3Sending application name
Source.softwareMSH-3 Sending application name
Source.endpointMSH-24Sending network address
Destination.nameMSH-5Receiving application
Destination.endpointMSH-25Receiving network address
dataReferences to the ‘root’ resource of the message.

El identificador lo establece el sistema de envío y debe ser único en el contexto del remitente. Idealmente única globalmente, pero no hay garantía de eso desde el lado v2. Desde la perspectiva de FHIR, debe ser único dentro de "la corriente de mensajes"; en la práctica, esperamos que sea único en el contexto del remitente; después de todo, es la forma en que coincidirán los reconocimientos con el mensaje.
El elemento de software es un campo obligatorio, y la asignación en la especificación sugiere usar el segmento SFT. Sin embargo, eso solo se introdujo en la versión 2.5, así que duplicaremos el source.name aquí.
El código del evento se define en la especificación FHIR (hay una lista más completa aquí). Estos no son los mismos que los v2, aunque como la "fortaleza" de la vinculación es que podríamos usar los v2 si quisiéramos. Sin embargo, hay un valor que se adapta a esta implementación, proporcionar observación, así que lo usaremos.
Los elementos entrante, autor y receptor nos permiten especificar individuos (u organizaciones) a partir de quienes se originó el mensaje, o para quién es. No necesitamos eso aquí, pero es bueno saber que está disponible si es necesario.
En este caso, el elemento de datos será una referencia a la Observación. Si tuviéramos varias observaciones, probablemente incluiríamos un recurso de Lista para agruparlas. Y, por supuesto, un mensaje puede ser mucho más complicado que eso.


Observation
Este es el recurso que contiene lo que realmente queremos representar, en este caso un resultado de radiología, y la observación es uno de los recursos más flexibles en el FHIR estable.

Aquí está la tabla de resumen de mapeo:

ElementV2 segmentcomment
nameOBX-3
valueStringOBX-5OBX-5 holds the actual value of the observation
interpretationOBX-8
commentsNTE-3See note below
appliesDateTimeOBX-14
issuedOBR.22
statusOBX-11Observation Result Status
reliabilityOBR-25
identifierOBX-21
subjectReference to the Patient
performerReference to the Practitioner
El nombre (o tipo) de observación (un resultado de radiología) se almacena en OBX-3. Es un tipo de datos CE en v2, que se asigna a un CodeableConcept en FHIR
El valor de la observación estará en el elemento Observation.value [x], donde [x] es uno de los tipos de datos FHIR especificados. En v2, hay al menos 3 campos que miraremos para decidir cómo obtener el valor.
OBX-2 es el tipo de Observación tal como se define en la tabla HL7 v2 0125. Para nuestro resultado de radiología, es probable que sea FT o ST y el tipo del elemento de valor [x] sea una cadena - haciendo el nombre completo del elemento valueString. Si estuviéramos construyendo un analizador genérico, entonces veríamos el valor de OBX-2 y lo usaríamos para decidir qué tipo de datos FHIR usar.
OBX-5 contiene el valor real de la observación. Los detalles de esto dependerán del tipo de datos como se discutió anteriormente, por supuesto ...
OBX-6 es las unidades del valor. No se aplica aquí, pero en muchas situaciones lo hará. Por ejemplo, si se tratara de una presión arterial sistólica, el tipo de datos sería Cantidad, que tiene un componente de unidades.
De acuerdo con la asignación en la especificación, cuando se emitió el informe, puede provenir de una serie de lugares diferentes, dependiendo de la fuente exacta y la naturaleza del mensaje. Iremos con OBR-22 (Fecha / hora de cambio de estado) para nuestro escenario.
La confiabilidad del resultado es un poco desafiante, y es un elemento obligatorio en el recurso de observación, por lo que no podemos ignorarlo. El mapeo en la especificación se refiere a OBX-8 (Banderas anómalas) y OBX-9 (Probabilidad), pero son más un reflejo del resultado dentro del rango esperado, en lugar de si el resultado puede ser confiable. OBR-25 (Estado del resultado) parece una mejor opción, así que iremos con eso.
Si hubo un comentario sobre el resultado, entonces se almacenará en un segmento NTE (o segmentos) separado inmediatamente después del OBX. No hay una referencia directa en v2 del OBX al NTE (o al revés); debe inferirse del hecho de que el NTE sigue al OBX.
También tenemos que pensar en lo que debe ser Observation.text, la narración legible para los humanos. Como se trata de un tipo de datos de cadena, y suponiendo que el tipo de datos v2 (OBX-2) era FT, incluiremos todo el valor en los elementos <pre> y tal vez agreguemos la fecha y los nombres de los autores allí también. Sospecho que una consideración adecuada de cómo generar narrativa es un tema completo en sí mismo, tal vez en otro momento.


Patient
En FHIR, el paciente es un recurso separado (tal vez ni siquiera en el mismo servidor que la observación), y la observación tendrá una referencia (como sujeto). Entonces, debemos encontrar al paciente en el servidor en el que esté almacenado y recuperar su url. También podríamos necesitar crear el paciente si no podemos encontrarlo, aunque esto dependerá de las políticas de la implementación, lo que podría requerir que el paciente exista primero.

La forma en que buscaremos un paciente utilizará el identificador del paciente del segmento PID. PID-3 tiene una lista de identificadores de pacientes que podemos usar, cada uno de los cuales es un tipo de datos CX, por lo que equivale al tipo de datos identificador FHIR. Necesitamos consultar el servidor del paciente para ver si el paciente ya existe, usando el identificador apropiado (basado en el espacio de nombres). Si existe, entonces tenemos la referencia. De lo contrario, podemos utilizar los datos en el segmento PID para crear un nuevo recurso para el paciente, si la política lo permite. Estos son los pasos:

Usando el identificador del mensaje v2, consulte el servidor FHIR de la siguiente manera:
GET [patientserver]/patient?identifier={identifier}

Si hay una coincidencia única, entonces tenemos la ID que podemos usar para el Observation.subject. (Y podemos colocar una copia del paciente dentro del paquete también)
Si hay más de una coincidencia, probablemente sea un error y deberíamos rechazar el mensaje o recibir intervención humana (nuevamente, habrá una política al respecto).
Si no hay coincidencias, el siguiente paso depende de si la tienda del paciente está en el mismo servidor que la observación.
Si es así, cree un nuevo recurso para el paciente utilizando los datos del segmento PID y asígnele un ID con un prefijo cid: (que le indicará al servidor que es un nuevo recurso para el paciente y lo guardará localmente, resolviendo la referencia a la Observación como lo hace).
Si el paciente está en un servidor separado, entonces necesitamos crear y guardar un paciente ahora, obteniendo una identificación del servidor a medida que se guarda. Luego podemos ubicar el recurso del paciente en el mensaje (junto con la ID correcta). Por supuesto, aquí hay preocupaciones transaccionales: ¿qué ocurre si salvamos al paciente, pero el resto del procesamiento del mensaje falla? Bueno, realmente no importa; la próxima vez que aparezca un mensaje con este identificador de paciente, encontraremos el que acabamos de crear, para que no se haga daño.
Tenga en cuenta que es posible descargar toda esta búsqueda al servidor utilizando la función de búsqueda interna de una transacción (hablamos de eso aquí), pero no estoy seguro de que la funcionalidad se aplique al procesamiento de mensajes y, en cualquier caso, no podemos Supongamos que todos los servidores tendrán esa funcionalidad, por lo que lo haremos por mucho.

Tener en cuenta que estamos asumiendo que el servidor que procesa el mensaje tiene la capacidad de crear recursos del paciente localmente. De lo contrario, tendremos que crear el paciente como un paso separado como lo hicimos con un servidor de paciente remoto. (Vamos a pensar en el procesamiento de mensajes con más detalle cuando pensamos en el flujo de trabajo en otra publicación)

Provider
La observación tiene un elemento ejecutante que es la persona / dispositivo que realizó la observación. En nuestro caso, este será un proveedor, aunque un dispositivo es otro uso común; pensaremos en las implicaciones de eso en otra publicación.

Las mismas consideraciones se aplicarán al Proveedor como lo hizo para el Paciente en términos de encontrar un recurso y proporcionarlo como una referencia a la Observación, pero hay un par de ganchos adicionales:

Hay más ubicaciones posibles en el mensaje v2 en las que podemos obtener información de "actor", y la que elijamos dependerá del tipo de mensaje (consulte la asignación en la especificación para ver algunas de las posibilidades).
Y dependiendo de cuál escojamos, es probable que tengamos menos información sobre el proveedor en nuestro mensaje, por lo que es más difícil crear uno si aún no existe en nuestro sistema (y la política local lo permite).
En nuestro caso elegiremos OBX-16 - observador responsable. Esto tiene la ventaja añadida de que el tipo de datos v2 para este campo es XCN (número de identificación compuesto extendido y nombre para personas), lo que significa que deberíamos tener los detalles suficientes para crear un recurso de proveedor si es necesario (siempre que todos los campos mensaje están llenos, por supuesto).

Conclusiones
Cuando comencé este ejercicio, asumí que el ejercicio de mapeo sería sencillo, y en un nivel alto, es razonable. Sin embargo, al igual que todas las implementaciones de v2, existe una gran cantidad de opciones para el mapeo, lo que tal vez no sea demasiado sorprendente dada la complejidad de la atención médica. Incluso si los proveedores proporcionan herramientas con asignaciones "estándar" y generación narrativa automatizada, espero que la mayoría de las implementaciones requieran un cierto "ajuste" de esas asignaciones para recursos individuales ...

¡Y muchas de las elecciones hechas en este post ciertamente pueden ser desafiadas!

La cuestión de la "política" surgió un poco: lo que deben hacer los sistemas en determinadas circunstancias, como los nuevos pacientes o en los que hay múltiples pacientes con el mismo identificador o qué hacer cuando no se puede encontrar un proveedor, también es más importante que Yo había anticipado.

Referencias
https://fhirblog.com/2014/10/05/mapping-hl7-version-2-to-fhir-messages/

lunes, 30 de julio de 2018

EDITORES JSON



JSON es la abreviatura de JavaScript Object Notation, y es una forma de almacenar información de una manera organizada y de fácil acceso. En pocas palabras, nos brinda una colección de datos legibles por humanos a los que podemos acceder de una manera realmente lógica.

Los editores JSON son herramientas que nos permiten trabajar con esta notación en forma mas sencilla que con otro tipo de editores. Algunos de los editores JSON disponibles son:

JSONEDITORONLINE.ORG
Este editor, Nos permite validar el documento, marcándonos el error en la línea en la que se encuentra. Es muy práctico podemos pegar un json sin formato (todo junto) y opcionalmente aplicar formato y nos lo mostrara por líneas y con su sangría como debe ser, para poder leerlo mejor. Y viceversa una vez que terminamos de trabajar con el json, podemos compactarlo. Hay un articulo en mas completo sobre este editor en https://hl7latam.blogspot.com/2018/07/editor-json-onlina.html

CODEBEAUTIFY.ORG
Muy similar al anterior, salvo que aquí podemos poner a todo lo ancho de la pantalla el editor. Pero en funciones aparentemente tiene las mismas.

JSON-GENERATOR.COM
Este editor es más avanzado, en el sentido que podemos generar json mediante “codigo” y hacer uso de bucles y funciones, aun no lo he usado, así que no puedo mencionar más al respecto.

OBJGEN.COM
Con esta herramienta, podemos generar código mediante la escritura delimitada por sangría, al mismo tiempo que definimos el tipo de dato de manera opcional.


Referencias
http://soyprogramador.liz.mx/editores-json-online/
https://www.copterlabs.com/json-what-it-is-how-it-works-how-to-use-it/
https://hl7latam.blogspot.com/2018/07/editor-json-onlina.html

CLIENTES REST


Un Cliente REST (Representational State Transfer) o testadores de API  son herramientas que nos permite armar y enviar peticiones REST para testear una comunicación entre cliente y servidor.
Sirven para ayudar a los desarrolladores para desarrollar y probar las API de servicios web RESTful con todos los métodos admitidos, como GET, POST, PUT, PATCH, DELETE.

La extensión es compatible con la autenticación básica HTTP, soporta múltiples cabeceras y el formato de respuesta. La extensión acepta application / json por defecto. De lo contrario, seleccione application / xml, tipo de material personalizado aceptable text / plain o comodín, o entrar.
Introduzca HTTP autenticación básica de información si el servidor requiere autenticación. Otros métodos de autenticación, como OAuth se apoyarán en el futuro.

Los Clientes REST  API mas comunes son:

Postman es un cliente de descanso que comenzó como un complemento de navegador Chrome pero recientemente salió con versiones nativas para Mac y Windows. En un nivel alto, puede usarlo para enviar una solicitud postal a su servidor web y le devuelve la respuesta. Le permite configurar todos los encabezados y cookies que espera su API, y luego verificar la respuesta cuando vuelva.

Karate DSL Karate permite crear una prueba que puede secuenciar llamadas a cualquier tipo de servicio web y afirmar que las respuestas son las esperadas.

SoapUI es una herramienta de prueba funcional sin cabeza del software SmartBear. Viene en dos sabores: versión gratuita de código abierto y versión Pro. Dado que la versión gratuita es de código abierto, en realidad puede obtener acceso al código fuente completo y modificar según sea necesario. La versión pro es más amigable para el usuario y tiene una funcionalidad adicional que incluye un editor de formularios, un asistente de afirmación para XPath y un generador de consultas SQL.

HttpMaster Es una herramienta de prueba y desarrollo web para automatizar las pruebas de sitios web y servicios. Se puede usar para probar servicios web RESTful y aplicaciones API. HttpMaster también te permite monitorear las respuestas de la API.

Rest-Assured es un lenguaje de código abierto Java específico del lenguaje (DSL) que hace que probar el servicio REST sea simple. Simplifica las cosas al eliminar la necesidad de usar un código de placa de caldera para probar y validar respuestas complejas. También es compatible con XML y JSON Request / Responses.

Advanced REST client Esta extensión de Google Chrome puede ayudar a los desarrolladores para desarrollar y probar las API de servicios web RESTful con todos los métodos admitidos, como GET, POST, PUT, PATCH, DELETE y OPTIONS.


Referencias:
https://www.joecolantonio.com/2017/05/16/12-open-source-api-testing-tools-rest-soap-services/
https://hl7latam.blogspot.com/search?q=cliente+rest
https://hl7latam.blogspot.com/2018/07/que-es-una-api-rest.html
https://hl7latam.blogspot.com/2018/06/que-es-una-resp-api.html
https://hl7latam.blogspot.com/2018/07/tutorial-como-construir-paso-paso-un.html
https://hl7latam.blogspot.com/2018/07/cliente-de-servicio-web-restful-plugin.html

EDITORES XML

Un editor de XML es una herramienta para facilitar la edición de XML. Esto se puede hacer con un editor de texto plano, con todo el código visible, pero los editores de XML han añadido facilidades como finalización de etiquetas y menús y botones para las tareas que son comunes en la edición de XML, sobre la base de datos suministrados con la definición de tipo de documento (document type definition o DTD) o el árbol XML.

También hay editores gráficos XML que ocultan el código en el fondo y presentan el contenido al usuario en un formato más fácil de usar, aproximándola a la versión renderizada o a la edición de formularios. Esto es útil para situaciones en las que las personas que no dominan el código XML necesitan introducir la información de los documentos basados en XML, tales como hojas de tiempo y los informes de gastos.

Hay muchos programas que usan XML para almacenar información. En otras palabras, puede abrir, crear y editar un archivo XML en cualquier editor de texto.

Los archivos XML son similares a los archivos HTML pero no son lo mismo, XML se usa para transportar datos mientras que HTML se usa para mostrarlo. Hay algunos programas que pueden leer y editar archivos XML, y elegimos cinco de los mejores. Eche un vistazo a sus conjuntos de características para ver cuál es la mejor para sus necesidades.

Algunos de ellos son:

SourceForge’s XML Tree Editor puede mostrar archivos XML como vistas de árbol, y el software también permite operaciones esenciales que incluyen agregar, editar e incluso eliminar nodos de texto junto con sus atributos..

XML Explorer es otra utilidad ligera y rápida que le permite ver archivos XML. Lo mejor de este software es que es capaz de manejar enormes archivos XML.


XML Notepad 2007 ofrece a los usuarios una interfaz simple y realmente intuitiva que permitirá a cualquier persona navegar y editar documentos XML. Podrá encontrar esta herramienta extremadamente útil en la tienda de Microsoft.

EditiX XML Editor es otro editor XML de alta calidad generado y editor XSLT que es compatible con Windows y otros sistemas operativos.

Essential XML Editor es un programa ligero para la edición de documentos XML basados en texto. Hay suficientes funciones clave incluidas en este editor para proporcionar a los usuarios todo lo que necesitan.


Oxygen XML Editor. A diferencia de otros editores que ofrecen todas las entradas disponibles (por ejemplo, todos los nombres de elementos definidos por el documento XML Schema), Oxygen muestra solo las entradas que son válidas en el contexto de edición actual. Por lo tanto, el documento XML siempre permanece válido y el usuario no necesita un conocimiento experto de la relación entre los elementos.

Referencias:

Editores de mensajes HL7


Los Editores de Menajes HL7 son  herramientas que nos sirven para leer, editar, recibir y enviar menajes HL7 V2.X, Hay editores disponibles para distintos sistemas operativos y tambien  los hay pagos propietarios y gratuitos.

Resultado de imagen para what is an  hl7 message EDITOR?

¿Para que sirven?
Se usan para:
  Estudiar el estándar,
  Implementar probar validar chequear entornos de interoperabilidad en la etapa de desarrollo.
  Chequeo de errores en la etapa de producción
  Ver mensajes HL7
  Editar mensajes HL7 (Crear nuevos mensajes HL7 de cero)
  Validar los mensajes HL7 (depurar y afinar menajes)
  Enviar / recibir mensajes (utilizando TCP / IP, Serial, MLLP)
  Personalizar las definiciones y las tablas existentes  de acuerdo a lo que necesitemos
  Identificar los mensajes HL7, segmentos y campos apuntando a ellas
  Ver detalles tales como la longitud máxima, número de la tabla, la opcionalidad, etc.
  Ver fechas y marcas de tiempo en un formato legible por humanos
  Usar la búsqueda para encontrar mensajes, segmentos y campos
  Trabajar con múltiples mensajes simultáneamente
  Trabajar con archivos de gran tamaño que contiene miles de mensajes (hasta 100 K)
  Trabajar con Unicode y los mensajes no latinos
  Trabajar con mensajes no estándar, delimitadores y Z-segmentos
  Comparación de mensajes HL7
  Mostrar mensajes de HL7
  Crear nuevos mensajes HL7 
  Añadir / Modificar / Eliminar mensajes, segmentos y campos
  Utilice el selector de fechas para los campos de DTM y marcas de tiempo
  formato 2.x / Exportar Importar XML-HL7
  Exportar a formato XML y Excel
  Generar esquema XML (XSD) para un mensaje

Resultado de imagen para what is an  hl7 message EDITOR?

Los editores de menajes HL7 más comunes en el mercado son los siguientes:
Para Windows
      Propietarios con trial x 30 días
  HL7 SOUP Editor http://www.hl7soup.com/
  HL7 Spy http://www.hl7spy.com
  Interface Explorer http://www.laconic-designs.com
      Editores HL7 Libres para usos no comerciales
  Smart HL7 http://smarthl7.com/
  Quick view HL7 (Academic Free License ("AFL") v. 3.0) http://quickviewhl7.sourceforge.net
  Para Windows, Linux, Unix y MAC
      Editores HL7 Java funcionan tanto en Windows como en Mac o Linux.
  PacketSender para MAC