In a recent review of medical applications for iPhone and Android, I find that there is not too much that is being offered. I can the break the serious ones down into a few categories without missing out too many.
- Reference material
- Health tracking
There are as of yet, no applications (aside from Epic Systems’ Haiku) which aim to do any form of patient management. Although this heavily limits the utility of smart phones used in healthcare contexts, it is probably for good reason. There are probably three main reasons for this:
- Low demand (fewer than 100 doctors per 100,000 people in North America)
Most mobile apps by their nature target mass appeal offering either a no or low-cost application. Revenue is achieved either through a high volume of sales or by mining collected data.
- Legal trouble if device is lost
The hospital IT department has to get involved if cell phones are being used to access or store patient data. In order to be HIPAA compliant, a good reference is this post on securing mobile data for HIPAA compliance. IT departments are hesitant to go through this effort at the moment.
- No support in clinical context
Most healthcare applications are well entrenched in the environment. Hospitals would have to adopt specifically mobile software and deploy it to everyone or support both versions in parallel and let the user decide. This will cost a lot and take a long time.
Until these issues can be fixed, the extent of medical software on mobile devices will remain in the categories outlined above. It is just a matter of time though until all of this changes.
Does Apple’s iPad offer a solution for the healthcare environment? This post will look at several cases where it would fit and others where it does not.
Where it fits:
Explaining clinical results to a patient
Discussing test results or possible courses of treatment with a patient can benefit from an interactive device such as the iPad. The doctor can sit next to the patient and access his EMR, show graphs, look at numbers, and access informative websites as reference as he explains the results. The portability (small, light-weight) of the iPad makes this possible.
Looking up resources on the fly
The training period for doctors is long and detailed, but they can’t always remember everything. Having an iPad in their lab coat pocket could be just the thing they need when a drug name slips their mind or they want to look up the address for a referring doctor.
Consult data before treatment
Usually before surgery or other types of medical intervention, the surgeon will consult with diagnostic images or results prior to undertaking the procedure. If the hospital infrastructure is in place, having an iPad would save him that extra trip to the lab to check them. Usually the doctor would be already familiar with the case, so having a high screen resolution is not necessary. Consulting images prior to surgery is normally a precautionary measure.
Where it does not fit:
Initial patient consultation
Technology can sometimes get in the way. When meeting a patient for the first time, the focus should be on him and his medical problems. This is especially true if the patient is elderly since they may feel more uneasy with the presence of too many gadgets. Consultation is narrative in nature and the doctor would need some free-form method of text entry. The iPad also doesn’t ship with a stylus or an app to record handwritten text, so a special app would be needed.
On the ward
The most popular choice for technology on the ward is a computer on wheels (COW) since it cannot be taken off the ward. iPads, unless personal to the doctor, would soon get misplaced. I don’t see an institutional deployment of iPads to hospital wards any time soon.
Emergency rooms are mainly for treating urgent medical problems. If you have chest pain, that supersedes all other problems and that has to be addressed. If you have a broken foot, get it fixed. There is no time or need for an iPad in this context.
I can think of a number of worksheets or forms that could be filled in on an iPad. The form would have to be converted into a style that works with iPad. If you were to take a conventionally web form and ask someone to use it on an iPad it wouldn’t work. Application control would have to proceed question-by-question and then provide a way of viewing the final result.
Unfortunately, generally speaking, there are a lot more forms where this style doesn’t work. Intake forms with a lot of narrative entry would be more difficult on an iPad compared with a traditional keyboard. In the healthcare domain, I think these types of forms outnumber the ones that would fit on an iPad.
What we see here is that the iPad does have a place in the delivery of healthcare, but it will only work as a personal device for a physician, not as shared institutional device for a hospital.
It started out as an idea for ramping up our Windows Phone 7 skills. Why not build a small but useful mHealth app for tracking and charting an infant's height and weight - something that any mobile-savvy new parent could tinker with while in the waiting room at the doctor's office before the baby's next checkup.
But we decided to take it a step further - let's build the exact same app for iPhone and Android, simultaneously.
If we really wanted to be efficient, we would probably build for one platform first, then "port" to the others. Or we might even build a single HTML5 app that would work across all mobile platforms.
But efficiency is not really the point here. Instead, 3 small teams are building the same app on 3 mobile platforms, simultaneously, and sharing and comparing their experiences along the way. This includes UI design (which platform is more intuitive/simple/visually stunning for this simple mHealth app?), to the nitty gritty API complexities.
Check in with our teams at the Macadamian "Mobile Experience" to see how it's going today!