A Novel Way to Exchange Patient Health Information
Posted Sep 18 2009 10:12pm
An interesting post on THCB by Margalit Gur-Arie—titled "What if I Had to do HIT All Over Again?"—critiques the very large, very expensive and very clunky systems monolithic EMR/Practice Management/Billing system currently dominating the market. She concluded the post this way:
"So if I had to do it all over again, I would take a hard look at Microsoft Office. I would build multiple useful applications, like Word, Excel, Power Point, etc. I would make sure I can export data from one to the other. I would make sure that the user interface is consistent between them. I would allow others to create templates and integrate their software into my tool bars."
Wow, Margalit, that's exactly what we done! We've actually just presented the first live public demonstration of a prototype of our system to doctors, educators, and insurers. It went very well!
The demo showed, in real time, how this MS Office based system enables:
primary care physicians (PCPs) to send personalized referrals to specialists,
the specialists to reply to those referrals,
the PCPs to respond to the specialists' acceptance reply by sending them XML-based continuity of care documents (CCD) and other supporting data files, and
the specialists to access and view the resulting patient info.
This is all done with encrypted e-mail attachments and a small software program and macro routines that process the e-mails automatically. They automatically encrypt, zip, and attach the files to e-mail and put them in the outbox; as well as retrieve the email from the inbox and unzip, decrypt, format and display those files, and store them encrypted in the recipient's computer.
It requires as few as 5 mouse-clicks per end-user for the entire process. No need for central servers (or any other infrastructural build-out), there is little if any need for IT support, and there are no other costly complexities.
And all the data are stored locally in encrypted files, which is automatically retrieved and rendered any time via a few button clicks. From a technical perspective, it's a simple node-to-node (peer-to-peer), publisher-subscriber, and asynchronous decentralized desktop solution that uses Office macros, .Net, and SMTP. It is literally the easiest, most convenient, and least costly way I know to exchange and present patient health information securely between any EHRs in a way that promotes care coordination.
Another reader (Alexander) commented:
Margalit, what you describe, basically, reflects the principles, on which the proposed NHIN infrastructure is based. The only difference is that it is supposed to connect RHIO's rather than separate EHR systems. Without a nationwide patient ID, though, it is going to be very challenging to find and link all medical records on the same person since some important data fields used by matching algorithms can be empty or contain incorrect values. Besides, as I mentioned before, it is much more difficult to predict availability of EHR systems installed in small medical offices or hospitals, unless they use cloud-based applications.
To which I wrote:
Margalit - What do you thing use of a biometric index to create a unique patient identifier (medical record number)? It would negate the necessity to establish and connect to a central repository, and it would enable the fluid exchange of patient health info between any nodes in a mesh network architecture, which is similar to the way communication is done in telephone networks (see http://wellness.wikispaces.com/Network+Architectures
And she responded:
Dr. Beller, I think a biometric ID is probably a very good choice, short of implanting a chip :-)
The NCVHS has been tinkering with this for over a decade, but nothing happened. There seems to be some reluctance on the part of most people to have such identifier. I'm not sure why, since we all get SSNs immediately after birth and think nothing of it.
I think the technology is available for biometrics and the logistics are not insurmountable (put a machine in every DMV).
Alexander, I know that availability is an issue with the current crop of EMRs, but I strongly believe that SaaS is the future. Besides, as Dr. Beller mentioned, we all use phones without the operator having to patch calls through anymore and without having to run to the telegraph office to send something. Technology changes fast and I can see a device or an executable installed in every office to ensure availability.
I'm not ruling out RHIOs or other intermediaries, but I believe the actual data need not reside anywhere other than the provider system.
Yes! I suggest that important roles for RHIOs, HIEs, etc. would be
To aggregate de-identified patient data
To make those data available to authorized research organizations (universities, etc.) who study the data to help develop and evolve evidence-based preventive, diagnostic, self-maintenance/management, and treatment guidelines that focus on bringing ever-increasing value (i.e., cost-effectiveness) to the patient/consumer
To disseminate the resulting guidelines to all parties.
In this scenario, using the decentralized node-to-node architecture, the patient data would be stripped of patient identifiers and shipped to a centralized research data warehouse. The stripping and shipping would be done by the nodes having direct access to where those data are stored, that is, to the nodes belonging to the clinician/provider that access the data from their EHRs, and to the patient nodes having access to their PHRs. Nodes having direct access to the research data warehouses would then receive the de-identified patient data. In other words, the clinician and patient nodes would implement their publisher (sender/transmitter) function to transmit the data, and the RHIO/HIE's data warehouse nodes would implement their subscriber (receiver) function to retrieve the data. And the resulting guidelines would be shipped via the RHIO/HIE nodes by implementing their publisher function; the guidelines would be received by the clinician nodes implementing their subscriber functions and subsequently be presented through clinical decision support software programs.
This scenario is an example of a hybrid mesh node network architecture in which both centralized and decentralized networks work in harmony. BTW, another example of a hybrid mesh is when a multi-site healthcare organization with a centralized EHR system (behind a firewall) connects via nodes to the EHRs and PHRs of other parties outside their organization (beyond their firewall).
BOTTOM LINE: As our country struggles to transform healthcare into an efficient and effective system, there is great need for convenient, low-cost, secure ways exchange information, such as the kind of decentralized peer-to-peer mesh network architectures, publisher-subscriber communications, and desktop (standalone) applications that I've been describing. I'll be providing a concrete demonstration of this novel methodology next week on this blog with a video showing how our node-to-node system works.