Buscar este blog

Google+ Followers

Seguidores

Vistas a la página totales

martes, 28 de agosto de 2018

¿Qué es Deep Learning?


El  Deep Learning (aprendizaje profundo) es un subcampo de aprendizaje automático relacionado con algoritmos inspirados en la estructura y función del cerebro llamadas redes neuronales artificiales.

Si recién está comenzando en el campo del aprendizaje profundo o si tuvo alguna experiencia con redes neuronales hace algún tiempo, puede estar confundido. Sé que al principio estaba confundido y muchos de mis colegas y amigos que aprendieron y usaron redes neuronales en la década de 1990 y principios de 2000.

Los líderes y expertos en el campo tienen ideas de lo que es el aprendizaje profundo y estas perspectivas específicas y matizadas arrojan mucha luz sobre de qué se trata el aprendizaje profundo.

El  Deep Learning es parte de un conjunto más amplio de métodos de aprendizaje automático basados en asimilar representaciones de datos. Una observación (por ejemplo, una imagen) puede ser representada en muchas formas (por ejemplo, un vector de píxeles), pero algunas representaciones hacen más fácil aprender tareas de interés (por ejemplo, "¿es esta imagen una cara humana?") sobre la base de ejemplos, y la investigación en este área intenta definir qué representaciones son mejores y cómo crear modelos para reconocer estas representaciones.



Referencias:
https://machinelearningmastery.com/what-is-deep-learning/
https://www.youtube.com/watch?v=FbxTVRfQFuI
https://www.mathworks.com/discovery/deep-learning.html

What is Deep Learning? | Introduction to Deep Learning | Deep Learning T...

lunes, 27 de agosto de 2018

Aspectos éticos e legais da informática em Saúde” é tema do próximo SIG Rede Nacional de Pesquisa em Telessaúde


Aspectos éticos e legais da informática em Saúde” é tema do próximo SIG Rede Nacional de Pesquisa em Telessaúde


No dia 29 de agosto, a partir das 14h30 (horário de Brasília), acontece mais uma edição do SIG Rede Nacional de Pesquisa em Telessaúde. O tema deste encontro será “Aspectos éticos e legais da informática em Saúde“, com presença do Prof. Renato Sabbatini. 
A discussão será aberta ao público interessado com transmissão online para todo o país. Basta clicar no link abaixo para participar.
CLIQUE AQUI para acessar a sala virtual (dia e hora agendados)
Na última edição, a pauta do debate foi “Ensino da Informática Biomédica nas Graduação da área de Saúde”, ministrada pelo Prof. Luiz Roberto de Oliveira, coordenador geral do NUTEDS/UFC.
Informações de apoio da RUTE:
Antes da conexão com a sala de webconferência, por favor verifique os requisitos de uso:
https://wiki.rnp.br/pages/viewpage.action?pageId=89112372#ManualdoUsuáriodoserviçodeconferênciaweb-Requisitosdeuso
Dúvidas sobre informações de conexão nos SIGs devem ser consultadas diretamente na Coordenação Nacional RUTE: (61) 3243-4503 ou sig@rute.rnp.br.
Problemas de conexão ou suporte em webconferência: Service Desk RNP, 0800 722 0216 ou sd@rnp.br, todos os dias, 24h por dia.

Referencias
http://blog.nuteds.ufc.br/aspectos-eticos-e-legais-da-informatica-em-saude-e-tema-do-proximo-sig-rede-nacional-de-pesquisa-em-telessaude/

Motores de Interoperabilidad

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

CURSOS VIRTUALES EN ESPAÑOL DE HL7, FHIR, MIRTH CONNECT, DE HL7 ARGENTINA 20 % DE DESCUENTO SI TE ANOTAS EN LOS 3

NO SE LOS PIERDA







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

Healthcare 4.0

La informatización del sectro salud es compleja con varios actores, como pacientes, cuidadores, médicos, hospitales y empresas farmacéuticas. Esta industria también está restringida por reglas y regulaciones estrictas. En ocasiones, todo esto da como resultado una atención inferior a la adecuada para los pacientes.

Un sistema orientado al paciente puede dar como resultado una industria desfragmentada en la que el intercambio de datos entre los diversos actores puede conducir a una mejor prestación de asistencia sanitaria.

La recopilación de datos impulsada por la tecnología tiene un papel muy importante que desempeñar para brindar atención médica personalizada a las personas. La tecnología está afectando a muchas industrias con diversos grados de transformación digital que se están presenciando por todas partes. La sanidad es una de esas industrias que está posicionada para ser impactada por la introducción de tecnologías habilitadas para datos.

Los expertos lo llaman Healthcare 4.0, que incluye Analytics / AI y datos proporcionados por wearables (Internet of Things). Con base en la información proporcionada por IoT junto con un nivel avanzado de análisis, la industria puede mejorar la calidad de la atención médica brindada a las personas. Si nos fijamos en el mercado de la tecnología portátil, se está volviendo muy competitivo, lo que indica que la infraestructura fundamental está madurando para recopilar información confiable del paciente fuera del entorno de prueba de los pacientes.

Sin embargo, uno de los mayores obstáculos para la adopción temprana de Healthcare 4.0 sería la falta de coherencia en la habilitación digital entre las diferentes partes interesadas. Por ejemplo, muchos hospitales pueden no tener el músculo financiero necesario para implementar una transformación digital completa. Es posible que la industria no se transforme de la noche a la mañana, pero ciertamente puede comenzar a partir de frutos bajos como la enfermería o la adquisición.

