Buscar este blog

sábado, 21 de julio de 2018

Curso completo de Bootstrap desde cero 1.- Introducción e Instalación

How to install Bootstrap locally on Windows 7 | 8 | 10

Qué es un wireframe y cómo trabajar con uno gratis (wireframe.cc)

Editor JSON Online

En esta breve nota vamos a describir una herramienta sencilla y poderosa para editar JSON (JavaScript Object Notation) la notación de  Objetos de Java Script
JSON es una notación de  formato liviano de intercambio de datos. Es fácil para los humanos leer y escribir. Es fácil para las máquinas analizar y generar. Se basa en un subconjunto del lenguaje de programación JavaScript, estándar ECMA-262 3ª edición, diciembre de 1999.
Por su practicidad JSON,  traspasa el mundo de programadores JAVA  y cada vez más está siendo utilizado por cada vez más lenguajes y programadores y esta siendo en este momento un fuerte competidor del XML. Las ventajas con respecto al XML es que es más sencillo y rápido de implementar además de ser más claro para su lectura y construcción.
Por eso es importante contar con herramientas para que nos asista para analizar y editar JSON, y una que tenemos para usar en forma efectiva, rápida y gratuita es JSONONLINE   para usarla podemos ingresar a https://jsoneditoronline.org/ y vamos a ver la siguiente pantalla.


En el menú principal de las aplicaciones contiene opciones para borrar, cargar y guardar los contenidos JSON de la aplicación. Los archivos se pueden cargar desde el disco (a través del menú o arrastrar y soltar), url o en línea, y se pueden guardar en línea o en el disco. Tenga en cuenta que debido a restricciones de seguridad, la aplicación solo puede abrir URL desde sitios web públicos, no desde una intranet.
Como vemos en la fitura la aplicación contiene dos paneles: un editor de código a la izquierda y un Editor de árbol a la derecha.
Hay un divisor entre los dos paneles, lo que permite cambiar el ancho de ambos paneles según las necesidades. Para copiar el contenido de un panel a otro, se pueden usar los dos botones de copia entre los paneles.
En la derecha tenemos na notación java y en la izquierda una serie de herramientas para controlar el código la notación y navegar el árbol con suma facilidad.

Referencias
https://jsoneditoronline.org/
https://www.json.org/

Step by Step Tutorial - C# REST Client

REST Web API

La tecnología del desarrollo de sistemas informáticos varia y evoluciona a una velocidad impresionante. De la programación estructurada, la progració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 mas común es hablar de REST y .NET Web API. A menos que estes usando esas tecnólogias si estan en el ámbito de la informatica y no te toco susarlas es probable qué no sepas bien de que se trata. 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 analisesmos 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:

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

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.


viernes, 20 de julio de 2018

¿Qué formato tienen los archivos de SNOMED CT?

El formato de publicación 2 (RF2, por release format 2 en inglés) es el formato principal utilizado para los archivos de publicación de SNOMED CT.


La Edición Internacional de SNOMED CT se publica como un conjunto de archivos:
  • Los archivos de publicación son:
    • Archivos de texto delimitados por tabulaciones
    • Codificados de acuerdo con la especificación UTF-8 Unicode (que permite utilizar una amplia variedad de caracteres, símbolos y caracteres con acentos)
  • Hay archivos individuales con columnas especificadas para cada uno de los componentes centrales de SNOMED CT:
    • Conceptos
    • Descripciones
    • Relaciones


Tipos de publicación

La especificación RF2 ofrece un mecanismo de historial en los archivos distribuidos. Esto permite ofrecer diferentes tipos de publicación con el mismo formato de archivos y utilizar este mecanismo para optimizar la instalación y actualización de la terminología.
Publicación completa: Una publicación "completa" contiene cada versión de cada componente publicado alguna vez. Esta publicación proporciona un registro histórico completo y puede utilizarse para obtener vistas del estado de cualquier componente en cualquier punto de tiempo desde la primera publicación. La publicación "completa" es la forma más sencilla de instalar e inicializar SNOMED CT. Sin embargo, los archivos son grandes y en cada publicación sólo se modifica una pequeña proporción del contenido.
Publicación “delta”: Una publicación "delta" sólo contiene las versiones de componentes creados, inactivados o modificados desde la publicación anterior.  La publicación "delta" es mucho más pequeña que la publicación "completa" y es ideal para actualizar una publicación "completa" de la versión previa. El agregado de una publicación "delta" a la versión "completa" previa la actualizará como la versión actual "completa".
Publicación “snapshot”: Como en una fotografía, esta publicación contiene la última versión de cada componente publicado en un momento determinado. La versión de cada componente contenido en este tipo de publicación es la versión más reciente de ese componente en el momento de la publicación. La publicación "snapshot" es útil para instalaciones simples pero no brinda una historia ni una vista retrospectiva de la terminología.
Hay casos de uso válidos para cada tipo de publicación. Cada edición internacional incorporará estos tres tipos de publicación, y permitirá que cada usuario seleccione el formato más apropiado para sus necesidades. Las extensiones siempre deben estar disponibles como una publicación completa aunque también pueden estar disponibles los otros tipos de publicaciones.

