Ken on Health Interoperability

The Road [Not] Taken

2011-08-17T15:20:00.009-04:00

"...I took the one less traveled by,
And that has made all the difference."
Robert Frost

I had the good fortune yesterday to having been afforded the opportunity to participate in a symposium hosted by both George Washington University and UT Health entitled The Role and Future of HIT in an Era of Health Care Transformation. The experience there catalyzed me to get off my laurels and make a few comments after what has been too long of a hiatus.

In a nutshell, the symposium (http://sphhs.gwumc.edu/abouttheschool/events/healthinformationtechnology) sought to convene a community from across the health care sector to consider the principal recommendations put forward in the PCAST report. The document released last December identifying what were identified as key challenges facing the US affecting health care, and where HIT can/should be focused to achieving national objectives in terms of improving our ability to manage care, improve outcomes, and engage citizens. (Ref: http://www.whitehouse.gov/administration/eop/ostp/pcast/docsreports ).

John Halamka has already done an admirable job summarizing what happened throughout the day, so there is no need to do so again. (http://geekdoctor.blogspot.com/2011/08/role-and-future-of-hit-in-era-of-health.html ). What I thought merited attention was the approach that was taken to come to conclusions, as this particular activity chose the road not often taken.

All too often, solutions, policies, mandates, or otherwise narrowly conceived ideas are developed in a vacuum, "matured", and then unleashed onto a much broader constituency which is expected to understand, to embrace, and ultimately to support. There are a few observations about decisions made in this way:

Visibility: We can only address those problems or challenges that we're aware of. Solution development happening among a narrow community naturally has less visibility into a problem space. As ideas are vetted and potential approaches considered, they are done in the context of the problem being solved. A significant challenge that healthcare faces, particiularly when considered in a multi-institutional or National scale, is that complexities grow and there are ever increasing considerations that were not taken into account.

Buy-In: A number of years ago, Steven Wretling from Kaiser-Permanente noted in a keynote session that "Culture eats technology for breakfast." I would assert that it isn't only technology that gets eaten. When ideas are put forward that have not had sufficient vetting (or where there hasn't been an opportunity for the community affected to participate in the vetting), there is ubiquituously pushback. Building into any maturation process the means for the affected communities to engage with the decisions, to weigh in and have their thoughts considered, and to affect the outcome is key for long-term viability and success of any initiative.

The Other Road

While it is not the easiest path (or some might argue the fastest path, but we'll come back to that), a consensus-based approach where input and pushback are actively sought as part of the vetting and validation process can be a much more effective means to an end. Let's explore that notion:

Defining Consensus. The first misconception about consensus is the perception that consensus is ubiquity -- in other words, that 100% of participants agree on an outcome. While this is clearly a happy place, when it can be achieved, it is not technically necessary to achieve a consensus. A consensus, simply put, means that an overwhelming majority can stand behind a recommendation or decision.

A simple majority may be enough to technically make a group decision, but it is generally not enough for that decision to be embraced. If 51% of a constituency agrees with something, then up to 49% does not, and without clear indicators, incentives, or penalties associated, that 49% has yet to be convinced.

Let's poke at the "simple majority" point above. When we don't have consensus, there is a natural tendency for those whom were not believers to either 'wait and see' or pushback. The result is that activities (and ultimately progress) languishes even after a "decision" is reached and deployed.

A consensus-based approach involves much more compromise (and arguably a lower target) as the elements of an approach or solution are identified that can meet the needs of a much larger audience are determined. Sometimes that means leaving something out of scope. Sometimes it means compromising on a little purity. The enemy of the perfect is good enough.

Consensus cannot be about perfect. The question is whether enough common ground can be reached so that perhaps nobody is happy, but [almost] everyone can live with the outcome. Key is to ensure that whatever compromises made do not adversly affect the intent of what was being sought -- is the result still fit-for-purpose.

The difference in this approach, however, lies in what follows a decision point. The value proposition has been thought through. The compromises and tradeoffs already made. Done well, the result is not only fit-for-purpose, but also broadly supported.

The PCAST Symposium

I applaud the organizers, hosts, and participants of the GWU/UT Symposium for having taken the other road. The PCAST report has been a "disruptive" force affecting HIT, and disruption can be either negative or positive depending upon what follows that event. This event included a broad spectrum of diverse stakeholders respresenting government, payer, provider, public health, consumer advocates, industry, academia, and others.

The event was about embracing the core message that PCAST identified: that opportunities abound about how to more effectively leverage HIT to achieve national priorities, and that we must step up and address those challenges. What had been lacking, however, was the stage to convene what are multiple diverse points-of-view and interests into a common ground: to converge the community, and to identify a plan that a diverse industry could support.

While a full consensus cannot be achieved in one day and with a limited audience, what I believe was accomplished was the first step down that path. Having brought together a thoughtful and diverse community to begin to collaborate, and capturing "nuggets" in the form of suggestions that are helpful, useful, and actionable, the seeds of what could be common ground may have been sown from which a much broader consensus can grow.

Reaching that common ground takes longer than does a 51% decision. For that reason, it is often the road less travelled. In this case, however, I believe it will make all the difference.

Interoperability in the Real World....

2008-05-04T19:40:00.005-04:00

Over the past year, I have come to understand and appreciate the value, the importance, and the necessity of tooling in achieving health interoperability objectives. On the one hand, many would suggest that this is obvious, for we cannot build systems and deploy solutions without tools. On the other hand, I would suggest that this is profound. Here's why.

The Real World.
When I speak to folks that are working in the trenches -- the ones that have production systems that are in use and deployed, and are struggling with what new parts to buy, how to choose, and how to make those bits work with what they already have -- it becomes clear that it is all about the tooling. We can discuss the value of standards, which most would agree are good things. We identify target technologies which are the future and hold tremendous promise. We even talk about integration strategies -- the ones that will minimize impacts to the organizations while maximizing value and ROI.

I am coming to realize, though, that the above isn't the real world. [Just to be clear, I'm not denegrading any of the above, and will get into the case for these things momentarily]. What I mean by that is that those of us who need to make IT work in the real world can only do so with pieces that exist. Architecture is important. Strategic direction is important. Standards are important. Having a migration plan is important. Sequencing is important. Ultimately, a whole lot of things are important, but if you cannot touch it, feel it, use it, and deploy it, it isn't real

Standards in the Real World
Standards that go unused are un-useful. Those of you who know me know that I am passionate about standards and their incredible importance in helping Health IT achieve its promise to healthcare organizations the world over. That said, one of the core tenets behind good and useful standards work is the drive to have those standards implemented.

There has been a lot of really good standards work to emerge over the past few years in the Health IT space. One of the challenges that I believe the industry as a whole is facing is that of adoption. The vendors with whom I speak follow standards very closely, but ultimately they must make hard business decisions in terms of where to invest their product development budget, and standards are not always the top of the list. Why not? Us!

As consumers, the responsibility is ours to demand of our suppliers those things that we want and care about. If we say standards are important but continue to make purchasing decisions absent any consideration of which and what standards are supported, the fault is our own. Vendors will provide what the marketplace demands. How does this affect the users, the integrators, and the folks in the trenches? Here's how.

When we pick a new, sexy product that has the bells-and-whistles but not the core architecture, the standards, the interoperability "baked in", the onus falls on the poor systems administrator to make the things fit. The result are internal teams that are asked to perform heroic "one-offs" to glue two things together that were never intended to fit. The integration is brittle, inconsistent, and expensive. Matters are even worse when you consider maintenance releases.

So what about the vendors? Why not just make those investments themselves as a competitive advantage. Well, two reasons surface very quickly. First, if purchasers are not incenting their decisions based upon these factors, then it is pretty reasonable to assume that the competitive advantage is not there. Secondly, infrastructure is expensive. VERY expensive. To get these bits right takes a huge investment of time, cost, resources. There are definitely paybacks (such as improved time-to-market and improved ability to fit into a customer environment), but making the business case for those investments can be very problemmatic.

Moreover, infrastructure has a sustainment cost, particularly as core technologies continue to evolve and as new players enter the market. To many vendors, the business case simply isn't there (or hasn't been effectively made) to invest in the newer standards.

