Category Archives: 3 laws

XML Cowboys

While I was in Singapore recently, I spoke about the lessons I’ve learned through my various experience in Healthcare Interoperability. Much of what I spoke about has already been posted to my blog before, but one thnig I spoke about was “XML Cowboys”, which had an unexpected resonance in Singapore.

“XML Cowboys” is a phrase I used to hear a fair bit at HL7 about 5 years ago, but it seems to have fallen out of use. I suspect that most of the cowboys grew up and either used standards or made their own up. Fundamentally, the phrase refers to implementors who look at the standards that exist, throw their arms in the sky, and ask why they have to be saddled with such complexity from a bunch of committees who clearly don’t understand the real world. “And anyway,” they say, “we have XML now, which is self describing, so let’s just use XML.”

I understand this impulse – standards are complex because:

  • They’re designed by committee (both their greatest strength and weakness)
  • They are general case solutions in order to foster re-use of the standard
  • The cater for all the difficult cases that have arisen over the years

But most of all, they’re complex because there’s nothing so complicated as someone else’s solution to your problem.

I dipped my own oar back in the XML Cowboy seas back then too, for all those reasons. Standards are a complicated way to solve things, and it’s a lot easier to just do something direct. Well, it’s easier in the short term. And that’s the key – if your success measures are all short term, the pressure to avoid standards can be overwhelming, because the benefits of standards don’t accrue in the short term.

This is something I see a lot, btw – that people don’t understand the value proposition of standards – you give something up here, in order to gain over there. Here and there might be separated by time, or be different communities, but there’s always a separation. And then people act all surprised when a group of people who are doing all the giving up without getting any of the gain don’t appear to be very committed to the process.

Well, an integration project with short term deadlines and no long term perspective is going to have a terrible time justifying not shifting the complexity into the future (see the 2nd law of interoperability). Because that’s all you can do. In my experience, XML cowboys don’t understand two fundamental things:

  • XML is not self-describing – it needs dictionaries, schemas, agreements to give it meaning. And the agreement is the expensive bit – it takes $$$ to maintain agreement over time and multiple teams
  • All that complexity they reject – too much of it really exists, but they’re not sophisticated enough to know that it’s there. Their project will only succeed if they can get away with pushing that complexity over the horizon

Given enough time, XML cowboys learn the value of agreement and forward planning, and start to appreciate the things that the standards offer.

But the pressure to just do it in a custom way and avoid engaging standards never goes away – and it won’t, as long as it’s possible to incur technical debt without accounting for it. The harder question to figure out is when that’s actually justified, as opposed to occurring through ignorance.

Note: if you scale this up, you get to national programs, and engaging with standards means dealing with their process complexity too. My next post will be about this.

 

 

Complexity of Standards

I’m in Singapore this week, speaking at the 2011 Healthcare IT standards Conference. It’s a real pleasure to be in Singapore meeting with many people I’ve corresponded with over the years, but never met, and also exploring such a great city. In addition, I’ve had many deep and interesting discussions around how to progress either Singapore’s Healthcare system needs, or international standards (or both). Today, I spoke on sharing the experience I’ve learned over many years in my many and varied roles in HL7 and other standards contexts.

Much of the content was things I have already covered in this blog, such as the 3 laws of interoperability, drive by interoperability, and requirements for interoperability, but several things were new, and I’m going to post them here.

I’ll start with this diagram that I showed. It’s a rough plot of the internal complexity of the standard (y, log) vs the complexity of content that the technique/standard describes.

Some notes to help explain this:

  • Text (bottom left) is my (0, 0) point
  • You can solve more complex problems with any of these techniques than their position on the X axis – but you have to invent more protocol on top of it. (That’s what’s XML is for!) So the position on the x axis is that innate complexity
  • The actual position of the particular items will be a comment magnet. But I think they’re generally correct in an order of magnitude kind of way
  • What the graph doesn’t show is all sorts of other quality measures, such as breadth, tooling, integrity, – there’s heaps of other criteria. This is just about complexity.

Complexity is an issue of growing importance – we know that we need to have it – the problems we are trying to solve in healthcare are complex, and we can’t make that go way. But this means that we can’t afford to choose approaches that are any more complex than they have to be – which most of the existing approaches are. I’m spending a lot of time thinking about the question of how to move to the lower right of this diagram – RFH is an answer to that, but is there more we can do?

Btw, where does Snomed CT appear on this diagram? Way off to the top and right… I can’t think of anything that would plot further up than Snomed.

 

How much should we engage with a standard?

This morning I was on a conference call with Nicholas Oughtibridge from the NHS when he briefly outlined a series of levels at which an organisation can engage with standards. I thought his overview was highly worthwhile passing on, and with Nicholas’ permission, I share his document below. The document is shared under the UK Open Government Licence at http://www.nationalarchives.gov.uk/doc/open-government-licence/. Note that this requires attribution with “Contains public sector information licensed under the UK Open Government Licence v1.0.” (consider that atttributed)

