Yes! For the first time this topic didn't include the words "secure" or "security"! Why do I say this? Because it is now a given that connectivity cannot take place until it is at least HIPAA secured, and probably more so. Now, the question is about reliability. That's interesting because generally reliability is an issue brought up much later in the technology cycle...when adoption has been demonstrated and when methods are being evaluated and scrutinized. But that's simply not the case in the healthcare market. We're still dealing with clipboards in physician offices, photo copies of insurance cards, fedex of records/charts, and less than 1% consumer/patient adoption of personal health records application...even when a payer GIVES them the PHR free! So, at some point reliability of devices will be an issue. Today, my PC works just fine and is pretty reliable. Only problem is my cable modem drops out too often which drops both the PC and the phone (VOIP). Soon, my mobile phone will be asked to do more than make calls, retrieve emails and access favorite internet sites. PHR applications, perhaps as part of a broader life-management application running on a mobile device (RIM, Windows Mobile, Java, etc.) will one day be the norm, and at that point we should discuss reliability of devices. For now, we should focus on reliability of the data and the willingness of the various healthcare constituents (payers, patients, providers) to become engaged in using the currently available information in a way to improve wellness and healthcare outcomes. In my opinion, we haven't even broken the surface of that larger issue.

Reliability is an odd concept in our society. It is often given a number (50%, 95%, 100%, even 110%!), so it takes on the pseudo-attribute of being measurable. But, one can only measure reliability in the past. In order to measure reliability in the future, one requires a crystal ball. Furthermore, the demands for reliability are skewed depending upon who is demanding it. In our culture of lawsuits and self-centeredness, we all to often hear people demanding 100% in nearly everything. The more accurate (and therefore less reasonable) statement would be, "I demand 100% reliability in everything. Except me, of course." As Doug alluded, the cost in resources increases with the increase of reliability. The cost is not linear, but it is asymptotic. In simplified terms, it takes x resources to achieve 50% reliability. But it takes another x resources to achieve the next 50%. So, it takes 2x resources to achieve 75% reliability. Following this progression, even if one were to apply an infinite level of resource, one would still never achieve 100% reliability. That hardly matters, though. The resource drain has long since surpassed availability. I have often seen that in the health care industry, we seem to think that our lofty goals of reducing suffering, illness and death will somehow exempt us from these truths. In my life, I have observed quite the opposite. In our drive to achieve extremes in reliability, technology, and knowledge the resource drain has been so high that now many in this country (and world, for that matter) cannot afford any health care at all. I would choose 80% reliability for all over 90% reliability for the select few that can afford it.

I think a lot of connected health research seems to rely on the "remote patient and central server" paradigm. With something like your orb project it might be a lot more reliable if most of the communication was local.

Let's say a pill bottle on a small (usb-connected) weight sensor talks to a simple local programme on the PC. This relates prescribed dosage over time to the weight of pills left in the bottle then it lights up the orb appropriately. It's all local and would be as reliable as the consumers own personal kit.

Maybe it could then report periodically back to the centre. This would separate the local reliability elements from the network reliability elements.

Telcos need traffic on their networks and will be happy to drive applications like this, but maybe patients don't really need to use it.

How reliable is reliable in Connected Health? Well that depends on what your trying to accomplish.
Given my entry level exposure to the Connected Health world, I have yet to see an area where technology can't raise the bar. As Doug suggests, there are many areas of need with different tolerances for reliability. As I see it, the user interface has an impact on acceptance and therefore plays an important part in reliability. If you really like something, you strive to make it more reliable. Frankly, I don't like or use a blackberry so it is not reliable for me. Sorry Doug; the screen is to small and I find the keyboard difficult to use! I like the idea of interfacing (via USB) to home PCs as a stepping stone whereas many people have PCs as a standard part of the household. Also, I have high expectations for wireless RFID devices in the home for Connected Healthcare.

