¿Qué software de atención médica tiene la mejor (o incluso buena) experiencia del usuario? Esto podría expresarse como buscar y valorar los comentarios de los usuarios, contratar un equipo de UX fuerte y fomentar las habilidades de UX para los desarrolladores.

Las respuestas a estas preguntas parecen bastante polarizadas:

• En el lado “Ninguno” están los usuarios reales de los sistemas EMR: doctores y estudiantes de medicina en ejercicio. Estoy de acuerdo con estas personas.
• En el lado positivo están las personas que comercializan tecnologías de atención médica.

Sorprendentemente, un individuo defendió el uso de MUMPS aka M. Enfáticamente estoy en desacuerdo con su posición. El hecho de que todos los demás estén bebiendo Kool-Aid (adoptando aplicaciones basadas en MUMPS / M) no significa que usted también deba hacerlo. Pero esa es una discusión no pertinente a la pregunta original.

Soy un informático médico, y una de mis áreas de interés (y de investigación) en los últimos 27 años ha sido el uso de médicos y la adopción de tecnologías EMR. Los estudios publicados en revistas revisadas por pares apuntan a la falta de UI y UX efectivas como un impedimento importante para la adopción y el uso generalizados de los EMR.

El problema -la falta de una UI / UX efectiva que interfiera con la adopción de EMR- es tan generalizado que la ONC patrocinó un concurso dirigido al diseño de interfaz de usuario crowdsourcing para sistemas EMR, con premios de $ 50,000 para los diseñadores de UI ganadores. Vea Health Design Challenge.

Ninguna. Repita: NINGUNO.

No hay una sola compañía importante de software de atención médica que realmente se preocupe por la experiencia del usuario final, a pesar de que las implementaciones deficientes se han asociado, entre otras cosas, con una mayor muerte de los pacientes . La publicación en particular en la que estoy pensando es en realidad más una reminiscencia frustrada que una explicación científica tranquila [1].

Razones por las que a nadie le importa:

1. Nadie en la empresa realmente entiende cómo abstraer los flujos de trabajo de atención médica . Los ingenieros están absortos en la codificación de la funcionalidad, los gerentes de productos no tienen idea de cómo se usan sus productos para tratar a los pacientes, los documentos están demasiado ocupados tratando de usar este software malicioso para tratar a los pacientes que tienden a no estar disponibles para brindarles Los comentarios y los diseñadores que son buenos son adquiridos rápidamente por las compañías de Silicon Valley que entienden lo ridículamente valiosas que son.
2. Existe una gran barrera para alejarse de una pieza de software de atención médica una vez que se ha comprado e instalado, porque todos son caros y todos deben aprender un nuevo conjunto de flujos de trabajo. El cuidado del paciente casi invariablemente sufre durante esta fase de ajuste, y lo último que quiere luchar contra las trincheras es arruinar la vida de un paciente.
3. Muchos imbéciles en la administración sanitaria todavía no han descubierto que “la personalización extrema disponible para satisfacer las necesidades de su práctica” es publicitar BS porque “fuimos demasiado perezosos para descubrir esta parte realmente importante de nuestro software, pero no queremos admitirlo , así que vamos a darle vueltas como si fuera algo bueno y echamos la culpa a tus pies cuando la basura al azar que elijas inevitablemente falla de alguna manera importante “.
4. La implementación de back-end para muchos EMR grandes tendría que cambiar de manera bastante drástica (léase: ser completamente rehecho desde cero) para modernizarlo en algo que los diseñadores de codificadores de las generaciones recientes incluso querrían tocar. Para darle una idea, EPIC, el mayor proveedor de EMR, utiliza Cache [2]. Este marco se basa en MUMPS, que surgió en la década de 1960 antes de que la humanidad supiera qué buenas metodologías de programación eran. Ejemplo para usted tipos de programación: no hay alcance variable en Caché. Deje que se remojen un minuto. Sí. Todas las variables son globales Es una pesadilla impía.

[1] http://www.pediatricsdigest.mobi …
[2] http://en.wikipedia.org/wiki/Int …

Es fácil y provocador decir que TODO el software EHR es una mierda – pero ahora tenemos los datos para demostrar que los hechos son incorrectos. Además, dado que literalmente hay cientos de proveedores de EHR, no es razonable que una persona presente un veredicto único sobre una industria completa. Ciertamente, todos tienen derecho a una opinión, pero eso no es evidencia científica, ni habla de ninguna experiencia significativa en el dominio de la industria.

