L’emergence des APIs de santé

par Tarek Ibrahim

Bien qu’un peu partout, les APIs se soient imposées comme le dispositif standard d’interopérabilité, le monde de la Santé a été longtemps sur la défensive, pour des questions de sécurité mais aussi par manque de motivations. Les choses ont changé cependant car plusieurs facteurs font des APIs une opportunité attractive. D'autant plus que le paradigme se géneralise dans le secteur.

Apeyi vous dites?!

Une API (Application Programming Interface) est une interface entre logiciels. Elle permet à un développeur d’intégrer dans ses programmes des fonctionnalités qu’il n’a pas réalisé lui même.

Si vous voulez en savoir plus sur ce qu’est une API et comment elles sont utilisées, j’ai inclu des liens en fin de cet article.

Les APIs en tant qu’avantage compétitif

Il est de rigueur pour les grandes plateformes digitales de fournir des services sous forme d’APIs à qui veut bien les utiliser. Google Maps, par exemple. Vous l’avez probablement sur votre téléphone? Il est aussi intégré dans des milliers d’applications qui utilisent son API pour un nombre impressionnant de cas d’utilisation, dans l’Environnement, l’Assurance, le Tourisme, la Santé, et bien d’autres verticales économiques(1). Google, et tous les autres géants de la technologie s’assurent ainsi des revenus grâce à une offre API commerciale, mais surtout, un véritable statut de Plateforme, car ils sont d’autant plus ubiquistes et inaliénables du tissu économique quand un écosystème d’applications se développe autour de leurs services. Selon Harvard Business Review, présenter ses services sous forme d’API est un atout stratégique pour les entreprises(2).

En outre, les développeurs aiment les APIs. Et ce, en vertu d’une “Directive Première” des ingénieurs, qui consiste à ne pas réinventer la roue. Ils préfèrent donc utiliser une API ou une librairie quand c’est une alternative viable, au lieu d’implémenter eux-mêmes la fonctionnalité. Regardez le principe “Not Invented Here” pour mieux comprendre cet aspect de la culture du génie logiciel.

Les 10 dernières années ont ainsi vu une explosion de services de “niche” qui se basent sur les APIs de grandes plateformes pour être compétitifs sur leur propre marché, voire même pour exister sur leur marché. Pensez à Uber, par exemple, qui a pu lancer sa fameuse plateforme de transport pour un effort équivalent à 5000 heures/homme(3), soit environ 6 mois de boulot pour une équipe de 5 personnes. Uber a utilisé Google Maps, Twilio, Paypal et de nombreuses autres APIs, sans quoi le coût pour lancer son appli aurait été prohibitif.

Le secteur sanitaire, en décalage de phase

Bien qu’un peu partout, les APIs se soient imposées comme le dispositif standard d’interopérabilité, le monde de la Santé a été longtemps sur la défensive, à juste titre, puisque il y a des questions de sécurité de données sensibles. Il y a surtout l’absence de motivations particulières pour les acteurs de la santé : Pourquoi supporter la charge de développer et opérer des APIs sans bénéfices tangibles?

Heureusement, les bénéfices se matérialisent peu à peu, principalement grâce à trois facteurs :

Premier facteur : Quantified self

Il a d’abord fallu l’émergence du Quantified self avec la prolifération des mobiles et autres objets connectés intelligents (smartwatch, podomètres, …), qui offrent tous des APIs. En se répandant parmi le grand public, ces technologies ont ouvert la voie à toutes sortes d’applications qui touchent, de près ou de loin, à la santé.

Deuxième facteur : La santé fondée sur la valeur

Le concept de Value Based care fait partie de ce genre d’idées qui semble tellement évident qu’on se demande pourquoi cela n’a pas été fait plus tôt! C’est un paradigme économique qui consiste, pour simplifier, à mieux rémunérer l’Hôpital quand le patient n’est pas malade, contrairement au traditionnel modele “prestations de services” ou l’hôpital est rémunéré d’autant plus que le patient est malade.

Evidemment c’est plus facile a dire qu’a faire, car il faut réformer le mode de remboursement et faire évoluer les méthodes de coordination de soin. Il est à noter cependant que toutes les initiatives de ce genre, menées par exemple en Suède et aux Etats Unis, ont été couronnées de succès, avec une amélioration de la qualité de vie des patients, des conditions de travail des praticiens et une réduction substantielle du coût pour l’assurance maladie.

Le paradigme “Value-Based” va sans doute se généraliser dans le futur. Quoi qu’il en soit, cela requiert un suivi beaucoup plus régulier des patients par une équipe plus élargie et via une boucle de feedback plus courte. Ce qui se traduit par une dépendance plus forte sur l’échange numérique de données en temps réel. Dans ce paradigme, l’interopérabilité des systèmes d’informations est un élément crucial, qui est largement facilité par la disponibilité d’APIs.

Troisième facteur : le rôle des gouvernements