Enter Open Source Software
After a tremendous amount of mentoring and hand-holding over the past year or two (special thanks to Skip McGaughey for getting me straight), I have come to understand that open source software can play an instrumental role in filling this void. How? Open source software provides a platform and a cooperation allowing for this expensive infrastructure to be built via co-investment, where all the players with the need share the burden (and the spoils). The end result is an infrastructure that can support the standards the community cares about, source code that vendors can use (for free!), and most importantly, an engagement model allowing allies and competitors to collaborate on the common bits on which they are not competing.

For example, through open source, HL7 tooling is already available (with more coming soon) that can be picked up and used with no IP [intellectual property] encumbrances. It can be used for free. It can be extended for free. It can be made for-profit without patent violation. Vendors can use it. Hospital systems can use it.

When most folks think "open source", software like Linux comes to mind, or licensing such as GNU, which are not commercially friendly. The key to success in our industry is to marry the commercial and free worlds, allowing vendors to share investments but also allowing them to make a living. Caveat emptor. The code is there to use, however it adds value.

Why do we care? As consumers, we want these standards. We need our systems to interoperate. What better way to get vendors on board than to contribute to a core that the vendors can then use. They can contribute to. Contribution doesn't necessarily mean money. It may mean time -- the time of the poor guy or gal that is glueing systems together today -- only allowing that investment to solve multiple challenges instead of just the problem-du-jour.