Healthcare 4.0 imagina un mundo donde todos están conectados a través de dispositivos portátiles y cada punto de datos de los pacientes se está grabando, sin importar dónde se encuentren. Este futuro sería una combinación de Inteligencia Artificial, Internet de las Cosas (IO), Genómica y Big Data. Los perfiles genómicos para advertirnos sobre los riesgos futuros, los grandes datos para dar sentido a la gran cantidad de datos de wearables, la inteligencia artificial para ayudarnos a tomar las decisiones correctas sobre los procedimientos y el tratamiento se convertirán en parte de nuestra vida cotidiana al igual que los correos electrónicos y las redes sociales se han convertido en parte de todos los demás negocios.

Este nivel de sofisticación en la industria de la salud no solo requiere un alto nivel de transformación tecnológica, sino también un cambio de mentalidad. En la actualidad, las fragmentaciones en el sector no permiten una experiencia fluida para los pacientes que tienen que atravesar múltiples partes y tienen dificultades para almacenar sus registros médicos. Las complejidades involucradas en la industria necesitarían desenredarse primero si queremos que Healthcare 4.0 se convierta en realidad.

Referencias
https://www.healthcare.siemens.com/magazine/mso-digitalization-healthcare.html
http://www.vph-institute.org/news/healthcare-4-0-a-new-way-of-life.html
http://www.kmgus.com/blogs/healthit/index.php/2016/12/healthcare-4-0-the-future-of-healthcare/

Health Care 4.0 | Innovación y Tendencias de la Tecnología en Salud

La tecnología y los servicios se han convertido en el área de crecimiento de ingresos más rápido de la industria de la salud en los últimos cinco años, y su futuro crecimiento será fundamental para la industria. 
De esta manera, en el presente seminario se abordará dicha temática junto a los siguientes conceptos:
  • IoT en Salud: distintas formas de usar Internet of Things en el ámbito de la salud a través de distintos sensores y casos implementados. Ventajas y limitaciones.
  • Telemedicina: Teleconsulta/Segunda Opinión, Telemonitoreo y casos implementados.
  • Salud Cognitiva: aplicaciones y usos de la Inteligencia Artificial en Salud (incluyendo Watson), y casos implementados.
  • Gamification: usos de la Tecnología de Videogames aplicados a la Salud y la Educación, y casos implementados.
  • Historia Clínica Electrónica: distintos tipos, usos y proyectos de Historia Clínica Electrónica. Éxitos y fracasos.
  • Hospital Inteligente: proyectos de Hospitales Digitales en el mundo y sus ventajas.
Orador

Dr. Mariano Groiso

El Dr. Mariano Groiso es Médico de la UBA, con un Máster en Healthcare Informatics de la University of London. Lideró la Industria de Salud en IBM Latinoamérica desde 2010 hasta 2017. Previamente trabajó 10 años en Londres en el Programa de Informatización del Sistema de Salud Ingles (NHS), y como Director Médico y Desarrollo de Negocios en Salud para Iberoamérica en British Telecom UK. Es Partner de Doers! SAS y lidera el capítulo Latam de HealthXL, la aceleradora de Start Ups de TI en Salud de IBM, Novartis, Cleveland Clinic, BUPA y el Silicon Valley Bank. Es mentor para el área Salud de la organización de emprendedores Endeavor y de la aceleradora Incubando Salud, Juez en Start Up Chile y speaker sobre Watson Health e Inteligencia Artificial.

Referencias
https://eventos.udesa.edu.ar/evento/health-care-40-innovacion-y-tendencias-en-tecnologia-en-salud

Big Data y Analytics

Una estrategia de calidad de datos para permitir el acceso FAIR y programático en colecciones de datos grandes y diversas para el análisis de datos de alto rendimiento

Una estrategia de calidad de datos (DQS) es útil para investigadores, organizaciones y otros, principalmente porque les permite "establecer un nivel de seguridad y, por lo tanto, confianza para [su] comunidad de usuarios y partes interesadas clave como parte integral de la prestación del servicio. " Evans y col. de la Universidad Nacional de Australia, reconociendo esta importancia, discutir la implementación de su DQS en la Infraestructura Computacional Nacional Australiana (NCI), detallando su estrategia y proporcionando ejemplos en este documento de 2017. Concluyen que "[a] aplicar el DQS significa que los científicos dedican menos tiempo a formatear y reorganizar los datos para que sean adecuados para el uso de sus aplicaciones y flujos de trabajo, especialmente si sus aplicaciones pueden leer interfaces estandarizadas".
Cómo los datos de gran tamaño, la investigación comparativa de la efectividad y los sistemas de atención médica de rápido aprendizaje pueden transformar la atención del paciente en oncología de radiación.

En este breve artículo de opinión publicado en Frontiers in Oncology, Sanders y Showalter centran sus pensamientos en el sistema de atención de salud de rápido aprendizaje (RLHCS), un concepto que implica analizar datos de pacientes para obtener información sobre cómo mejorar la seguridad del paciente, la calidad del tratamiento y costo-efectividad dentro del marco del cuidado de la salud. En combinación con la investigación de efectividad comparativa (CER) y grandes flujos de datos bien administrados, el RLHCS tiene el poder "para acelerar el descubrimiento y el futuro de la planificación individualizada del tratamiento con radiación", argumentan. Concluyen que los macrodatos pueden "conectar una amplia gama de características para acelerar la generación de evidencia e informar la toma de decisiones personalizada", y su aplicación a través de CER y RLHCS puede "acelerar el progreso en la atención del cáncer".

Referencias:

hapi Tutorial — Getting Started and Your Server Up and Running

Construindo um HAPI FHIR™ SERVER - JPAEXAMPLE

