La diffusion d’événements et le Saint Graal de la santé

C’est une histoire de soins de santé et de technologie, mais elle commence, de tous côtés, sur LinkedIn. À la fin des années 2000, LinkedIn était devenu le premier réseau professionnel en ligne du pays. Il comptait plus de 50 millions d’utilisateurs et reposait sur un trésor de données, y compris les antécédents scolaires, les parcours professionnels et les relations interpersonnelles de nombreux leaders de l’industrie hautement respectés et recherchés. Comme la plupart des entreprises en ligne à l’époque, LinkedIn a écrit toutes ces données dans une base de données traditionnelle. Lorsqu’un utilisateur effectuait une recherche sur LinkedIn, l’application interrogeait la base de données et afficherait les résultats. Cela aurait certainement dû être suffisant pour un annuaire. Le fait était que LinkedIn aspirait à être bien plus qu’un annuaire.

La grande réalisation

LinkedIn s’est rendu compte que le fait d’être le lieu de rassemblement des professionnels lui permettait de proposer une gamme de services à valeur ajoutée au-delà de la simple publicité en ligne, tels que la création de carrière, le recrutement et le contenu. La clé pour poursuivre ces services était de créer une couche de renseignement sur toutes les données que LinkedIn collectait. Il s’est avéré que les profils et les CV – ce à quoi nous pensons quand nous pensons à LinkedIn – ne représentaient en fait qu’une très petite partie des données que LinkedIn collectait. La plupart des données concernaient l’activité des utilisateurs sur la plateforme – les clics, les recherches, les commentaires, les messages et les vues. Et ces données étaient non seulement massives mais en constante augmentation. Après tout, plus de cinquante millions de personnes utilisaient continuellement le site, et des millions d’autres s’y inscrivaient chaque année. Les systèmes de l’entreprise se noyaient littéralement dans un flot de données.

Pourquoi LinkedIn avait-il besoin d’enregistrer toutes ces données en premier lieu? Pourquoi ne pas s’en tenir aux profils et aux historiques de carrière? Le moyen le plus simple de comprendre l’importance de ces données est de prendre un exemple concret. Imaginez deux professionnels: Aaron et Zoe. Tous deux sont diplômés de l’Université Emory et ont passé les cinq dernières années à travailler pour le bureau d’Atlanta de Coca-Cola dans le département marketing. Sur la base de leurs profils, Aaron et Zoe se ressemblent. Cependant, imaginons que nous sachions également que Zoe a passé le mois dernier à se connecter à LinkedIn et à consulter les offres d’emploi à New York. Si LinkedIn ne collectait pas d’informations sur l’activité des utilisateurs sur la plateforme, il ne se rendrait pas compte que Zoe cherchait un emploi dans une autre ville et il ne serait pas en mesure de proposer des services de recherche d’emploi à Zoe ou aux recruteurs new-yorkais à la recherche de professionnels comme Zoe.

Une autre façon d’y penser est que si les profils et les CV vous indiquent où quelqu’un est allé, ce sont le comportement et l’activité en ligne qui vous indiquent où quelqu’un va. À son tour, savoir où quelqu’un va est extrêmement précieux du point de vue de la fourniture de services marketing ciblés et à valeur ajoutée. Ainsi, l’analyse de rentabilisation de la collecte de ces données était claire. Le défi était que les bases de données traditionnelles avaient été construites pour stocker des données d’état, c’est-à-dire des données qui ne changent pas fréquemment – des données telles que des profils et des CV. Ce dont LinkedIn avait besoin, c’était un moyen de capturer toutes les données d’activité générées par ses dizaines de millions d’utilisateurs, de fournir ces données aux services qui en avaient besoin et de faire tout cela en temps réel.

La solution innovante

Dans un premier temps, LinkedIn a tenté de résoudre ce problème avec une approche d’architecture orientée services (SOA) traditionnelle. Ils ont créé des API pour leurs magasins de données qui permettaient à d’autres systèmes de leur infrastructure de demander des données à ces magasins de données. Le problème avec cette approche était que les systèmes qui avaient besoin des données n’avaient aucune idée du moment où les données avaient changé. Une façon de résoudre ce problème consistait à envoyer des notifications chaque fois que les données changeaient, mais lorsque les données changeaient tout le temps et qu’il y en avait tellement, cela entraînerait des volumes d’appels de services Web entre les magasins de données et les systèmes consommateurs. qui n’étaient pas viables du point de vue de la fiabilité ou de la vitesse.