Referencias

jueves, 19 de julio de 2018

¿Qué es GDHP?

La Alianza Global de Salud Digital (The Global Digital Health Partnership - GDHP) es una colaboración internacional de gobiernos, agencias gubernamentales y organizaciones multinacionales dedicadas a mejorar la salud y el bienestar de sus ciudadanos a través del mejor uso de las tecnologías digitales basadas en evidencia. Lea nuestra visión y nuestros principios y descubra quién está involucrado. El GDHP se centra actualmente en los cinco flujos de trabajo a continuación.


La Argentina forma parte de GBHP, participando de distintos comites.La visión del GDHP es apoyar a los gobiernos y los reformadores del sistema de salud para mejorar la salud y el bienestar de sus ciudadanos a través del mejor uso de las tecnologías digitales basadas en evidencia.
A medida que los países de todo el mundo enfrentan los desafíos de diseñar sistemas y brindar servicios que den como resultado una buena salud y bienestar para sus ciudadanos, las tecnologías digitales pueden proporcionar soluciones potenciales. Pueden mejorar la seguridad, la calidad y la efectividad de la atención médica, respaldar el diagnóstico precoz de la enfermedad y el desarrollo de nuevos medicamentos y tratamientos. Pueden empoderar a los pacientes, a los ciudadanos y a los profesionales de atención que los atienden.

Referencias:

¿Qué es SMART on FHIR?

SMART en FHIR es un conjunto de especificaciones abiertas para integrar aplicaciones con registros de salud electrónicos, portales, intercambios de información de salud y otros sistemas de TI de salud. 
SMART Health IT es una plataforma de tecnología abierta y basada en estándares que permite a los innovadores crear aplicaciones que se ejecuten sin problemas y de forma segura en todo el sistema de atención médica. Es una plataforma de tecnología basada en estándares que permite a los innovadores crear aplicaciones que se ejecutan sin problemas y de forma segura a través del sistema de salud. Al usar un sistema de registros de salud electrónicos (EHR) o un depósito de datos que admite el estándar SMART, los pacientes, médicos y profesionales de la salud pueden recurrir a esta biblioteca de aplicaciones para mejorar la atención clínica, la investigación y la salud pública.

¿Qué ventajas tiene usar SMART?
SMART es que se trata de un estandar que permite que las aplicaciones de salud sustituibles tiene muchos beneficios para los desarrolladores de aplicaciones, proveedores de servicios de salud, pacientes, instituciones de salud y salud pública.

Desarrolladores de aplicaciones: reducen el costo y la complejidad de integrarse con los sistemas de EHR de los clientes y aceleran la creación de aplicaciones con herramientas y recursos de código abierto.
Proveedores de atención médica y pacientes: agregue nuevas capacidades y datos a los sistemas existentes (por ejemplo, para visualizar los riesgos, las tendencias y las trayectorias) y complete los registros clínicos con información de sensores, dispositivos e informes de pacientes.
Instituciones de salud: mejore el retorno de la inversión en EHR mediante la racionalización de los proyectos internos de personalización de EHR y el uso de una biblioteca de aplicaciones innovadoras.
Salud pública: las aplicaciones pueden transferir ideas, funcionalidad y flujo de trabajo en un solo paquete: una buena aplicación, distribuida ampliamente, podría remodelar la práctica de la noche a la mañana.



Referencias:

HL7 Argentina: MIRTH CONNECT HL7 ARGENTINA

HL7 Argentina: MIRTH CONNECT HL7 ARGENTINA

HL7 Argentina: MIRTH CONNECT HL7 ARGENTINA

HL7 Argentina: MIRTH CONNECT HL7 ARGENTINA

HAPI: Health Application Programming Interface

HAPI FHIR - La API FHIR de código abierto para Java

HAPI quiere decir Health application programming interface, Aplicaciones para salud. FHIR es un servidro FHIR Open Source (de código abierto) para Java, HAPI FHIR  requiere para funcionar la máquina virtual de Java (Java SE Development Kit)  JDK 8. El soporte para JDK 7 y versiones posteriores se ha eliminado oficialmente. HAPI-FHIR, esta progamado en JAVA, todo su código esta disponible para modificar y programar y corre sobre los prinicipales sistemas operativos,Linux, MAC, Windows y otros.

HAPI FHIR se basa en el mismo principio de practicidad de FHIR. Se aplica a la implementación de Java: Se ha basado el diseño de esta API en las API JAXB y JAX-WS, que consideramos que están muy bien pensadas y son API muy útiles. 
Parte de la clave de por qué FHIR es una buena especificación es el hecho de que su diseño se basa en el diseño de otras API exitosas (en particular, los diseñadores de FHIR a menudo hacen referencia a la API de Highrise como una influencia clave en el diseño de la especificación).

HAPI FHIR se basa en el mismo principio, pero se aplica a la implementación de Java: hemos basado el diseño de esta API en las API JAXB y JAX-WS, que consideramos que están muy bien pensadas y son API muy útiles. Sin embargo, esto no significa que HAPI-FHIR realmente use estas dos API, o que HAPI-FHIR sea de alguna manera compatible con JAXB (JSR222) o JAX-WS (JSR224), solo que hemos intentado emular la facilidad de uso. uso, pero diseño flexible de estas especificaciones.

Para instalar y bajar el servidor puede hacerlo de http://hapifhir.io/download.html
Hay varias versiones disponibles, como puede verse en el grafico siguiente:


¿Quién desarrollo y mantiene HAPI-FHIR?
HAPI-FHIR es un proyecto abierto del departamento de redes de Salud de la Universidad de Toronto (University Health Network Toronto, Canada) quien lo desarrolló y lo mantiene.

Referencias
http://hapifhir.io/
http://hapifhir.io/download.html
https://link.springer.com/article/10.1007/s10278-018-0090-y
https://github.com/jamesagnew


Próxima 34ª Conferencia Global de GS1 Salud

Tailandia tuvo en vilo  al mundo entero con los chicos atrados en las cuevas de Chiang Rai en ese mismo país se va a desarrollar la 34ª Conferencia Global de GS1 en Salud  en la ciudad de Bangkok, Tailandia, del 30 de octubre al 1 de noviembre de 2018. 
GS1 es la tecnologia que permite controlar, la trazabildiad, los medicamentos falsificados, así como los errores médicos, continúan causando problemas de salud para pacientes de todas las edades y en todas las regiones. Asegurar la cadena de suministro a través de un sistema de trazabilidad es una de las herramientas para ayudar a prevenir que los medicamentos falsificados y de calidad inferior lleguen a los pacientes al tiempo que contribuyen a la eficiencia de la cadena de suministro y, por lo tanto, reducen los costos. Aquí es donde los estándares GS1 juegan un papel importante.


Los estándares GS1 se utilizan hoy en día por la gran mayoría de los fabricantes de dispositivos médicos para respaldar la implementación de los requisitos UDI (Unique Device Device). Además, los proveedores de servicios de salud de todo el mundo utilizan cada vez más los estándares GS1 en los procesos clínicos para mejorar la atención del paciente, en quirófanos, laboratorios, farmacias y más.

Para  ver el programa del evento, inscripción y mayor información les dejamos el link

¿QUÉ ES UNA TERMINOLOGÍA CLÍNICA?


Terminología es  un conjunto de términos o palabras propias utilizadas en una ciencia, técnica, o especialidad, o por un autor."terminología científica; terminología cinematográfica" un sinónimo de terminología es nomenclatura. La terminología clínica es: “un conjunto de términos específicos relacionados con el ejercicio práctico de la medicina y fundamentados en la atención de la salud de los pacientes”. 
La terminología médica terminología estandarizada mas utilizada es SNOMED CT (Systematized Nomenclature of Medicine-Clinical Terms).
Esta definición se podría completar añadiendo además que: “una terminología clínica es también un conjunto de términos estructurados y normalizados que busca servir de instrumento para el registro de datos clínicos, como base para posibles investigaciones o como medio de intercambio de información clínica entre profesionales para la atención de la salud de los pacientes”.
El uso de una terminología clínica estandarizada como SNOMED CT para describir la información contenida en las historias clínicas de los pacientes, aporta congruencia, precisión y fiabilidad a la información sobre la salud y contribuye a mejorar la seguridad de los pacientes.