Recientemente, Medscape publicó los resultados de una encuesta de EHR que realizaron con más de 21,000 médicos, que representan 25 especialidades diferentes. En una escala de 1 a 5, donde 5 es la más alta, aquí están los primeros 17:

NB: 2 de los 10 mejores (Epic y VA-CPRS) usan M / Mumps como tecnología “fundacional”. Regresaré a esa parte “fundamental” en un minuto.

Amazing Charts está claramente a la cabeza. De 12 categorías, obtuvieron un puntaje superior a 4 en 10 de las 12 categorías. Muchas de las categorías fueron diseñadas específicamente para sondear sobre la “facilidad” de uso (o ingreso de datos) o implementación.

Contrariamente a la crítica popular (y fácil), esta es una clara evidencia de una satisfacción muy saludable .

Es igualmente provocativo afirmar que un diseño de EHR pobre ha llevado a muertes de pacientes. Desafortunadamente, es una visión tan estrecha que prácticamente no tiene sentido. ¿Por qué? Porque las muertes debidas a un diseño de EHR pobre no se comparan con nada. ¿Cuántos pacientes murieron porque los datos estaban bloqueados en papel? ¿Cuántos pacientes murieron porque la farmacia no pudo leer la receta de una nota garabateada por un médico? De hecho, ¿cuántas muertes han resultado de mala escritura en general? El hecho más grande es simplemente que el sistema de salud en sí mismo es responsable de miles de muertes cada año. Destacar aquellos que resultaron de un diseño de EHR pobre es fácil, incluso puede ser popular, pero no es en absoluto constructivo ni útil. Es tan similar como decir que 100 personas murieron cruzando la calle, por lo que nuestro diseño de los cruces de peatones y el alumbrado público son los culpables. Esa podría ser una declaración veraz, pero aparte de ser provocativa, ¿a qué propósito real sirve?

Esto también trivializa los esfuerzos de miles de ingenieros que han trabajado durante décadas para ayudar a resolver este problema difícil y complejo. Muchos de esos ingenieros (y proveedores) han trabajado en esto durante años, a menudo directamente con los médicos , para ayudar a mejorar el software. El desafío no es trivial. Las soluciones y el software de flujo de trabajo de grado empresarial rara vez son tan simples como un iPad o una aplicación móvil. SAP para la fabricación, Oracle Financials para la contabilidad, incluso Adobe Photoshop CS, todos requieren una capacitación importante y luego se utilizan para ser competentes. La diferencia entre una solución empresarial y una de consumo es realmente significativa, en todos los niveles.

Finalmente, es bastante común criticar abiertamente a M / Mumps. Antes de descartar esa tecnología por completo, animo a cualquiera que esté interesado a revisar una respuesta más equilibrada y reflexiva de Tom Munnecke (uno de los arquitectos originales de M / Mumps que trabajaron en VA VistA y DoD CHCS) a la pregunta de Quora:

¿Por qué la industria de la salud usa M / MUMPS en lugar de un lenguaje de programación más moderno o más ampliamente utilizado?

La perspicacia de Tom y su experiencia en el dominio específico en relación con M / Mumps es indiscutiblemente insuperable. En la misma pregunta, otro ingeniero – Mark Olschesky argumenta:

Pero, para decir una cosa para M / MUMPS (y su estructura de base de datos asociada en GT.M, Intersystems Cache, etc.): era una forma “NoSQL” antes de que NoSQL fuera una cosa. La naturaleza del flujo de datos en Healthcare IT es que los sistemas HIT son sistemas pesados ​​de lectura / escritura. Cada acción tiene marca de tiempo y audita. Imagine un internado admitido, con valores de máquinas que bombean datos de constantes en el EMR constantemente. 20 laboratorios se realizan 4 veces al día. Y un equipo de 20 médicos revisa constantemente partes del registro de este paciente (que deben ser auditadas). Ahora, imagina esto para 100,000 pacientes. Estas bases de datos crecen rápida y dinámicamente. Algunas de las limitaciones tradicionales de las bases de datos SQL (que también mejoran con el tiempo y también se adaptan como Azure Tables) hicieron que esto no condujera a una codificación productiva y escala escaladamente las implementaciones sin necesidad de realizar gimnasia de arquitectura de base de datos multi-SQL. Intersystems ECP proporcionó, en términos conocidos de mongoDB, “Sharding” en todos los servidores.