Encore une fois, un exemple concret peut aider à illustrer le problème. Imaginez que le magasin de données LinkedIn soit un gars nommé Larry avec une excellente mémoire. Il travaille avec Rachel, qui s’occupe du recrutement, avec Mary qui s’occupe du marketing, avec Sage qui s’occupe de la messagerie et avec Steve qui s’occupe de la sécurité. Lorsque Larry reçoit une information liée au recrutement, comme un utilisateur qui consulte une offre d’emploi, il envoie un message instantané à Rachel. Lorsqu’il reçoit une information liée au marketing, comme un utilisateur cliquant sur une annonce, il envoie un message instantané à Mary. Et lorsque Larry reçoit une information liée à la messagerie, comme l’envoi d’un nouveau message, ou à la sécurité, comme plusieurs tentatives de connexion infructueuses, il envoie un message instantané à Sage ou Steve, respectivement. À leur tour, ses collègues répondent à ses messages instantanés en demandant à Larry de fournir plus de détails sur ce qui s’est passé. Quelle offre d’emploi l’utilisateur a-t-il consultée? Sur quelle annonce l’utilisateur a-t-il cliqué? À qui l’utilisateur a-t-il envoyé le message? À partir de quelle adresse IP l’utilisateur a-t-il tenté de se connecter? Comme vous pouvez le voir, tous ces va-et-vient sont très inefficaces et si Rachel va déjeuner ou Steve prend une pause-café, toute possibilité de tout capturer en temps réel tombe complètement en panne.

L’équipe d’ingénierie de LinkedIn s’est rendu compte qu’au lieu que Larry ait des conversations séparées avec Rachel, Mary, Sage et Steve, ce dont ils avaient besoin était un moyen pour Larry d’écrire simplement tout ce qui se passait dans un journal en cours d’exécution et pour ses collègues de le regarder. ce journal et lisez les parties qui les intéressaient. Ils ont considéré les choses comme ceci: Larry est un producteur de données et ses collègues sont des consommateurs de données. Nous pouvons classer toutes les données enregistrées par Larry par sujet, puis Rachel, Mary, Sage et Steve pourraient simplement s’abonner aux sujets qui les intéressent. Cela élimine les allers-retours entre Larry (producteur de données) et ses collègues (consommateurs de données). Il permet également aux consommateurs de données de s’abonner à des sujets qui se chevauchent. Par exemple, Rachel (recrutement) et Mary (marketing) aimeraient savoir qu’un utilisateur a cliqué sur une offre d’emploi, afin qu’elles puissent toutes deux s’abonner au sujet «offre d’emploi».

En utilisant cette approche, LinkedIn a réussi à construire un système qui lui a permis de traiter d’énormes quantités de données en temps réel et d’offrir une expérience personnalisée à ses plus de 300 millions d’utilisateurs. LinkedIn a appelé le système Kafka et, en 2011, l’a mis à la disposition de la communauté d’ingénieurs open source via l’Apache Software Foundation à but non lucratif. Kafka a représenté un bond en avant pour la gestion massive des flux de données et a rapidement été utilisé dans de nombreux secteurs. Des sites de commerce électronique massifs, comme Walmart.com, utilisaient Kafka pour gérer des millions de pièces d’inventaire en temps réel. Les mastodontes de l’économie gig, comme Uber et Lyft, utilisaient Kafka pour suivre des millions de voitures sur les routes. Les puissances des médias numériques, comme Netflix et Pinterest, utilisaient Kafka pour suivre et réagir instantanément aux actions des utilisateurs.

Le changement conceptuel

Si Kafka était une technologie transformatrice, la contribution la plus durable de LinkedIn était peut-être conceptuelle. Son approche de la construction de Kafka a montré que, pour de nombreuses industries technologiques, les informations les plus précieuses ne reposent pas sur des données d’état, mais plutôt sur des données d’événements. LinkedIn a appris que l’information la plus exploitable sur Zoe n’était pas qu’elle travaillait chez Coca-Cola à Atlanta, mais qu’elle cherchait activement un nouvel emploi à New York. De même, Walmart a appris que les informations les plus exploitables sur son inventaire n’étaient pas qu’il disposait d’un certain nombre de widgets, mais qu’il pouvait déterminer l’emplacement et la destination de chaque widget en temps réel. Uber et Lyft ont réalisé que ce qui importait, ce n’était pas seulement le nombre de voitures qu’ils avaient sur la route, mais aussi où se trouve chacune de ces voitures à un moment donné et où elle se dirige. Et Pinterest et Netflix ont appris que ce qu’un utilisateur faisait sur ses plates-formes à un moment donné était souvent plus exploitable que son précédent historique de diffusion et de publication.

