Blog Odyssée

Le Staff virtuel naît du concept de Ligne de vie que nous ne décrirons pas ici. Il suffira de dire que la Ligne de vie est un outil basé sur le principe qu’une personne peut souhaiter « gérer sa santé comme un projet » et que cette démarche passe par la matérialisation de l’équipe de santé qui « l’entoure » et par une vision au cours du temps des préoccupations de santé, de ce qui a déjà été réalisé et de la qualité de suivi du risque.

La Ligne de vie est une idée déjà ancienne, née au tournant du siècle, développée au début des années 2000 avec le support de plusieurs URMLs (alors regroupées dans le GUEPARD, Groupe InterUnion Échanges et PARtage des Données) puis mise sous le boisseau par le caractère exclusif du DMP. La Ligne de vie sera lancée cette année dans une version plus mature et générique qui postule qu’une personne ne peut logiquement pas se résumer à son projet de santé.

Le Staff virtuel est né, au sein du CISP Club, de l’intérêt de ne pas voir la Ligne de vie comme une pancarte, mais comme un objet en trois dimensions (une sorte de « cake » étiré au cours du temps) qu’il serait possible de découper en tranches.
Les tranches longitudinales seraient assez bien des « vues spécialisées », typiquement des pancartes construites pour une préoccupation de santé donnée (une pathologie, un risque…) tandis que les tranches perpendiculaires représentent les informations connues à un moment précis.

Le Staff virtuel trouve ainsi sa genèse de la considération que « la tranche d’aujourd’hui » pourrait bien fournir « l’espace de la prise de décision », par exemple l’interface d’une consultation médicale moderne. Cette hypothèse a été explorée dans le cadre d’un projet de recherche en collaboration avec l’équipe du Professeur Degoulet à l’HEGP (ex Broussais) et l’équipe INRIA Acacia alors encadrée par Rose Dieng (malheureusement décédée depuis).

L’état de l’art en terme de structuration de la consultation médicale est plutôt chaotique. L’approche classique, déjà ancienne (développée par le Docteur Lawrence Weed dans les années 60) consiste à organiser la consultation par problèmes (approche « orientée problèmes » ou POMR pour « problem oriented medical record ») et à recueillir pour chaque problème le déroulé de la consultation selon les étapes SOAP (pour faire simple : Subjective (motifs), Objective (examen clinique), Assesment (discussion diagnostique) et Procedure (conduite à tenir)).

Cette « grille » a le grand mérite de conduire à analyser les problèmes traités lors de la consultation, et à noter proprement ce qui a été réalisé ou planifié pour chacun d’entre eux, d’où son succès et le nombre de ses « produits dérivés » comme la Classification Internationale en Soins Primaires (la CISP) qui a été construite pour permettre de classifier les éléments S, A et P.

La grille SOAP/POMR a pourtant deux inconvénients majeurs :

• Elle pose plusieurs problèmes ergonomiques, typiquement par le fait que les éléments des cases S, O et P sont assez souvent dupliqués (par exemple, un traitement peut concerner plusieurs problèmes), classiquement également par le fait que, faute de faire tenir toute la grille à l’écran, certaines interfaces présentent les problèmes sous forme d’onglets, et perdent ainsi la vision d’ensemble. En résumé, elle constitue un bon support analytique, mais une mauvaise interface.
• En organisant le flux de la consultation selon les étapes motif puis clinique et enfin diagnostic et traitement, elle est adaptée à l’aigu, mais pas au chronique qui ne voit pas seulement le patient se présenter avec une liste de motifs, mais également des problèmes et des traitements en cours (le flux de la consultation ne démarre pas uniquement avec du S, mais aussi avec le A et le P des problèmes et traitements chroniques).

Comme élément de la Ligne de vie, le Staff virtuel a été conçu à la fois comme une version plus moderne du SOAP et comme un outil destiné à faciliter le travail en équipe. Il est basé sur quatre principes directeurs :