Además, la implicación es a menudo que M / Mumps es algún tipo de monstruo UI / UX. El hecho es que M / Mumps es “fundamental”. Se utilizan tecnologías, técnicas y herramientas más actuales para el diseño real de UI / UX. Esto también es cierto para otros lenguajes de programación como C, que es igualmente antiguo, e igualmente robusto. Todavía se usa mucho en la industria de servicios financieros específicamente por su fortaleza industrial.

En pocas palabras, todo el software EHR no es una mierda. ¿Hay margen de mejora? Siempre. ¿Hemos terminado con UI / UX? Nunca. Pero la idea de que todos los que alguna vez trabajaron en software EHR es un “imbécil” atrapado en una disciplina de ingeniería antigua es imprudente, y también refleja una comprensión muy limitada de cómo funciona la verdadera tecnología de la salud. ¡Espero que ese no sea mi doctor!

Si pregunta por registros médicos electrónicos, la respuesta es ninguna. No hay un médico que conozca, que vea un número significativo de pacientes, que esté contento con su sistema EMR, no uno. Invariablemente, la entrada de datos es demasiado tediosa, es demasiado difícil retroceder para encontrar un informe o resultado importante, y pedir medicamentos implica demasiados pasos.

A las compañías no parece importarles una vez que tienen su negocio. Los ciclos de actualización de software son demasiado lentos (18 meses para nuestro sistema altamente promocionado) y, a menudo, no incorporan los cambios que ha solicitado.

Si esta no era tu pregunta, perdón por la diatriba.

Tomamos UX muy en serio en Hello Doctor. Entendemos el dolor y queremos empoderar a las personas para que tomen el control de su salud.

La mayoría de las respuestas aquí se refieren estrictamente a EMR. Hola Doctor no es un EMR. Es una solución móvil que ayuda a los pacientes a controlar su salud y administrar todos sus registros médicos en su iPad.

Los pacientes pueden almacenar registros médicos de cualquier fuente (registros en papel, portales de pacientes, archivos PDF de CD, etc.), acceder rápidamente a cualquier registro, compartirlo con el médico o un familiar por fax o correo electrónico, y escribir notas en cada registro.

Para los pacientes con afecciones médicas complejas, Hello Doctor reemplaza completamente la carpeta que necesitan para llevar consigo docenas de registros, resultados de laboratorio, segundas opiniones, etc.
También reemplaza el portal del paciente (y a veces algunos de ellos en total)

Entendemos lo que las personas están pasando, y el UX lo refleja abordando los puntos problemáticos de todos los días. Para nombrar unos pocos:

• Antes de reunirse con su médico: escriba notas y preguntas directamente en sus registros médicos para que no se olvide de nada.
• Sentado frente a su médico: acceda a cualquier registro médico en solo dos golpes
• El médico está pidiendo resultados de pruebas anteriores: no es necesario hojear docenas de documentos, acceder a todos los registros anteriores en un solo golpe. No pierdas un tiempo precioso buscando.
• Organizar: etiquetar cualquier registro (o hacerlo automáticamente)
• y mucho más.

Aquí hay un breve video introductorio:

Descargo de responsabilidad: soy parte del equipo de inicio

Sobre la base de lo que dijo Jae Won Joh, el principal problema con el software de salud suele ser las instituciones que adquieren el software.

1. Con Imaging Systems, el dinero se gasta en medicamentos , no en interfaces de usuario. Los sistemas de imágenes como rayos X, imágenes de resonancia magnética, etc., alimentan EMR. Cuando los jefes de departamento están buscando una nueva máquina de rayos X, están buscando ver el # 1 cómo puede ofrecer una mejor funcionalidad médica y # 2 cómo puede ahorrar dinero con cada facturación. La interfaz de usuario siempre es la última prioridad, no solo con los clientes, sino también con las personas que desarrollan los sistemas. Por lo tanto, puede encontrar escáneres de imágenes multimillonarias que se ejecutan en MS-DOS.
2. Las oficinas privadas no contribuyen a un EMR central. ¿Desea que las oficinas de médicos privados envíen sus registros médicos para almacenarlos en el sistema informático central de un hospital (propiedad de una empresa privada)? Jajajajajajaja! No va a pasar. Por lo tanto, cualquier EMR es naturalmente incompleta. Cuando está incompleto, menos gente lo usa, y cuando menos gente lo usa,
3. Ningún desarrollador de EMR crea todo el ecosistema. Una de las claves de una excelente interfaz de usuario es la consistencia, lo que significa que el desarrollador de EMR también tiene que hacer la interfaz para todos los sistemas informáticos del hospital, lo cual es irrisorio y probablemente imposible. Estoy seguro de que a una empresa como 3M le encantaría que tu hospital local abandonara todos sus sistemas y comprara todo de ellos, pero los doctores se rebelarían.
4. El equipo ejecutivo compra el EMR. Este es un problema con cada corporación importante (¿cuántos de ustedes han usado SAP?). Los ejecutivos se centran en hacer sus propias vidas más fáciles (informes, seguimiento comercial, eficiencia empresarial) sin pensar demasiado en los detalles sutiles de los usuarios diarios.
5. ¿Realmente quieres un EMR que haga el trabajo por ti? Ha habido EMR que comprenden los términos médicos y las relaciones entre ellos, e incluso pueden sugerir un posible tratamiento. ¿Es esto algo que realmente queremos?