Ainsi, les données d’événements sont essentielles pour la prise de décision en temps réel. Dans tout cas commercial où nous devons réagir à la façon dont quelque chose a changé plutôt qu’à ce qu’il est, nous devons maîtriser le traitement des données d’événements. Kafka et d’autres systèmes de traitement d’événements ont propulsé une révolution dans la gestion des flux de données à grande échelle et nous avons ressenti cette révolution. Les sites sur lesquels nous achetons, expédions, diffusons, étudions et socialisons ont commencé à avoir l’impression de répondre à chacune de nos actions et de chaque clic, parfois même à anticiper nos intentions. Pourtant, alors que tout ce qui concerne nos vies est apparemment transformé en intelligence exploitable pour nous accélérer vers notre destination, il manque un élément énorme, et c’est sans doute celui qui a le plus d’impact sur notre bonheur.

C’est là que l’histoire tourne, car la pièce manquante, comme vous l’avez probablement deviné, est notre santé. Le corps humain est une machine extrêmement complexe qui publie constamment des données d’événement pouvant fournir des informations exploitables. Si elles sont traitées suffisamment tôt, ces données peuvent être utilisées pour résoudre les problèmes avant qu’ils ne se transforment en problèmes qui nous déposent au cabinet du médecin ou à la salle d’urgence. Et quand nous voyons un médecin, que se passe-t-il? Le médecin essaie d’imiter un processeur de flux de données, en examinant vos signes vitaux, vos symptômes et vos systèmes. Les seules autres données sur lesquelles le médecin peut s’appuyer sont les données sur l’état périmé de votre dernière visite, qui peut avoir eu lieu des années dans le passé. Le flux d’événements sur la façon dont votre corps a changé au cours des mois, semaines et jours qui ont suivi est une boîte noire.

Le médecin ne vous voit que lorsque vous vous sentez malade, c’est comme si LinkedIn ne voit que lorsqu’un utilisateur a déjà changé d’emploi, ou Uber apprend uniquement où se trouvent ses voitures après avoir manqué une prise en charge, ou Walmart découvre seulement que c’est à court de widgets après que des milliers de commandes clients n’ont pas été satisfaites. Bien sûr, même si nous pouvions enregistrer tous nos signes vitaux, nos symptômes et les performances de nos systèmes en portant des capteurs chaque jour, ce serait beaucoup trop de données à examiner pour un médecin. D’un autre côté, il n’y a aucune raison technique pour laquelle nous ne pourrions pas coupler des capteurs avec un système de traitement de flux d’événements qui recherche des modèles et crée des alertes au moment où nous commençons à nous attaquer à un problème de santé.

L’impact pour les assureurs

Notre santé n’est pas seulement un problème pour chacun de nous individuellement, mais aussi un problème macro pour les assureurs maladie et les organisations de soins gérés qui ont un intérêt financier direct à nous maintenir en bonne santé. Alors que vous et moi sommes principalement occupés par nos propres trajectoires de carrière, LinkedIn est également intéressé par les trajectoires de carrière de moi, de vous et de chacun de ses trois cent millions d’utilisateurs. De même, les grands payeurs de soins de santé doivent trouver un moyen de gérer efficacement les trajectoires de santé de chacun de ses millions d’inscrits.

Les progrès de l’électronique grand public ont rendu disponibles un niveau sans précédent de flux de données. Par exemple, la dernière Apple Watch prend en charge non seulement le suivi des activités pour la marche, le sommeil et l’exercice, mais également la surveillance de la fréquence cardiaque et la détection des chutes. Le défi pour les payeurs de soins de santé est d’acquérir ou de créer des systèmes capables de prendre toutes ces données, de les combiner avec des réclamations et des données de contact basées sur les fournisseurs, et de générer des informations exploitables en temps réel.

Historiquement, les assureurs maladie ont construit leur activité autour de données d’état plutôt que de données d’événements. L’activité d’assurance traditionnelle est basée sur des tableaux actuariels, qui fournissent des statistiques relatives à l’incidence des événements couverts au sein d’une population. À leur tour, les tableaux actuariels sont compilés sur la base de décennies de données historiques, qui ne changent pas de jour en jour, de semaine en semaine ou même de mois en mois. Sur le spectre des données d’état par rapport aux données d’événements, les tables actuarielles sont à peu près aussi d’état que l’état peut obtenir. À l’aide de données actuarielles, les assureurs maladie fixent les couvertures et les primes à un niveau plus que suffisant pour couvrir les coûts attendus des services de santé pour leur population affiliée. Compte tenu de cette approche, pourquoi les assureurs seraient-ils intéressés par les données d’événements?