1. En tant que « tranche orthogonale du cake », il constitue un « point d’inflexion » du projet en cours : les préoccupations et traitements qui y arrivent sont éventuellement différents des préoccupations et traitements qui en partent. Au lieu d’un flux SOAP, il s’agit donc d’une transformation (A,P)SO(A’,P’).
2. L’interface est conçue comme si on écartait, comme on ouvre un rideau de théâtre, la ligne verticale qui matérialise le moment présent sur la Ligne de vie, en alignant sur la marge gauche les préoccupations et traitements anciens et en réservant la marge droite pour leurs versions futures (le nouvel état du projet), et en organisant le centre du terrain de jeu sous forme de « graphe cognitif » avec une zone dédiée aux motifs de rencontre et une zone réservée aux données clinique. Il est alors possible, si besoin, de construire un graphe en reliant entre eux les éléments qui vont ensemble ou, au contraire sont en contradiction.
3. Il est possible d’inscrire des points d’interrogation lorsqu’on suppose qu’il existe un problème qu’on ne peut pas encore nommer, et/ou que le traitement doit être adapté. On peut donc exprimer l’inconnu et, si besoin, ne pas refermer la consultation et, au contraire, l’ouvrir à (tout ou partie de) l’équipe de santé afin de bénéficier d’une vision pluridisciplinaire.
   Pour « résoudre les interrogations », il est alors possible de mettre en œuvre un diagramme QOC (Question, Options, Critères), qui permet au groupe de lister les options possibles et d’apporter, pour chacune d’entre elles, les critères positifs ou négatifs qui permettent in fine de travailler sur l’hypothèse qui possède le meilleur ratio +/-.
4. L’un des aspects importants d’une représentation de ce type est de constituer une mémoire de la prise de décision. Il est assez naturel que, dans le futur, quelqu’un s’interroge sur la raison pour laquelle un traitement a été stoppé, modifié ou instauré ou pour laquelle l’équipe a travaillé sur une hypothèse qui semble erroné. Pouvoir consulter, à l’aune des événements qui ont suivi, le raisonnement construit qui avait guidé la décision, est un élément précieux de support décisionnel.

La recherche documentaire pourrait intervenir à deux étapes en tant que support décisionnel : en utilisant le graphe de la consultation comme guide de requêtes pertinentes et, au sein du QOC, en fournissant des critères issus de la littérature.

Globalement, il faut imaginer qu’un outil construit pour permettre le travail d’équipe permet également à un acteur solitaire de bénéficier de l’apport d’agents intelligents, et, typiquement, d’un agent qui chercherait sur PUBMED si des tableaux similaires ont déjà été décrits.

"We live in an age when machines can learn. Can government?" concludes a great paper by Businessweek.

My favorite excerpts:

The saga of healthcare.gov has been a symphony of government inefficiency. The effort, directly overseen by the IT department of the Centers for Medicare and Medicaid Services, involved no fewer than 55 contractors. The process was thick with lawyers and political interference. In violation of current best practices in the software world, the code was kept almost entirely secret; other engineers weren’t able to point out its flaws, and it wasn’t tested rigorously enough. The Obama administration has been assailed for not calling in Silicon Valley’s top minds to collaborate, but that misses the fundamental problem: The best coders in the Valley would’ve never agreed to work under such deadening, unpleasant conditions.

For all its deficiencies, healthcare.gov isn’t the worst disaster a government has experienced on a major IT project. That distinction belongs to the U.K.’s endeavor to create an electronic medical records system for its National Health Service. The effort, which began in 2002, tore through about $10 billion before the government admitted it simply couldn’t be salvaged. In an editorial at the time, the liberal Guardian newspaper declared, "The government is an inept purchaser of private services: indecisive, ponderous, overambitious, and wasteful. Mass centralisation does not reduce costs, but it kills flexibility."

The British learned from their mistakes. The disaster empowered Francis Maude, the minister for the cabinet office, to bring in technologist Mike Bracken to overhaul how the British government did IT. Today, gov.uk is something of a wonder. It’s a single, centralized portal to pretty much everything the British government might be able to do for you. It’s designed for users. It’s nominated for awards. With the deep admiration of Silicon Valley boosters, Bracken is working to change everything about the way the British government builds technology. His keynote speech at the October Code for America conference received a standing ovation.

"This is a hard problem for government," Bracken says, "because it’s not really a technology problem. It’s a self-image problem. Government constructs its self-image in terms of size. It thinks of itself as huge and big. I’ve been in D.C. and seen your buildings. They’re very big! The harsh truth for governments all over the world is that many digital public services could be developed at a fraction of the size of nondigital services, and they can be created by very small teams of people in an open way."