So, what do we do?
My recommendation is that there are a few steps that organizations should consider as they embark upon major HIT initiatives:

1) Create a roadmap. You can't get to your target objective without having a sense for where that is. While the 3-5 year vision is not attainable today, there needs to be a path to get there. That path must be paved with tools and technologies that exist, particularly for those objectives you hope to achieve in the next 18 months. Either you're using something that is out there or you're building it yourself.

2) Change your purchasing behavior. If there are no ties between your purse-strings and your plan, you have no hope of incenting the marketplace to meet your needs. While no one organization can do this on its own, collaborating withing the community to drive change is viable and achievable.

3) Engage in Standards. It is really easy to take a back seat and bash the standards for not being useful, and not meeting your needs. It is far harder to be part of the solution. The hidden secret is that the way to influence standards is to show up, and a few committed people can move mountains, particularly when they are trying to achieve a real, tangible objective.

4) Consider Open Source. Open source software is not the be-all, end-all, but there are organizations (such as Open Health Tools) that have the structure to allow for community engagement and vendor participation. These efforts will create shared health IT assets that are real, that can be used, that can be implemented, and that can be deployed.

Until next time...

- Ken

Being Conformant...

2007-10-18T07:22:00.000-04:00

Over the past several months, I have come to a much deeper understanding around issues of conformance. Simply put, conformance is the ability to make an assertion as to some functional capability which can be rigorously and authoritatively tested and proven. Conformance is a term often bantered about when talking about standards, but I believe that it is subject to widespread variation when it comes to interpretation. Perhaps my our recent journeys in the areas of conformance can shed a little bit of insight.

Asserting Conformance

At a base level, it seems desirable (or even advantageous) to use standards to be able to say 'we use standard X', therefore anytime we need to interface we will be relying upon X. This sounds reasonable. Why, then, doesn't it work?

Most standards define qualities, attributes, or criteria which constitute conformance criteria. The intention behind these processes is to provide the foundation against which the standard may be tested, ultimately determining the compliance of any given implementation in adequately addressing the standard in question. Product vendors and organizations alike then make conformance assertions, effectively public statements declaring which standards and which versions are being supported.

This means that the standard is real, is being used, and has been implemented. The implementation has considered those qualities expressed in the conformance criteria and can adequately and sufficiently address all of the expressed criteria appropriately. Further, if the assertions are accurate, the implementation can be subjected to formal testing (either internally or by a third-party) and the implementation verified to conform. How then can all of these steps still result in non-interoperable systems, especially when the standards are being specifically developed to solve interoperability challenges?

Defining Conformance

One of the reasons it doesn't work explains the very mission behind IHE (Integrating the Healthcare Enterprise). IHE has identified, and rightly so, that many of the standards in place today lack the rigor necessary to allow for strong interoperability and conformance. In other words, it is all too easy for two different products or organizations to both be using the same version of the same standard yet not be able to interoperate. This "wiggle room" is a manifestation of ambiguity within the standard, and creates inherent challenges when interoperating.

There are many potential shortcomings that get highlighted when specifications are examined closely. In some cases, underspecification is the problem (where multiple ways to do the same thing may exist). In other cases, standards fall short by not enumerating how the standard applies to a particular situation or use case, rendering it ambiguous at best or unusable at worst.

So, through means such as profiling as IHE does, don't we have the tools to specify the ambiguous portions and result in plug-and-play interoperability, and achieve our objective of strong conformance? Not exactly.

While IHE does an admirable job of nailing-down ambiguity and creating profiles to support designated use cases, their interoperability and ultimately conformacne assertions are based upon their fitness to support the specified use case. While asserting conformance to an IHE profile, one can have a reasonable expectation of interoperability support for the use cases supported by that profile. The real challenge lies when your business need deviates from the IHE use case. Conformance outside of those use cases is no more rigorous than the base standard.