La réponse est liée à la montée en puissance des soins basés sur la valeur (VBC). Dans les modèles basés sur la valeur, les organisations de soins gérés, dont beaucoup incluent des assureurs maladie, reçoivent des primes et des niveaux de service fixes pour chaque inscrit d’un payeur en amont, tel qu’un programme Medicare ou Medicaid. Dans les contrats VBC, les assureurs ne peuvent pas simplement augmenter les primes ou réduire les services lorsque les coûts des soins de santé augmentent, il ne leur reste donc qu’une seule option: garder les inscrits en meilleure santé. Et comment garder des millions d’inscrits en meilleure santé? En déterminant ce qui arrive à leur santé entre toutes ces visites chez le médecin et à l’hôpital et en identifiant les opportunités de détecter les problèmes de santé avant que ces visites ne deviennent nécessaires en premier lieu. Et comme nous l’avons déjà vu, les données d’événement sont la clé pour y parvenir.

Le Saint Graal

Quand j’étais à l’école primaire, je me souviens avoir vu un film intitulé “L’Indien dans le placard”. Il s’agissait d’un jeune garçon à qui on a offert une armoire en bois d’une qualité très spéciale: tout jouet placé dans l’armoire a été magiquement animé. Le garçon découvre cette propriété du placard quand il donne vie par accident à la figurine d’un guerrier amérindien nommé Little Bear. Lorsque Little Bear est accidentellement blessé, le garçon donne vie à une autre figurine – un médecin de l’armée britannique de la Première Guerre mondiale – pour soigner Little Bear.

Au cours de mes années de travail avec des entreprises de soins de santé, j’ai souvent eu l’occasion de réfléchir à ce film, car de nombreuses initiatives de soins de santé visent en réalité à trouver un moyen de placer un petit médecin dans la poche de chaque personne qui serait en mesure de surveiller, d’éduquer, et guider la personne avant qu’un problème ne devienne si grave qu’il nécessite une hospitalisation ou une intervention chirurgicale. Aujourd’hui, nous nous trouvons dans un monde où un type différent d’intelligence vit dans la poche de chacun: le smartphone.

Le smartphone fournit un hub pour les capteurs, tels que les montres intelligentes et les appareils portables, qui deviennent de plus en plus sophistiqués pour suivre notre biométrie. Nous enregistrons déjà nos pas, notre sommeil, notre exercice et notre fréquence cardiaque. D’ici peu, nous pourrons enregistrer l’équivalent des clics, des recherches, des messages et des vues réalisés par nos systèmes d’organes. Cela se traduira par un flux de données encore plus massif que ce à quoi LinkedIn, Walmart ou Netflix doit faire face, car cela se produira en continu, et pas seulement lorsque nous utilisons un site Web ou une application en particulier.

C’est précisément la raison pour laquelle les avancées dans le traitement des événements à grande échelle sont si essentielles. Nous sommes au bord d’un bond en avant qui nous mènera du suivi des données de santé tous les quelques mois ou années à un suivi toutes les secondes. Prendre ces informations, les traiter en temps réel et les rassembler avec d’autres flux de données fournira des informations exploitables à une échelle sans précédent et nous permettra de détecter des problèmes de santé alors qu’ils sont encore en train de faire germer des graines plutôt que des séquoias bruns complets.

Les organisations de soins gérés qui ont adopté des modèles de soins basés sur la valeur sont idéalement positionnées pour bâtir cet écosystème technologique de bout en bout. Cela nécessitera la combinaison innovante d’une pile de technologies, y compris le traitement des flux d’événements, l’analyse et l’apprentissage automatique au niveau de la gestion de la population, associée à des technologies de gestion des soins et d’engagement pour conduire le changement au niveau du patient individuel. Ce qui est intéressant, c’est que toutes ces technologies existent déjà, ainsi que les incitations financières, réglementaires et, surtout, sociales, pour en faire une réalité. La course est lancée pour le Saint Graal des soins de santé: un médecin IA dans la poche de chaque patient.

Jack Plotkin est le PDG de Cardinal Solutions, une société de conseil et d’investissement basée à New York. Il a plus de deux décennies d’expérience au carrefour des affaires et de la technologie et a conseillé plus d’une centaine d’entreprises du Fortune 500 dans pratiquement toutes les grandes industries. Il a également apporté des contributions stratégiques clés à un certain nombre de startups perturbatrices, y compris VirtualHealth.