Here is Nicholas’s document (thanks very much). I’ll comment a little below.


 

Levels of engagement framework

For each standard the contributors to the healthcare system in an enterprise or jurisdiction (referred to as a contributor in the remainder of this document) can choose their level of engagement in its design, development and maintenance.  Often standards come with associated products, where level of engagement is also a choice.  The level of engagement continuum ranges from avoidance through to control of all aspects of design, development and maintenance.  For simplicity, the continuum is broken down into the five tranches of control, leadership, involvement, acceptance and avoidance.  These five tranches are described in a framework below with illustrative examples.

There is a risk that multiple contributors will seek to control a particular area of standardisation.  This risk needs to be managed with a single governance model with representation for all contributors.

Control

The highest level of engagement is control.  For this level, the contributor values the standard sufficiently to want to control the standard.  Typically a controlling contributor will fund and manage the design, development and maintenance of the standard so that it meets all of their requirements within the context of the healthcare system in an enterprise or jurisdiction.  This will often extend to funding the implementation of the standard throughout the healthcare system.  Compliance is often a combination of contractual, financial, regulatory and technical.

Adopting a control level of engagement risks being unable or unwilling to recognise and accommodate the requirements of other contributors to healthcare systems in the enterprise, jurisdiction or internationally.

Leadership

Where it is not possible, practical or desirable to have a controlling level of engagement it is often desirable to lead other organisations so that standards are designed, developed and maintained in the interests of the contributor.  A contributor leading that design, development and maintenance will often fund their contribution, but probably not the whole cost of the standard.

Leadership ensures that the requirements of the enterprise or jurisdiction are accommodated by the standard or product so there is minimal need to tailor the standard or its products for deployment in the enterprise or jurisdiction’s healthcare system.  Leadership enables a broader range of stakeholders to contribute to the design, development and maintenance of the standard or product, sharing the burden without compromising utility.

Co-production with other parties reduces the cost of development to the contributor and broadens the pool of expertise to exploit.  The leadership level of engagement controls the quality of the standard or product.  Simply engaging without leadership risks the standard or product becoming unsuitable for use in the enterprise or jurisdiction.

Involvement

For some standards or products leadership or control is available from other trusted contributors, organisations or jurisdictions.  Where the contributor has confidence in that leading or controlling party but wishes to exert a level of influence either as a body of expertise or to achieve a national objective it is appropriate to be actively engaged without leading.

Involvement can take many forms, including contributing to telephone conference calls, participation in workshops, undertaking specific work packages, developing software and hosting a secretariat service.

Involvement without leadership is also appropriate where the contributor has no ambition to improve the standard or product so that it better fits the enterprise or jurisdiction’s Healthcare System.

As with leadership, co-production with other parties reduces the cost of development to the contributor and broadens the pool of expertise to exploit.  Engaging without leadership risks the standard or product becoming unsuitable for use in the enterprise or jurisdiction.

Passive acceptance

For many standards the enterprise or jurisdiction has had no direct influence, despite depending on the standard for operations.  For many standards such as Simple Mail Transfer Protocol for e-mail or Hypertext Transfer Protocol this is not an issue.  For some however it is and it is appropriate to seek influence and possibly to strive to lead on-going development.

Avoidance

There are some standard which it is appropriate that the enterprise or jurisdiction does not adopt for various reasons, including incompatibility with legislation within a market or jurisdiction, incompatibility with architectural choices or fulfilling a use case which is not appropriate in the enterprise or jurisdiction


I think that’s a very governmental perspective – but it’s still very clearly laid out, and I’m very happy to be able to share it here.

What about vendors? I think that vendors get to go for control or leadership a lot less often than governments (though they achieve it more often when they do?). Most of us choose between Involvement and Passive acceptance (or Reluctant Dread – don’t forget that option). But a vendor’s choice is about more than control – it’s also about the people;

  • establishing bona-fides to prospective purchasers
  • being informed
  • upskilling & retaining key staff
  • keeping track of industry trends

Academics and consultants have their own model – as I’m finding out (being a consultant now). What about you? why do you participate (and which model do you follow with HL7?)

ISO 21090: Underlying design propositions #2

This is a follow up for ISO 21090: Underlying design propositions #1

Mixins

The underlying notional data type definitions on which ISO 21090 is based (the HL7 v3 Abstract Data Types) include several mix-ins, specifically HXIT, URG, and EXPR. Mixins are a strange type: a generic class that extends the parameter class, instead of expressing properties of the type of the parameter class. That’s a hard idea to get your head around; it’s much easier to understand when you express it like this:

mixin<T> means to use T, and also to use whatever features mixin has as well