Referencias
https://www.msssi.gob.es/profesionales/hcdsns/areaRecursosSem/snomed-ct/preguntas.htm
http://www.minsa.gob.pe/renhice/documentos/Pre2Jor/09%20Daniel%20Luna%20-%20Terminolog%C3%ADas%20Cl%C3%ADnicas.pdf
http://www.studentconsult.es/ficheros/booktemplate/9788445821152/files/terminologia_medica.pdf
http://www.medicosypacientes.com/articulo/la-principal-terminolog%C3%ADa-cl%C3%ADnica-estandarizada-nivel-mundial-estar%C3%A1-disponible-en-toda

miércoles, 18 de julio de 2018

Falls Extinguisher FHIR HL7


HL7 New Zealand (HL7NZ), en colaboración con la Universidad de Auckland y con el apoyo de Microsoft, organizó "Desarrolladores en FHIR" como un desafío divertido para crear nuevas herramientas y aplicaciones que pueden afectar directamente la atención del paciente utilizando el nuevo HL7® Fast Estándar de recursos de interoperabilidad de salud (FHIR®).

  El desafío "Desarrolladores en FHIR" se desarrolló entre diciembre de 2017 y marzo de 2018, y culminó con un evento presencial de día completo organizado por la Universidad de Auckland.

  El desafío para los participantes fue crear una solución, utilizando HL7® FHIR®-APIs, que exhibe creatividad en el desarrollo de una aplicación orientada al cliente que tiene una gran utilidad para uno de los grupos de interés involucrados en la recopilación de datos de eventos adversos , análisis e informes, incluidos médicos, pacientes, consumidores, analistas, agencias gubernamentales y otros.



Reference
http://www.hl7.org.nz/solutionsshowcase


Google lanza Cloud Healthcare API

Cloud Healthcare API es una herramienta de código abierto diseñada para permitir a los proveedores de servicios de salud recopilar y administrar varios tipos de datos médicos a través de la nube, incluidos los estándares DICOM, HL7 y Fast Healthcare Interoperability Resources (FHIR).

Google espera que la API brinde un punto de partida para que las organizaciones sanitarias lancen proyectos analíticos y de aprendizaje automático en la nube, utilizando datos agregados de múltiples sistemas clínicos.

Los proveedores de servicios de salud podrán realizar análisis de estos datos para identificar patrones que podrían ayudar a mejorar los resultados de los pacientes.

El aprendizaje automático ya ha demostrado su capacidad para apoyar la toma de decisiones clínicas, identificar pacientes en riesgo y mejorar la efectividad de los ensayos clínicos.

En una publicación publicada en el blog de Google Cloud, el Dr. Gregory Moore, vicepresidente de atención médica en Google Cloud, dijo: "Nuestro objetivo con la API de Cloud Healthcare es ayudar a transformar la industria de la salud mediante el uso de tecnologías en la nube y el aprendizaje automático.

El objetivo de Google Cloud para el cuidado de la salud es en gran medida un reflejo de la misión general de Google: organizar la información del mundo y hacer que sea universalmente accesible y útil. Aplicar esta misión a la asistencia sanitaria significa utilizar estándares abiertos para permitir el intercambio de datos y la colaboración interactiva, a la vez que proporciona una plataforma segura. Imagínese si todos los proveedores de atención médica pudieran colaborar de manera fácil, segura e instantánea mientras lo cuidaban. En última instancia, esperamos que un mejor flujo de datos inspire nuevos descubrimientos con inteligencia artificial (AI) y aprendizaje automático (ML), lo que conducirá a conocimientos que mejoran los resultados de los pacientes.


Referencias
https://www.digitalhealth.net/2018/03/google-launches-cloud-healthcare-api/?utm_content=70209228&utm_medium=social&utm_source=facebook
https://www.blog.google/products/google-cloud/google-cloud-healthcare-new-apis-customers-partners-and-security-updates/
https://cloud.google.com/solutions/healthcare-life-sciences/
https://www.cnbc.com/2018/03/05/google-cloud-healthcare-api-to-address-medical-reord-interoperability.html

SNOMED International anuncia que Brasil es su 33º País Miembro