Evolución de hapi-fhir (Gource Visualization)

Evolution of hapi-fhir (Gource Visualization)

Video que muestra la evolución

https://www.youtube.com/watch?v=8_V29YnNMwU

HL7 Tutorial: Testing HL7 Message responses with Mirth Connect and HL7 Soup

domingo, 26 de agosto de 2018

Curso básico (Foundation course) de Snomed CT

SNOMED CT tiene varios sursos de E-Learning  en línea, tutoriales y otros materiales diseñados para que pueda obtener más información sobre SNOMED CT. Estos servicios se entregan a través del Servidor de aprendizaje electrónico SNOMED CT.

Dentro de los cursos online esta el Curso de SNOMED CT Foundation
El objetivo de este curso es ampliar la profundidad y amplitud del conocimiento de SNOMED CT en la comunidad global. El curso tiene como objetivo proporcionar una cobertura autorizada de una amplia gama de temas relacionados con SNOMED CT en un nivel relativamente básico. También permite el desarrollo de una comprensión más detallada de SNOMED CT al permitir que aquellos que completen este curso se unan a cursos más avanzados de E-Learning de SNOMED CT en el futuro. Este curso está dirigido a cualquier persona que desee adquirir o demostrar un amplio conocimiento fundacional de SNOMED CT.

El estudio es autodidáctico, puede comenzar en cualquier momento y se espera que requiera un total de 30-35 horas. El curso debe completarse en un plazo máximo de cuatro meses, pero es posible completarlo en tan solo una semana.

Cuando finaliza estos cursos si aprueba los parciales y el final se emite un certificado.



Para tomar el curso, deberá tener una cuenta en el Servidor de aprendizaje electrónico de SNOMED CT. Solo toma unos minutos crear una cuenta. En unos minutos, se enviará un mensaje a su dirección de correo electrónico. Lea el correo electrónico y haga clic en el enlace web que contiene para confirmar la solicitud de su cuenta. Luego podrá iniciar sesión en el servidor. Si tiene una cuenta pero olvidó su información de inicio de sesión, no intente crear otra, en su lugar use el enlace de contraseña olvidada para restablecer su cuenta.

Cuando inicie sesión en su cuenta, verá un enlace en la página de inicio de E-Learning con la etiqueta "Inscribirse automáticamente en el curso SNOMED CT Foundation". Haga clic en ese enlace y se inscribirá automáticamente en el curso. Una vez en el curso, verá un enlace a un formulario de registro que debe completar. Inmediatamente después de completar el formulario de inscripción, podrá comenzar el curso.

Visite la página de aplicaciones del curso SNOMED CT Foundation para obtener información sobre cómo postularse.


Referenias:

¿Qué significa que un concepto sea fully-defined en SNOMED CT?


El punto principal sobre el estado de definición (primitivo o totalmente definido) es que no se relacionan con la naturaleza inherente del concepto en sí, sino con la suficiencia del conjunto de relaciones de definición proporcionadas actualmente en SNOMED CT. Entonces, la forma de saber si un concepto es primitivo o está completamente definido es observar el atributo definitionStatusId del concepto. Si el autor observa las relaciones definitorias y considera que TODOS los conceptos para los cuales todas las relaciones que definen son verdaderas serían el concepto nombrado por el nombre completamente especificado o un subtipo de ese concepto, entonces marcaron el concepto como totalmente definido. De lo contrario, está marcado como primitivo.

Hay cuatro razones distintas por las cuales un concepto puede ser primitivo:

  1. Porque es inherentemente imposible definir algunos conceptos al definir relaciones con otros conceptos. Por ejemplo: ambos | procedimiento | y | hallazgo clínico | simplemente se definen como subtipos de | SNOMED CT Concept | Son conceptos muy diferentes, pero ¿cómo podríamos indicar esa diferencia entre usar relaciones de definición con otros conceptos?
  2. Porque los atributos que distinguirían el concepto de otro concepto no están (todavía) en el modelo conceptual. Por ejemplo, | dolor ardiente | es un subtipo de | dolor | pero SNOMED CT no (todavía) tiene un atributo para hacer esa distinción. Es posible pensar en atributos que podrían llenar este vacío, tal vez algo así como "naturaleza de la sensación", pero un punto clave es que no solo agregamos atributos cada vez que se necesita (eso se ha intentado en el pasado y conduce a solapamientos). e inconsistencia que no son útiles, por ejemplo, alguien podría elegir "tipo de dolor" y esto tendría un uso más restringido de "naturaleza de la sensación". El enfoque de SNOMED CT es agregar atributos definitorios al modelo conceptual para priorizar los atributos que son aplicables a una gran cantidad de conceptos y documentar su uso para que las relaciones definitorias aplicadas sean reproducibles (es decir, diferentes autores que modelen un concepto tomarán la misma decisión basándose en reglas comunes).
  3. Porque el concepto no se encuentra en un dominio clínico directo sino en uno de los dominios de soporte utilizados para definir conceptos clínicos. Por ejemplo, fuerzas físicas, sustancias, estructura del cuerpo). Si bien algunos de estos tienen relaciones definitorias, el objetivo de estos es respaldar las definiciones lógicas del contenido clínico. SNOMED CT no tiene la intención de definir completamente las fuerzas químicas, etc., por lo que la mayoría, si no todas, serán primitivas. Como en el punto 2, este no es un límite absoluto, sino uno impulsado por las prioridades para apoyar la representación significativa de los conceptos clínicos.
  4. Porque el modelado de las relaciones definitorias es un proceso continuo y en los mismos casos es incompleto.Incluso cuando todos los atributos requeridos para definir completamente un concepto están presentes y respaldados, el concepto puede no estar completamente modelado. En cada nueva versión de SNOMED CT, más conceptos están completamente definidos. Sin embargo, los conceptos se agregan a SNOMED CT en función de los requisitos identificados y, en algunos casos, el concepto se necesita más rápidamente de lo que se puede modelar por completo.