Ninguno de los programas de asistencia sanitaria cumple este criterio. La razón es que UX está diseñado por desarrolladores de software en lugar de por profesionales médicos . Estos desarrolladores de software dan su 100% para cumplir con todos los requisitos, pero no logran esto. Hubiera sido mucho mejor si estos programas de salud fueran creados por profesionales médicos. Porque un médico comprende completamente qué características deberían ser provistas por un software de atención médica. Uno de los mejores foros de salud diseñados recientemente es EMR Systems que satisface todas las necesidades de los profesionales de la salud. Y recomiendo al menos echarle un vistazo, ya que es una plataforma muy versátil que cumple con los requisitos de casi todas las especialidades.

Parte del problema con el “software de atención médica” proviene de una comprensión limitada de la industria de la salud (como empresa) y la falta de diferenciación entre los tipos de “usuarios”.

Quiero decir, ¿de qué estamos hablando cuando decimos “software de atención médica”? ¿En que contexto? Pacientes Proveedores? Pagadores? No es toda la práctica clínica (EMR); administrivia es una parte enorme y onerosa del flujo de trabajo a considerar. ¿Qué pasa con la coordinación de la atención y la colaboración entre los proveedores y con los pacientes / consumidores / miembros?

Puede parecer dividir los pelos, pero en términos de IxD / UX: las personas sanas tienen diferentes necesidades y objetivos que los pacientes enfermos; los médicos que interactúan con los pacientes tienen diferentes necesidades y objetivos que un profesional que envía la factura, o un director médico que revisa las apelaciones, y así sucesivamente.

De todos modos 🙂 me doy cuenta de que esta no era la pregunta en absoluto, así que mencionaré algunas empresas / proyectos que aún no se mencionan y que pueden valer la pena examinar, dependiendo de lo que estés buscando.

Para nuevas empresas: Rock Health: un acelerador de arranque. Algunas buenas ideas allí.

Para los médicos: diagnóstico ágil: pautas clínicas interactivas

Para los diseñadores (y para todos de verdad): Design for Care (libro) Rosenfeld Media | Diseño para el cuidado

Para desarrolladores: Plataformas SMART: “forma de baja barrera para diseñar y desarrollar aplicaciones informáticas clínicas serias para cerrar brechas funcionales en muchos sistemas EMR del mundo real” y humanos / api – Todos los datos de salud humana en una API

Jeff Margolis (fundador de TriZetto, ahora en WellTok.com) escribió un libro titulado The Information Cure: Resolviendo la crisis de la atención médica a través de Integrated Healthcare Management, que vale la pena revisar si alguien quiere un contexto / visión adicional sobre la imagen más grande de la atención médica. La industria está cambiando rápidamente, pero sigue siendo un libro relevante. [revelación completa: trabajé en TriZetto en una vida pasada mientras él todavía estaba a cargo.]

Si desea averiguar qué tan segura es su aplicación EMR / EHR contra las brechas de datos y las amenazas a la seguridad, Opsfolio es una solución libre de riesgo de HIPAA de Netsective.

Las infracciones de datos de su EHR / EMR, gestión de la práctica u otro software y dispositivos médicos representan un riesgo mayor de lo que podría pensar. Una vez que se produce una infracción, puede afectar a su organización al dañar su reputación ganada con esfuerzo, además de someterlo a multas del gobierno. Opsfolio puede proporcionarle una evaluación autodidacta o guiada en la evaluación de riesgos conforme con HIPAA de su aplicación EMR / EHR de misión crítica con una mejor experiencia de usuario.

Esperando a alguien que pueda proponer un producto como Slack, Asana, Robinhood en el espacio sanitario. Hay algunos competidores que lo intentan, pero todavía no veo la calidad como las mencionadas anteriormente.

