I’ve had the opportunity to follow the development of OpenID and related technologies from afar for a couple years. Watching the good work of some friends who have developed ClaimID has opened my eyes to what the hurdles are in keeping a unique identity as we move more and more digital.
Here’s the problem: Identity on the web can be nefarious at best. An email address is at its heart temporary and often not the only unique email one person might have. Who hasn’t either contemplated or actually dumped an email address after a particularly bad week of spam? Identities are also defined online by the many services and sites we might have a login for. Yet these are usually different IDs - we can’t be sure of a person’s identity by looking at various accounts.
ClaimID is a great example of a way to combat this by allowing a person to manage their online identity themselves. Further, they are doing so by using the very simple and elegant OpenID protocol. The concept of OpenID being that we have a unique identity which allows us to log in to various services and sites with one single ID by allowing the services to retrieve credentials from a trusted identity provider of the user’s choosing. This last part being key: “of the user’s choosing”.
OpenID is still very much in a phase where, although it is being adopted by some well known services, it is still in roll-out. Although this means we can’t use our OpenIDs in many places yet, the tools for developers to add OpenID support are available and ready for use.
This could be very important for our work here at IntraHealth. This week there have been a couple of different projects plans come up which have made me think about how we could use OpenID. In both cases it comes down to patient records and tracking. The thought of such use in places like Uganda has made me step back and wonder why this type of implementation hasn’t been talked about much in Western medical records and services development. Perhaps it has and I have missed it, nonetheless I do feel like a tool like OpenID could present the beginnings of the type of security which is needed to provide patients and health care givers records online or on handheld devices.
The trick here is creating the trusted identity provider. In the case of the Ugandan projects we could propose that the Ministry of Health become a trusted provider for a Ugandan citizens “Medical ID”. This ID could then be used on the already growing list of servers and applications which have to have unique identifiers for their patients. The same system could also be used to identify health workers as they pass from systems like iHRIS Qualify to a training center’s application - therefore more easily (and automatically) updating either system’s records on what type of training the health worker has completed. The beauty of the OpenID process is that, if implemented correctly, it allows the patient or worker to be in charge of their own identity and who they trust with the creation and storage of that identity. As long as we keep them first in any design, they win.
Posted by
David Mason on 1/14/2008 • Tags: Design, Development, Software, Technology, Tools
No Comments Yet
Add Yours
When we design information systems, particularly working with stakeholders who have had difficulties accessing data in the past, it can be very tempting to collect every piece of data we can think of, just because we now have a tool that can capture and store the data. But we have to resist such temptations, or we’ll end up with systems that are too bloated to maintain and unwieldy amounts of data that are impossible to analyze meaningfully.
We’ve all seen forms that ask for so much information it’s exhausting to even think about filling them out. What incentives do we have to complete such forms, or to not rush through them as quickly as possible? The data entry person who fires up a bloated information system has the exact same reaction. When faced with a seemingly endless number of fields to complete, she might be tempted to skip some or fake data if all fields are required. She typically doesn’t know what is critical to the analyst. So bad data goes in, and bad analysis comes out. The system runs the risk of being abandoned, either by the people trying to maintain it or the people trying to get information out of it — or by everyone.
It’s better, when first designing the system, to ask “why” about each data field that is proposed. Why is it necessary to collect this? What report will require that data item to be complete? How will you use this piece of data to make better decisions? That’s why we typically ask stakeholders to come up with their most critical policy and management questions that they have been unable to answer because they couldn’t access the pertinent data. This process narrows the types of data that the system needs to collect to only the most critical pieces of information and helps us avoid “data smog” that can actually keep analysts from making good data-driven decisions.
Even with this process, it’s difficult to control the kid-in-a-candy-store mentality. Sitting down with stakeholders and brainstorming requirements for a new module often results in calls for everything but the kitchen sink. Just because we can collect a lot of data doesn’t mean we should.
I think it’s better to take a minimalist approach, especially when first introducing an information system to an organization that hasn’t used one before. Real-world use of the system will reveal which critical pieces of data may still be missing, and those fields can be added in a later version, or by the organization with a customized need. It is better, I think, to risk the system being too small than being too large.
What do you think? How much data is too much?
Posted by
Shannon Turlington on 10/22/2007 • Tags: Data Quality, Decision-Making, Design, Information Systems
3 Comments
Add Yours
I had the great fortune to go hear Edward Tufte talk the other day. If you are unfamiliar, Tufte is a Yale professor who is a master at analytical design. He’s written (and self-published) four books on better information display and has even pioneered some new ideas in the field. Though there was a lot to learn in a one day course I will need to think and study much of it some more to start applying those ideas to our work here at IntraHealth. The obvious areas for Tufte’s lessons to work their way in are: interface design in our applications, reporting tools for iHRIS and other apps, our work on data-driven decision making, and the simple presentations we all have to make from time to time.
On presentations, Tufte has always had a lot to say (in the negative) about PowerPoint, and though sometimes humorous he did make it clear that often the bad design that PowerPoint forces on users is used in the dissemination (or more likely not) of very important, and life-saving information. Those are definitely not the times to not be using slow revealed bullet points!
One thing Tufte talked about that I personally want to think about more is the idea that the principle of design is the same as analytical thinking. One must show comparison and causality in design just as they would when simply thinking about the problem. A good chart is one that compares findings with a norm, or another similar scenario and then gives the cause. Yes, all in one chart. Tufte’s books are full of good examples from Galileo to a good newspaper sports page. When considering the amount of information millions of people acquire from the tables of the sports page everyday, it is not so daunting a task to show a similar amount of data to someone who needs to make a decision about the health care in their country. There is no such thing as clutter, there is only bad design.
We, at IntraHealth, are designing all the time. From software applications such as iHRIS, to paper-based public health systems, its all design. As Clay Shirky recently wrote “users are experts in their own lives” therefore “Design is humility.” Something we should always keep in mind.
Posted by
David Mason on 10/19/2007 • Tags: Data Quality, Decision-Making, Design, Development, Documentation
No Comments Yet
Add Yours