La razón por la cual importa si un concepto está o no está completamente definido es que si está completamente definido, entonces es posible inferir automáticamente todos sus conceptos de subtipo. Si es primitivo, entonces esos subtipos necesitan ser explícitamente afirmados por | es un | relaciones establecidas por un autor.

Referencias:

4º Seminario Internacional de Bioderecho. IV Jornadas nacionales de Derecho de la Salud

Lunes 3, 4 y 5 de septiembre de 2018, Facultad de Derecho (UBA)
Programa:
Lunes 3 de septiembre en el Salón de Actos
  • 8:30 hs. - Acreditaciones.
  • 9:00 hs. - Acto de Apertura. Vicerrector UBA: Dr. Juan Pablo Mas Vélez.
    Decano de la Facultad de Medicina UBA: Dr. Ricardo Gelpi.
    Decano de la Facultad de Derecho UBA: Dr. Alberto Bueres.
    Directora Observatorio Derecho y Salud Facultad de Derecho UBA: Dra.Marisa Aizenberg.
    Presidente Red Internacional de Bioderecho: Dr. Erick Valdes.
    Fundación Garrahan: Dra. Silvia Kasab.
    Representante Organización Panamericana de la Salud : Dra. Maureen Birmingham
  • 9:30 hs. - Panel Inaugural.
    Panel Inaugural: Dr. Adolfo Rubinstein (Ministro de Salud de la Nación) y María Inés Baqué (Secretaria de Gobierno Digital e Innovación Tecnológica del Ministerio de Modernización).
  • 10:30 hs. - Conferencia Magistral del Dr. Jacob Dahl Rendtorff. “United Nations Sustainability goals as a new horizon for biolaw”.
    Presenta: Andrés Brandolini.
  • 11:30 hs. - Pausa saludable.
  • 12:00 hs. - Panel: - Los desafíos de la innovación tecnológica en genética y longevidad. Fernando Rovira, Claudia Perandones, Diego Bernardini e Isolina Dabove.
    Coordina: Lily Flah
  • 13:00 hs. - Receso.
  • 15:00 hs. - Conferencia del Dr. Erick Valdes. “¿Es el Bioderecho internacional realmente Bioderecho?”.
    Presenta: Dra. Viviana Bonpland
  • 15:45 hs. -Diálogo entre el ecosistema emprendedor y el Derecho de la Salud. Emilio Goldenhersh, Mariana Rojo, Federico Ares, Maximiliano Nitto y Pablo Chami.
    Coordina: Fiorella Bianchi.
  • 17:00 hs. - Pausa saludable
  • 1730 hs. - Panel: - Interrelaciones del Bioderecho y el Derecho de la Salud con otras disciplinas”. Andrea Andreacchio, Ricardo Li Rosi, Mario Bruno y Silvia Kassab.
    Coordina: Mónica Pires.
  • 18:30 hs. - Conferencia del Dr. Oscar Ameal.
    Presenta: Dr. Carlos Clerc.
Martes 4 de septiembre en el Aula Magna
  • 9:00 hs. - Conferencia Magistral del Dr. Roberto Andorno. “Principios del Bioderecho Internacional: logros alcanzados y desafíos futuros”.
    Presenta: María Verónica Scaro.
  • 10:00 hs. - Panel: El hospital del futuro y las nuevas modalidades de atención. Anibal Krivoy, Dr. Roberto Debbag y Elian Pregno.
    Coordina: María Litvachkes.
  • 11:00 hs. - Pausa Saludable.
  • 11:30 hs. - Diálogo: - Oportunidades y complejidades del Big Data en salud. Sus marcos regulatorios”. Mario Fiad, Daniel Luna, Daniel Rizatto y Juan Pablo Decia.
    Coordina: Mariano Fernández Llerena.
  • 12:30 hs. - Conferencia del Dr. Alvaro Villar.
    Presenta: Ignacio Millé.
  • 13:00 hs. - Receso.
  • 15:00 hs. - Panel: Los cambios en la relación medico paciente y su impacto en la responsabilidad profesional”. Sandra Wiezba, Jorge Meza, Daniel Chaves y Ricardo Hayes.
    Coordina: Laura Bilotta.
  • 16:00 hs. - Conferencia del Dr. Sergio Romeo Malanda. “Moda de los análisis genéticos como producto de consumo”.
    Presentación: Dr. Martin Morgensten.
  • 16:30 hs. - Pausa saludable
  • 17:00 hs. - Conferencia del Dr. Alberto Lecaros. “Los desafíos regulatorios de la donación de datos en la era del big data en salud”.
    Presenta: Antonio Luna.
  • 17.30 hs. - Panel: Patient advocacy, emancipación ciudadana y nuevas tecnologías centradas en el paciente”. Lisandro Zeno, Silvia Fernández Barrios y Emilia Arrighi.
    Coordina: Mercedes Jones.
  • 18:30 hs. - Conferencia de la Dra. Laura Puentes. “Constitucionalismo Contemporáneo y Bioderecho”.
    Presenta: Juan Manuel Colla.
