Stumping Around

I’m running for the Board of Directors of HL7. If you’d like to vote for me for the HL7 Board of Directors, click on the link to the right that says “Vote for Keith”. That will take you to a page where you can decide who you want to vote for as an HL7 member.

I have just one thing that I want to focus on as a member of the HL7 board, and that is to strengthen our connection to our customers.

Who are HL7’s customers? Are they the organizations that are members of HL7? Is it the individuals in those organizations who participate in the development of HL7 standards? Is it the vendors who deliver products using HL7 standards? Is it the engineers who create interfaces between products using our standards? Is it healthcare IT organizations looking for best practices for developing frameworks? Is it all of these?

In an HL7 implementation, there are different kinds of people who will be exposed to an HL7 standard in many different ways. At the very highest level, there is one person who is responsible for the budget that pays for use of the standard in the technology that solves their business problems. They may know the standard by name (often not). Next are the handful of enterprise architects and analysts who decide to use an HL7 standard to solve a particular problem. They will know its name, what it is intended to do, and likely how to use it. Following in their footsteps are the handfuls of developers who have to interact closely with the standard to implement it in a business solution. They will know its name, what it is supposed to do, and understand where it works, and where it needs to be worked around for their solution. After that there are potentially hundreds of doctors who use the system that implements the standard. They may be aware of the standard, but only if it happens to be named in some regulation or law, and even then, they might not. Finally, there are the thousands of patients whose healthcare will be impacted by it. They won’t even be aware that it is used in all but the rarest of cases. Who of these are our customers?

The patients and doctors who use applications built upon our work products or who benefit from those applications are not our customers, but they are the people who our customers serve. The person who approves the project isn’t really our customer either. He or she may approve the project, but the real users are elsewhere. Of the groups I enumerated previously, only the architects, analysts, and developers are “directly” impacted by the text that we write that appears in our standards. In our membership HL7 has many more of the architects designing these systems, and very few people who write the running code.

But the people who write the code are the customers we must reconnect to if HL7 is to be as successful as we would like to be. In order to be not just the best, but also the most WIDELY used healthcare standard, we must be the MOST EASILY implemented standard, and that also means the most easily understood. To get there, we need to worry about not just the engineering viewpoint (al la SAIF), but ALSO the ENGINEERS viewpoint.

What Nurses have taught me is that you must treat not only the disease, but also the patient. What I have learned from them, and from the RESTful crowd, and those who struggle to implement HL7 is that to develop a standard, you must understand not just what it must do, but also what the people who implement it must do.

If you feel as I do, please cast your vote for me as a member of the HL7 board this year.