SOPA certainly made a big name for itself over the past few weeks. The Stop Online Piracy Act, and it’s Senate sister bill PIPA (Protect IP Act) has been halted in both the House and the Senate after a day of protest from thousands of websites worldwide, including Google, Wikipedia, and Reddit. These web giants encouraged their users to stand up and write their representatives urging them to vote against this nasty piece of legislation which would enable censorship over the internet by private corporations who believe that foreign websites are linking and hosting content that they own.
Up at 5AM: The 5AM Solutions Blog
For the past 6+ years, since I
escaped was sent off lovingly with a diploma from college, I have been working on contracts that have all dealt with improving workflows and systems through technology. This has provided me with opportunity for many musings on the process of changing these workflows and how to make sure you can make a system that not only does what it’s supposed to, but does it better.
First and foremost, you’ve got to keep in mind the problem that has to be solved. Often you won’t be solving new problems right off the bat, but it will begin with translating a workflow from one process to another. In most cases this will mean you will be taking a paper process that has been in place for years (even decades) and replacing it with a digital process, though there are occasions where this might just be moving from an older clunky digital system to a new fancy state of the art system. Henry Ford is often quoted as saying, (which may not actually be true) "If I had asked people what they wanted, they would have said faster horses.” We can use this in how we think about transitioning from old workflows to new ones as well. Think about if Ford’s car wasn’t the Model T as we know it, but was a flying car instead. Users would still be able to travel much faster than they could on horse and could even take things (or more people) with them, but the result is so different that people who were used to horses wouldn’t know what to do with it. We need to be conscious of these same changes as we change workflows, as we want to innovate and build a more efficient version of their current workflow but we don’t want to overwhelm the users too much. We want to change how they work without too many surprises.
Why are we doing this project if not to improve? The worst feeling in the world is to know that you are wasting your time working on something that isn’t going to be used. So while you are working towards change, you need to keep in mind the major hassles that users go through with the current process. How can you make their lives easier and make the user WANT to use your new application over the way they’ve been doing it for years? Look at how they do things and how things could be better. If the user constantly has to be going to their computer or calling someone up to find the same information over and over again, think about how you can link that system into yours. Does the user have to go through the hassle of gathering up documents and mailing them off and hoping they get there in time (or at all)? How about figuring out a way for them to be able to digitally submit all of that to the recipient? What also needs to be kept in mind is that the system can’t have steps that prove to be a greater hassle as compared to how much easier it is to use as this might drive users away. You don’t want the user to feel like there is greater relative burden on them now that they are in a system that they don’t encounter on paper. The first iteration of any system is to entice and bring users into the fold of the application and to start convincing them that your system gives them more benefits vs. sticking with the old way, while not introducing new hassles.
Evolution occurs over time...
Although not biological by definition, applications are growing organisms in their own right. They change and evolve as time progresses absorbing new capabilities and losing some of now useless features that were moved over from the old processes / systems it was deemed to replace. This is an expectation that needs to be accepted from the very beginning, making sure that the initial scope is actually doable and the expected features match those of the current process. As the application is built and once it has been released, you will receive user feedback from those who actually will be using the application. During this time you find out even more about what direction the application will begin to grow as users provide feedback about what is good and what isn’t. This allows the application to adjust to its environment becoming stronger and better equipped to handle the tasks at hand.
Learn from the Phoenix...
The application you are working on now will die. It might not be soon and you might not have anything to do with it when it does, but you might wind up working on a different application to replace an existing application. In these circumstances we must remember the Phoenix in that from the ashes of the existing application a new one will be born. An application tends to die for a few different reasons:
It is no longer useful as the processes it was meant to cover no longer exist.
It is outdated, or the technology used in it is no longer relevant and it is more beneficial to rewrite from scratch than put a new coat of paint on the old one.
It has been replaced by something different.
In the second two situations the need still exists for the project and likely a lot of the business rules and knowledge about the application can be reused. The application might be completely different but the work and knowledge of everything can be used as a foundation to build that new application to replace the old. In the first situation, it’s hard to defeat irrelevancy so the application and its functionality won’t be replaced by anything. It is likely that the pieces of the old application could be re-purposed to other closely related areas. In any situation, keeping the application evolving with the needs and the technology of the times can maximize the duration that the application will hold its existence and the longer the application is useful the most worthwhile the application was to build in the first place. But in the end, don’t we all just want what we build to be useful?
-Adam Swift, 5AM Solutions
Working in the biobanking field and observing researchers use tissue samples to help cure cancer is fascinating stuff. I see stories all the time about people who have rare diseases, and because there just isn't enough of the population with that disease to collect samples, no research gets done. Tissue samples become vital to finding the cure. I think we all want to help find a cure for cancer and the great part is that we all could help by donating our tissue samples for use in research. The not so fascinating stuff is seeing the Herculean effort it takes to actually obtain banked samples for research.
From my first encounter as a kid with Nostradamus, I’ve been a sucker for predictions about the future. And it doesn’t hurt if they’re couched in scary, end-of-times imagery. Shout out to all my Mayan Calendar fans – it’s time to party like it’s 199 … uh, I mean 2012. Things seldom turn out the way we think they will, but it’s still fun to peer into the crystal ball of the future and make your best guess. So, to start the year off right (since it’s probably our last), I give you the gift of the future of Health IT, as seen through a glass darkly on the Interweb:
Information Week reports the following predictions from IDC Health Insights:
Electronic Health Records will be in widespread usage by US providers as 2012 comes to a close. Sadly, all of the providers will be destroyed in the cataclysmic end-of-times before they can collect on their "Meaningful Use" bonuses.
Successful Accountable Care Organizations will emerge from private or public-private initiatives. Only to be driven back deep underground by giant rocks raining down from outer space.
A minimum of 70% of health insurance and technology resources will be directed to improving consumer engagement. Unfortunately, 100% of the consumers will be busily engaged in extinction from earthquakes, tsunamis, and the plague.
Robert Rowley of Practice Fusion offers the following predictions:
Usage of web-based Electronic Health Records will continue to grow. ...Then stop suddenly on December 21st.
Real connectivity will make significant progress using point-to-point solutions, such as Direct, and platform systems, such as … that’s right, Practice Fusion. With ultimate connectivity being achieved on the 21st as space rocks mash humanity into one big mass of human jelly.
Anonymized “big data” from electronic health records will significantly increase our medical knowledge. Until anonymized “big rocks” significantly decrease it by force.
Consumer data will flourish, and become linked to personal medical data. That’s right, our data will outlive us. Some people fear the rise of the machines, but it’s really the data we should fear as it has the real advantage on us.
Kaiser Health News predicts that 2012 will be a big year in healthcare because of the continuing impact of the 2010 federal health law. While, in case you can't tell by now, I predict it will be big because of all the apocalyptic dying and destruction.
Seriously, though, what are your big predictions? Where do you think Health IT will go in 2012? I’d love to hear from you. Comment away below...Then we can all look down from Mayan Heaven in 2013 and see how right we were.
-Michael Hunter, 5AM Solutions