Si te dedicas a la innovación en el sector Salud, o tu servicio tiene casos de uso en el sector Salud, este artículo te interesa. Seguramente ya conoces la importancia estratégica que ha cobrado la “apificación” de los servicios y el concepto de empresa “API-first”. Si es así, sigue leyendo porque te presentamos las 6 características clave que debe tener tu API para Salud.
“Apificar” tus servicios, es decir, ofrecerlos a través de APIs, te va a permitir llegar a más clientes, simplificar tu integración en sus aplicaciones, y adquirir una ventaja competitiva importante. Te permitirá también ahorrar costes y abrirá nuevos modelos de negocio y colaboración para tu empresa.
Pero adoptar el concepto “API-First” no es un asunto menor.
Una arquitectura organizacional que sitúa a las APIs en el centro de la innovación y el desarrollo de las soluciones, las convierte en el producto principal sobre el que se construye toda la experiencia de los usuarios desde aplicaciones móviles y plataformas SaaS.
En esta arquitectura debes pensar en el desarrollador del cliente como primer usuario de tu API, puesto que será quien la pruebe y la integre en el software de tus clientes, y el principal artefacto sobre el que debes trabajar es la especificación de la API en un contrato.
El primer aspecto que se debe cuidar a la hora de desarrollar una API de Negocio y más en concreto de Sanidad es el “contrato” de la API. Entre los distintos lenguajes existentes para especificar el contrato de una API, hay un claro ganador en la industria: OpenAPI.
Por tanto el punto de partida para definir y desarrollar una API empresarial debe ser la especificación de la misma mediante un contrato basado en OpenAPI 3.X Estamos ante un “estándar de facto” en la industria, y la cantidad de herramientas que le dan soporte es enorme.
Podemos comenzar a desarrollar la definición con un simple editor y de inmediato podremos distribuirla a nuestro equipo de desarrollo para implementar un prototipo, a nuestro equipo de QA para que implementen las pruebas y al equipo de desarrollo de producto para que puedan implementar las soluciones en base a ese contrato, incluso cuando no hay nada de código implementado todavía.
Pero ¿qué incluye este contrato para que sea tan versátil y qué es necesario tener en cuenta?. Vamos a verlo de manera resumida.
En primer lugar hay que completar aspectos puramente formales, como la descripción de la API, una ruta de publicación de los endpoints de desarrollo, pruebas y producción, el control de versiones, etc. Un aspecto importante que se incluye en esta sección es la definición de los niveles de seguridad y acceso que se emplearán en los recursos y las operaciones. Conviene definirlo desde el principio para ir asignando a cada recurso.
En segundo lugar la definición de los recursos (modelo de objetos) que se van a emplear definiendo de forma jerárquica los tipos de datos que los definen. En este punto hay que indicar que los recursos de una API deben estar representados en JSON, y un plus es acompañar a los tipos de datos con una referencia al JSON Schema.
Y por último las rutas (URI) a los recursos y las operaciones que se pueden aplicar sobre ellos. Básicamente el equivalente a un CRUD para los recursos (Create, Read, Update, Delete)..
Pero sobre todo, todo esto deberá estar acompañado de propiedades que nos permitan describir y documentar cada uno de estos aspectos de una manera formal y sencilla. Por ejemplo, podemos agregar ejemplos a los parámetros en cada petición y a las respuestas recibidas.
¿Hemos mencionado ya que Nubentos es “openAPI compliant”?
El segundo apartado al que debemos prestar atención desde el principio se refiere a la arquitectura.
Debemos mantener un estilo de arquitectura API RESTful y cumplir el principio HATEOAS, respetar los estándares y las RFCs que dan soporte al protocolo HTTP, los códigos de Error HTTP, cabeceras y códigos.
En el siguiente enlace puedes descargar un resumen de los principales códigos de error HTTP y en este breve vídeo te explicamos los más comunes.
Todas las APIs que se publican en Nubentos, son expuestas en nuestra plataforma como APIs REST estándar. Por tanto, ofrecemos la estandarización técnica de cualquier API para la Salud de forma automática.
A la hora de desarrollar una API de Salud, un aspecto fundamental es la seguridad del dato, a todos los niveles.
Nuestra API puede ser una puerta a una información muy sensible y por tanto debemos asegurarnos de seguir las mejores prácticas en cuanto a privacidad y normativas de seguridad.
Por ello es recomendable que nuestra organización cumpla el marco normativo que se aplique en nuestro país o al tipo de servicio que prestamos. Desde la GDPR, pasando por el Marcado CE o la HIPAA, o la norma ISO 27001 y los informes de cumplimiento SOC 2.
Como mínimo, todo ello nos ayudará a proyectar la suficiente confianza como para permitirle manejar los datos de nuestros usuarios. Pero en muchos casos, serán requisitos imprescindibles para que nuestros potenciales clientes del sector Salud se decidan por nuestra solución.
En Nubentos ofrecemos a nuestros clientes toda la información relativa a las regulaciones que cumplen las APIs que se publican en nuestra plataforma.
De esta forma, facilitamos dos cosas:
- Que las mejores soluciones en esta materia destaquen sobre el resto
- Que nuestros clientes tengan la información que necesitan para encontrar las soluciones que puedan usar en sus proyectos.
El primer detalle que hemos explicado en este artículo es el contrato. Un elemento que introduce una capa de estandarización muy importante, pero independiente del sector. Podemos decir que es una estandarización técnica.
Pero hablando del sector Salud, existen numerosos casos de uso que están cubiertos por el estándar más importante de la industria: la familia de estándares HL7 y en concreto su última versión, FHIR.
Añadir al diseño de tu API un nivel de estandarización de negocio como este supone un importantísimo valor añadido para tu solución. Podríamos decir que permitirá a tu servicio “hablar el mismo idioma” que la mayoría de los productos software que gestionan el día a día de un Hospital, en prácticamente todo el mundo.
No es una característica imprescindible, porque de hecho el sector salud integra actualmente numerosas soluciones que no siguen el estándar HL7. Pero incorporar esta característica a tu solución te da una ventaja competitiva enorme.
La dificultad está en tener el nivel de conocimiento y experiencia necesario para llevar a cabo esta estandarización y sobre todo mantenerla.
Por suerte, en Nubentos ofrecemos esta posibilidad a las APIs que se publican en nuestro catálogo. Nosotros nos encargamos de la interfaz estándar de tu solución, para que los potenciales clientes de tu API la encuentren aún más interesante y atractiva respecto de tus competidores.
Al principio de este artículo, mencionábamos que en una empresa “API-first” aparece un nuevo tipo de usuario a tener en cuenta: los desarrolladores de nuestros clientes.
Es un error desatender la importancia de este perfil de usuario técnico, porque en muchas ocasiones será un perfil cercano al responsable técnico, o será él mismo, y por tanto tendrá influencia en la toma de decisiones del cliente. Además, su feedback servirá para confirmar o desmentir que tu API está bien diseñada y es fácilmente integrable en su software.
Es importante acompañar tu API con ejemplos, código listo para integrar y un soporte corporativo que responda rápido a sus preguntas, así como juegos de datos de prueba.
Lo más habitual y lo que espera cualquier desarrollador acostumbrado a trabajar con APIs de terceros, es ofrecer entornos sandbox para hacer pruebas de forma segura. El apartado de la Observabilidad de las acciones que se realizan con la API proporcionando logs adecuados y trazables es otro punto a favor.
¿Y si tu servicio es un modelo de IA que básicamente va a responder lo mismo en un entorno productivo que en un entorno sandbox? Bien, en estos casos debes al menos ofrecer tramos de acceso gratuito que permitan probar tu API sin riesgos.
Este es un asunto a analizar con detalle. ¿Qué resulta más costoso? ¿Montar un entorno sandbox que fuerce la respuesta para que no pueda usarse en entorno productivo, pero permita probar tu servicio de forma segura y separada de la versión productiva? ¿O permitir un acceso limitado gratuito a tu servicio productivo, arriesgándote a que el uso de prueba perjudique el aprendizaje de tu modelo de IA?
En Nubentos todas las APIs ofrecen acceso a un entorno sandbox, o bien un tramo de uso freemium. En los modelos de IA que abundan en el entorno de la Salud, siempre aconsejamos invertir esfuerzo en ofrecer un acceso sandbox a una versión aparte del algoritmo cuya respuesta sea forzada a, por ejemplo, un mismo resultado, o con limitación en los casos de uso, etc.
Llegamos al que curiosamente es uno de los aspectos que más a menudo se descuidan en el diseño de una API empresarial en general, y en particular para el sector Salud.
Con frecuencia encontramos empresas que obligan al cliente a realizar un proceso manual de alta y obtención de claves, para después poder usar las credenciales obtenidas en la integración de su API en su software.
Este enfoque es recorrer el camino a medias, y supone una oportunidad perdida para ofrecer una verdadera capacidad de integración “marca blanca” en tu cliente, una demanda cada vez más frecuente en el sector Salud.
Y sobre todo, perjudica seriamente la escalabilidad de tu API.
Una API es la fachada de tu empresa en internet, y para que sea escalable y 100% integrable en el software de cualquier cliente, debe ofrecer los recursos necesarios para gestionar el control de acceso. El mecanismo más usado en la industria es OAuth2.
Y relacionado con el acceso debes ofrecer una serie de ingredientes adicionales, como es un SLA, soporte técnico y soporte de negocio.
Para terminar, es importante que puedas monitorizar y medir el uso que realizan tus clientes de tu API a través de sus integraciones. Dispondrás de una fuente de valiosa información, acerca de los recursos más usados y los menos usados, los casos de uso más demandados, etc. Podrás orientar la evolución de tu servicio de manera más cercana a las necesidades del mercado, y por tanto, mejorar tu product-market fit.
En Nubentos disponemos “de serie” del protocolo OAuth2 para todas las APIs publicadas en nuestro catálogo, y ofrecemos a nuestros proveedores un panel de control para observar distintos aspectos del uso de sus APIs por parte de los clientes que las integran en sus productos.
En este artículo hemos hecho un recorrido sobre las 6 características clave que debe tener tu API para Salud. Hay más detalles a tener en cuenta, y en Nubentos tenemos la tecnología, el modelo de negocio, el expertise y los partners adecuados para que tu API esté lista para la digitalización del sector Salud mediante APIs. Un cambio que ya ha comenzado y que irá en aumento en los próximos años.
Publicar tu API para el sector Salud en Nubentos te permite usar nuestro canal de alta escalabilidad, estandarización, ventas e integración de forma totalmente gratuita, y añadir a tu proyecto nuestra fuerza de marketing y ventas para atraer más clientes a tu API, ahorrándote el esfuerzo recurrente de integrarla en cada nuevo cliente.
Para empezar ya a publicar tu API en Nubentos, sólo accede a nuestro asistente y regístrate. Estaremos encantados de estudiar tu caso y acompañarte en el proceso.