You would have to define what 100% reliability means. If my home PC or wellness control center (I made that up) is transporting information about my well being and loses the connection, after a retry or two, it should sound alarms to inform me. If it loses power, an intelligent UPS (battery) should sound an alarm or call someone.
As far as connectivity from the home is concerned, we should not ignore computers such as your TV. After all, TVs are extremely powerful computers in the home with network connections. When I think of connected health, I envision people in need and then try to devise technology solutions to help them. The reliability aspect will depend of the criticality of the service being provided. Also, the technology architecture plays an important role here as well.

Very interesting commentary as always, Doug. The work you all are doing with the Diabetes Monitoring program is incredible. We remain committed to telling your story in Washington!

The consumer products industries have become proficient at making high volume products very reliably, even using new technology. Those companies who didn't learn how to do this have long since gone out of business - in high volume manufacturing you cannot afford to make unreliable products.

Making 50 of something is quite a different matter. If 85% reliability was achieved then it was a good result.

The pharmaceutical packaging suppliers who believe in smart compliancy packaging are investing tens of millions to make their concepts manufacturable in high volume - before a single product has been shipped. It is not only a question of money, it starts with design for volume manufacture and is followed by a commitment to process and quality.

If the real issue with the Orb project was to test whether reminders actually help people be more compliant and thus lead to improved outcomes then it might have been smarter to do it with proven products. In Holland, for example, a lot of trials are being run with sms reminders. The patients are given mobile phones - which is a lot cheaper than building a small batch of prototypes - and the infrastructure for handling sms is widely available. Doubtless when the trial owners are convinced that reminders help patients, then they will think about scaleable solutions which may well look quite different and have a lot more functionality.

I judge your handling of reliability in your own programs, Doug, to be very appropriate. Certainly ultimate reliability of products/systems always comes from a learning-curve affect: for instance, the more pill packages a pharma company makes, the greater its chance to "learn" and so improve reliability. However, in the early stage of a system's life, it is more important to prove the benefit that will sustain the system's use than fretting about it's ultimate reliability. In the early stage of a connected-health system's life, we can simply match the reliability of the human system it replaces - even if that means adding costly humans to make-up any shortfall.

When we get to that elusive point that the value of a new connected health system is proven, then we can indeed learn from the ultra-reliability of the Blackberry system. I believe two features therein are worth transferring to our connected-health system at that point: (1) bringing the END-TO-END system under the tight control & scrutiny of a single organization (did you know that every single email passing to or from a Blackberry worldwide goes through a control center owned and staffed by Blackberry's maker?): this gives that organization the chance to understand failures and correct them, and (2) using the intelligence of the remote device to detect, log AND report errors, even through system crashes: this the failure data from a tiny part of the rolled-out system (failure of one device in a million, say) to be captured, effectively running a closed loop continuous trial using every single actually-placed device (not just during specifically-run forensic reliability trials); paying for the design and implementation of such a reliability overlay, of course, only makes sense once the basic system benefit is proven and its ability to generate revenues to cover the reliability costs is beyond doubt.

Great that you are thinking about scaleability by fretting over reliability. I hope it means that some of your programs are moving past the elusive financial benefit proof-point that can so effectively hides from us in connected-health.

In reaction to Paul's comment.

I fully agree with your premise. All of us who have taken a course of medication are familiar with the "did I take it, didn't I" moment.

As far as I am aware, the majority of medication adherence issues are to do with memory. In this respect, any local system which can record usage and give reminders is going to be better than the current situation in which nothing is recorded and no there are no reminders. Why the healthcare industry is in a continuous loop of wanting to prove the obvious here is beyond me.

Communicating data to a central point has more to do with the possibilities for intervention by a professional or call-center. In marketing terms this is the "worried well" segment as the moment, but I expect this will expand in future

Recognizing the need for agility in an environment of adaptive healthcare solutions.
It is essentially tries to conform human networks, with the support
of the ICT that motivate and harness, in dynamic and systematic
form, the interaction between the people, who fortify the
generation, dissemination and exchange of information and
knowledge based on the professional objectives, institutional and
social in each context of an individual