So, does IHE have it wrong? Not at all. IHE is performance a very valuable service within the industry, and is raising the interoperability bar. That said, IHE alone isn't the entire story.

Engineering Conformance

After working with this issue for several months, I have gained a new appreciation for the complexities of conformance. First off, we must consider conformance along a number of axes: technical, functional, and semantic/informational. [Actually, one can even make a strong case for a business-context as well, and we'll touch on this gently in the section below].

Technical level conformance is perhaps the easiest to understand. Usually tied to a physical or software infrastructure, such as a hardware platform or a software development or operating environment. Technical interoperability is not healthcare's biggest challenges. Far bigger issues lie ahead.

HSSP has based functional conformance around the behavior expected and performed in an interoperability setting. Functional conformance is about two interacting things doing what we expect of them. In defining functional conformance, we are expressing formally and rigorous how a system/component/service will behave. This includes its inputs, its outputs, expected behaviours, and so on. Behaviours that are not specified are inherently not supported. The converse, however, is not true, and that is where the power lies.

Semantic conformance, or information conformance, specifies the information content, construct, and formalism needed for interoperablity. By specifying information content, we can then make conformance assertions that relate to that information (and also test those assertions). For instance, if we indicate that a valid value range for a Systolic blood pressure reading cannot exceed 500, then we can verify that assertion by sending a value of 600 and expect to receive an error message indicating that a value constraint has been violated. Similar assertions can be made around terminology-based content, inter-concept relationships, and so on. In effect, this approach allows us tremendous flexibility to define and support information assertions.

Now we have the building blocks, but we're still missing something. For standards to be successful, they must provide for rigor but also be useful. Part of that utility stems from the ability to be flexible, extensible, and adaptable to a variety of needs and conditions, not all of which can be predetermined as the standard is being developed. The notion of conformance profiles is not new, but this is perhaps a bit of a different approach to them.

In order to engineer conformance, we must consider each of the interoperability perspectives independently, providing a mechansm for rigorous specification, supporting multiple use-cases, supporting extensibility within the specification, but without allowing such ambiguity so as to render conformance pointless. Let me assert that the following approach affords us that opportunity: rigorous conformance while supporting extensibility and flexibility. What would constitute such a profile? Consider the following:

A conformance profile tagged with sufficient metadata so as to be expressable and discoverable. Each profile would have at a minimum an identity, a name, and a version, allowing a vendor or user to assert conformance against it and a consumer to be able to look-it-up and verify it and its rules. A conformance profile is comprised of a functional profile, a semantic profile, and used within an interoperablity paradigm.

A functional profile that identifies the subset of the functions within the standard that are supported by that profile. In other words, the standard itself must specify behaviours so as to clearly define what is permissable within the scope of the standard. Not every function is appropriate in the context of any given profile. Within a particular conformance profile, the functional profile will enumerate exactly which functions (or which portions of those functions) apply. A functional profile allows for significant customization or localization of a standard, but it does not technically extend the standard. In other words, one cannot add new functions not previously supported in a profile. Why? What would happen if we add a function foobar within a profile, and then try to invoke it on another system. Nobody but us knows about foobar. That doesn't mean that a vendor can't do it. It means that those added functions do not fulfil conformance assertions within the standard.

A semantic profile defines the universe of potential information content, the formalism for expression, and enumerates specific information constructs that are supported within that profile. For example, a semantic profile may indicate that valid values are HL7 Version 3 RIM components, expressed in RIM terminologies. The notion of semantic signifiers (also known as "templates", "archetypes", and by a host of other names) are enumerated instances that are supported. For example, a Health Summary semantic profile may include may include semantic signifiers defining a Patient History, Patient Demographics, Vital Signs, Allergies, Medication List, and so on. Each of these signifiers would be formally and rigorously expressed, calling out where terminologies are used and what the valid values and value ranges contain.

An interoperability paradigm effectively allows one to express a context in which a conformance profile applies. For instance, an interoperability paradigm may include technical platform details, business agreements, pre-conditions (such as assumptions patient consent, authorization, authentication), and whatever other details are pertinent to the interoperability context. In effect, the interoperability paradigm is a generalization of the IHE use cases that drive their profiling activity.

What have we learned?

The analysis that led to the above concepts has yielded a number of interesting and counterintuitive discoveries. This journey embarked when we discussed what conformance meant to a generic "Retrieve, Locate, Update" service. What was found, very quickly, was that making conformance assertions about something so generic was effectively meaningless, and did not provide value when asserting, testing, or proving interoperability. The means of expression was simply too juvenile. As the thinking evolved and the understanding evolved with it, we came to the realization that the above building blocks provided tremendous flexibility and specificity. WIthin the context of any given profile, things could be strongly, formally, and rigorously defined. Underpinning the specification, however, was a core set of concepts that were more generally applicable. By incorporating a profiling mechanism as part of the base specification and including the dimensions above, new communities and use cases could be easily served within the core specification suite without compromising rigor.

Roles still exist and are desperately needed to identify profiles, to formalize them, and ultimately to test them and implementation's conformance to them. Between professional societies, standards groups, regulatory bodies, IHE, and other organizations, we believe these tools can be applied to address a significant number of challenges not yet thought of. This approach is not a silver bullet, but it provides a depth desperately needed to understand and address many of healthcare's challenges.

Until next time...

- Ken

Creating a Culture of Success

2007-01-18T22:50:00.000-05:00

The Healthcare Services Specification Project (HSSP -- http://hssp.wikispaces.com ) celebrated its unofficial one-year anniversary last week. One year ago, the HL7-side of the HSSP standards collaboration was formally chartered. We have learned a bunch of things during the course of the year, and made our fair share of mistakes.

Ultimately, if HSSP is to achieve its goal of creating viable healthcare SOA standards that are to realize marketplace acceptance, the group creating them must be successful. The energy around this activity has been growing throughout the course of the year, and more activities are presently in the "channel" than we ever imagined would be -- presently six active HL7 functional model specifications under development, and two OMG-issued RFPs to industry soliciting technical specifications based upon already balloted HL7 work.

The following are some of the cultural lessons-learned that I have observed within the group during the past year. I do not believe that we're doing everything right by any stretch of the imagination. That said, I think we are doing a lot of things right.

1) Don't be afraid to fail. The adage "fail early and often" couldn't be truer. We've made a bunch of mistakes along the way. That said, HSSP as a group has been pretty fearless. Ultimately, people are very forgiving folks. We screwed up getting our communications channels right (mixing two mail lists was a horrific failure). We started a little to ambitiously. We didn't have sufficient materials out there for folks to learn and understand what we were up to. The practical guidance to developers trying to solve business problems was lacking.

But we learned. We learned and improved. Problems were corrected. We persevered, and we listened. That listening has made us a better group, and we've done a good job of documenting what we do, improving as we go, and not making the same mistakes twice.

2) Keep the pressure on. Deadlines themselves are good things, not bad things. When we started, we tried to keep "Uncomfortably aggressive" timelines. Nothing so ridiculous that it wasn't plausible, but nothing that would be "comfortable" either. The result is that HSSP continued to push and get things done. Every deadline slipped. That said, I don't believe any have slipped more that one calendar-quarter. Not bad for a project with zero budget and zero dedicated resources.