To start, the president could study the example of how the British government used the initial failure of its electronic medical records system as a catalyst for broader change. But he doesn’t even have to look that far. The Affordable Care Act, after all, isn’t the only product his administration has launched. The Consumer Financial Protection Bureau (CFPB), created by the Dodd-Frank financial reform act of 2010, has won wide plaudits for its remarkable, user-friendly deployment of technology. Merici Vinton, who recruited most of the original technology and digital team and oversaw the creation of consumerfinance.gov—her agency’s version of healthcare.gov—outlined three principles for making technology work in government:

1. Never build a website that’s too big to fail; instead, start small.
2. Do open-source when possible, preferably always.
3. Have in-house strategy, design, and tech.

I must confess that I am not easily impressed by computer science innovations. Trust me there, Pranav Mistry belongs to the "World Changer" club.

His bio at TED says:

Pranav Mistry is a PhD student in the Fluid Interfaces Group at MIT’s Media Lab. Before his studies at MIT, he worked with Microsoft as a UX researcher; he’s a graduate of IIT. Mistry is passionate about integrating the digital informational experience with our real-world interactions.

Some previous projects from Mistry’s work at MIT includes intelligent sticky notes, Quickies, that can be searched and can send reminders; a pen that draws in 3D; and TaPuMa, a tangible public map that can act as Google of physical world. His research interests also include Gestural and Tangible Interaction, Ubiquitous Computing, AI, Machine Vision, Collective Intelligence and Robotics.

What it doens’t say is that he manages to put all this into bright while simple concepts. Enjoy the video!

C’est un projet qui me tenait à cœur depuis longtemps… je profite, en ce 24 septembre, des bons auspices cumulés de l’anniversaire de mon compère Jean-François Brûlet et de la journée Paris, Capitale du Libre.

Plus sérieusement, ce travail de longue haleine est justifié par la stabilisation de ma situation personnelle, en grande partie grâce au dynamisme du Club Nautilus, qui a été créé par les utilisateurs des modules de comptes rendus d’endoscopie digestive et d’échocardiographie, et par l’avancement des projets internationaux, au Brésil par exemple.

L’open source est indéniablement un moyen de garantir les investissements de ceux qui me font confiance, c’est aussi, et surtout, une façon de mettre « sur la table » les technologies de continuité des soins qui doivent accompagner l’évolution de la médecine.

Il ne faut pas se leurrer, les technologies anciennes, adaptées à une vision ponctuelle du patient, ne ressentiront pas avant longtemps les secousses de la mise à disposition de la communauté des technologies de gestion de la connaissance et de suivi au long cours : les logiciels d’aujourd’hui suffisent à outiller et maintenir des pratiques anciennes… faire naître une démarche plus moderne se heurte au problème de la poule et de l’œuf : comment valoriser des outils qui obligent à « voir autrement » avant que leurs utilisateurs soient en mesure de réaliser qu’ils permettent de « voir mieux ».

J’ai dépensé une énergie considérable à créer des technologies puis à les « apprivoiser » au sein d’un logiciel réellement utilisé par des médecins… il est temps de les banaliser, d’en faire la norme, de faire passer l’informatique médicale du temps de la photographie, du bilan instantané, à l’ère du film, de la vision continue.

Si, dans les mois ou les années qui viennent, il devient courant et naturel de « raconter l’histoire de santé d’un individu » et d’y prendre sa juste place en contribuant à un projet de santé en collaboration avec les autres membres d’une équipe, ce sera signe que cette « annonce du 24 septembre » aura porté ses fruits !

Dans les jours qui viennent, je choisirai une « forge » ou déposer les sources et mettre en place étape par étape les composants de travail collaboratif…

Today, I really enjoyed attending to the French conference of Adobe’s “on AIR tour” spring 2008 Europe.

Presentations’ quality was really good and the guys from Adobe were truly committed to making themselves available for having the audience chat with them during pauses. I just might criticize a little overlap – some concepts have been addressed in several presentations – but education is about repetition, so there is nothing wrong here.