Using mixins like this leads to lovely clean designs. But very few languages can actually implement them. (Eiffel can. Ruby supposedly can. Ada supposedly can). But none of the mainstream implementation technologies can (and I think that’s not merely coincidence). If the architectural design uses mixins, there’s three different bad choices for how mainstream implementations can make them work:

  1. Create a wrapping type Mixin<T: X> where it has a property base : T
  2. Create a whole slew of types Mixin_T – bascially pre-coordinate the Mixin type by hand
  3. Push the attributes of Mixin up to X (the base type for T)

Mixins are also discussed here (in a little bit more detail).

ISO 21090 had a base value proposition: that implementers can take the UML model or the schema, and implement them as is with no fancy shenanigans. So we had to make a choice – one of the three above. We chose option #3 for most of the mixins, and pushed their properties up to X, which in practice means that ANY has the HXIT properties, and QTY has the URG and EXPR properties. This, after all, mapped directly to the actual implementations that existed for the v3 data types at the start of the project (at least, those that people would own up to).  Btw, it works too – my data type implementation is code generated from the UML (manually, by keyboard macros, but still generated). Other implementations are code generated from the UML or schema too.

But option #3 doesn’t lead to good theoretical definitions. The mixin derived properties are everywhere, so that they could be used if it was appropriate, but mostly they aren’t relevant or allowed to be used.

To my fascination, the choice to have a practical implementation instead of a theoretically better specification that requires much mucking around to implement particularly angered two VIPs in the healthcare data type world. I understand that, but tough. Again and again we looked at it in committee and chose to have a spec that worked for most implementors.

Design by Condensation

This is a bit harder to explain, but it’s an important plank of the way the data types are defined. It’s a design pattern I’ve never seen discussed anywhere else (though it probably is – there’s a myriad of design patterns out there). (btw. it wasn’t me who invented this one, and it took me many years to come to feel the weight of it’s advantages, where as it’s disadvantages are quickly obvious).

Lets take the measurement related notions as an example. The basic notion is a value with a unit. Sometimes, you might want to track how the data was estimated. Sometimes, you might want to just use some human text instead of or as well as the measurement. (it might say “About 6 foot”, for instance).

Here’s a simple standard O-O model where this is done by adding features in specialist classes.

The problem with this is that while it’s evident what this means, it’s not at all evident how this actually works in practice – it’s just fine and dandy when you have a simple measurement, but when do you have to check whether it’s a particular subtype? And there’s also a permutational explosion of classes as different aspects compete to pollute the specialisation tree. In a moderately complicated O-O system, this starts to become pretty difficult to manage (as consequently, there’s all sorts of lore, design patterns etc about how to manage this. The specific model above might or might not be a good one by these patterns, and I don’t want to argue about the specific model in the comments please).

Instead of inventing ever more elegant and difficult to comply with rules about class heirarchies, we could abandon specialisation altogether, and do the design by composition:

 

Designing models by composition like this is growing in popularity. It’s just pushing the same complexity around to different places, but it’s less…. ethereal. Large compositional models aren’t hard to understand, just hard to navigate. And they’re still dominated by lots of type testing and casting and various kinds of switch statements.

Instead of either of these two approaches, we could define as few classes as we can get away with:

This is what ISO 21090 does (btw, this UML model includes heaps more features than the other ones above). I call it “design by condensation” since we condense everything (it’s just a name I made up, I’m not particularly attached to it).This design pattern has the following features:

  • Fewer types (a lot fewer)
  • The types themselves are not simple
  • But all the logic is done up front
  • your investment will pay off with much easier leverage in the long run (there’s that up-front investment again)
  • The classes do have more “dangling appendages” – properties that won’t get used very often, and perhaps not at all by particular implementations (See Tom Beale on “FOPP”)

