¿Qué es el IPS (International Patient Summary)?
¿Qué es el IPS (International Patient Summary)?
El resumen internacional del paciente es un resumen mínimo
IPS (INTERNATIONAL PATIENT SUMMARY) y no exhaustivo del paciente, independiente de la especialidad, independiente de la condición, pero fácilmente utilizable por todos los clínicos para la atención no programada (transfronteriza) de un paciente.
http://international-patient-summary.net/mediawiki/index.php?title=Main_Page
El Comité Europeo de Normalización (CEN) han aprobado la Norma Europea para Resúmenes de Pacientes para atención transfronteriza no planificada. Este es un hito para la colaboración europea y mundial y puede salvar vidas.
La norma toma como punto de partida las Directrices europeas sobre atención transfronteriza, adoptadas por la Red Europea de eSalud. Estas directrices surgieron del programa piloto a gran escala epSOS financiado por la UE. Forman la base para la infraestructura de servicios digitales de eHealth en Europa que está actualmente en funcionamiento.
Con el fin de facilitar la adopción de un formato común para el resumen del paciente en todos los Estados miembros, la Comisión Europea permitió al CEN crear esta norma y su guía de implementación complementaria, a través del proyecto CEN International Patient Summary (IPS).
Un resumen internacional del paciente, accesible a los profesionales de la salud a través de las fronteras, puede salvar vidas en caso de situaciones de emergencia y mejorar la atención segura.
Fue desarrollado por el piloto europeo a gran escala epSOS y desarrollado y probado por proyectos europeos como eStandards y Trillium-II.
El Comité Europeo de Normalización (CEN, francés: Comité Europeo de Normalización) es una organización pública de estándares cuya misión es fomentar la economía de la UE, el bienestar de los ciudadanos europeos y el medio ambiente a través de estándares y especificaciones. Los miembros del Comité Técnico del CEN 251 aprobaron la norma europea para 'El resumen del paciente para la atención transfronteriza no planificada'.
Un IPS (Resumen de Paciente Internacional) contiene los siguientes datos:
Información general sobre el paciente (por ejemplo, nombre, fecha de nacimiento, sexo)
Un resumen médico que consta de los datos clínicos más importantes del paciente (por ejemplo, alergias, problemas médicos actuales, implantes médicos o procedimientos quirúrgicos mayores durante los últimos seis meses).
Una lista de los medicamentos actuales, incluidos todos los medicamentos recetados que el paciente está tomando actualmente.
Información sobre el propio Resumen del paciente, p. cuándo y por quién se generó o actualizó el Resumen del paciente. Estos datos también se utilizan para fines de protocolo y seguridad.
Referencias
http://international-patient-summary.net/
http://international-patient-summary.net/mediawiki/index.php?title=Main_Page
02 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:
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.
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.
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 https://hl7latam.blogspot.com/2018/08/soap-vs-rest.html
03 REST Web API
La tecnología del desarrollo de sistemas informáticos varía y evoluciona a una velocidad impresionante. De la programación estructurada, la programación visual a los conceptos actuales de servicios web, API (Application Programming Interface) y REST (Representational State Transfer). Actualmente en aplicaciones o sitios web hoy, lo más común es hablar de REST y .NET Web API. A menos que estés usando esas tecnologías si están en el ámbito de la informática. La mejor forma de entender las cosas es usarlas en forma práctica.
En un esquema de integración de aplicación tradicional cada aplicación cliente tiene su propia lógica de negocios (probablemente programada en varios leguajes diferentes) que se conecta directamente a la base de datos para obtener, actualizar y manipular datos.
Esta lógica de negocios local significa que las aplicaciones del cliente pueden volverse complejas fácilmente y todas deben mantenerse sincronizadas entre sí. Cuando se requiera una nueva característica, deberá actualizar cada aplicación en consecuencia. Este puede ser un proceso muy costoso que a menudo conduce a la fragmentación de las características, errores y realmente puede retrasar la innovación.
Ahora analicemos la misma arquitectura con una API centralizada que contiene toda la lógica de negocio.
La Arquitectura REST modera sigue el concepto de Don’t Repeat Yourself’ (DRY) No repetir el proceso' (DRY) de desarrollo de software. Las aplicaciones se convierten en capas de interfaz de usuario relativamente livianas. REST es un patrón arquitectónico para crear una API que usa HTTP como su método de comunicación subyacente.
REST fue originalmente concebido por Roy Fielding en su trabajo de disertación de 2000 titulado 'Estilos arquitectónicos y el diseño de arquitecturas de software basadas en red', les recomiendo ver ese artículo en el siguiente link: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
Casi todos los dispositivos que están conectados a Internet ya usan HTTP; es el protocolo base sobre el que se basa Internet, y por eso es una gran plataforma para una API.
HTTP es un sistema de solicitud y respuesta; un cliente llamante envía una solicitud a un punto final y el punto final responde. El cliente y el punto final pueden ser cualquier cosa menos un ejemplo típico es un navegador que accede a un servidor web o a una aplicación que accede y API.
Hay varios detalles clave de implementación con HTTP que debe tener en cuenta:
Recursos: REST usa recursos direccionables para definir la estructura de la API.
Un identificador de recursos uniforme (URI) es o bien un localizador uniforme de recursos (URL), como también un nombre de recurso uniforme (URN), o ambos a la vez.
Estas son las URL que usa para llegar a las páginas en la web, por ejemplo 'http://www.microsoft.com/Surface-Pro-3' es un recurso.
Acciones de solicitud: describen lo que quiere hacer con el recurso.
Un navegador típicamente emite un
GET para obtener un recurso del servidor
POST para crear un recurso del servidor, envía datos a una URL para que el recurso en esa URI los maneje.
PUT para actualizar un recurso del servidor, pone un recurso en la dirección especificada en la URL. Exactamente en esa dirección. Si no existe, lo crea, si existe lo reemplaza.
DELETE para eliminar un recurso del servidor
La lista completa en http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
En el contexto de una API REST, los recursos normalmente representan entidades de datos
(es decir, 'Paciente', 'Profesional', 'Orden', etc.). El verbo que se envía con la solicitud informa a la API qué hacer con el recurso, por ejemplo, una solicitud GET obtiene datos sobre una entidad, las solicitudes POST crean una nueva entidad.
Existe una convención que establece que las solicitudes GET a una url de la entidad, como Pacientes, devuelve una lista de Pacientes , posiblemente coincida con algunos criterios que se enviaron con la solicitud. Sin embargo, para recuperar un Paiente específico, usaría la identificación del Paciente como parte del recurso.
Por ejemplo
/ Paciente / 81 devolvería el Paciente con la ID de 81.
También es posible usar parámetros de cadena de consulta con una API, por ejemplo puede tener algo como / Paciente? Sexo= Femenino que devuelve todos los Pacientes femeninos.
La Web API utiliza los conceptos de Controlador y Acción de MVC ( Model View Controller) , por lo que si ya entiende .net MVC, se encuentra en un buen lugar. Si no lo hace, entonces la API web es una excelente forma de aprender MVC.
Los recursos se asignan directamente a los controladores; normalmente tendría un controlador diferente para cada una de sus entidades de datos principales (Paciente, Profesional, Orden, etc.).
La API web usa el motor de enrutamiento .net para asignar direcciones URL a los controladores. Normalmente, las API se mantienen dentro de una ruta '/ api /' que ayuda a distinguir los controladores API de otras API que no pertenecen al mismo sitio web.
Las acciones se utilizan para mapear verbos HTTP específicos, por ejemplo, normalmente tendrías una acción GET que devuelve todas las entidades.
Web API es parte de 'One ASP.net'
Web API es parte de la familia 'One ASP.net', lo que significa que admite de forma nativa todas las excelentes funciones compartidas que puede usar actualmente con MVC o formularios web, esto incluye (estos son solo algunos ejemplos):
Entity Framework, (Marco de la entidad).
Authorisation and identity, (Autorización e identidad).
Scaffolding, (Andamiaje).
Routing, (Enrutamiento).
El uso de una API hará que la arquitectura de su aplicación sea mucho más limpia, lo que facilitará la adición de características y la corrección de errores a medida que avance su proyecto.
REST es un patrón arquitectónico que se basa en HTTP y utiliza solicitudes HTTP, respuestas, verbos y códigos de estado para comunicarse. El hecho de que los servicios REST usen HTTP significa que pueden ser consumidos por casi cualquier dispositivo o aplicación "en línea" (incluidos dispositivos IoT como tostadoras, automóviles, podómetros, etc.). No se requiere conocimiento propietario de la API.
Web API en .net es la forma en que escribes los servicios de API REST en .NET. Web API le ofrece todos los beneficios del .NET Framework y se ocupa de muchas de las complejidades de la negociación de contenido, el enlace de modelos, etc. que tendría que tratar usted mismo sin Web API.
Referencias
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm http://www.microsoft.com/Surface-Pro-3 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
https://hl7latam.blogspot.com/2018/07/que-es-una-api-rest.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
https://restfulapi.net/rest-put-vs-post/ http://notasjs.blogspot.com/2013/07/ http-diferencia-entre-post-y-put.html
https://blogs.msdn.microsoft.com/martinkearn/2015/01/05/introduction-to-rest-and-net-web-api/
Ejemplos de código
http://prideparrot.com/blog/archive/2012/3/creating_a_rest_service_using_asp_net_web_api https://www.codeproject.com/Articles/788580/WCF-RESTful-service-and-WebGrid-in-ASP-NETMVC-P
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 más 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.
Cliente de Servicios Web RESTful
Es cliente de servicios Web para desarrollar y probar las API de servicios web RESTful
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.
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.
https://chrome.google.com/webstore/detail/rest-web-serviceclient/ecjfcmddigpdlehfhdnnnhfgihkmejin?hl=es-419
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
Comentarios
Publicar un comentario