Brasil  es el país número 33 que  se unió a SNOMED CT International en abril de este año (2018) . SNOMED CT  ya esta siendo utilizado en varias partes del Brasil. SNOMED International ingresa al pais para apoyar la transformación del sistema de salud a nivel nacional como un elemento fundamental de su estrategia de eSalud, digiSUS.

Como se describe en la estrategia nacional, del Departamento de Monitoreo y Evaluación del SUS del Ministerio de Salud de Brasil que es responsable en general de la gobernanza de la Estrategia Nacional Electrónica de Salud.

Brasil ha definido a SNOMED CT como la terminología de referencia internacional elegida para su uso en sus sistemas clínicos que respaldan la estrategia nacional de eSalud.

SNOMED International se enorgullece de que SNOMED CT desempeñe un papel en el apoyo a la estrategia nacional DigiSUS (estratégia e-Saúde)  en Brasil", dice el CEO de SNOMED International, Don Sweete. "Brasil prevé que un entorno digital basado en datos jugará un papel clave para acelerar el cambio a la atención basada en valores, y SNOMED International se complace en participar en el progreso de este camino".

La Dra. Juliana Zinader, Coordinadora General, Departamento de Monitoreo y Evaluación del SUS del Ministerio de Salud comenta que "hemos logrado un hito en el campo de las Tecnologías de la Información y la Comunicación en Salud en Brasil.

Con la adopción de SNOMED CT como el estándar de la clínica Para la terminología del Registro Electrónico de Salud, el país da un paso importante hacia la interoperabilidad semántica. El Dr. Zinader continúa afirmando que una terminología clínicamente validada, semánticamente rica y controlada como SNOMED CT agregará un significado procesable al EHR de Brasil, jugando una clave papel en los esfuerzos para mejorar la eficiencia y la calidad del Sistema Nacional de Salud que es de particular beneficio para la salud de la población en general.

Referencias

El Open Source cumple 20 años


La Iniciativa de Código Abierto ( Open Source Initiative - OSI) está celebrando su vigésimo aniversario en 2018. La etiqueta de "código abierto" fue creada en una sesión de estrategia celebrada el 3 de febrero de 1998 en Palo Alto, California. Ese mismo mes, se fundó el OSI. Como una organización sin fines de lucro, la OSI protege y promueve el software, el desarrollo y las comunidades, defendiendo la libertad del software en la sociedad a través de la educación, la colaboración y la infraestructura, administrando la definición de código abierto (OSD) y evitando el abuso de los ideales y valores inherente al movimiento de fuente abierta.

El código abierto  o Open Source, es un modelo de desarrollo de software basado en la colaboración abierta.​ Se enfoca más en los beneficios prácticos que en cuestiones éticas o de libertad que tanto se destacan en el software libre.




El software open source ha destacado como una alternativa viable al software propietario. Este tipo de sistemas han demostrado no ser sólo una solución ética, sino también económica y productiva. Este tipo de licencia posibilita el estudio y la modificación del software con total libertad. Además, su redistribución está permitida siempre y cuando esta posibilidad vaya en concordancia con los términos de licencia bajo la que se adquiere el software.La ventaja principal del software open source es la posibilidad de compartir, modificar y estudiar el código fuente de un sistema informático. Por otro lado, el código abierto promueve la colaboración entre usuarios. Esta característica supone el desarrollo rápido y variado de multitud de herramientas. Por ejemplo, los usuarios de un determinado programa pueden realizar personalizaciones, solventar fallos o mejorar las funcionalidades básicas gracias a los miembros de las comunidades, los foros, etc.


Referenecias
https://opensource.org/
https://www.filmaffinity.com/ar/film663390.html

Scientists Can Now 3D Print Functional Organs

lunes, 16 de julio de 2018

Tipos de licencia de SNOMED CT


Existen varios tipos de licencias y consideraremos cada una de ellas, incluyendo, licencias de afiliado, sublicencias y licencias nacionales.
Las condiciones de licencia para el uso de SNOMED CT varían en países miembros y los que no son miembros. 


En primer lugar hay que aclarar que todos los que usan SNOMED necesitan una licencia. Usualmente es una organización, en donde trabajan las personas es la que realmente posee la licencia de SNOMED CT. Pero si un individuo  utiliza SNOMED CT  fuera del alcance de la licencia organización también necesitan tener una licencia.

