Participating in Standards: Burden or Benefit?

Through the course of day-to-day interactions with many organizations, there appear to be three philosophies regarding industry standards. The first philosophy is ambivalence -- organizations that do their own thing and ignore standard. The second philosophy involves using industry standards where there is a business reason to do so, but the standards-making is left to others. The last philosophy involves active engagement in the standards community. This is clearly the hardest path. The open question, then, is whether it is worthwhile?

I believe it is, and for several reasons. Ignoring standards only serves to isolate you or your organization from a bigger community. True, using standards is not without pain. Standards that are open by definition cannot be controlled, so there are no guarantees that they will do precisely what you want or need. That said, the strength in numbers in the marketplace has influence, and eventually if all of your competitors support a standard you'll be compelled to do so to, or to risk obscelence. Just look at the status of proprietary desktop/laptop PC accessory interfaces and you'll see what I mean. How many plug-in devices don't support USB or Firewire, right?

The laissez-faire approach to standards has merit. Standards participation takes investment, and it is not difficult to put together a compelling case to let other companies/organizations make those investments, and for your own to simply harvest the reward. In some circumstances, this can be a sage approach. If the standard is in an area where you have limited existing investment, and the results are not core to your business, for instance. Suppose your product is really about user interface enhancement. You may not care what type of data you are presenting, so whatever data standards emerge from the marketplace would be fine. Laissez-faire works.

Very often, however, companies elect to defer Standards participation even in areas core to their business. Instead of engaging, they wait to see what Standards emerge, and then either adopt them or gripe that they don't meet their needs. Why participate? Participation is expensive. Participation takes time. Perhaps worst, you can participate and still not "get your way" in the result. It can be hard to make a business case to engage. Let's explore why you should...

There are several benefits to Standards participation that make the investment worth it.

1) Earliest marketplace insight. Vendors engage do so to influence the market. Instead of waiting to see what happens, you can influence and shape a standard to be friendly to your products or offerings. While an open standards body will prohibit any one vendor or interest from pushing things into a proprietary solution, there is often a fallback "70%" alternative that is open and still friendly to your organization's interests.

2) Community learning. In my experience, the standards community is rich with A-players that bring extensive expertise and insight. Moreover, within this community there is a shared focus on problem solving very difficult challenges, and the opportunity to interact with resources that you would never be able to reach otherwise. The interpersonal networking is unbelievable, and the credibility established once you're "in the club" allows you future access to bounce ideas and share thoughts with people that have been doing deep thinking about topics such as your biggest challenges. Besides, how can you quantify a return-on-investment that results from NOT doing something that doesn't work based upon a discussion about how others tried it and failed?

3) Soft-sell value of participating. Participation in standards is a commitment above and beyond implementing them. It demonstrates community responsibility, and that has tangible business value. Working to solve the tough challenges facing industry helps corporate image and changes the nature of dialogue with customers. This doesn't mean just going to meetings--it means making something happen.

Organizations elect to participate in standards for many different reasons, but ultimately it is driven because they see a business rationale for doing so. If you're not participating, you might want to take a moment to see how many of your competitors are, and ask yourself why...

Personal Health Records: The Fast Track to EHR?

Many healthcare organizations are working furiously to institute an Electronic Health Record within their environnment. Some have EHR systems already purchased, and are grappling with the impacts of trying to deploy them into the mainstream of care delivery within their organizations. Others have addressed these issues and are tackling the cultural difficulties of making the EHR an asset and not "additional work" for their caregivers. Most organizations, however, have not yet made the commitments to embrace an EHR.

Matters get further complicated when we look across organizations. Of organizations that have EHRs, those EHRs are not necessarily interoperable. Even within a given product suite, organizations may choose to deploy differently, and even use varied content standards making this interoperability challenging or near to impossible, especially if the intent is to share information in a computer-actionable ("computable") form.

In the United States, there is significant buzz around Regional Health Information Organizations (RHIOs), which are working through interoperability challenges at regional and local levels. The issue, however, is that people are mobile and do not exist exclusively within a RHIO. True, a significant portion of people's healthcare is geographically centric, but the business drivers aren't entirely there at the moment to promote regional interoperability.