Dans certains pays, les gouvernements accélèrent délibérément l’adoption des APIs par les acteurs de la santé. Aux Etats Unis, le gouvernement fédéral vous accorde des avantages financiers attractifs si vous êtes un centre hospitalier, pharmacie ou laboratoire médical qui adhère à un “calendrier d’interopérabilité”. En Corée du sud, c’est l’Etat lui même qui a mis en oeuvre une base de données centrale de tous les fichiers médicaux avec un accès API. Il est notable qu’en Tunisie, le gouvernement a adopté un programme de developpement de la sante numerique qui prévoit des actions de facilitation(4).

Tour d’horizon des API de santé

Donc, les vents favorables font que les offres API se développent comme jamais. Elles sont ici classées en quatre catégories :

Les fournisseurs de logiciels

Les EHR (abbr. Electronic Health Records, dossier médicaux électroniques ) sont les logiciels de gestion intégrés que les hôpitaux, cabinets médicaux, pharmacies, et autres organismes de la santé utilisent pour leurs opérations quotidiennes. Les entreprises qui commercialisent ces logiciels de gestion sont naturellement bien placées pour proposer l’interopérabilité via des APIs. Les EHR incorporent de plus en plus un accès API dans leurs dernières moutures.

Les APIs EHR sont extrêmement utiles car elles ouvrent le dossier médical numérique au patient, ou a une tierce partie avec l’accord du patient. Cela inclut des données sur les prescriptions, procédures, imagerie, et autres données cliniques, qui peuvent être utilisés au service du patient dans un autre contexte applicatif.
Ces produits sont bien disponibles, encore faut-il que les hôpitaux les intègrent dans leurs systèmes d’informations. Ce que beaucoup n’ont pas encore fait. Un rapport publié en 2016 par California Health Foundation indique que XXX % des hôpitaux n’ont pas encore franchi le pas(1).

Les 5 plus gros fournisseurs EHR aux Etats-Unis, totalisant un Chiffre d’Affaire de 6.4 milliards de dollars ont tous déjà introduit des modules API dans leurs solutions.
Nextgen, ci-contre, a baptisé son initiative “Connected Health”. Mais seulement xx% des hôpitaux aux etats unis disposent d’une API au sein de leur systèmes d’information.

Objets connectés et quantified-self

310 millions d’objets “wearable” ont été vendu en 2017. Les smartwatch, coach personnel et fitness tracker comptent pour plus de la moitié. Ces objets ont des capteurs intégrés pour observer des signes vitaux et le niveau d’activité.

Chaque fabricant propose des APIs pour ses produits. L’adoption du format API est quasi unanime : vous en trouverez presque toujours une, du moins pour les produits grand publics.

Les constructeurs n’accordent pas toujours la meme attention a la partie API de leur produit. C’est pour cela que la qualité des APIs varie. Cette variation se traduit par une documentation plus ou moins complète, la fréquence de mise à jour des données, et bien d’autres aspects qui facilitent (ou pas) l’intégration.

Les APIs du génome

Ceux-là méritent une catégorie qui leur est propre. Il s’agit de services numériques autour du génome qui sont aussi disponibles en API.
Soit pour accéder ou échanger des données génétiques (23andme par exemple) soit pour faire des calculs intensifs dans le cloud (Google Genomics). Si le sujet vous intéresse, je le développe un peu plus dans un autre article.

Les agrégateurs

Il y a de plus en plus d’APIs de la santé, mais la nature unique de la réalité dans le secteur a produit des systèmes propriétaires qui ne sont pas vraiment compatibles les uns avec les autres.

“Si tous mes utilisateurs avaient le même modèle de bracelet connecté ou s’ils allaient tous au même hôpital, ce serait plus simple. Mais ce n’est que rarement le cas dans la vraie vie.”

Par exemple, le marché des objets connectés est encore très fragmenté. Ci-contre, 45% du volume des ventes est fait par des dizaines de marques différentes. Autant d’APIs a integrer!

Donc paradoxalement, si chaque APIs parle sa propre ”langue”, plus il y en a, moins il y a d’interopérabilité. Aussi, une classe de méta-APIs ont vu le jour. On dit qu’elle sont “méta” dans la mesure où, comme les “méta moteurs de recherche”, qui vont chercher sur d’autres moteurs de recherche, les méta APIs vont fédérer plusieurs APIs et les présenter comme si c’était une seule.

Il y a déjà un marché pour ce type de produit. A Human API par exemple, nous développons et commercialisons une méta API qui supporte la majorité des appareils connectés, ainsi que bon nombre de systèmes hospitaliers, pharmacies, etc. Ce produit est déjà en ligne avec des millions de requêtes par jour. Human API n’est pas le seul fournisseur de ce type de solutions. Le secteur est en pleine explosion. Il y a notamment des agrégateurs spécialisés dans les capteurs (Validic) ou l’assurance (Eligible)

Pour conclure

Les APIs sont en marche bien qu’il demeure encore beaucoup d’obstacles à surmonter avant qu’elles se répandent dans la santé comme elle l’ont fait dans d’autres secteurs. Quoi qu’il en soit, le paradigme API porte la promesse de l’interopérabilité et la liquidité des données. Facteurs essentiels, s’il en est, pour réaliser ce que Pr Muir Gray appelle “La troisième révolution de la santé”, une révolution faite par les citoyens, le Savoir et l’Internet.

Sources