3) Document your process, and seek continuous improvement. HSSP follows a formally documented process. That process started out with a lot of holes, and still has plenty. Many have been filled in. Inherent in the process, the group, and the culture has been engrained the attitude to do things better, capture those lessons, document them, and then follow our process.

Without a documented process, activities cannot be repeated. Perhaps most importantly, having the process documented means that newcomers can understand what we are doing. A colleague and HL7 attendee whom I very much appreciate and respect said of HSSP "This is [one of] the only groups where you can come into the room and understand what they are doing." The byproduct of having process rigor and operating in the daylight.

4) Let subgroups work autonomously. HSSP created a model where each subgroup must conform to the overall methodology and processes of the project, but they work autonomously. This autonomy allows each effort to establish their own dates, develop their work, meet and discuss, and ultimately custom-tailor to their needs. That said, the overall process ensures sufficient public vetting, quality assurance, and confidence that the work is consistent with the scope of HSSP activities and aligned with parallel work streams.

The upshot is that an increasing number of new work threads are emerging with new communities taking on the responsibilities. HSSP has been able to scale-out and actively collaborate with many HL7 committees, and is even entertaining discussions with newly-interested external standards bodies.

Perhaps most important, this autonomy has created diverse leadership opportunities, where anyone willing to do heavy-lifting can participate and realize business value and recognition for doing so.

5) Keep a relentless focus on business value. Many standards activities are about creating standards, and lose sight of the fact that standards must solve some problem to be useful. HSSP welcomes any point of view, but ultimately makes decisions based upon business value and resource contribution and interest. By aligning standards-development with people's day-jobs, the notion of "volunteers" largely goes away: working on the standard is working on the "day-job."