Miércoles 5 de septiembre en el Salón de Actos
  • 14:30 hs. - Conferencia del Dr. Carlos María Romeo Casabona. “Aspectos Jurídicos de la medicina personalizada de precisión”
    Presenta: Jorge Menehem.
  • 15:00 hs. - Conferencia del Dr. Arístides Obando. “Ciudadanía materialmente diferenciada y ciudadanía como derecho humano. Una perspectiva de articulación en clave de bioderecho”.
    Presenta: Lidia Mendo.
  • 15:30 hs. - Diálogo sobre los desafíos de la formación académica. Alan Gobato, Lucas Amín, Julia López, Marcos Ibarra, Ana Inés Díaz, Marianela Fernández Oliva y Leonardo Perea.
    Presenta: María Teresa García de Dávila.
  • 16:30 hs. - Pausa Saludable.
  • 17:00 hs. - Panel: Pensando en la sustentabilidad del sistema sanitario: ¿Gasto o inversión en tecnología?”. Luis Giminez (a/c), Hugo Magonza, Gustavo Caramelo , Juan Pivetta y Guillermo González Prieto.
    Presenta: Mario Lugones.
  • 18:00 hs. - Conferencia Magistral del Dr. Miguel Angel Ciuro Caldani.
    Presenta: Enrique Suárez.
  • 18:30 hs.: Acto de clausura: Dres. Marisa Aizenberg y Javier Uribe.
Actividad no arancelada.
Informes e inscripción: observatorioderechoysalud@derecho.uba.ar


Referencias:
http://www.derecho.uba.ar/institucional/deinteres/2018/4-seminario-internacional-de-bioderecho-iv-jornadas-nacionales-de-derecho-de-la-salud

Protocol Buffer para C#


¿Por qué usar los  Protocol Buffer?
El ejemplo que vamos a utilizar es una aplicación de "libreta de direcciones" muy simple que puede leer y escribir datos de contacto de personas desde y hacia un archivo. Cada persona en la libreta de direcciones tiene un nombre, una identificación, una dirección de correo electrónico y un número de teléfono de contacto.

¿Cómo serializas y recuperas datos estructurados como este? 

Hay algunas formas de resolver este problema:

Use la serialización binaria de .NET con System.Runtime.Serialization.Formatters.Binary.BinaryFormatter y las clases asociadas. 

Esto termina siendo muy frágil frente a los cambios, costoso en términos de tamaño de datos en algunos casos. Tampoco funciona muy bien si necesita compartir datos con aplicaciones escritas para otras plataformas.

Puede inventar una forma ad-hoc para codificar los elementos de datos en una sola cadena, como codificar 4 entradas como "12: 3: -23: 67". Este es un enfoque simple y flexible, aunque requiere escribir códigos únicos de codificación y análisis sintáctico, y el análisis impone un pequeño costo de tiempo de ejecución. Esto funciona mejor para codificar datos muy simples.
Serializar los datos a XML Este enfoque puede ser muy atractivo ya que XML es (algo así) legible por humanos y hay bibliotecas vinculantes para muchos idiomas. Esta puede ser una buena opción si desea compartir datos con otras aplicaciones / proyectos. Sin embargo, XML es notoriamente intensivo en espacio, y la codificación / decodificación puede imponer una gran penalización de rendimiento en las aplicaciones. Además, navegar un árbol XML DOM es considerablemente más complicado que navegar campos simples en una clase normalmente.

Los Protocol Buffer son la solución flexible, eficiente y automatizada para resolver exactamente este problema. Con los búferes de protocolo, usted escribe una descripción .proto de la estructura de datos que desea almacenar. A partir de eso, el compilador de búfer de protocolo crea una clase que implementa la codificación automática y el análisis de los datos del búfer de protocolo con un formato binario eficiente. La clase generada proporciona getters y setters para los campos que componen un buffer de protocolo y se ocupa de los detalles de lectura y escritura del buffer de protocolo como una unidad. Es importante destacar que el formato de búfer de protocolo admite la idea de ampliar el formato a lo largo del tiempo de tal forma que el código aún pueda leer datos codificados con el formato anterior.

¿Donde podemos encontrar código?
https://github.com/protocolbuffers/protobuf/blob/master/csharp/src/AddressBook/Program.cs
Ejemplos
https://github.com/protocolbuffers/protobuf/tree/master/examples
https://github.com/protocolbuffers/protobuf/tree/master/csharp/src/AddressBook

Definiendo su formato de protocolo
Para crear su aplicación de libreta de direcciones, deberá comenzar con un archivo .proto. Las definiciones en un archivo .proto son simples: agrega un mensaje para cada estructura de datos que desea serializar, luego especifica un nombre y un tipo para cada campo en el mensaje. En nuestro ejemplo, el archivo .proto que define los mensajes es addressbook.proto.

syntax = "proto3";
package tutorial;
import "google/protobuf/timestamp.proto";
En C #, las clases generadas se colocarán en un espacio de nombres que coincida con el nombre del paquete si no se especifica csharp_namespace. En nuestro ejemplo, se ha especificado la opción csharp_namespace para anular el valor predeterminado, por lo que el código generado utiliza un espacio de nombre de Google.Protobuf.Examples.AddressBook en lugar de Tutorial.

option csharp_namespace = "Google.Protobuf.Examples.AddressBook";
Luego, tienes tus definiciones de mensaje. Un mensaje es simplemente un agregado que contiene un conjunto de campos tipados. Muchos tipos de datos estándar simples están disponibles como tipos de campo, incluidos bool, int32, float, double y string. También puede agregar más estructura a sus mensajes usando otros tipos de mensajes como tipos de campo.