El acuerdo de licencia de SNOMED CT estipula
1.     Que el licenciatario (por ejemplo, un usuario, desarrollador o proveedor) conoce y reconoce que SNOMED International  es dueña de SNOMED CT y su propiedad intelectual asociada.
2.    El acuerdo de licencia también deja en claro qué derechos otorga SNOMED International a el licenciatario y las limitaciones que se aplican a esos derechos. Dicho de otra manera, la licencia establece lo que un licenciatario puede hacer con SNOMED CT y lo que no son permitido hacer.
3.    Finalmente, existen obligaciones que el licenciatario debe aceptar como condición de uso de la terminología.  Los derechos, limitaciones y obligaciones dependen del tipo de licencia.

La Licencia de Afiliado es requerida por todos aquellos que desarrollan, mantienen y / o distribuyen cualquier tipo de sistema, aplicación o servicio que incorpore o utilice SNOMED CT.
Todos aquellos que están desarrollando o distribuyendo un sistema basado en Extensiones nacionales de SNOMED CT, así como aquellos que solo están usando el International.
La razón de esto es que todas las extensiones SNOMED CT dependen del contenido de la versión internacional de SNOMED CT - y las Licencias de afiliados son requeridas por quienes desarrollan o distribuyen cualquier sistema.
Vale la pena señalar de pasada en este punto que la combinación de una extensión nacional con el lanzamiento internacional de SNOMED CT a menudo se lo conoce como una edición nacional.
De manera similar, a menudo se hace referencia al lanzamiento internacional de SNOMED CT utilizado por sí mismo. Como la edición internacional de SNOMED CT.

La licencia de Afiliado 

Permite
1. Acceso a bajar los distintos  archivos de ralease de SNOMED.
2. Usar SNOMED
3. Crear extensiones y derivaciones
4. Sub licenciar a sus clientes
5. Distribuir SNOMED CT con sus productos.
6. No pagar por el uso si el país es miembro

No Permite
1. Traducir SNOMED
2. Tiene que tener la licencia de Afiliado cuando el país es miembro
3. Usar la misma en países no miembros.
4. Pagar si el país no es miembro

Tenga en cuenta que el pago de tarifas de países no miembros a SNOMED International es una responsabilidad del Afiliado.

Hay dos formas de obtener una licencia, ya sea desde el Centro Nacional de licenciamiento (NRC -National Realease Center) en un País miembro o en SNOMED International.

Para el caso de Argentina la dirección del  NCR es
y para obtener la licencia simplemente hay que anotarse y la misma se obtiene en forma gratuita ya que Argentina es un país miembro de SNOMED International.

Dondequiera que se obtenga una licencia de afiliado de SNOMED CT, los términos de la licencia son los mismo y en todos los casos el acuerdo es entre el Afiliado Licenciatario y SNOMED International.
Algunos miembros proporcionan un sistema de licencia y un control del sistema de distribución, para consultar que países son miembros puede ingresar a:

El segundo tipo de licencia para la versión internacional de SNOMED CT es una sub-licencia emitida por un licenciatario afiliado a sus clientes, clientes o usuarios finales. Una sub-licencia permite a los usuarios de los productos o servicios del Afiliado usar SNOMED CT. Esto significa que un Afiliado puede incluir SNOMED CT como parte del sistema o servicio que el proporcionar a sus clientes.

El Afiliado puede incluir la sub-licencia como parte de una licencia más general para el uso de su sistema o servicio alternativamente puede ser un acuerdo separado. De cualquier manera, en los términos de la sub-licencia permitirán el uso de SNOMED CT en sistemas, aplicaciones o servicios prestados por el licenciatario afiliado emisor. 
Los términos de la sub-licencia deben no permitir ningún uso de SNOMED CT que no esté permitido por la Licencia de Afiliado.

Además, un sublicenciatario no puede sublicenciar ni redistribuir SNOMED CT.

El Afiliado también puede limitar el uso de sublicencias de SNOMED CT, por ejemplo para controlar el uso en un país no miembro, y de hecho puede obligar al sublicenciatario a cubrir los costos del afiliado para ser utilizados por el sublicenciatario en un país que no es miembro.

Un sublicenciatario que desea redistribuir o utilizar SNOMED CT de formas no permitidas por la sublicencia, puede registrarse como un Licenciatario Afiliado con SNOMED International.

Los países que son miembros de SNOMED International también tienen derechos de uso de SNOMED CT. Estos derechos se otorgan como parte de los Estatutos que definir formalmente las estructuras de gobierno de SNOMED International.

Los países que son miembros de SNOMED International también tienen derechos de uso de SNOMED CT. Estos derechos se otorgan como parte de los Estatutos que definir formalmente las estructuras de gobierno de SNOMED International y establecer los beneficios y obligaciones que se aplican a la organización y a sus miembros.