HSSP since its inception has been constantly striving to connect these two worlds, and has been enjoying slow but steady growth as a result. The business world and the standards world do not need to be in conflict. Recognizing that business needs and interests are strong motivators, there are many work threads that are synergistic to both. Striving to remain in that space is hard, but rewarding.

6) Maintain a high-trust environment. I met Jim Demetriades (Biomedical Engineer and Healthcare Architect, Veterans Health Administration) many years ago and learned a lot from him. One of the most important lessons was the impact of a low-trust vs. a high-trust environment.

In a low-trust environment, we must take on activities ourselves because if you don't, the original intent of your work, how it fits, its success, and progress can be stymied by the world at large. Collaborating is largely risk-mitigation. Ultimately, ownership is of paramount importance, for it provides the enabler to achieve your objectives.

A high-trust environment is very different. It is predicated on the fact that others are focused on their areas of interest, which may-or-may-not intersect with yours. In a high trust environment, you work in the sunlight and expect criticism and feedback that is constructive. Some is, and some isn't, but you learn from each data point on the way.

HSSP has created a culture and in my opinion a high-trust environment. There can be (and are) many very heated, juicy arguments in a high trust environment. That said, the arguments are always technically focused and about improving the work product, and almost always end with the opponents heading off together to lunch or to a watering hole. Built on mutual respect, when each of us expects and demands this from each other we can all be successful together and not at each others' expense.

7) Have fun. I think it was particularly fitting when HSSP concluded its business activities last week in passing a guiding principle that stated, very basically...

...No group would have more fun doing meaningful work than HSSP...

Hard work can be fun, and fun does not have to be irrelevant.

Until next time....

- Ken

Asserting Interoperability

2006-11-07T16:31:00.000-05:00

There are an increasing number of activities today trying to address and/or measure interoperability. Organizations such as HITSP (in the US) are defining standards that will be the support structure for interoperability. Groups such as IHE are developing interoperability profiles to tighten areas of ambiguity en route to stronger interoperability. HL7's EHR group has produced materials to guide consumers through the myriad of infrastructure en route to interoperability.

As we have been progressing with the HSSP activities, our work of late has been drilling-down into interoperability, considering what is needed to interoperate. As I think about my earlier posts, and given that some time has passed since my last posting, I have come to appreciate the importance of the multitude of perspectives that must each be considered to be interoperable. Let's delve...

1) Semantics. "The Holy Grail.' At the point we are able to meaningfully exchange business-pertinent healthcare information, at one level we will have achieved success. The challenge is to maintain sufficient information richness and sufficient context for the information to be meaningful and useful to the consumer.

2) Computational Mechanism. If we have the richest business semantics and we are exchanging that information on paper and via fax, have we achieved the potential of EHR's and interoperability? Probably not. While a purist view only requires information exchange, the format matters. Anyone who has travelled and forgotten a power adapter appreciates the difference. How things plug together matters, and the better the infrastructure we put into place to allow systems to interoperate (such as SOA services), the more flexible our organizations are to adapt to changing needs and technologies.