message Person {
  string name = 1;
  int32 id = 2;  // Unique ID number for this person.
  string email = 3;

  enum PhoneType {
    MOBILE = 0;
    HOME = 1;
    WORK = 2;
  }

  message PhoneNumber {
    string number = 1;
    PhoneType type = 2;
  }

  repeated PhoneNumber phones = 4;

  google.protobuf.Timestamp last_updated = 5;
}
// Our address book file is just one of these.
message AddressBook {
  repeated Person people = 1;
}

En el ejemplo anterior, el mensaje de persona contiene mensajes de PhoneNumber, mientras que el de la libreta de direcciones contiene mensajes de persona. Incluso puede definir tipos de mensajes anidados dentro de otros mensajes; como puede ver, el tipo PhoneNumber se define dentro de Person. También puede definir tipos de enumeración si desea que uno de sus campos tenga una lista de valores predefinida; aquí debe especificar que un número de teléfono puede ser uno de MOBILE, HOME o WORK.

Los marcadores "= 1", "= 2" en cada elemento identifican la "etiqueta" única que ese campo utiliza en la codificación binaria. Los números de etiqueta 1-15 requieren un byte menos para codificar que los números más altos, por lo que, como optimización, puede decidir usar esas etiquetas para los elementos comúnmente utilizados o repetidos, dejando etiquetas 16 y superiores para los elementos opcionales menos utilizados. Cada elemento en un campo repetido requiere una nueva codificación del número de etiqueta, por lo que los campos repetidos son particularmente buenos candidatos para esta optimización.

Si no se establece un valor de campo, se usa un valor predeterminado: cero para los tipos numéricos, la cadena vacía para las cadenas, falso para los bools. Para mensajes incrustados, el valor predeterminado es siempre la "instancia predeterminada" o "prototipo" del mensaje, que no tiene ninguno de sus campos establecidos. Llamar al descriptor de acceso para obtener el valor de un campo que no se ha establecido explícitamente siempre devuelve el valor predeterminado de ese campo.

Si se repite un campo, el campo se puede repetir cualquier cantidad de veces (incluso cero). El orden de los valores repetidos se conservará en el búfer de protocolo. Piense en campos repetidos como matrices de tamaño dinámico.

Encontrará una guía completa para escribir archivos .proto, incluidos todos los tipos de campo posibles, en la Guía de idioma del búfer de protocolo. No busques instalaciones similares a la herencia de clase, sin embargo, los búferes de protocolo no hacen eso.
Compilando sus búfers de protocolo
Ahora que tienes un .proto, lo siguiente que debes hacer es generar las clases que necesitarás para leer y escribir los mensajes de AddressBook (y por lo tanto Person y PhoneNumber). Para hacer esto, necesita ejecutar el protocolo del compilador del buffer del protocolo en su .proto:

Si no ha instalado el compilador, descargue el paquete y siga las instrucciones en el archivo README.
Ahora ejecute el compilador, especificando el directorio de origen (donde vive el código fuente de su aplicación, el directorio actual se usa si no proporciona un valor), el directorio de destino (donde desea que vaya el código generado, a menudo lo mismo que $ SRC_DIR), y el camino a su .proto. En este caso, tú ...
protocolo -I = $ SRC_DIR --csharp_out = $ DST_DIR $ SRC_DIR / addressbook.proto
Como quiere las clases C #, usa la opción --csharp_out - se proporcionan opciones similares para otros lenguajes compatibles.
Esto genera Addressbook.cs en su directorio de destino especificado. Para compilar este código, necesitará un proyecto con una referencia al ensamblado Google.Protobuf.

Las clases de la libreta de direcciones
Generar Addressbook.cs le da cinco tipos útiles:

Una clase de libreta de direcciones estática que contiene metadatos sobre los mensajes del búfer de protocolo.
Una clase AddressBook con una propiedad People de solo lectura.
Una clase Person con propiedades para Name, Id, Email y Phones.
Una clase PhoneNumber, anidada en una clase Person.Types estática.
Una enumeración PhoneType, también anidada en Person.Types.
Puede leer más acerca de los detalles de lo que se generó exactamente en la guía C # Generated Code, pero en su mayor parte puede tratarlos como tipos de C # perfectamente normales. Un punto a destacar es que las propiedades correspondientes a los campos repetidos son de solo lectura. Puede agregar elementos a la colección o eliminar elementos de ella, pero no puede reemplazarla con una colección completamente separada. El tipo de colección para campos repetidos siempre es RepeatedField <T>. Este tipo es como List <T> pero con algunos métodos de conveniencia adicionales, como una sobrecarga Add que acepta una colección de elementos, para usar en los inicializadores de recopilación.

Aquí hay un ejemplo de cómo puede crear una instancia de Persona:

Person john = new Person
{
    Id = 1234,
    Name = "John Doe",
    Email = "jdoe@example.com",
    Phones = { new Person.Types.PhoneNumber { Number = "555-4321", Type = Person.Types.PhoneType.HOME } }
};
Note that with C# 6, you can use using static to remove the Person.Types ugliness:
// Add this to the other using directives using static Google.Protobuf.Examples.AddressBook.Person.Types; ... // The earlier Phones assignment can now be simplified to: Phones = { new PhoneNumber { Number = "555-4321", Type = PhoneType.HOME } }
Parseo y serialización
El propósito de utilizar memorias intermedias de protocolo es serializar sus datos para que puedan ser analizados en otro lugar. Cada clase generada tiene un método WriteTo (CodedOutputStream), donde CodedOutputStream es una clase en la biblioteca de tiempo de ejecución del búfer de protocolo. Sin embargo, generalmente usará uno de los métodos de extensión para escribir en un System.IO.Stream regular o convertir el mensaje a una matriz de bytes o ByteString. Estos mensajes de extensión están en la clase Google.Protobuf.MessageExtensions, por lo que cuando quiera serializar, generalmente querrá una directiva de uso para el espacio de nombres Google.Protobuf. Por ejemplo:

