Gran pregunta Mi punto de vista personal es que ya no es el Botón Azul del “gobierno” sino un movimiento público-privado (es decir, lograr que las personas accedan a sus datos de salud digitales) y una marca, y luego para la norma, un acuerdo sobre lo que sucederá poder ayudar a la mayoría de los consumidores a tener acceso a sus datos de salud, y luego poder no solo verlos, sino también ponerlos en hojas de estilo y visualizaciones más limpias y utilizables, así como usarlo con aplicaciones y servicios innovadores en la parte inferior , sin mencionar enviarlo a otros doctores. La iniciativa Automatizar Blue Button Initiative trata específicamente de hacer que este acceso sea más automático, de modo que “descargar mis datos de salud” no es una tarea repetitiva y manual, sino algo más parecido a “configurarlo y olvidarlo” para los consumidores de todos los días.
El botón azul comenzó como un archivo ASCII, y la mayor parte del acceso hoy en día sigue siendo raw ASCII. Creo que la razón original para esto fue hacer que sea lo más simple posible de implementar, y visible para la mayor población posible sin la necesidad de ningún software especial. 1 millón de usuarios únicos más adelante, incluso el caso de uso simplista de solo visualizar datos de salud parece haber sido exitoso como el producto viable mínimo, pero es un paso en el camino hacia la utilidad de mayor impacto con el uso posterior.
Por comparación, el CDA consolidado no estaba diseñado para el uso del consumidor, sino que estaba diseñado para la interoperabilidad. Y la huella será enorme con Meaningful Use Stage 2, que efectivamente no solo lo hace disponible como la lengua franca de los registros de salud gracias a las muchas plantillas que contiene.
Entonces, con el fin de unir el mundo de este intercambio de información de salud de hospital a hospital y el acceso de los consumidores a los datos, creo que los participantes S & I Workgroup se dieron cuenta de que la factibilidad era un problema principal, que valdría la pena intentarlo. obtener datos tal como estaban, e intentar alcanzar un estándar en torno a esos datos.
El desafío es que cCDA, como un documento XML para desarrolladores, en particular desarrolladores móviles, no es tan atractivo como, por ejemplo, JSON serializado. Por lo tanto, para ayudar a impulsar la innovación particularmente en aplicaciones y servicios de terceros (a diferencia de las aplicaciones empresariales / hospitalarias o basadas en MD), que a menudo sufren el problema de tratar de cargar datos de salud, Blue Button podría ser mejor servido con algún tipo de transformada JSON que pueda obtener los datos de forma más limpia en un formato amigable para desarrolladores.
JSON también tiene atractivo desde el punto de vista de la tecnología móvil, lo que ha vuelto a inquietar la limitación del ancho de banda y las necesidades de eficiencia en la representación de datos con la que solíamos lidiar en la era previa a la banda ancha de módems y acceso telefónico.
Microsoft HealthVault es otro ejemplo de tratar de unir estos mundos. Por un lado, tiene un montón de fuentes de datos dispares, todas contra los diferentes estándares y esquemas de datos locales propietarios. Para el equipo de HealthVault y Sean Nolan en particular, el esfuerzo se ha dirigido directamente a tratar de facilitar la vida de los desarrolladores, con una interfaz XML-over-HTTP y una API razonablemente inteligible. Este modelo funciona si usted, como consumidor, se siente cómodo al enviar y almacenar sus datos dentro de HealthVault, y luego acceder a su aplicación a través de HealthVault API. Aquí hay un enlace al Ecosistema de Microsoft HealthVault
Pero digamos que solo quiere descargar sus datos, y asegurarse de que puedan ser absorbidos por otra aplicación y entendidos. El mayor requisito para esto es, probablemente, la legibilidad humana, y XML y JSON no son tan buenos en eso (aunque los desarrolladores podrían argumentar que JSON es legible por humanos). Entonces terminas en ASCII o PDF. Si es inteligente, puede encontrar una manera de manipular XML utilizando XSLT y XSL: FO para producir algunas representaciones legibles por humanos; la especificación IHE XDM muestra una forma de crear una estructura de carpetas estandarizada que contiene un archivo HTML que apunta a las hojas de estilo y el archivo XML sin formato para representar los formularios legibles por el ser humano, pero sería difícil para la abuela resolverlo necesariamente sin instrucciones, y no deja mucho espacio para el diseño visual adicional. JSON, por otro lado, probablemente tenga muchas oportunidades para un diseño visual más creativo si está incrustado en un documento HTML, lo que lo hace altamente utilizable por el ser humano e interoperable por la máquina.
Pero para llegar a la interoperabilidad, y permitir que las startups y desarrolladores mejoren las aplicaciones de sus consumidores con datos de salud personal de Blue Button, hay dos necesidades principales que resolver: 1) lo que es factible y atractivo para los proveedores de datos, principalmente hospitales, médicos y aseguradores de salud, y 2) lo que es factible y atractivo para los desarrolladores. Para hospitales y médicos, esa respuesta es CDA consolidada, aunque solo sea por la falta de otros estándares comunes de intercambio de datos clínicos (distintos de su predecesor, CCD o C32). Para startups y desarrolladores, sin embargo, no está claro si elegirían eso si pudieran dictar la respuesta.
(¡Disculpas por verbosidad!)