3) Business and Context (credit to HL7 EHR). Maintaining contextual relevance is important to interoperability. Receiving information items such as systolic and diastolic values does not convey enough information for that data to be useful. The same is true with business context. Patient self-entered information may be less reliable than that entered by a healthcare professional. Maybe not. (For example, what if we're talking about a family history). Understanding metadata and contextual information has relevance as we seek to build interoperability bridges across organizations and enterprises.

So, what do we do?
Two very important pieces must converge to address these matters and be able to assert and test conformance. HSSP work already includes the notion of conformance profiles, which comprise many of the datapoints above. By making conformance assertions that address the semantics and the functions (e.g., the computational mechanism), we are taking a more comprehensive view of interoperability.

Alan Honey (Kaiser-Permanente) had a great realization on a teleconference today that I believe ties things together nicely. If we consider the idea of an implementation context, many of these issues come into focus. Including this concept into our perspective of conformance propels this notion forward. We can elect to have an implementation context bringing together the business perspective, policies, and relevant environmental context in play within an organization. We can do the same for a RHIO or National context.

Integrating the notion of a "domain" into comptuational specifications is well established. (This approach was taken in the OMG Person ID Service -- PIDS -- many years ago). Perhaps I'm just now realizing the potential of this very simple idea as it adds a dimension to conformance and interoperability assertions.

What about Localization?
Not everything needs to be standardized and interoperable. Frankly, that is one of the strengths of this approach. In our conformance profiles, we can make assertions about what information, what behaviors, and what contextual elements can interoperate. The "rest" comes along for the ride. So long as we can precisely describe what is and is not interoperable, we have the freedom to extend specifications to include what we need and still be useful.

Many criticize HL7 v2 messaging because of the lack of interoperability that resulted from ambiguity in "Z" segments. On the contrary, HL7 V2 was and remains wildly successful at allowing organizations to interchange information and interoperate. The problem is not in the wire protocol, it is in the conformance assertions.

We have an opportunity now to benefit from the lessons learned from the past, taking the utility and flexibility offered by "Z" segments and tempering them with strong enough conformance so as to give confidence to consumers that things will interoperate within an interoperability profile. The challenge is on us to ensure that the interoperable portion is sufficient.

Global Warming

2006-09-01T13:26:00.000-04:00

I've just had the good fortune to have been able to attend four conferences over the past several weeks, spanning the US and the Globe. Ranging in audience from dedicated conferences hosted by a large healthcare provider to the Australian Health Information Conference in Sydney to the Mayo Conference on the Intelligent EHR, it has been a tremendous experience.

Several aspects of this experience seem noteworthy. At the forefront, however, was a tremendous shift in attitude toward open engagement, dialogue, and collaboration. Not very long ago, proprietary interests were king, with most organizations worrying almost exclusively about their own interests and concerns.

I have been heartened over the past few weeks to see that this mindset has been clearly pushed to the background, and there is a new (or renewed) interest in working together, learning from each others' mistakes, and in moving together as an industry to tackle the problems and challenges ahead.

Several themes seem to be resonant throughout the very different venues I attended. You can expect to see more on each of them in the coming weeks:

1) HealthcareIT is more about healthcare than about IT.
2) It is very hard to get IT to work effectively within a healthcare organization, and much of that work is about the culture and the deployment (and not necessarily the software)
3) The struggles each of us are facing in our own organizations recur consistently across other organizations and even countries.
4) More than ever, there is a desparate need for standards that meet business challenges

I entitled this entry "Global Warming" to emphasize the consistency that is beginning to emerge across organizations and cultures to resource and contribute to similar activities en route to achieving EHR interoperability. Within the US, there was just signed an executive order that directs Federal healthcare organizations to purchase products and direct investment based upon alignment with industry standards.

In Australia, the National e-Health Transition Authority has been backing the use of standards as they align to their emerging architecture. Collaboration continues between multiple different standards bodies and industry groups: HL7 and CEN, HL7 and OMG, OMG and IHE, and so on.

I encourage each of you to look "across" the industry and not exclusively within. Good work is happening everywhere. After my recent Australian trip, it struck me that some of the closest IT challenges and emerging solutions might well be clear across the globe.

To What Extent Computable?

2006-07-24T09:02:00.000-04:00

As organizations strive to create semantically-meaningful, interoperable systems, the push is always toward establishing "computable data." In informatics speak, computable data is a representation of data values in a form that can be machine processesed and reasoned upon. It is usually depicted in a code value from some formal terminology where semantic links are meaningful and support activities such as decision support.

Present systems suffer in part because they lack this computable data. Free text information is helpful and valuable to a caregiver, but does not allow for the computer to provide the assistance that would be possible if a more structured representation were available. For instance, support functions such as drug-order checking, drug-drug interactions, allergy checking, and so on each require computable data to perform.

I have a big concern, however, that the pendulum has "swung" too far to the other side, where organizations are seeking solutions involving almost exclusively computable data. Computable data comes at a cost, and the "garbage-in, garbage-out" scenario applies here in spades. Without measures in place to validate data content, verify accuracy, and assure compliace to the valid codesets and terminologies in use within an organization, computable data is of no value.

Computable data comes at a cost. In addition to keeping up on data entry and assuring quality, the terminologies themselves must be maintained and kept current. Without quick response terminology maintenance, staff "in the trenches" will quickly become disenchanted and force-fit incorrect coded values for purposes other than what they are intended.

So what is the 'middle ground"? I am very supportive of computable data. It is essential in achieving the potential of EHR systems. That said, we must be judicious and not try to codify everything. Computable data comes at a cost. When that investment is made in capturing and maintaining data that has impacts on maintaining or improving patient health, it is a wise investment. If there is limited or no payback as a result of the effort, it is not a wise investment.

I recommend the following as a start to identify and manage computable data. It is only a start, but hopefully can get some dialogue going within the industry:

