The EMR just got social

Social networks are all the hype. Before long social network addiction will get its own ICD (disease) code. How does this translate into the real world where the concept of virtual friends is not yet widely known ?

For years companies big and small are talking about healing the health system by providing tools for medical data sharing. Those goups have it all layed out but to date very little of it made it mainstream (into general practices around the world).

Diversity is good (meaning a never ending bunch of EMR) and data sharing among other things lacks a widely deployed data exchange record format. But even if the format is there and implemented there is a missing link. This link is to remove the neccessity of a doctor knowing how to reach the other party (e- mail, fax, printout, usb-drives) ideally without a breach in media.

The problems are numerous. GP does not know which physician is treating the patient in the hospital (let alone a communication channel) and physician in hospital usually could not care less about collaborating with the GP or has no idea how to send information short of handing a multiple page discharge letter to the patient. Apart from that rarely does the patient deliver (copies of) the letter to all physicians invloved (GP, cardiologist, diabetes specialist and whatnot). From what I experience (as a hospital doctor) information (incoming and outgoing) is lost somewhere on the way, tests and procedures are repeated because it is quicker to repeat then hunt down the missing information.

All this has long been known and seems to have one common ground. Health systems are organized in a way where getting the information from a to b is challenging. Solutions like handing portable media (USB drives) to patients have been proposed but that is copying the letter concept to electronic media.

The social network of a patient consists of the patient, a number of physicians, friends and relatives. Storing as much health data as feasible centrally (e.g. at Google or Microsoft) is not the solution to the problem. The solution is to get back to the concepts that have proven successful for thousands of years. The problem to solve is providing communication channels just in time.

A caring physician will take on the challenge to phone the other party as often as needed until reached and ideally will have a phone number at all and moreover reach the correct physician.

Recently a young lady (23 yrs) came in for palpitations. She recalled an EKG had been done while one of the attacks was ongoing. I was told that this was done in her GPs office and the EKG could be obtained from there. She did not have any phone number of the GPs office. Calling the GP it turns out the EKG is not there. So it was either never done or misplaced or whatever. Suddenly she changed her story and recalled that her cardiologist had done the EKG. No phone number either. Looking up the number (it was listed which is not always the case) it turns out the EKG was not available there as well. Then the story changed to the EKG was done in the GPs office and sent to the cardiologist for review. Anyway the only (most important) EKG is gone.

This tells us that communication channels more then once played a huge role in loosing the EKG.

How can this be prevented ( and that is what I want your opinion on). GNUmed sports the concept of social network of a patient. It knows about familiy members and treating physicians. This concept can be extended from in GNUmed knowledge to communication channels.

Here is the concept. Each GNUmed instance and each active doctor inside that GNUmed instance gets a unique (or at least almost) unique handle. A system which will be described later knows about those instances (doctors running GNUmed instances) and provides a transparent means of communications. If GP Joe sees a patient of GP or specialist Jane and needs more information she can go into that system and find that other party. Forget phone numbers. Forget fax numbers. For E-Mailaddresses. Say hello to handles. A handle is the system's identifier for an institution or person transparently offering communication channels (phone, fax, e-mail, pidgeon).

Why is this a step forward ? Addresses change, e-mailaddresses change (after a hack or whatever, phone numbers change but handles have the potential to stay stable for life.

Until now this was the easy part. Here is an example.

When seeing the above patient I would click on the handle of the physician named by the patient. The system would know the phone number and fax number as well as electronic comm channel of that physician (This data is maintained by e.g. your local authorities , specialty societies or yourself). It would offer me to dial the number , request the information per fax or start a (video) chat session. The other party would receive the request and opt to pick up the phone, return a fax or engage in the chat session. Upon request (and authorized by the patient) she would give me (electronic) access to the patients record in her systems. Upon request she would demonstrate certain findings and results and authorize my request to transfer that to my EMR.

The same system would be used to offer discharge letters to her (her EMR) without ever saving it to some central (hackable) cloud storage.

Sounds fictious ? The technology is there today.

As for the technology we are not short on solutions. Central and decentral storage and exchange solutions exist. All have pros and cons. The ideal technology is one that works across operating systems, across client types (web or fat) and across hardware (PC, tablet, phone). Ideally it would not invent new solutions or hardware but rather make use of the exisitng ones.

Technologies that could be chained together include: telepathy [1] and gstreamer, the xmpp protocol [3], the ejabberd server [4], clients such as empathy, OneTeam? or Peregrine, smartphones on android, iOS or Symbian.

[1] www.collabora.co.uk [2] www.collabora.co.uk [3] http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol [4] http://www.ejabberd.im

Telepathy has been shown to work for VOIP, video chat, text messaging and text chat. Supposedly a bridge to SIP exists enabling regular phones as communication channels. Telepathy tubes have been developed to enable collaborative work on e.g. text documents (realtime collaboration on the same document). Transfering files between contacts is there as well. Clients have been developed for PC, handsets (e.g. Meego) and tablets.

The intended feature set has four larger blocks. First one is to get up the infrastructure for managing accounts and getting text chat inside GNUmed running. The second block would be to get file export, transfer and import for data exchange up and running. Once this is done additional comm chanels such as SIP or VOIP would be implemented. As a last block window/desktop sharing would be implemented for support and case discussions.

All this needs to work across operating systems (is know to work on Linux and Mac) and across hardware options (handset might have voice but no file sharing, PC might have file and window sharing but no voice capability).

http://telepathy.freedesktop.org/wiki/Telepathy%20and%20other%20Projects
http://telepathy.freedesktop.org/wiki/Presentations
https://joindiaspora.com/
http://www.macports.org/ports.php?by=name&substr=dbus
Topic revision: 06 Feb 2011, SebastianHilbert
 
Download.png
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark