Approches de pointe et Big Box pour la maturité numérique des fournisseurs
Approches de pointe et Big Box pour la maturité numérique des fournisseurs
Ade Byrne, CIO de l’hôpital universitaire de Southampton, partage ses réflexions sur les meilleurs intégrateurs (BoB), les EPR et la maturité numérique avant d’organiser un événement dédié aux meilleures pratiques des réseaux régionaux à Southampton le 23 octobre.

Comment les meilleurs hôpitaux peuvent-ils aborder au mieux la maturité numérique, comment peuvent-ils résoudre les problèmes d’interopérabilité et comment éviter de se perdre par rapport aux solutions EPR à grande surface? Telles sont quelques-unes des grandes questions auxquelles Southampton a tenté de répondre dans son programme GDE.

Certains d’entre nous y sont depuis longtemps, dans mon cas plus de 20 ans, et peu de choses ont changé à certains égards. À l’hôpital universitaire de Southampton (UHS), nous avons décidé de nous développer autour de systèmes qui communiqueraient entre eux et d’un modèle de données ou d’une architecture d’entreprise commune.

Cette stratégie a résisté à l’épreuve du temps à UHS et les avantages sont évidents dans un meilleur flux de patients, la sécurité dans des choses telles que la reconnaissance des résultats, et maintenant une volonté de travailler véritablement sans papier, passant de la numérisation à l’entrée directe.

Mais BoB n’a pas fonctionné pour toutes les fiducies. Pourquoi beaucoup de ceux qui se sont lancés dans cette façon de travailler semblent-ils à court de route, et y a-t-il des leçons à tirer pour les aider à maintenir leur projet viable et en vol?

Obstacles du meilleur de la race

Il est juste de dire que cette meilleure approche a eu ses critiques, mais des défis existent quelle que soit la manière dont vous essayez de numériser un hôpital. Les obstacles de BoB sont clairs en ce qui concerne la gestion de plusieurs relations avec les fournisseurs, le maintien d’une main-d’œuvre dotée d’une mémoire organisationnelle et de compétences techniques et l’intégration technique.

En dehors de cette approche, quelle que soit l’approche adoptée, les problèmes de gestion du changement, de prix abordable de l’infrastructure, de normes d’interfaçage et de codage des données, de nouvelles exigences et de technologies émergentes auront tous un impact.

On pourrait soutenir que les solutions à grande surface de numérisation des hôpitaux ne sont pas si agiles, nécessitant un degré élevé de conformité, et il est vrai qu’elles semblent avoir du mal à se débarrasser de l’héritage et à supporter beaucoup de dettes techniques. Cependant, une approche plus patchwork aura différents niveaux de technologie et cela peut être difficile à gérer.

Je me demande souvent pourquoi les approches sont présentées comme une dichotomie. Je dirais que pour réussir, vous avez besoin d’éléments de tout. Ce sera davantage le cas à l’avenir, car les exigences d’interopérabilité seront étirées pour permettre aux parcours des patients de s’entrecroiser davantage entre les organisations et les secteurs. Ceux qui ont une bonne implémentation à la fois d’un Master Patient Index (MPI) et d’un moteur d’intégration trouveront qu’ils sont mieux préparés pour relever ces défis.

Il y aura probablement toujours des systèmes départementaux et spécialisés dans les hôpitaux, et ceux-ci nécessiteront une sophistication accrue dans l’interfaçage, probablement en utilisant un mélange de ce que l’on appelle le HL7 hérité et la ressource d’interopérabilité Fast Health (FHIR).

Règle de base

D’après mon expérience, il y a très peu de preuves que de nombreux systèmes spécialisés ont été remplacés de manière adéquate par une suite intégrée. Vous trouverez toujours des systèmes d’endoscopie, de cardiologie, d’ophtalmologie ainsi que de pathologie, de pharmacie, de PACS et bien d’autres.

La modularisation du code et la croissance des capacités d’intégration d’outils comme Microsoft Teams, par exemple, signifieront que toutes les applications devront prendre des informations à partir d’une interface où elles s’attendaient auparavant à ce qu’un utilisateur se connecte et utilise son logiciel.

Il semble qu’il existe certaines règles empiriques et des choses qui doivent être bien faites dans tous les modèles. Le problème clé de l’intégration est simplement que, comment mettez-vous vos données de votre laboratoire, votre prescription, vos observations de signes vitaux, dans un endroit où l’utilisateur et le système peuvent interagir avec eux pour suggérer et à l’avenir automatiser des actions en temps réel ?

Dans le passé, cela aurait sans aucun doute signifié une base de données unique. Aujourd’hui, de nouvelles techniques d’intégration signifient qu’il existe des alternatives. Cependant, une bonne base est toujours nécessaire, et je dirais que c’est la règle de base numéro un. Je ne vois pas comment vous pouvez passer de ce que j’appellerais une stratégie par morceaux à une stratégie d’interopérabilité où vous obtiendrez vraiment les avantages requis. Dans ce cas, vous serez en effet à court de route.

La question pour les organisations qui conseillent, tout le monde, des équipes centrales de l’alphabet du NHS au HIMSS et aux autres auditeurs de maturité, est de savoir comment reconnaître et identifier une stratégie en morceaux à partir d’une approche stratégique cohérente? Je pense que le différenciateur clé est que vous devez avoir une idée de l’état futur que vous comptez atteindre.

Plan réalisable?

Existe-t-il un plan clair pour parvenir à l’intégration qui conduira des flux de patients automatisés intégrés et de plus en plus intelligents? Et ce plan est-il réalisable? Est-il réellement plausible et peut-il être soutenu par les équipes locales et les technologies actuellement utilisées? Si ce n’est pas le cas e