But what about all of the grass-roots regional integration that is occurring?

True, there is a groundswell of regional activity happening. That said, the functional breadth of what is being integrated is still very small, and many of these solutions are but one-off demonstrations that do not form the foundation for bigger things. At present, the drivers aren't there. Healthcare providers want people to use their services, so the business impetus isn't there. Payers achieve some benefits, but since people change health plans more than geographies, the driver isn't really there either.

Enter the Personal Health Record. As the "computer generation" begins to age, we are facing health challenges that weren't concerns at younger ages: hypertension, obesity, diabetes, and all of the other "joys" that come with middle or advancing age. What is different between today's forty- and fifty-somethings and those of yesteryear is that today's folks grew up with computers and have a mindset of personal empowerment. "Entitlements" that other generations came to expect are largely gone, and what has replaced them is a personal ownership of issues, including our health.

Nobody has as compelling interest in an individual's health information than they do. With the emergence of the Web as a ubiquituous source of information, people are taking matters into their own hands: researching disease conditions, investigating medications, researching alternative treatment, and so on.

It is my believe that this is the community that will drive healthcare to adoption of EHRs. If you look at other market sectors, such as banking, customer service has driven an e-enabled business model. Consumer demand created supply. The same will hold for healthcare. Having to provide personal identifying information dozens of times will become increasily unacceptable. Submitting to duplicate tests already performed adds cost and burden on the patient. Individuals will seek a place to retain their trusted information, even if that comes at a financial cost (so long as those costs are reasonable). People pay small fees for monthly bill-paying convenience, and I believe they will do the same for health information.

As these knowledge sources begin to grow--both in terms of content and marketplace acceptance--pressures on health provider organizations will increase to use that content and integrate that into their workflow. Individuals will opt-in to plans that reduce hassle in their already over-complicated lives. This creates the Gladwell "tipping point".

The byproduct of this will be health IT interoperability. At the point there are sources of content and marketplace drivers to use that content, the pressure will be there for solutions that work. Health interoperability is not about exchanging a handful of data fields among a regional community--it is about providing critical, high-quality health information to providers at the point they need it for clinical decisionmaking (either for intervention or for wellness). Our job as the health IT community is to work the hard problems through so that we are ready to respond to these marketplace challenges.

Why Measure Interoperability?

There is global interest right now in health systems interoperability. Be it the RHIOs connecting community healthcare organizations in the states, or the National e-Health Transition Authority(NeHTA) connecting states in Australia, there is tremendous focus, activity, and spending right now on making health systems work together.

What is needed is an "Interoperability Maturity Model" -- an independent framework against which interoperability solutions can be objectively measured. So, given the seemingly insurmountable challenges in making health systems interoperate would we spend effort in measuring interoperability? Let's explore this topic a bit and the rationale will become clearer.

In the present environment, every vendor and integrator on the planet is peddling solutions that will interoperate. Standards are plentiful. Collaboration is king. Every healthcare IT decision-maker being driven to interoperate by business drivers, internal or external pressures, or their own objectives must find a way to differentiate the marketplace and various marketplace offerings. Similarly, Governments are selecting standards and protocols to address interoperability challenges in various contexts. Which is the best standard to promote demogramics data sharing? How will patient health summary information be communicated? And so on...

As significant decisions affecting health information sharing are being made, there is a very wide spectrum of alternatives available, each with implications. Some solutions are elegant but not yet available to deploy today. Others are stopgap measures that may inhibit the progress of tomorrow. And some are placeholders for more rich solutions that are emerging. The challenge to the CIOs and architects is to select the right solution for thier context.

Enter the Interoperability Maturity Model. An objective metric against which solutions could be measured would provide the basis for informed decision-making. It would allow CIOs and architects to choose solutions based upon their strengths and not market hype. It would allow for more strategic planning and informed investment. Finally, it would also allow those working on interoperability solutions (such as standards) to identify and address shortcomings, improving the overall work.