using Google.Protobuf;
...
Person john = ...; // Code as before
using (var output = File.Create("john.dat"))
{
    john.WriteTo(output);
}
El análisis también es simple. Cada clase generada tiene una propiedad de Analizador estática que devuelve un MessageParser <T> para ese tipo. Eso a su vez tiene métodos para analizar secuencias, matrices de bytes y ByteStrings. Entonces, para analizar el archivo que acabamos de crear, podemos usar:

Person john;
using (var input = File.OpenRead("john.dat"))
{
    john = Person.Parser.ParseFrom(input);
}
Un programa de ejemplo completo para mantener una libreta de direcciones (agregar nuevas entradas y enumerar las existentes) utilizando estos mensajes está disponible en el repositorio de Github.

Extendiendo un buffer de protocolo
Tarde o temprano, después de que libere el código que utiliza su búfer de protocolo, sin duda querrá "mejorar" la definición del búfer de protocolo. Si desea que sus nuevos almacenamientos intermedios sean compatibles con versiones anteriores, y sus almacenamientos intermedios antiguos sean compatibles con versiones anteriores (y es casi seguro que sí lo desea), existen algunas reglas que debe seguir. En la nueva versión del buffer de protocolo:

no debe cambiar los números de etiqueta de ningún campo existente.
usted puede eliminar campos.
puede agregar nuevos campos pero debe usar números de etiqueta nuevos (es decir, números de etiqueta que nunca se usaron en este búfer de protocolo, ni siquiera por campos eliminados).
(Hay algunas excepciones a estas reglas, pero rara vez se usan).

Si sigues estas reglas, el código antiguo leerá felizmente nuevos mensajes y simplemente ignorará cualquier campo nuevo. Para el código anterior, los campos singulares que se eliminaron simplemente tendrán su valor predeterminado, y los campos repetidos eliminados estarán vacíos. El nuevo código también leerá mensajes antiguos de manera transparente.

Sin embargo, tenga en cuenta que los nuevos campos no estarán presentes en los mensajes antiguos, por lo que deberá hacer algo razonable con el valor predeterminado. Se utiliza un valor predeterminado específico del tipo: para cadenas, el valor predeterminado es la cadena vacía. Para booleanos, el valor predeterminado es falso. Para los tipos numéricos, el valor predeterminado es cero.

Reflexión
Las descripciones de mensajes (la información en el archivo .proto) y las instancias de los mensajes se pueden examinar mediante programación utilizando la API de reflexión. Esto puede ser útil cuando se escribe un código genérico, como un formato de texto diferente o una herramienta de diferencia inteligente. Cada clase generada tiene una propiedad Descriptor estática, y el descriptor de cualquier instancia se puede recuperar utilizando la propiedad IMessage.Descriptor. Como un ejemplo rápido de cómo se pueden usar, aquí hay un método breve para imprimir los campos de nivel superior de cualquier mensaje.