Los derechos de los miembros de SNOMED CT incluyen;

  • Uso de SNOMED CT International Release dentro de la organización que cumple las responsabilidades de ese Miembro, esa organización suele denominarse el Centro Nacional de Liberación o NRC.
  • Un miembro también puede crear extensiones nacionales de SNOMED CT que se basan y dependen del lanzamiento internacional.
  • El miembro también puede traducir la versión internacional de SNOMED CT y distribuir esta traducción como parte de su Extensión Nacional.

Tenga en cuenta que esto contrasta con la licencia de afiliado que explícitamente excluye el permiso para traducir.
Los miembros también pueden emitir licencias para el uso de su extensión nacional por SNOMED CT Afiliados.


Referencias
● Página web 'Obtener SNOMED CT'
● Servicio de licencia y distribución de membresía (MLDS)
● Acuerdo de licencia de afiliado de SNOMED CT
● Artículos de asociación internacionales SNOMED
 http://www.ihtsdo.org/about-ihtsdo/objectives-and-results/articles-of-ass
● Tarifas de licencia de afiliado
● Orientación sobre licencias de navegadores en línea
 http://snomed.org/browserlicenseguidance

¿Qué son las Extensiones FHIR? ¿Por qué son necesarias? ¿Para qué sirven?



 ¿Qué son las Extensiones FHIR?
Las Extensiones es un mecanismo que tiene el estándar FHIR, para permitir flexibilidad a la hora de interoperar con sistemas en el sector salud. Las estructuras rígidas no permiten contemplar todas las necesidades que existen y para estas particularidades se usan las extensiones. La extensibilidad una parte fundamental del diseño de FHIR, permitiendo que cada elemento de un recurso pueda tener elementos secundarios que complementen al mismo con información que no forma parte de la definición básica del recurso. El uso de extensiones permite mantener una simplicidad suficiente en el núcleo de FHIR, sin penalizar su usabilidad.  La especificación de intercambio se basa en los requisitos comunes generalmente acordados en toda la asistencia sanitaria, que abarca muchas jurisdicciones, dominios y diferentes enfoques funcionales. Es común que las implementaciones específicas tengan requisitos válidos que no forman parte de estos requisitos comunes acordados. La incorporación de todos los requisitos válidos haría que esta especificación sea muy engorrosa y difícil de implementar. En cambio, esta especificación espera que se implementen requisitos válidos adicionales como extensiones.

Como tal, la extensibilidad es una parte fundamental del diseño de esta especificación. Cada elemento de un recurso puede tener elementos secundarios de extensión para representar información adicional que no forma parte de la definición básica del recurso. Las aplicaciones no deben rechazar recursos simplemente porque contienen extensiones, aunque es posible que necesiten rechazar recursos debido a los contenidos específicos de las extensiones.

¿Porque son Necesarias las Extensiones?
Las extensiones son necesarias para darle flexibilidad al estándar y permite resolver problemas particulares de interoperabildiad que son imposibles de contemplar con una estructura rígida. Tenga en cuenta que, a diferencia de muchas otras especificaciones, ninguna aplicación, proyecto o estándar puede tener estigma asociado al uso de extensiones, independientemente de la institución o jurisdicción que use o defina las extensiones. El uso de extensiones es lo que permite que la especificación FHIR conserve una simplicidad central para todos.
Para hacer que el uso de extensiones sea seguro y manejable, se aplica una gobernanza estricta a la definición y al uso de extensiones. Aunque cualquier implementador puede definir y usar extensiones, existe un conjunto de requisitos que deben cumplirse como parte de su uso y definición. 


¿Para qué sirven?
Sirven para facilitar el intercambio de información y la interoperabilidad entre sistemas cuando el estándar definido no contempla un problema en particular. Cada recurso incluirá un elemento que contendrá una descripción legible del contenido del recurso en formato XHTML. Dicha descripción podrá contener, o no, todos los elementos codificados en secciones anteriores y también información no incluida en los datos estructurados (como por ejemplo textos incorporados por personas). Pero siempre, y dentro del ámbito de la definición del recurso, la descripción narrativa debe ser clínicamente segura para aquel profesional que la pueda leer.   

¿Qué estructura tiene?
La extensión tiene una estructura definida.  Cada elemento en un recurso o tipo de datos incluye un elemento hijo opcional "extensión" que puede estar presente varias veces. Este es el modelo de contenido de la extensión tal como aparece en cada recurso:

Como tal, la extensibilidad es una parte fundamental del diseño de esta especificación. Cada elemento de un recurso puede tener elementos secundarios de extensión para representar información adicional que no forma parte de la definición básica del recurso. Las aplicaciones no deben rechazar recursos simplemente porque contienen extensiones, aunque es posible que necesiten rechazar recursos debido a los contenidos específicos de las extensiones.

Tenga en cuenta que, a diferencia de muchas otras especificaciones, ninguna aplicación, proyecto o estándar puede tener estigma asociado al uso de extensiones, independientemente de la institución o jurisdicción que use o defina las extensiones. El uso de extensiones es lo que permite que la especificación FHIR conserve una simplicidad central para todos.


Referencias:

HL7 FHIR Blockchain y el Sistema de Salud



Nadie hubiera pensado hace solo unos años que Blockchain tiene el potencial de transformar los registros de salud.

Los ingenieros de la Universidad de Vanderbilt dicen que han desarrollado y validado con éxito la viabilidad de una arquitectura basada en blockchain que aprovecha el estándar de recursos de interoperabilidad rápida de HL7 para el intercambio seguro y confidencial de registros médicos de pacientes.

Llamada FHIRChain, la tecnología cumple con los requisitos técnicos de la Oficina del Coordinador Nacional de Informática Médica para compartir datos clínicos entre proveedores distribuidos, de acuerdo con investigadores de Vanderbilt, que la desarrollaron en colaboración con los tratamientos de radiación oncológica y el fabricante de software Varian Medical Systems.

Específicamente, FHIRChain utiliza elementos de datos FHIR junto con un diseño basado en tokens para intercambiar recursos de datos de forma descentralizada y verificable sin mover los datos.


"Demostramos una aplicación descentralizada (DApp) basada en FHIRChain que usa identidades de salud digitales para autenticar fácilmente a los participantes y gestionar autorizaciones de acceso a datos en un estudio de caso de intercambio de datos clínicos", indican los investigadores de Vanderbilt y Varian en un documento de reimpresión que ha sido enviado para publicación. "Este DApp permite a los usuarios compartir información específica y estructurada (en lugar de un documento completo), lo que aumenta la legibilidad de los datos y la flexibilidad de uso compartido".

Los registros de pacientes habilitados por Blockchain potenciados ​​por la interoperabilidad benefician principalmente a los pacientes al permitirles un grado de libertad que no se está disponible en el entorno sanitario actual.

Imaginemos que cada HCE (Historia Clínicas electrónica) enviara actualizaciones sobre medicamentos, problemas y listas de alergias a un libro de confianza de código abierto de toda la comunidad, de modo que las adiciones y sustracciones al registro médico fueran bien entendidas y auditables en todas las organizaciones. En lugar de solo mostrar datos de una única base de datos, el HCE podría mostrar datos de todas las bases de datos a las que se hace referencia en el libro mayor. El resultado sería una información perfectamente conciliada a nivel de toda la comunidad, con integridad garantizada desde el punto de generación de datos hasta el punto de uso, sin intervención humana manual.

Blockchain es un nuevo participante en la comunidad de estándares de interoperabilidad. HL7 (Health Level 7 International), Y FHIR (Fast Healthcare Interoperability Resources) entre otros estándares clínicamente enfocados consumo de miles de páginas de información detallada están considerando blockchain.

El estándar de blockchain de Bitcoin y el estándar HL7 tienen números de versión en común. Sin embargo, ese es el alcance de la similitud. En el cuidado de la salud, tenemos múltiples estándares, versiones, tipos de datos y formatos de archivo para hacer malabares. HL7 publicó recientemente la versión tres de su estándar de recursos de interoperabilidad de atención médica rápida para uso de prueba (STU).

FHIR es otro estándar de intercambio de atención médica asignado a HL7. Se supone que FHIR es el salvador de la interoperabilidad sanitaria para permitir el acceso universal a los datos de los pacientes en varios ecosistemas sanitarios. Similar al término "paz mundial", FHIR es un concepto interesante que vale la pena explorar; sin embargo, las aplicaciones del mundo real son más complejas. HL7 ha aparecido en todas partes en entornos de atención médica (con versiones múltiples ofrecidas como sabores de helados). A pesar del progreso de FHIR hasta la fecha, FHIR aún no ha establecido un punto de apoyo significativo o una escala efectiva en todo el panorama de la atención médica.

Referencias