That’s how ISO 21090 works. Is it the right way? I don’t know, but it does have real advantages. But the complexity hasn’t gone away, because you can only move it around (law #2).

Summary

These are the big four design propositions of ISO 21090. I think that understanding these will significantly help people who have to “implement” ISO 21090 in their systems. I put “implement” in quotes because it just means so many different things in different contexts. Which is one reason why ISO 21090 is “for exchange”, not for systems. The problem for system implementors is that this knowledge has never been written down anywhere (until now, now that it’s here), and even knowing this stuff still raises a “so what?”: how would you actually implement ISO 21090 in a system then?

Tom Beale and I are going to co-author a system implementation guide for ISO 12090. It’ll include a different simpler model for the types, and describe how to handle other features, as well as discussing issues like how much to normalise the concept data types. It’s a long time ago we agreed to do this, and I was supposed to do something about it – it will happen one day.

 

Reader vs Writer

There’s a a trade-off between reader and writer in most interoperability specifications, though it’s not always widely appreciated. What suits the reader is sometimes the exact opposite of what suits the writer.

As an example, let’s consider exchanging a patient address. Generally speaking, in English language countries, an address has a two lines of text, a city, a postcode (usually), a country, and sometimes a state or province. Around the world, some countries do not have post codes, some have states or provinces, and the amount of structure in the other lines and the usual order of the parts varies wildly. There are a variety of approaches to handling addresses across different systems. Some systems simply treat the address as four lines of text; many systems pull out the city, state and postcode separately in order to either validate them or allow their use for statistical analysis. Usually such systems have to create a field for country too, though this does not always happen. Recently the postal services have started focusing on improved data handling to support high-volume automated solutions for postal delivery, and different countries have created different structured definitions for the street and delivery details . Given the amount of mail that healthcare organizations send, there has been strong interest in adopting these solutions.

Now, consider the general concept of defining a format so that a variety of systems can exchange addresses with each other. The first question is, what are we trying to achieve? Briefly, there are five main reasons for exchanging addresses:

  1. To allow the use of address to assist with identifying persons
  2. So physical mail can be sent to the person/organization associated with the address
  3. So physical mail can be sent to the person/organization associated with the address using high volume mailing methods
  4. To allow a correct billing address to be used as part of a financial exchange
  5. To allow for address based data analysis (usually be post code, but there are public-health monitoring applications that do more fine-grained analysis – though GPS coordinates are more useful for something like this, they are mostly not available)

Here are a few example choices for how we could represent an address:

  1. As plain text with line breaks Suitable for uses #1 – #2, maybe #4 (depending on the the financial standard)
  2. 2 lines of text, city, state, post code and country Suitable for uses #1#2, #4 and #5
  3. A data element for each known part. Suitable for all uses
  4. A series of parts with a type code. Suitable for all uses

Each of these approaches has advantages and disadvantages for the different use cases. but this is not the focus of this post. Now, imagine that we have three different systems:

  • System A Stores an address as 4 lines of plain text
  • System B Stores an address as 2 lines of text, with city, state and postcode
  • System C Stores an address as a set of data elements

This table summarizes how easy it is for each system to be the reader and writer for each structure:

  Structure #1 Structure #2 Structure #3 Structure #4
Writing        
System A Easy: Straight in Very hard: try to parse city/state/code Too hard? Too hard?
System B Easy. Convert to Text Easy. Straight In Very hard: try to parse lines of text? Very hard: try to parse lines of text?
System C Easy. Convert to Text Easy. Convert parts to text Easy – just fill data elements out (as long as parts match) Easy – just create parts
Reading        
System A Easy. Straight in Easy. Convert to text Easy. Convert to text Easy. Convert to text
System B Very hard: try to parse city/state/code? Easy. Straight In Easy. Read parts and build first two lines Easy. Read parts and build first two lines
System C Too hard Very hard: try to parse lines of text? Read Elements into parts Read Elements into parts (lose order)

The effects of entropy are clearly visible in this table: introducing structure is far harder than removing it. A more structured model is easier to read and harder to write. Likewise, more choices about how things are written makes it easier to write and harder to read. The key point of this table is that the different systems have different trade-offs for whether reading or writing addresses is easy.

If you sit representatives of these different systems down to hammer out a format they’re going to use to exchange data, they’re each going to want something different; who wins will be as much about personalities and influence as is it about the right choice (see 1st and 2nd laws of interoperability).

 

Moving the deck chairs around the titanic

In a recent post, Tom Beale argued that one of the central planks of good object design is a principle he called the FOPP (fundamental ontology property principle) principle:

As a fundamental principle, all properties defined on any given type in any ontology or information model must have the potential to be true for every instance of this particular type, at some point in its lifetime.

I think, after reflection, I’m going to have to disagree. And not just because of the name; it’s not that I don’t want to have foppish objects. No, it’s more than that. My first issue, which I made as a comment on Tom’s post is that the definition is still too loose to be of use.

Tom offered as an example, the property “wingspan” on a class of Animal; this, he claimed, clearly violated the principle. Well, ok, I guess that’s reasonable. So let’s be a bit more challenging. How about the property “legCount”? Is legCount a good one to be on the Animal Class? I’m not sure. I sure don’t think Tom’s rule helps me figure it out either. I’m going to start by interpreting as “apply” rather than “be true”. But still – does it have the potential to apply to all instances? Does a snake have 0 legs? Or is it an irrelevant concept on a snake? Does a kangaroo have 2 legs and 2 arms or 4 legs? I guess we’d need a good ontological definition of legs before we could figure that out. And, btw, we don’t even know what an instance of Animal is – is an instance of Animal a species, or an individual beast? I think that might influence the answer too.

I don’t know the answer, because I think it depends on what you’re trying to do.

And there’s the rub: it depends on what you’re trying to do.

Which is where it suddenly stops sounding so easy (not that it did). So let’s go back to nullFlavor, which is our favourite little poster child for this argument. Now Tom says that he’d like a Quantity class that is used for the following:

  • A – uses Quantities to do statistical analysis;
  • B – represents Quantities in data captured from user application screens or devices in an EHR system;
  • C – uses Quantities to represent lab test reference range data, as found in a typical lab test handbook.

Tom claims that the concept of nullFlavor only applies to #B – because clearly you would never perform statistical analysis on data captured from users. Err. Right. Actually, I asked Tom about this and he said that you’d sanitize the data first before analysis (no, but that’s a separate discussion). But still, let’s grant that, and say that therefore we’ll take nullFlavor off this quantity type so you can define it and use in the hypothetical absence of unsureness.

But hang on – what do we do about use case #B now? Well, it pretty much comes down to two different approaches. You can take the HL7 v3 road, and define a “mixin”. That’s a class that extends it’s parameter type class. When I teach the v3 data types, the concept of a mixin is the single most difficult thing to cover. It’s such a simple concept to describe:

When we use type Quantity here, we’ll just add the nullFlavor to it

Easy to describe… but not at all easy to implement. I’ve never seen such a beast quite like that. AOP comes close, and C# has something close. Supposedly ADA does too – but I’ll never use that. The rest of us are stuck with real o-o languages where close enough is not good enough (anyone who’s stared cluelessly at an arcane compiler error about parameter type mismatches will know what I mean). In XML it comes naturally – but if you want to model the XML in some class language (UML, say), what are you going to do?

Alternatively, you can do what openEHR does, and wrap type A in a wrapper class that carries the nullFlavor. See, this is good because it avoids the mystifying questions a mix-in raises, and still means that

When we use type Quantity here, we’ll just add the nullFlavor to it by instead using a thingy that has the nullFlavor and then the Quantity.

All well and good. We now have an implementable solution based on this hypothetical ontologically clean class definition (though we’ve pretty much foregone being able to treat cases which don’t have a nullFlavor and cases which can’t have a nullFlavor interchangeably- this wrapper thing is in the way now). But the clean definition means nothing to me when I implement. Because I can’t go to my customers and say, “Oh, yes, this particular combination of circumstances isn’t something that could potentially be true all the time, so I can’t think about it.” No, indeed. My rule of thumb when programming is that something that happens one in a million cases will arise on a weekly basis across the deployed code base.

Given Tom’s design, instead of dealing with this cleanroom “Quantity” object, I’m just going to end up holding on to this wrapper class instead, so I can handle the few weird cases where I do positively need this nullFlavor. So much for clean design.

The problem comes from this “doing” thing: clean theory doesn’t make for clean implementations. All you can do is move the deck chairs around the Titanic (or see my second rule of interoperability).

p.s. A note about ISO 21090: there are attributes in there that violate the FOPP principle, and that I would’ve liked to go away (HXIT, for instance). But NullFlavor itself isn’t one of them. It’s ubiquitious presence is not an embarrassment to be subtracted away later; instead, it’s a positive statement of value. I understand why people (including Tom) resist that notion, but ISO 21090 does at least offer a single consistent solution to bad data across the whole implementation space. (Some of the particular nullflavors, on the other hand, clearly violate the FOPP principle, and mainly because of modeling laziness too).

 

Taking a fresh look at the community

A couple of private emails I’ve received suggest that my take on the Fresh Look task force is ducking the real issue, that I’m not thinking wide enough. The real issue, they say, is that

Its immensely frustrating how much fractioning (or factioning) there is in Health Informatics generally and certainly in Australia. It’s just as bad in Interoperability and yet by its very nature these are the guys who should sing off one song sheet! Interoperability has a big opportunity to unify Health Informatics and help drive the National direction forward, provided it can get people together from the lowest level (physical) up to the highest (applications).

Um, yes. Let’s go back to my first law of interoperability:

Interoperability: it’s all about the people

Yes. It’s all about the people. The whole task of interoperability is to get people to work together. So when the leaders of the interoperability community can’t actually work with each other…. then it’s the proven blind leading the probably blind. It’s a sad state of affairs that we are in.

I’m serious about this. When I first started formulating my laws, I realized that a corollary of the first law is that

If you can’t work with people (i.e. everybody), you can’t help with interoperability

It was a bit of a surprise when I first thought of that sentence. It made me wonder, because there’s a few quite strong and obvious personality clashes inside HL7, and between various healthcare interoperability communities (all right, there’s more than a few). And so I’ve worked really hard to maintain good relationships myself – because human relationships are what interoperability solutions are based on. Not being technically correct.

That needs emphasis too. A given interoperability problem can be solved multiple ways. Some solutions will be good in one way, some in another. There’s no single right solution – except for the solution that everyone will accept.

But I’ve lost count of the number of times people condemn a solution based on it’s technical merits alone. Wrong. It’s not that it doesn’t matter – but that solutions are never conceived or chosen in the absence of a community with human dynamics. Of course, very often the technical criticisms are just proxies or facades for more human dynamics. Anyone involved in the community will know what I mean there.

When I used to work in the lab (biochem lab in a teaching hospital), we used to joke that HPLC scientists are all the same: for all of them there’s “my way to do things, and all the other wrong ways”. But once I got involved in standards I met a new class of people; for them, there’s “my way to do things, and all the other ways that I am dedicated to destroying because they are wrong.”

It’d be nice if the Fresh Look taskforce could do something about this – but no, that would be self-defeating. The whole point of being able to work with people is that you can work with the people you have, without having to change them. I appeal to my co-workers in this space – work together. This is a human problem, not a game to be won.

I’m not saying it’s easy. It’s a creative journey that we’re on. And it’s one that we believe in strongly, commit our lives to. We try hard – it’s not a gravy train that we’re on. So it’s an inevitable outcome that there’s going to be sparks and fire. But we have to look beyond that.

Btw, I thank the people in HL7 and elsewhere who’ve taken me aside and explained to me when I wasn’t maintaining as good relationships with other people as I though was. It’s part of working with people – eating humble pie (even when we weren’t particularly wrong, though I have been many times).

Context of Interoperability

Interoperability Law #1 says that Interoperability is all about the people.

That has some interesting consequences. One is about the radically different contexts for interoperability. The people who are involved, and the context of their involvement, makes a massive difference to how you approach the problem.

I’ll illustrate by providing two different scenarios, both of which are thoroughly based in real life (I know the people, but names have been changed to protect the guilty and the innocent – and me).

Alice vs Bob

Alice and Bob are integration managers who work for two different vendors, Acme Healthcare Systems and Best Computing. Both vendors sell clinical records systems and laboratory information systems. Alice and Bob have known each other for twenty years, since Bob first worked for Alice. Acme has just won a contract to supply a clinical records system to EverGood Hospital, against stiff competition from Best. Best made a better offer, and has a system more suited to EverGood’s requirements, but EverGood already uses Acme’s laboratory system, and Acme was chosen because both Acme and Best made wildly conflicting claims about how well Best’s clinical records system would integrate with Acme’s Laboratory Information system. Both Alice and Bob know that they were both, err, “generous” with the truth during the sale process, but they’ve been doing this for twenty years now. And over those twenty years, they have come to hate each other with a passion. No opportunity is missed to stab each other in the back.

Now the GoodFeelings Hospital over in the next city wants to get a closer integration between Acme’s clinical records system and Best’s Laboratory information system, and they have called Alice and Bob to a meeting to discuss the problems they are having, and how they can get better results.

Peter and George

Peter and George both work for a large program that is funded and administered by large corporations, universities, and the national government. All the work of the program is published as open source software, and there are multiple virtual and face-to-face interactions through the year. Peter and George have worked together closely over the last few years, and though they don’t actually work in the same team or physical location, they’ve become good friends. In fact, so much so that their families holidayed together over the last major holiday (had a great time camping, and their rooms both feature photos of the fish they caught). Peter generates data that requires analysis as part of the program, and George works for the analysis group.

They need to share their data. Peter and George are used to sharing – they share more than 90% of their data models, libraries, and development methodology as part of the overall program, and even what they don’t share, they can look at anyway. Now Peter and George are discussing how to get even more data exchanged over a drink while meeting at a conference.

In both these, the two people need to improve the way their systems interoperate. And they face the same technical challenges (discussed in a later post).

But because of their relationships, the way that they can go about solving problems is radically different. An approach that will work for one is surely gauranteed to fail for the other.

Generally, Alice and Bob are going to spend a great deal of additional money to solve their problems. But even with George and Peter, conflict may arise, and it can be harder to solve in that case.

Interoperability – it’s all about the people. And there’s not that much difference between interoperability and diplomacy.

Drive By Interoperability

I refer to the case of Alice and Bob as “drive-by interoperability”. They both want a clean encounter, with as little interaction with each other as possible. And the hospital does too – conflict between vendors can be a real problem to resolve. Also, due to variation between institutions etc, what works at one institution probably won’t just work elsewhere.

So all three players want a clean hit with the most bang for the buck in terms of solving local problems with real technical change.

This is the historical context of HL7. That’s what we do: sharing data between two systems where we can take nothing for granted. We don’t assume any rational sharing of any nature between the systems at all, except for the specific interaction that is under consideration. The more interactions you depend on, the more risky the overall implementation.

Forget talking about enterprise buses. We aren’t even talking about shared authentication contexts or user databases. No trust. Ever.

(Aside: I reckon this matches the healthcare system I know far better than any other approach. Trust is just a word you can find in the dictionary 🙁 )

So that’s the classic background of HL7. Drive By Interoperability.

In a case like this, the HL7 standard is a framework for solving problems. The players want fixed technology – because technological change is expensive, and easy adjustment to particular and peculiar business practices between institutions. v2 gives this – Minimal Lower layer Protocol exchanges, common syntax, loose semantics in the fields, highly adaptible. Fit for purpose.

National Programs

That approach was just fine for vendors and small providers. But the problem was that it didn’t scale. If you’ve seen one v2 interface, you’ve seen one v2 interface. And once healthcare institutions started rationalising themselves or their IT, this adaptability of v2 actually become the pain point. You’d think that you had things sorted out, but no.

v2 got a bad name for it’s adaptability (though I think that was the symptom, not the problem). HL7 folks decided that it’s loose semantics were a problem. And kicked off V3, with the reasonable and laudable aim of solving this. And they have too, in many respects. (now we stand on the new mountain top of our work, and see how many new mountains are now visible).

Along the way, HL7 attracted the national programs. They have very different concerns indeed. Firstly, they are much more infrastructural and community centric (i.e. they build their own community). Peter and George fit into the national program picture (though it’s not usually so rosy as that picture). They want to share what can be shared in a rational fashion. It’s not scoring points with the national programs to keep the contact points between systems down, and armor up the ones that do exist with a myriad of possibly related data items. That’s a big disadvantage for them.

Also, they know that  changing technology is expensive (we all know that!). And they need to operate across multiple institutions without having to impose new technology on them. Further what they want to do is impose common semantics and behavior (this is just rationalizing writ large). So what they want is leveragable exchange protocols (web services…), fixed semantics, and highly adaptable technology.

That’s almost the exact opposite of what the original players in HL7 wanted – and still want (sort of).

One house fits all

How do all these players fit in the HL7 house? Well, there’s a fair bit of  tension, not helped by the fact that it’s hard to see this particular problem.

There’s the v2-centric players. They’re still living in the days of pre-rationalisation. (And they’ve got a point too – just what has this rationalisation created, since the underlying problems are still there?)

There’s the big national SOA guys. They’re playing to their script – give us deep integration, what we want. Don’t muck as around with technology. (oh, and, btw, these guys have money and corporate/governance expertise to take over HL7).

Then there’s the techies. They said, “yeah, sure, we can do that. HL7 v3 can solve everybody’s problems.”

Only… I don’t think that’s true (If anything, it doesn’t solve anyone’s problems – see other posts). We actually need to figure out how to capture these different player’s interests, and express the differences without that destroying the larger commonality which does exist.

We solve interoperability

HL7 does solve interoperability. We’ve sorted half adjusted to the SOA/large program community by allowing more points of contact and so forth. But in our hearts, we still design the information models for worst case interoperability. You can see that manifesting, for instance, in HXIT attributes in ISO 21090 (subject of yet another post).

Programs that take up HL7 interoperability solutions need to be aware that the closer they get to Peter and George (and the further from Alice and Bob), the less HL7 is going to seem like a good fit off the shelf. That doesn’t mean it’s not useful – just that you need to know how to correct for these assumptions of badness that HL7 implicitly makes.

HL7: Interoperability in the worst case.

 

Law #3: Healthcare Software: Cheap, Flexible, Interoperable – you can have any two

Healthcare software is expensive. Always much more expensive than people want it to be. But there’s some aspects of this that a lot of people don’t understand.

It’s intuitively obvious that there’s a trade-off between the upfront price of software and flexibility. The less optionality a software package offers, the less work involved in specifying, developing, testing, and implementing it. However once you account for the full cost of the software over full the life cycle, the costs of flexibility are offset by the advantages of the flexibility offered – if the flexibility matches that needed by the user requirements.

The simplest pieces of software are not at all flexible: they solve exactly one problem in only one way. This kind of software isn’t generally very reusable – all software needs to be configurable at least in regards to deployment. Beyond this there is a smooth continuum with growing amounts of configuration, ranging from simple ini-file type settings, through scripting/archetyped solutions, ending with products that are effectively Development Environments in their own right based on some healthcare specific domain language. The more flexible a software product is, the more likely that you’ll be able to make it do what you want. On the other hand, being flexible has a price – as software becomes more flexible, more skills are required to work with it, including learning the product, and thinking with the appropriate level of abstraction. On the other hand, these skills are deployed closer to the problem, which saves the cost of educating developers about the problems.

Interoperability refers to the potential of the software to exchange information with other healthcare software. This includes both functional and semantic interoperability: the ability to transfer information between systems, and have both systems use the information. Obviously there is an automatic cost for interoperability: adding the exchange feature cannot come for free. Even if a whole interoperability framework already exists somehow, connecting features into it is work that must be accounted for (and usually paid for too, one way or another). However the general trade-off between interoperability and cost is only very loose, due to the strong effect of existing infrastructure and frameworks on the cost of development.

The real tradeoff is between flexibility and interoperability. In order to use any information that is exchanged, someone has to understand it. It depends on the design of the system who that is, and what kind of skills they need to have – it could be a programmer, the system maintainer, an external consultant, but someone has to understand it. The more the system understands the data, the easier it is for the person. But the more flexible the system, the harder it is to understand the data, both for the system itself, and for any people trying to work with it, since it has a lot more variability.

This doesn’t make it impossible – just more expensive, much more work to be done. So you have to sacrifice something: either cost, flexibility or interoperability.

The following table provides some example systems that illustrate each of the points.

Cheap Interoperable System An HL7 v2 Messaging Transfer Agent. Can receive and send HL7 v2 messages between almost any system that supports HL7 Lower Layer Protocol, but nothing else.
Cheap Flexible System A clinical reporting tool where reports are specified in an XForm document. Reports can look like anything, but the system doesn’t know how to turn them into a standard message
Flexible Interoperable System Archetype based system where each clinical archetype (of hundreds) is accompanied by full specifications for how to read and write the archetypes to HL7 v2 messages and CDA documents, along with a workflow engine that knows when this is required.  

Note: Fans of openEHR archetypes will claim that archetypes are the cheapest way to build such a system; that might indeed be true (or not), but a system that meets this general description would not be a cheap system.

Of the three rules, this is the one people most want to disagree about. The most common disagreement is that you can’t even have two of these, or sometimes not even one.

The other objection many people have to this rule is that it isn’t binary: you can sacrifice a little on all three, and kind of get some of each of them. This is certainly true, and should be kept in mind. The rule is only true as a general principle. But it’s important and useful because few people are properly aware of the trade-off between flexibility and interoperability.

Update: Mike Bainbridge points out that an improved formulation of this law could be “Healthcare Software: Cheap, Flexible, Interoperable, Safe – you can have any two”. That’s getting a little pessimistic even for me.

Law #2: Complexity: you can move it around, or externalize it, but you can’t make it go away

Healthcare Interoperability projects are complex; they are made up of lots of people and a great number of data items, each with their own complexity, and usually with subtle interactions between the data, the business processes, and the people involved. Generally, the complexity arises from three different sources:

  • The innate complexity of the problem, the real underlying scientific, clinical and business processes involved
  • Diversity in approach and thinking between different instances of the same processes and data items due to different legacy practices, cultures and personalities
  • Human factors (poor communication, poor motivation, failure to understand, fraudulent behaviour)

It can be very difficult to tease these apart; very difficult to determine whether business process variability is justified or not. This is always aggravated by the fact that any gathering of ten scientists, managers, doctors or nurses etc will have at least ten ways of doing something, all of which are the only way. Even if you can properly resolve business variability and somehow correct for human factors, you’re still left with the innate complexity.

You can’t make the innate complexity go away: it has to exist somewhere. However you break up the project, divide the work amongst the project participants, and write the specifications, that complexity has to be somewhere. It’s not going to go away.

Of course, it’s always possible to make things worse, to divide the work up so badly or to describe it so incoherently that you make things much worse than they need to be. In fact, it often seems impossible to avoid this, impossible to do things cleanly: we keep our solutions as simple as we can, but they get complex all by themselves. Since this problem is so ubiquitous, it can be hard to know exactly how simple a solution gets before it’s gotten too simple, before it’s failing to deal with the complexity.

There’s two ways for a solution to be too simple: it just completely fails to account for the complexity of the problem, or it finds some way to externalize the complexity so it becomes Someone Else’s Problem. The first will inevitably turn into a problem during the implementation phase of a project; such projects often turn into death marches as the complexity slowly is dealt with and the successive cycles of reworking for discovered complexity turn the overall project into a permutational explosion of special cases.

The second kind of simple solution – one that externalizes the complexity – can be a very powerful solution indeed. There’s nothing like turning your own problem into someone else’s problem. One of the hallmarks of successful IT solutions is exactly that – that they solve a subset of the problems, the ones that can be solved neatly, and allow other people to extend the system one way or another to solve more complicated problems. On the other hand, this approach can also backfire badly – it all depends on just who the problems have been shifted to, and whether the cost of that is part of the project, or someone else’s project.

The bottom line is that the complexity that does exist must be handled somewhere, by someone. It’s not going to go away. So everyone involved in healthcare interoperability should account for where the complexity has gone throughout a project, and rigorously resist accepting overly simplistic solutions where it’s not clearly understood what happened to the complexity that does exist. Unfortunately this implies that requirements gathering should actually capture the extent of the complexity of a project, and this is most often a total failure – in particular, people seem hardwired to express their requirements as simple principles with some special cases.