> Determine the behaviours you hope to influence, and codify data with direct/indirect impacts
> Identify the information that are the indicators of the health status you wish to monitor
> Identify the information that is the predominant basis for care or care consistency
> Focus on the "20%" which has the "80%" impact
> Relate the terminology work to business purpose. If you can't identify a purpose, question the effort
> Consider secondary uses of data in these decisions (for instance, epidemiology)
> Consider phased deployments of this. Not everything needs to be computable on day-one (but there are interdependencies that must be considered with this approach)
> Recognize that using computable data is not a wholesale replacement for free text

Standards Participation II: Returning Your Investment

2006-07-10T08:59:00.000-04:00

Last time I made a case for getting involved in Standards, but I fell short of describing how to do so in a way that resulted in a productive engagement and ROI to your organization. Standards participation is an investment. Many companies, even those that do participate regularly in standards, neglect to remember this. I've found that there are a few principles to keep in mind when engaging within the standards community.

1) You get out what you put in. One of the most common gripes I hear about standards is that it is a "black hole", where organizations feel like they spend months or years and get little for their participation. These are often the same companies that send their second-tier players to meetings--the ones that sit at the back of the room and take notes but make no impact.

The standards community is a very dynamic, challenging, and political environment. Standards are about compromise, finding a tractable middle ground between different views that is acceptable to all (but likely optimal to none). If you send an inexperienced staff member or a "B"-player, don't expect results. You can expect a good set of meeting minutes, perhaps, but forwarding an important organizational agenda won't just happen. Besides, if 'the other guy' is sending their "A"-team, that's what your staff is up against.

2) Results will not come overnight. As a community, Standards folks have seen people come and go. There are many organizations who believe that they can "game" the system, showing up in force to a meeting or two and trying to push an agenda.

It doesn't work.

Why not? Think you're the first who has tried? Think again. Almost every meeting, almost every organization, it has been tried. The standards community tends to be durable, with people being involved in Stanards for years or decades. Fly-by-night interests come and go. It is a long-term commitment to achieving an objective that will produce success. Standards are about collaboration and compromise, hopefully en route to solving a shared problem.

A sustained involvement from an organization trying to achieve a set of objectives creates credibility, and will result in success. That success may take time--something that can be difficult to justify in a "quarter-to-quarter" basis, especially when you're getting started. Set realistic expectations and performance measures for your involvement, but do set measures to ensure that you are achieving return on investment.

3) You need consistent representation. One mistake many organizations make is in "rotating" around their standards participants among their staff, so everyone gets a chance to participate. Notionally, this makes sense, as a broader exposure within an organization broadens perspectives and is inherently valuable.

Whether this is a sound strategy depends upon the organization's objectives. If you are trying to educate staff this is a valid approach. Organizations trying to influence and change standards find little success in this method. Why? Because Standards groups are political, and interpersonal relationships are every bit as important here as in the rest of the business world. A more prudent approach is to have consistent company representation attend all meetings, and then to supplement that representation with "newbies" who are there to learn.

Remember, if someone is taking a tutorial or bouncing between committees, they are not going to be able to track the nuances of your business agenda and the potential implications of changing standards upon it.

4) Standards do not have to be altruistic. Many standards-goers will flame me for this statement, but I firmly believe that a well grounded business objective is critical to standards success. While it would be nice to think that Standards are all altruistically-based, ultimately some company is footing the bill to participate. Few organizations can afford to do that without a business benefit.

The key is to align the business objectives with the standards work. If you can find standards activities that are day-job relevant, there is a much clearer return on investment. Equally important, that means that the input to the standards process is that much more valuable, because it is based on actual need.

5) Welcome to the club. I hope I haven't scared you off of Standards. Standards involvement is a rich, rewarding, intellectually stimulating, and business-valuable endeavour. The professionals whom I have met in this venue are among the best and brightest in their respective fields, and have contributed countless benefits to me personally and the organiztions that I have represented. Many of this community will change employers several times, with a continual stipulation that they remain involved as they move from one job to the next.

Ultimately, standards particiation is an investment. That investment requires some nurturing, but the rewards are ultimately worth it.

Participating in Standards: Burden or Benefit?

2006-06-30T11:36:00.000-04:00

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?

2006-06-23T14:43:00.000-04:00

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?

2006-06-16T07:31:00.000-04:00

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

2006-06-09T16:13:00.000-04:00

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!

2006-06-09T12:28:00.000-04:00

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!