Maturity Models are not new, and instituting them is not without pain. One need only look at the Carnegie-Mellon CMMI as an example. That said, providers and consumers alike have reaped benefits from understanding CMMI assessment ratings, even if they do not choose to become CMMI certified themselves.

If industry analysts would take on the challenge of creating an objective maturity model for interoperability, I think they would find a huge audience interested. After all, if you're the one entrusted to make these difficult decisions, wouldn't you want a confidence that you're choosing wisely?

SOA for the Right Reasons

I've just recently returned from a set of engagements in Sydney and Brisbane. The Australian National e-Health Transition Authority (http://www.nehta.gov.au) has recently published a set of papers indicating a national direction toward service-oriented architecture as their to-be architectural direction. NeHTA is responsible for connecting state healthcare systems together so as to provide seemless e-Health across the whole of Australia. I was asked to participate in a set of conferences to help stimulate the dialogue about the topic of SOA in Healthcare.

Prominent from the set of discussions (not with NeHTA, but with representatives from vendors, providers, universities, and so on) were a lot of technical questions about SOA: tooling, middleware, architecture, and so on, but not as many about the rationale behind why SOA would or would not make sense.

The selection of a service-oriented architecture must be made for (what I'll call) the right reasons. SOA needs to help address business challenges, or it may not be the right target platform. So, what are the right reasons?

1) Establish authoritative responsibility sources within an organization or enterprise. Large organizations often have multiple different systems, some of which overlap in responsibility. In these cases, it is difficult to know "which system is right", especially if data conflicts between systems that house the same information. Establishing authoritative services solves this business challenge.

2) Address unplanned redundancy. Redundancy itself is not bad. In fact, redundancy is a very good answer/approach to improve system response time, support distributed continuity-of-operations, and so on. The unplanned redundancy is problemmatic though. It means that multiple systems are performing the same function. That means that multiple teams are supporting these systems, and that monies are being wasted. Worse still, it is likely that each different team does things a little differently, meaning that business rules are inconsistently enforced and ultimately problemmatic for the organization.

3) Faciliate technology migration. Heathcare IT systems are often deployed for a very long time, significantly outliving the technologies upon which they are architected and designed. There is a significant need to be able to adopt and embrace new and emerging technologies as they evolve, bringing them into the fabric of the enterprise as they mature and add business value. SOA promotes this integration, since one can "wrap" the new capability as a service, and provide an interface in whatever the protocol de jour happens to be.

You'll notice that in the examples above, there is no mention of whiz-bang tooling, leading-edge technology, or of reuse (per se). Although tooling and reuse are real benefits to SOA, I find them much less compelling than the business reasons. Re-use is not a winning arguement as the basis for migration to SOA. Improving mission-crtitical data quality is. The fact that we can also reap reuse benefits is icing on the cake.

SOA is not a silver bullet, and it must be selected as a target architecture for the right reasons. SOA offers some wonderful advantages, both functionally and technically. That said, if the rationale for your interest in SOA isn't well grounded in your business challenges, you may be looking in the wrong place.

Welcome Aboard!

After spending years getting my thoughts together and distributing them exclusively through e-mail, I've decided to join "the rest of us." Welcome to my Blog on healthcare informatics and interoperability.

I've been working for almost ten years on a variety of topics around making healthcare systems work together. My philosophy is that healthcare IT needs to form the basis for systems to interoperate, and the foundation for making that work is a well-grounded architecture relying heavily on agreed-upon, useful, accepted industry standards.

At present, I am proud to be a co-chair of the OMG Healthcare Domain Task Force (OMG HDTF) and the HL7 Service-oriented Architecture SIG (HL7 SOA SIG), and actively leading the Healthcare Services Specification Project (HSSP http://hssp.wikispaces.com ).

I am a Senior Healthcare Architecut for EDS, serving in the role as the Chief Architect for their Civilian Healthcare and DoD Federal Portfolio. I've been involved in health informatics for 10 years, and IT for 15.

I intend to use this "point of presence" on the web to share some of my current thinking, as a venue to collect new ideas, and to facilitate the dialogue and discussion around healthcare interoperability.

Welcome aboard!