Why Do We Need Accessible Platforms? They Learn

We need health care platforms that all of us can access to make better every day. Why? When you can access and change a system, it has the opportunity to learn.

Accessibility is a kind of perceptive system. The people that know what’s broken are the ones that can identify and fix the problem, the very people using the system are the often the ones best suited to fixing it.

But that’s not whare I’m at today. We’ve been struggling with what happens when systems don’t learn. When they’re inaccessible, the right feedback mechanisms can’t take hold.

My team, our partners and I have been struggling with a system for the last four months. People who need to use it can’t get it to work as expected, including customers. It’s mission critical, and yet here we are at the mercy of a 3rd party.

We can’t make changes to the system. It’s not our system. It’s not even our contract. We can’t do any scenario testing, we don’t have test accounts.  All we have is the same thing anyone else with a browser has: a web page to visit.

We can, on occasion, with our own made up data, verify that one scenario or another works, but beyond that, we have to wait until someone has a problem with the system (usually a customer) before we know what’s working and what’s not, raise the issues as best we can, then trust that the problem has been fixed, which is running about a 50/50 chance.

We’ll be successful on this project, but the system is a major hurdle we continue to have to overcome on a near-daily basis.

The issues we need to resolve are not complicated, the real problem is access. That’s the name of the game in platforms.

In our case, the people who could really help to fix the system and make it better (us) can’t and won’t get access the system. And the crazy thing is, the vendor then has to pay to have someone on their team fix it! Wouldn’t it be easier if we (in a very controlled setting) could fix it ourselves?

One industry leader who’s been struggling with the same nameless system aptly put it this way: “Certain ironies here around the difficulties of software development: Imagine that we are patients trying to (use the system) for a health care program at a hospital.”

This has really driven the point home in regards to healthcare and health IT: It’s broken in large part because users and outside developers can’t make changes to health IT.  This is the reason why the architecture and the focus of Health IT must and will change from institutions to patients.  We need to be in closer contact with the systems that are intended to make all of us patients better (yes, we’re all patients).

Can your physican make changes to his EMR? Not likely. He’ll have to go through his consultant, who will have to work with the vendor, who will have to talk to customer support, etc., etc., etc. Physicians who love your EHR, raise your hand! šŸ˜‰ Even after all that, needed changes are highly unlikely.

Physicians notoriously hate EHRs, but they love their iPhones and their range of helpful medical apps. Physicians have control over what goes on their iPhones and they can select what works for them. Developers can add new apps and make changes to existing apps without changing iOS.

In most cases, those that need to change the system are several layers removed from their ability to make changes.

Shahid Shah, who will be delivering a capstone session at the eCollaboration Forum uses this simple rule, borrowed from Marc Andreeson, that states simply: “if you can’t develop or make changes to the system without contacting the system’s internal development team, it’s not a platform.”

We need platforms for every participant in the health care system, so that everyone in the health care ecosystem has the power to change the system.

Patients can’t access their own data, and they can’t really add to their data, despite the recent study showing that patient-entered data is as accurate as physician-entered data.

So, in a nutshell, I’ve relearned in the last several months one of the core values of the Collaborative Health Consortium: “Solutions must be developed in conjunction with the people that will use them. They must be accessible”

Right now, the majority of health IT solutions are overly complex, monolithic, and not flexible enough to be developed with the people who must use them in the wide variety of settings they must be used. I sense this will change as soon as providers have more at stake in having systems that work the way they want them to.

And ultimately, it’s for this very reason that the Collaborative Health Consortium is hosting the eCollaboration Forum to bring attention to the need for more open systems. Systems that can learn.

Accessibility creates opportunities for learning. The broader the learning, the more you can scale learning, the more successful you’ll be.

BTW, accessibility doesn’t have to mean risk. There are many ways to provide controlled access and access at a multitude of different levels. That’s why we need modularity of our systems design, and a topic for another post. Openness and access can come in many flavors.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s