Usability

100th Blog Post: What I know about Software Development and Crisis Management

dondennison Healthcare IT , , , , , ,

I started writing this blog post about this…

Opinions on policy and politics aside, this article on the struggles of healthcare.gov tells a classic tale of large software development project failures, and how not to react when trying to solve the issues.

But as I continued to write my thoughts, this became more about my views on software development and crisis management. So, enjoy (or ignore, or comment).

Hopefully, it is worthy of my 100th blog post (which this is).

On software development…

  • Software development, no matter how much research is done on development methodology effectiveness, is as much art as it is science. Treat the artists like factory workers, and you get what you deserve.
  • Not all software developers are great at developing all applications in all languages, using all tools. Web development, especially when connecting to legacy systems, is a specific discipline. The best Web developers don’t work at large contract system development houses, in my experience. That’s usually because there are more interesting projects in the world for them to work on.
  • In software, one of the most common reasons for failure is complexity. For large projects like the one cited in the article, you have to work very hard to come up with an architecture that makes concepts and aspects of the application simple to extend and use. This is not cheap—it takes time and significant energy from artists to achieve. But, when it is achieved, it is a beautiful thing. You owe it to yourself to experience this at least once in your career.
  • Never ignore or otherwise skimp on quality User Experience Design (UXD). Never.
  • Designs change. New needs and unidentified technical risks are discovered. Requirements evolve. But if you want to get something done on time, quit changing the (in scope) requirements. If a good design forces you to re-write significant parts of your requirements, that is a good sign that you didn’t write effective requirements. In fact, they may not be true requirements at all. And, BTW, a list of features from a competitor’s brochure are not requirements. If you don’t how to write effective, (mostly) design-neutral requirements, learn. Start here. Then read this.
  • Well-written use cases—that everyone on the team has read and understands—solve a lot of problems. So does identifying the operating environment and performance goals sooner rather than later. Tip: Print this stuff out and hang on the walls were the developers and testers sit. Or (if you want to save some trees) make a JPEG of it and ask everyone to set it as their desktop wallpaper for the duration of the project.
  • Make developers create unit and integration tests for their code. Have them do code reviews with peers. Make them use code comments and consistently format their code. Make them fix their own bugs. Hold them accountable to the quality of software build they provide to the test team. Make them perform design checkpoints with their peers (or even customers) for any significant component. Anything less and they are not a serious professional developer.
  • Developing for security and performance are specific skill sets, but these are most often “want to” issues. As in, if a talented developer truly wants their product to be secure and fast, they will figure out how to make it happen.
  • Do daily stand ups. Make the product manager show up.
  • A good tester is as valuable as a good software developer. So is a good technical documentation person. They are artists too.
  • Give them all good, fast computers with at least two monitors and reliable Internet access. You want something done faster, remove inexpensive barriers.
  • Don’t make them pay for coffee. And don’t buy the cheap stuff.

On crisis management (in IT)…

  • The comment in the article about the “war room” is spot-on. I call it “the body cannon”. When **it hits the fan, there is usually some executive wanting to pull anyone and everyone off their current work and throw them at the problem, with no real plan. They are simply hoping that through volume, that the problem will be solved faster, when in fact it usually has the opposite affect. The better approach: select a small team of talented, trusted artists (that know the code!) and simply ask them: “What do you need?”, and then get it for them ASAP. Then, be prepared to pay the price of pulling these people off their current project (usually in the form of a schedule slip), once the crisis is over. These things are always about choices, not decisions.
  • Yelling at software developers doesn’t work. People that choose a career creating art by typing all day with headphones on are not the type that react well to yelling. If you don’t know how to convey a sense of urgency without yelling, the problem is you. If you don’t understand the problem or software really well, get out of the way.
  • If you have hired talented people, they can become heroes. Let them.

And, finally, if you are making an application for use in healthcare, take it seriously. Lives are at stake. It can still be fun and rewarding, but the problems within healthcare are large and demand our best efforts all the time. Now, go be great.

Articles: EHR Stress

dondennison Change Management , , ,

