I recently had to go for x-rays on my hip. The imaging company called saying they’d received the “order” from my chiropractor for a knee arthrogram without contrast.
Apparently, this was both wrong and confusing. It’s wrong, because the “order” said hip, but they couldn’t read it; also it’s confusing because, well something to do with x-ray and contrast.
After a short discussion, it turned out the imaging company received the order by fax. Yes, real actual paper fax. The US medical profession still seems to run on faxes. My prior cardiology hospital sent my medical records to my new cardiology Dr via, yes, paper fax. Hospital-1 printed the records to a fax based printer driver, which sent them uing a fax protocol to Hospital-2. Apparently Hospital-2 receives as images in a variation of the TIFF file format.
In the case of my PT, no such luck. Handwritten, manually faxed, received by paper. Even if there had been no problem this created a HIPPA privacy and security cost. In this instance, the cost to clear up the confusion likely cost almost as much as the actual hip x-ray, as that was all that was needed.
While I know there are data interchange standards in the USA for medical records, or as they are called PHRs, it seems there still nothing that is universally adopted. When I contacted my new cardiology hospital and offered my PHR in (Epic Systems) Lucy format, they declined and asked for them to be faxed.
There are a growing number of apps for both ios and android that support EHRs (electronic health records) however, for the most part these are tied to a specific hospital and/or medical group. A good example is the Epic Systems MyChart app. It can read the data from my former cardiology provider, including details of my ER/and cardio surgery and the prescriptions I was given. I can export the data using the Hospital groups website, and that’s it.
Unless you choose your medical providers not on their medical excellence, but their ability to import your lucy records, this is no use at all.
The Big Boys are doing data interchange
My interest was sparked by the recent announcement from Google, Microsoft, Twitter and Facebook introducing the open-source Data Transfer Project (DTP). For the more technically interested, you can read the DTP Overview here.
Ultimately it doesn’t look that different from the Enterprise Service Bus implementations we were working on 15-18 years ago. Same core concept, n-n interchange and interoperability. Same basic extensability through adapters and shared protocols.
I have to say, the use cases given for DTP are pretty weak. Conceptually, though there is much potential for this architected “Share…” facility. One of the key failings of DTP is that there is no ability to delete data, sure you can share your data to more sites/services but the DTP as specified doesn’t allow you to leave.
However, the most disappointing thing about this announcement is it’s aimed at allowing you to move your videos/photo’s, social media posts, and hopefully subscription platforms among the services supported.
To become a supported platform there are a few fairly simple architecture docs and then you have to build plugins or adapters to interface to the service to be able to send/receive data.
Ho hum. Boring. There is definitely space for big tech co’s to innovate around data interchange, but who cares about social media. I want to be able to pay for a PHR service, where I can store and control my medical record. Where I can grant access rights and authorise medical providers to retrieve my data, where I can see my medical records from across the providers etc.
I’m hoping that someone will point out this already exists, or that Nigel or Tom, who both now work in Helathcare will tell me why this isn’t a good idea. The USA is in desperate need for data interchange but it isn’t for social media.
FURTHER READING:
- Paper on moving from paper to electronic records and the associated problems.
- Review of numerous leading healthcare records mobile apps.