UX definitivamente sería difícil de traer.

Las personas también necesitan saber que el producto no debe tener solo un buen diseño, sino que también debe formar hábito (los usuarios están apegados al producto).

Descargo de responsabilidad: he administrado un hospital de 300 camas y también he trabajado en una empresa centrada en productos en crecimiento.

Practo es la empresa líder de atención médica de la India que cuenta con información auténtica sobre todos los médicos y hospitales. Se lanzó Practo Ray, un software SAAS con el objetivo de simplificar el acceso a la información para todos los usuarios. El software tenía que ser robusto y potente y, lo que es más importante, auténtico, porque los datos completos de los pacientes y del hospital son demasiado sensibles. Uno de los factores más importantes en el éxito de Practo Ray fue que no utilizó ninguna herramienta o software de terceros. Por lo tanto, todos los datos fueron verificados por Practo primero y luego cargados en la base de datos. Con el uso de este software, los médicos pueden programar citas, acceder a registros de pacientes, administrar recetas y administrar otros servicios de atención médica. Además, para hacer que la búsqueda de atención médica sea más refinada, la compañía lanzó su motor de búsqueda de atención médica, Practo Search, donde los médicos y los pacientes pueden buscar digitalmente servicios de salud.

Lea más sobre esto aquí.

Al igual que con cualquier software de productividad de nivel empresarial, la “buena experiencia del usuario” es realmente difícil de cuantificar. Estos sistemas son intrínsecamente complejos y sirven a varias partes interesadas. Cada uno de estos grupos de interés tiene perspectivas y objetivos de UX que son importantes para ellos, todos los cuales deben ser efectivamente equilibrados (y algunos de los cuales pueden ser contradictorios). Entonces, ¿algún sistema tiene UX universalmente bueno para todos los interesados? La respuesta a esa pregunta es inequívocamente NO. Pero, ¿cada uno de los sistemas tiene algunas facetas de buenos UX para algún subconjunto de partes interesadas? Sí, por supuesto que sí; si no lo hicieran, no serían productos viables.

Creo que la verdadera pregunta que está haciendo es: ¿alguno de estos sistemas tiene más flujos de trabajo con buen UX que flujos de trabajo con UX incorrecto? Y la respuesta a eso se puede ver en los datos a los que hace referencia Dan: en general, los proveedores más pequeños (con menos flujos de trabajo y menos complejidad) tienden a tener mejores UX generales que los proveedores más grandes con más flujos de trabajo y complejidad.

Ahora, si aplicamos las pautas de Google Experience Design de necesitar 3 experiencias positivas para superar 1 negativa, podemos ver fácilmente por qué los médicos y proveedores responderían que todos los EHR son una mierda. Si no estamos entregando una gran experiencia de usuario para más del 75% de los flujos de trabajo de productos, entonces nuestra experiencia global es probable que sea negativa. Por lo tanto, hasta que lleguemos sistemáticamente por encima de .750, los productos se clasificarán como que tienen un UX deficiente.

Entonces, estoy de acuerdo con Dan en que todos los EHR no son una mierda, y la mayoría están entregando valor para al menos algunas de las partes interesadas. Pero también estoy de acuerdo con los proveedores en que, en general, los sistemas EHR más grandes y complejos no proporcionan un UX constantemente positivo. Estamos progresando pero el espacio problemático es muy grande.

Finalmente, argumentaría el subtexto de su pregunta, que es que si las empresas solo priorizaran UX, entonces los sistemas serían mucho mejores. Puedo hablar por mi empresa y tengo contrapartes en la mayoría de los grandes proveedores de HIT que estarían de acuerdo con el hecho de que hay una inversión significativa y una prioridad en UX y siempre hay (y siempre ha habido) una prioridad en escuchar a nuestros clientes. Pero este no es un problema rápido o fácil de arreglar. Estos son sistemas extremadamente grandes y complejos que tienen cientos de flujos de trabajo (con más añadidos constantemente) que abarcan múltiples productos y docenas de roles. Resolver los problemas de usabilidad y UX en la mayoría de los flujos de trabajo y roles llevará tiempo.