public void PrintMessage(IMessage message)
{
    var descriptor = message.Descriptor;
    foreach (var field in descriptor.Fields.InDeclarationOrder())
    {
        Console.WriteLine(
            "Field {0} ({1}): {2}",
            field.FieldNumber,
            field.Name,
            field.Accessor.GetValue(message);
    }
}

Referencias:
https://developers.google.com/protocol-buffers/docs/csharptutorial?hl=es-419
https://github.com/protocolbuffers/protobuf/blob/master/csharp/src/AddressBook/Program.cs
https://github.com/protocolbuffers/protobuf/tree/master/examples
https://github.com/protocolbuffers/protobuf/tree/master/csharp/src/AddressBook

¿Qué es protocol buffers?


Protocol buffers o los búferes de protocolo son el mecanismo extensible, independiente de la plataforma neutral de idioma de Google, para serializar datos estructurados, piense en XML, pero más pequeño, más rápido y más simple. se define cómo desea que sus datos se estructuren una vez, luego puede usar un código fuente especial generado para escribir y leer fácilmente sus datos estructurados desde y hacia una variedad de flujos de datos y usando una variedad de idiomas.

Los búferes de protocolo son un método de serialización de datos estructurados. Es útil en el desarrollo de programas para comunicarse entre sí a través de un cable o para almacenar datos. El método implica un lenguaje de descripción de interfaz que describe la estructura de algunos datos y un programa que genera código fuente a partir de esa descripción para generar o analizar una secuencia de bytes que representa los datos estructurados.

Protocol buffers actualmente es soportado por código generado en Java, Python, Objective-C y C ++. Con nuestra nueva versión de idioma de proto3, también puede trabajar con Go, Ruby y C #, con más idiomas por venir.


Referencias:

FHIR Bulk Data


En el sector salud muchas veces es necesario para exportar datos masivos, incluyendo llenar un almacén de datos para análisis operativos o clínicos, aprovechar la salud de la población y las herramientas de soporte de decisiones de un proveedor externo, migrar de un proveedor de EHR a otro y enviar datos a agencias reguladoras como CMS . Hoy en día, la exportación a granel se realiza a menudo a través de tuberías propias y cada operación de transferencia de datos se convierte en un proyecto de ingeniería y mapeo. Esta especificación describirá un enfoque basado en FHIR para la exportación masiva.


FHIR permite el acceso a los datos de múltiples pacientes a la vez, las implementaciones de Argonaut generalmente están limitadas a un acceso de un solo paciente, y requiere un inicio de sesión mediado por humanos de forma regular. Esto se debe principalmente a que el caso de uso en el que se centró la comunidad Argonaut fue el acceso del portal del paciente. Si este trabajo se va a extender para proporcionar soporte para el acceso basado en API a un gran número de pacientes para respaldar el intercambio basado en proveedores, las siguientes preguntas (entre otras) deben ser respondidas:

¿cómo un cliente de negocios (un servicio de backend, no un ser humano) tiene acceso al servicio? ¿Cómo se manejan las autorizaciones?
¿Cómo se ponen de acuerdo el cliente y el servidor sobre a qué pacientes se accede y qué datos están disponibles?
¿En qué formato están disponibles los datos?
¿Cómo se realiza la solicitud en una API RESTful?
¿Cómo garantizarían el cliente y el servidor de la manera más eficiente que el cliente obtenga los datos que solicita, sin enviar todos los datos cada vez?
Las últimas preguntas son importantes porque los datos podrían ser bastante grandes: potencialmente> 100000000 recursos, y hasta ahora nos hemos centrado en intercambios altamente granulares. Nuestras soluciones existentes no se escalan bien.

Referencias:
http://docs.smarthealthit.org/flat-fhir/
https://github.com/smart-on-fhir/bulk-data-server
http://wiki.hl7.org/index.php?title=201801_Bulk_Data

sábado, 25 de agosto de 2018

SOAP vs REST

¿SOA o REST?¿Que conviene?, antes de ver las diferencias aclaremos algunos conceptos. Un error muy común que puede hacer que distorsione por completo tu entendimiento con respecto a los Web Services y es que SOA no es igual que SOAP y tener Web Services no significa que tenemos SOA.  Los terminos que tenemos que tener en claro son:
  1. SOA (Service-Oriented Architecture) es un tipo de Arquitectura de Software y no una
    tecnología o producto. 
    SOA es una arquitectura que se base en la integración de aplicaciones
    mediante Servicios, los servicios representan la medida más granular de la arquitectura, sobre la que se construyen otros artefactos como: composiciones, proxys, fachadas, BPM e incluso API completas. 
  2. REST (Representational State Transfer) o Transferencia de Estado Representacional es una arquitectura para proporcionar estándares entre los sistemas informáticos en la web, lo que
    facilita la comunicación entre los sistemas. Los sistemas que cumplen con REST, a menudo llamados sistemas RESTful, se caracterizan por la forma en que son apátridas y separan las preocupaciones del cliente y el servidor. Veremos qué significan estos términos y por qué son características beneficiosas para los servicios en la Web.
  3. SOAP (Simple Object Access Protocol) mejor conocimos simplemente como Web Services, son servicios que basan su comunicación bajo el protocolo SOAP  el cual este definido por Wikipedia como “protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML”. Por lo tanto, queda
    claro que la comunicación se realiza mediante XML, lo cual nos debe de quedar muy claro, pues es en este aspecto donde radican las principales diferencias contra REST. Los servicios SOAP funcionan por lo general por el protocolo HTTP que es lo más común cuando invocamos un Web Services, sin embargo, SOAP no está limitado a este protocolo, si no que puede ser enviado por FTP, POP3, TCP, Colas de mensajería (JMS, MQ, etc). Pero como comentaba, HTTP es el protocolo principal.


SOAP solo soporta formato XML, por lo que cuando lo que necesitamos es flexibilidad y un performance superior, podemos optar por REST. Tengo otro artículo donde hablo de XML vs JSON por si quieres profundizar en el tema.

tanto SOAP como REST siguen siendo muy útiles en condiciones diferentes, incluso existen aplicaciones que ya exponente todas sus API’s en SOAP y REST para asegurar que la integración con ellas sea lo más natural posible sin importar la aplicación con la que se estén integrado.
Cabe mencionar que REST ha estado tomando fuerza a una velocidad impresionante y más con la llegada de NodeJS y las bases de datos NoSQL como MongoDB. Sin embargo, el hecho de que REST tome fuerza, no significa que le esté quitando protagonismo a SOAP, pues recordemos que con la llegada del Internet de las cosas (IOT) cada vez se conectan más dispositivos a internet que necesitan ser integrados (una gran oportunidad para REST) y es donde REST está tomando la delantera.
La verdad es que el futuro no se ve claro, pero lo que, si es que a pesar de que REST siga tomando fuerza, SOAP sigue siendo una tecnología muy robusta y extremadamente utilizada por lo que una cosa si es segura, a SOAP todavía le queda un largo camino.
A pesar de todo este análisis, lo importante es tu qué opinas, ¿cuál crees que sea el futuro?, ¿crees que REST poco a poco matara a SOAP? O ¿simplemente SOAP seguirá funcionando a la par con REST?.


En informática un Bus de Servicio Empresarial (ESB por sus siglas en inglés) es un modelo de arquitectura de software que gestiona la comunicación entre servicios web. Es un componente fundamental de la Arquitectura Orientada a Servicios.



Un ESB generalmente proporciona una capa de abstracción construida sobre una implementación de un sistema de mensajes de empresa que permita a los expertos en integración explotar el valor del envío de mensajes sin tener que escribir código. 

Referencias:
https://www.youtube.com/watch?time_continue=1&v=7s_S5Hkm7z0
https://www.oscarblancarteblog.com/2017/03/06/soap-vs-rest-2/
https://www.youtube.com/watch?v=L1tM0tMJdzY
http://www.epidataconsulting.com/tikiwiki/tiki-read_article.php?articleId=44&highlight=SOA