It is important to never forget that a standard is a tool to be used to attain a certain end. It is easy, and sometimes selfishly rewarding, to get caught up in situations where developing new standards-based solutions seems like the right idea, but in fact it’s putting the ladder up against the wrong wall in the context of certain business cases. One must carefully choose between a path that explores the effectiveness of a new standard and a path of meeting the customer’s business need. Sometimes these paths converge, but they must be taken with care and each situation has a different tolerance level. The truly golden moments are those where the standard actually helps to solve the business problem in a way better than a non-standard can. That’s what we call a win-win!
Standards exist along a very lengthy spectrum and in varying degrees of maturity and usefulness. They have very different meanings and provide different levels of value to different stakeholders. Some standards we take for granted today, such as TCP or XML, but those standards were once bleeding edge, believe it or not. And some developer somewhere was exploring what it might be like to leverage TCP to move data between systems. For example, Tim Berners-Lee was one such developer and used TCP/IP to invent the World Wide Web. This was quite revolutionary at the time, but something we certainly take for granted today.
There are most certainly appropriate times to use new standards to solve business problems, but as developers, we must view them as a tool in our toolbag, not the end-all-be-all way to solve a problem. I have seen customers so often become hyper-focused on a particular standard being the single best solution to their problem, and then once the layers of reality are exposed which make evident the complexity of the situation, all doubt ensues about standards being good for solving real-world problems. It feels like there is some sort of pattern here, perhaps it’s Gartner’s Hype Cycle, and it’s the Trough of Disillusionment that these customers and find themselves in. It is our job then, as developers, and as evangelists of standards to guide customers in and out of the issues to achieve a successful end for all parties involved.
So how do we prevent this? We educate, educate, educate. We must educate at the right level, in the right time, and in the right way.
I don’t do plumbing, but I know a bit about plumbing. If I need to hire a plumber, I know enough about plumbing that I know how to talk to a plumber. This is important because it ensures the contract I have with the plumber is understand both by me as well as the plumber. Expectations of the work being performed and the expected results are well-enough understood for the project to be determined to be a success (or not!). This ensures I do not pay for something I do not understand to a minimal degree at least, and it also holds the plumber accountable for doing a good job. What is important from the plumber’s viewpoint is to set the right expectations to the receipient of the services (me) as to the benefit of the service being provided. If the recipient of the service expects too much, the plumber will come out on the losing end of the arrangement.
People are receptive to receive information in different ways, at different times. We must think about when it is appropriate to deliver information to people so they are receptive to it, and so that understanding will persist. At the beginning of a project is usually a good time, ideas are being shared around, requirements are being clarified, it’s usually not too late to make last minute changes to scope. Bad news should be delivered early and often, along with a mitigation plan, and assumptions should be made that the customer probably doesn’t understand the complexities of successfully delivering interoperability solutions (just as I may not understand the complexities of a complex plumbing project).
The right people must provide education about the effective use of standards for a particular project in the right way. The right demeanor, not insulting/disrespectful, not too assuming, the right amount of patience, and having a passion for learning are all good characteristics to have in such individuals. These characteristics generally are found in people with enthusiasm about their role as an educator of standards. It’s not just about the content being delivered but it’s how that content is delivered. It’s about building a rapport with the “students,” about gaining their respect so that any instruction is well-received. This becomes quite an art when the amount of actual time available to build such trust is so often limited.
Standards are created to bring order to a chaotic world. They must be implemented appropriately and in situations that bring value to most or all parties involved. If there is a cost to bear as an early adopter that cost must be understood and planned for. The big challenge here is that cost must also not be allowed to prevent innovation in the interest of longer term success for the customer and organization alike, and this requires gaining buy-in from the sponsors of the work.
Standards implementation in Health IT is often about vision casting, and educating the middle ground between the exiciting vision and ground level developer work that happens. It’s that in-between ground that helps customers see the benefits of the vision without having to get too deep into the mess (and fun!) of writing code to leverage those standards.
So what is your experience using health IT standards to solve real-world business problems and how have you worked with your customers to overcome issues around early adoption?