Lamentablemente, la prisa por la acreditación y la interoperabilidad de sistemas acreditados ha desplazado toda innovación. La idea de usar EMR en lugar de registros en papel no es una mala idea, pero cuando se combina con prácticas de software empresarial, ha creado infinidad de UX, especialmente para los médicos que se dan cuenta de que su tiempo no se gasta mejor al ingresar datos. Nuestro trabajo ha sido mejorar la interfaz de usuario, por lo que existen modos de usuario expertos. Esto podría ser especialmente útil para los usuarios que aún desean escribir en lugar de ubicar punteros sobre botones pequeños y menús desplegables. Pero los vendedores de EMR tienen poco o ningún incentivo para realizar este tipo de mejoras, incluso como modos de usuario expertos opcionales. Los problemas de UX son solucionables. El problema de la innovación del proveedor es más difícil. Tenemos el mismo problema con el software empresarial para la enseñanza en línea de la universidad. No es un problema técnico. Es un asunto de negocios y regulatorio.

En lo que respecta a los registros electrónicos de salud, diría que el sistema EHR debería ser una combinación de facilidad de uso fácil (es decir, una gran UX y UI) y debería ser completamente personalizable. Además de esto, debería ser capaz de darles a los practicantes, o médicos, o clínicos, una idea clara del flujo de trabajo. Deben poder replicar su flujo de trabajo y, por supuesto, ser capaces de actualizarlo y evolucionar hacia un entorno más potente.

Entonces, si realmente necesita estos dos trabajos para usted, entonces debe tratar de encontrar a los proveedores de EHR que estén dispuestos a ayudarlo a personalizarlo. Y es por eso que sugeriría blueEHR (anteriormente blueEHS). He trabajado con su producto, es aparentemente perfecto. Siempre hay una personalización sencilla y un excelente servicio y apoyo de su personal en todo momento.

Sugiero que busque EHR azul que es un producto de zhhealthcare.com.

Si bien estoy de acuerdo en que no existen sistemas de atención médica que tengan la “mejor” experiencia del usuario, tiendo a estar en desacuerdo sobre la “mejor” parte de la pregunta. Después de todo, ¿qué es “lo mejor”? Debería ser en comparación con otra cosa, no tenemos un punto de referencia.

Actualmente trabajo para una compañía llamada CareCloud que, como su nombre indica, está en el dominio de la salud. Desarrollamos software para proporcionar una premisa completa para una práctica médica o profesional. Y estamos fuertemente, sí fuertemente invertidos en la experiencia del usuario. Tenemos un equipo dedicado para el diseño y desarrollo de frontend. Visite el sitio web para más detalles: http://www.carecloud.com/

Y también tenemos un fuerte equipo de backend. Y sí, estamos disminuyendo el avance hacia la construcción de un ecosistema de salud. Tenemos doctores que tienen años de experiencia trabajando como asesores comerciales para nosotros constantemente tratando de mejorar el software. Espero que con el financiamiento de $ 20 millones de la Serie A alcanzaremos nuevas alturas y nos esforzaremos para servir mejor en este dominio.

Hace unos días estaba viendo videos de demostración de diferentes software EHR, allí vi una demostración del software Electronic Health and Medical Records que fue realmente buena. Estoy compartiendo el enlace espero que a la gente también le guste. Seminario web sobre el sistema de gestión electrónica de la salud y la práctica web de MTBC

Ninguna. Justificación: el usuario final de EHR es muchas veces una enfermera. La enfermería es la profesión de atención médica más grande del país , con más de 3.1 millones de enfermeras registradas en todo el país. Los Endusers generalmente no son parte del desarrollo Front End. Eso es un problema. Las compañías de software que realmente valoran el UX encontrarán la manera de involucrar al usuario final con anticipación. Puede ser más fácil enseñarle a una enfermera acerca de Software Dev (muchos de nosotros crecimos con Devices in hand) de lo que es enseñarle a un Desarrollador sobre las complejidades de los Flujos de Trabajo de la Industria de la Salud.

La demanda de software de registros médicos y de salud en la actualidad es muy alta en la industria de la salud. Muestra cómo la industria de la salud se está convirtiendo en un día digital por día. La experiencia del usuario es el problema más importante que se presenta en el software EHR, que debería ser eficaz y fácil de usar, ya que este software también es para los usuarios, por lo que la experiencia de UX debería ser máxima. Tengo una empresa de software reconocida que proporciona soluciones de calidad de HealthCare IT a los clientes.

Hay muchos softwares de asistencia sanitaria que compiten en todo el mundo. Sin embargo, cada compañía ofrece sus servicios únicos que pueden adaptarse a su gusto. Recomiendo PracticeMax ya que han estado en servicio durante mucho tiempo. He usado sus servicios antes y no me puedo quejar con el servicio que recibí de ellos. Depende de usted decidir si el software o la compañía es el mejor entre los que ha probado anteriormente.