People often ask me why I'm involved in standards, or what it does for my employer. I can speak generally on this topic because I've had several different employers who have had an interest in standards, as well as experiences with other organizations who engage with IT and specifically Health IT standards.
The most commonly perceived benefit is that there is an advantage to a organization using a standard by being part of the development of the standard, sometimes to the exclusion of others in your industry. This makes me giggle more than just a bit, because while I wish that it might be true, it generally isn't. If you are dealing with a consensus based SDO, anyone who wants to can participate in the development process. In HL7, you don't even need to be a member of the organization, or pay any fees to participate in the development. Your only cost is your time. So, there's no exclusive access.
The "opportunity" presented by participation is early access to content that could eventually become a standard. But most standards development processes take quite a bit of time to get to the point of developing content that is sound enough to begin building software to support. You wind up trying to hit what is either a fast moving target in the early stages, or something which moves at a glacial pace only to introduce new ideas later that break what you might have spent months coding. Building product at the same time as the standard is being developed means that you have to deal with change, and with schedules that are outside your own control. This is especially challenging in healthcare where you have regulatory processes that might also need to be overlaid on your development efforts.
I recall one organization that I worked with that was trying to build an XSLT stylesheet editor at the time that the standard was being developed. Over the course of XSLT development, starting from the first submission in August of 1997 to the first working draft in August of 1998, to the final recommendation in November of 1999 there were numerous design changes that required a great deal of code rework. Having early access doesn't mean that you will have a successful product either. That particular project died before the standard itself became widely used. There was just too much change for the product to accept.
Another common mis-perception is that an organization can simply donate something that it has developed to become a standard. While some standards organizations do provide mechanisms by which standards developed outside the organization can be voted on to become a standard (HL7 does allow this), that's a very hard process for a commercial vendor to succeed at. In part, because the standards development process is open to all, and because affected organizations will want to protect themselves, rarely will a commercial vendor be able to "donate" its IP without having to accept a number of improvements and changes to it. One of the biggest challenges in the development of the XML and HTML Document Object Model Release 2 was dealing with existing work that had been done by two leaders in web browser development. The Web Browser wars were as much fought on T-Cons and W3C meetings as they were in the marketplace. The two biggest opponents in those wars steadfastly refused to allow features into the standard that would have given one or the other a significant advantage in its products.
Organizations must also address the SDO's development process and methodology. A specification that isn't developed using the organization's process, specification structure, and methodology simply won't be able to be accepted without significant change. MITRE has devoted a significant amount of time in the development of their hData specification in order to fit with HL7's methodology. And, by the way, it's very rare that a single organization could develop something on its own that couldn't stand some improvement when examined through the eyes of others (that too is a benefit of the use of the SDO process).
So, what is the benefit to participation if it doesn't provide a significant commercial advantage over the competition? The benefit is elsewhere. Use of standards allows an organization to focus on its core competencies and proprietary* value. Most organizations (except interface engine suppliers) don't focus on "interoperability". Instead they focus on optimizing workflows to perform specific tasks, using technology to enable their customers to better perform their jobs.
Interoperability? Those are wheels on the car. Customers didn't use to ask for them by name (Meaningful Use did change that to a great extent), they were simply expected to be there and to work. The only time something new came into play is when it added a capability that didn't previously exist (like IHE's Cross Enterprise Document Sharing or XDS profile), and customers wanted and asked for that capability. That's why for example, most HL7 ADT interfaces and Laboratory interfaces are several revisions behind the current release of HL7 Version 2.x. Until meaningful use came along, the standards that customers were using worked and were good enough for what they indicated they wanted to accomplish.
Another place where using standards is a benefit is access to the expertise of broad groups of experts. The existing CDA and CCD implementation guides are not the work of one person. The HL7 CCD specification has the input of 14 separate editors, and an even wider group of people who provided commentary, input and improvements.
Use of exchange standards allows organizations to avoid work. They don't need to spend time and effort developing, supporting and maintaining proprietary mechanisms to connect things. Think of what you do today to connect a printer to your PC. Printer manufacturers don't focus on page description languages (any more at least), USB connectors and serial interface characteristics. Those are instead addressed by standards. Where the printer manufacturers focus their attention is on printing speed, resolution, quality and cost. Could you have imagined 10 years ago being about to get 300dpi, 8 page per minute printing that worked with virtually any computer you owned for less that $50?
A final benefit is customer appreciation of standards. While they may not always ask for them by name, they do appreciate when they are supported. Being able to say "we use the standards in our product" is a great check-box item on a product specification sheet. Don't get me wrong, employers also like to be able to say "we led the development of standards" too, but even that rarely shows up in RFPs. My first job working with standards was with an organization that led much of the development on XML based standards, including XSLT, XPath, DOM2 and others. Having that experience can be valuable, but only if that leadership also shows up in the quality of your products, and their ability to meet a customer's need. I've always liked to think that my experience in standards has value, and when it hasn't, I've found a different place to work.
Keith
* Proprietary used to mean "belonging or pertaining to a proprietor" (and still does in some circles). A proprietary product is something sold by a proprietor. It should be a neutral term, rather than a judgmental one, but in today's jargon it has changed in meaning. You can build a proprietary product based on standards. In fact, most interface engines and middle-ware products are just that.
thanks for the information This is very helpful.
ReplyDelete