The benefits will come, but we must get through the change and this will be painful. Think of the shift from film to filmless, and paper to paperless (with coded, structured records) is this, times a thousand.

The rise of the mobile-only user …and how this helps the underpriviliged

dondennison Healthcare IT , , ,

A friend shared this article from HBR on the rise of people that use their phone as their primary method of accessing the Internet.

When I read about these users, I envision a Starbuck’s-carrying, iPhone-toting mover-and-shaker on the way to a spin class, but there are other parts of the world that are mobile-only by necessity and not by choice.

A good (and very talented) friend of mine courageously left the corporate world to dedicate his time to TulaSalud, an organization that helps healthcare workers in rural Guatamala provide better care. If you speak Spanish, check this site out too.

The only IT platform available to the users are cell phones. Note that I said cell phones, not smart phones (at least today). And network connectivity is not always available. Want to test your mettle as a developer? Try delivering solutions in this environment.

The more mobile-first solutions are available, the faster care can be improved in the areas of the world that need it most, so this trend can only be good.

They are getting some amazing results (lots of folks talk about better outcomes; these folks are getting them) and are an inspiration of mine. I’m sure if you would like to help, they would love to hear from you.

Article – Readers Write: 256 Shades of Grey(scale): The Dirty Little Secrets of Radiology and PACS

dondennison Healthcare IT , , , , , ,

Contrary to what the title suggests, this article debates whether radiology has succeeded in solving the problem of going digital (by using PACS).

I believe that PACS solved the initial problem that it was intended to solve: get rid of film. Whether it provided more value than that had a lot to do with the design of the PACS, and who was managing it.

But, the value of PACS has a lot more to do with how it is deployed, configured and managed. If a PACS owner fails to use informatics and operational best practices, they and their users will suffer. If they fail to invest in and manage the infrastructure—such as the networks, servers, and storage—they will suffer.

I have seen too many PACS operators with too heavy of a dependence on their PACS vendor. Radiology and IT too often lack staff that understand informatics, integration best practices (e.g. as defined by IHE), or how their system operates. I have seen two hospitals with the same software application doing very similar exam volumes, and one experienced high levels of user satisfaction and operational excellence, while the other had chronic issues.

I would argue that in today’s mature PACS market, it is not what you buy, but how you use it. Provider staff need skills and knowledge about best practices. They need to know more about PACS in general, and be less constrained to knowing only what their PACS vendor tells them. And one of the best places to develop these skills and broad knowledge is SIIM.

I’ll be at the SIIM meeting—stop and say ‘hi’ if you see me.

Apps for Health – Tips for Building an App, Key Trends in Health IT

dondennison Product Management , , , , , ,

Prezi presention from @azbib (Heart and Stroke foundation) from today’s Apps for Health event.

Product developers, have a read: 10 great, practical tips on approaching app development that applies to mobile and traditional application products.

Also, some key trends in health for 2013 (originally from Forbes).

Apps for Health 2013 at Mohawk College

dondennison Healthcare IT , , , , , , , , , ,

Mohawk1

I had heard good things about this one-day conference, so I decided to take the drive down to Hamilton, ON to check it out. I am glad I did.

Apps for Health has 3 tracks. One focused on Technology, one on Health, and another on Education. They also had keynote speakers to open and close the day of sessions.

To be honest, I was fearing that the recurring trend was going to go something like this: “Healthcare is broken! I love the App Store! Why can’t we get more apps faster!?!” …but the speakers were polished and came with insight and data.

Topics ranged from the needs for a “prescription” for a set of apps for different patient conditions, different levels of safety and risk that apps represent (for physicians and patients), regulatory challenges, privacy, security, and development approaches.

A collection of small and not-so-small vendors had table top displays set up, and attendees (and students) seemed to be routinely interacting with the vendor staff.

Having never been to Mohawk college before, I have to admit that I was quite impressed with the facilities. The buildings are very modern. Everywhere you look, you see technology—on the walls, in the classrooms, in the library, in the hands of the students …everywhere.

