Friday, August 11, 2006

Medical Admin Insanity

More thoughts from my recent visit to the eye doctor. I only saw one doctor, but expect that there may have been as many as three working in this facility based on the number of patients cranking through. THERE WERE 8 RECEPTIONIST TYPES.

What these people did was mostly greeting new patients, typing in their personal and insurance info, and filling out insurance paperwork to go to their insurance company, as well as haggling with folks at insurance companies about paperwork mistakes. I was amused to find that the person who spent half an hour doing this for me could not say definitively whether or not I had a $5 copay for my visit and allowed me to choose whether I would copay with possible refund or not pay with possible invoice. Oh yeah, they also personally escort each patient to an exam room, where a physician or technician will eventually work with them.

Here's how we eliminate most if not all of those nice and well meaning 8 people. I walk into the eye clinic. I wave a RFID tag at a reader or type in the URL for my patient record and insurance info wiki (http://radlook.blogspot.com/2006/08/patient-record-is-wiki.html). I type in my person PIN number. I sit in the waiting room (the half hour of data entry and confusion about copay were done when my medical record wiki was accessed). When it is time to go into an exam room, my name is displayed on a monitor in the waiting room along with a map showing how to get to the room I am assigned. Above the door is a panel displaying my name. I go inside and wait for the technician/doctor.

There is no paperwork, and thus no paperwork errors. A claim for my medical services is added to my patient wiki and my insurance company is digitally notified that they need to access the wiki and process the claim. All of the administrative work that is currently required to run my eye doctors office is eliminated and we're all better off for it.

While we're at it why not give real-time insight into a doctors patient queue? I usually sit for an hour or more in the doctors office because his schedule took an unforeseen hit. I suspect in 90% of cases, someone could have let me know that I could arrive an hour later and still see the doctor at the same time. We could save money by eliminating the waiting room and patients could walk into the doctors office at the moment that the doctor was ready to see them. But perhaps doctors haven't noticed that other people's time is also important to them...

Patient Record is Wiki

When I think about what a patient medical record is, I picture a wiki. It is a thing that gets passed among a (closed) group of interested parties who have a need to read, change, or add to it. The elements added are as diverse as office equipment allows; printed documents, photographs, medical images, speech for physicians notes, etc. This record needs to be perpetually available to a wide audience with the ability to understand what changes were made, when and by whom. The thing would live in the web/Internet cloud on a wiki server, but could also go off-line;being carried around by a patient and then synchronized with the "master" copy on the server. Hosting this entity would include a damned reliable backup/restore capability. If the patient owned this entity (or was provided such a trusted digital service), changing medical providers would seemlessly transfer a complete medical history to the new doctor.

At this point, I look at how current wiki technology would support the diverse role-based authorization requirements for medical records. Defining the group of folks allowed to access one's records becomes more critical as the physical barriers to access are erased by the Internet. Unlike a community development project, where the organization is flat and all contribute equally, there is a regulated, and well defined set of roles and actions they are allowed to perform in medical record management. I am not aware of "carrier class" wiki implementations that include sufficient richness of authentication and access control to enable the mapping of a digital patient record via this technology. This is unfortunate given that the mapping is so natural and clean, and the benefits so compelling.

As I think of the software development required to build a wiki server capable of protecting suc h critical data, it is clear to me that many other business records would map nicely onto the wiki format and would also require rich AAA capabilities and think there is a business here.