Some buzz, of course, but not too much… I could just joke a little bit about “these Evangelists talking a lot about Leveraging technologies for a great (user) Experience”.
Strange enough, I must confess that I would have hard time translating those 3 words in French: Evangelist (I mean the one preaching for technology), Leveraging (currently this term seems to have a very comprehensive scope) and User Experience (or just Experience). No need to say that it is an evidence of France being somewhat left behind current web trends!

It is rather easy to explain what AIR is about; let’s imagine you are a web developer, used to using Flex or Javascript, then AIR will allow you to seamlessly (ok, another buzzword – but it seems accurate here) transform/extand your in-browser program into a genuine desktop application. Moreover, this app will natively run in a Mac, Windows or Linux environment. Two important things to notice:
1) an AIR application can really use usual OSs services, like files management, menus, windows control, etc
2) Since an AIR application potentially remains a web app, while gaining unlimited access (within user’s rights, of course) to desktop resources, it could become the favorite target of web pirates. This is the reason why the default design of such application cleanly separates two sandboxes (the web part and the desktop part). Of course, it is possible to establish a communication between both sandboxes, but it requires some additional – on purpose – work.

As an experienced C++ developer, I cannot say that programming in Javascript is something I am usually looking forward to. Trying to have the same code behave in the same way inside various browsers is something I have always considered as a fuzzy process! However, having the very same user interface available as a true desktop application and as a light client application is really becoming something users are now asking for.

Of course, it would not be wise to write complex application logic with Javascript, but after all, keeping C++ as the prefered language for this tier and switching to Javascript for user interface is a good way to ascertain than both layers are neatly separated.

My current application already uses a Java tier for persistence. In this case, the Java Native Interface between C++ and Java is the place where data processing and data storage are neatly separated. Isolating C++ business processes as services for the Javascript user interface could become a similar process – even for the desktop application.

No need to say that performances could suffer from such architecture, but Adobe provides a nice component to address this issue: Life Cycle Data Services (DS), and its open source subpart Blaze DS.

I must confess that I have been lurking into Firefox XUL environment for some years, while not being able to make the decision to use it, for two reasons:
- first XUL is fully embedded inside Firefox, and as such limited as a true desktop application;
- then I once heard Firefox evangelists explicitly assert that they are fully dedicated to the browser; and I have always guessed that they only consider external XUL apps as byproducts. In my opinion, it explains the reason why doing rather simple things, like changing chromes, always appeared to me as a rather tricky process during the demos I attended to, because the XUL app must always be careful not to interfere with/put the mess in user’s Firefox settings.

AIR appears as a far more efficient concept because AIR apps are plain vanilla desktop apps (a true .exe in Windows). It also compares favorably against Java, whose JVM can sometimes be a true limitation (not speaking of the deployment nightmare when multiple versions of the JVM are installed in the same computer – and it is, unfortunately, the usual case!).

Time will tell if, as a chronically overworked character, I will manage to invest the needed time (even if limited) to adopt AIR…
However, I am pretty much confident in the fact that AIR and Blaze DS will give birth to a brand new type of applications… Evangelists will tell you that developers now have the proper tools to leverage every facet in favor of a great user experience

Valuable resources:
adobe.com/devnet/air

Oshca means Open Source Health Care Alliance, and this is the place where most of the open sourcers in the medical domain have been able to meet and eventually become friends.

Oshca was initially created by Brian Bray and his partners from Minoru, a company that had received a budget from the European Community to establish an open source community in ICT for health.

The first and most important achievement of Minoru probably is the Openhealth mailing list, but Oshca was the place where we could physically meet, and this is of utmost interest.

I attended the 2001 Oshca meeting in London, with the sponsorship of the NHS, and the last one in 2003 in Geneva, where the audience was much scarcer, in a little conference room kindly provided by the University Hospital of Geneva.

Brian Bray already went back in Canada and there was no longer any genuine official organization. I remember that Joseph Dal Molin and Adrian Midgley had done a pretty good work allowing this meeting to occur, and that there was a nice group of Vista boys. Anyway, it was clear that it was the end of something.

Three years after, it seems that Oshca will be born again and that the open source community will have a place to meet. This is undoubtedly a very good news… and a very good opportunity to start this blog