One of the more enjoyable parts of my excursion to The Hammer (nickname for Hamilton), was a tour of the Mohawk MEDIC lab. The students demonstrated a complete workflow of a patient’s journey through a referral from her family doctor, to an exam with a specialist (an allergist), and an unfortunate skiing accident in a remote area.

They showed how an EMR—in this case, the open source OSCAR EMR—could accept the referral and share it with the specialist by using an IHE XDS infrastructure. They then showed how the specialist could perform the exam and share the results back to the EMR using the same methods. They also showed the use of mobile technology by EMT and ER staff to review the patient’s records before administering treatment, thus avoiding a potential adverse incident (the allergist report found her allergic to penicillin and other drugs).

Mohawk is serving its students well. They are not only learning about the real world challenges facing healthcare, they are learning about how to build and apply open solutions, and use the latest tools to do it. And they are doing it in a fantastic facility. If you know someone thinking of going there, at least go for the tour—you won’t regret it.

Infographic – Healthcare Providers and Health Information Technology

dondennison Healthcare IT , , , , ,

A picture is worth a 1,000 words …or about US$19 billion, in this case.

Check out this USA Today-style (or theonion.com, if you prefer) infographic from the ONC.

Here is some fun with numbers….

A couple of months ago, I posted on a survey on doctors’ satisfaction with their EHR. An excerpt from the article about the survey…

“In 2012, about one-third were “very dissatisfied” with the ability of their EHR to decrease workloads, up from only one-fifth in 2010, according to the survey. Gripes were seen elsewhere, too. Thirty-two percent were dissatisfied with EHR features and functionality in 2012, compared with 20 percent in 2010, while 37 percent in 2012 were not pleased with their product’s ease of use, up from 23 percent in 2010.”

In the infographic, the ONC claims that “85% of physicians who have adopted an EHR system reported SATISFACTION with their system” (47% “somewhat”, and 38% “very” satisfied).

So, somewhere between 15% (ONC’s numbers) and about 33% (survey’s findings) is about right, I guess.

The survey and the ONC did agree on one area…

  • ONC: “8 in 10 of physicians reported that EHR use enhanced overall patient care”
  • Survey: “One-fifth were also highly displeased with the technology’s ability to improve patient care last year, compared with one-tenth in 2010″

Don’t get me wrong: I believe in the value of an EHR. I just bet that those using them 10 years from now wish that they could send us a message about what ended up really mattering.

Blog – Hospital versus clinic EMRs: what’s the difference?

dondennison Healthcare IT , , , , ,

Technology is easy these days—it really is. Knowing how to use it to solve a problem is harder. And truly understanding the problem is often the difference between success and failure.

I have always felt that one needs to understand the motivations, habits, and even fears of the user, as well as the environment where the product will be used, before design can start.

In this commentary, the author compares the differences between the hospital and clinic environment, and the people working there. I found it insightful, well-written and I learned some new things—check it out.

Article – AMA: EHRs create ‘appalling Catch-22’

dondennison Policy , , , , , ,

I enjoyed this article.

Often, policymakers and executives debate the merits of an initiative. What is often lost in the shuffle are the important lessons and optimizations that make the program a success.

In the article, a number of folks discuss the implications of an EMR after implementation, including the possibility of fraud, or the incorrect perception that it has occurred.

My thoughts…

  • Fraud is easier to detect the more the information is electronic and coded. In fact, any pattern is easier to detect if extensive, well-structured data is available. Algorithms that detect possible fraud patterns will emerge, just as they did for credit card transactions. I recall a investigative news show on Medicare fraud where the agent stated that the move to electronic transactions and ‘smarter and smarter’ alogrithms have made their job easier. False positives will be a problem for a while until they get it right.
  • Coding of records is about to become a huge push. Beyond regulations for coding of data, there are several initiatives to provide codes for orderable procedures, lab/clinical observations, medical terms, diseases, medical/surgical/diagnostic services, and even imaging workflow concepts. Other groups are working to provide practical guidance on how to best use these codes in different contexts. This article talks about the need for better and more coding.

And here is an article on a Web site where EMR users can rate their EMR. There are some interesting comments in the article.

Also, an Accenture survey finds a significant increase in the use of EMR and HIE technology by physicians.