Monthly Archives: April 2011

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.


HL7 Fresh Look Task Force

The HL7 board has authorized a new “Fresh Look” Task Force to examine the best ways we can create interoperability solutions, with no pre-conditions on what those solutions might be.   The idea is that, knowing what we now know from what has already been created within HL7 and by other groups outside of HL7, what would be our best approach to interoperability solutions?

I have accepted an invitation to be a member of this task force. It’s my belief that this is a real fresh look; none of the sacred cows are off the table for re-examination.

What’s the task force going to focus on?

I worry that the fresh look will get distracted into arguing about information modeling methodology. HL7 folks are real good at that (I am too). We do need to do that, but to my way of thinking, that’s not our problem, and we can’t get distracted by that.

Instead, I believe that we should devote time to considering how we assess “success” in a fresh look. What do we are we trying to do? What do our customers want? What exchanges are we trying to serve? Are we doing syntax or semantics? Does the market even want semantics? HL7 has two quite different stakeholders in vendors and large programs – can they agree on what they want?

Side Note:Vendors want “Drive by Interoperability”, large programs want something rather different. I think I’ll write a whole post about that (see here).

Note that this is a outgrowth of the v2/v3/cda taskforce – so it’s not about choosing between them. Which is why I don’t want it to be (just) about information modeling.

So who is going to be consulted?

Well, I don’t currently know who else is on the task force (Stan Huff is lead). But I know who’s being consulted. You are. Please think about what I have above. What do you want from HL7? What does your company / government / provider want from HL7? How would we (HL7) know whether we have succeeded?

Either comment here on this post, or write a blog post somewhere else, and let me know about it, and I’ll add a link below. If there’s enough interest, I’ll host a wiki for comments. Stan says, “Please ask for input from everyone,”  so pass this link on – we want as many people to comment as possible. Even Barry Smith and Thomas Beale ;-). (Actually, seriously, I had a long chat to Tom about this last night, and I’ll be adding another post that tries to capture some of what we talked about.)

I’m all ears…

Design by Constraint – not as useful as people think (#4)

This post is the last part of the Design by Constraint series (first post)

In the last 3 posts, I’ve described “Design By Constraint”, and pointed out that one inevitable outcome of design by constraint is that there will be transforms everywhere.

And I said:

The inevitable outcome of Design By Constraint is implementation chaos

Before I go on to explain why I think that, I just want to recap on some of the uses of Design by Constraint:

HL7 v3

  • Reference Model is The RIM + Data Types + Structural Vocab (Note that the RIM has some additional patterns that are orthogonal to Design By Contract, particularly the Act based grammar, and the structural vocabulary layer. I’ll take them up in other posts)
  • Static models as constraints. The static models are constraint specifications masquerading as constrained models – but they are syntactically equivalent to ADL. Static models may derive from other static models and in effect stack up
  • The actual transform to constrained class model is executed by the schema generator, which produces schema that are in effect constrained class models
  • In addition, there is the RIM serialisation, which is the normative XML form for the reference model


  • The Reference model is “the reference model”. The reference model is both more concrete and more abstract than the RIM – it explicitly represents a logical EHR, and then is has open clusters/elements for actual data that carry no semantics at all
  • There is a canonical XML representation for instances of data that conform to the the reference model
  • ADL is used to describe constraints in the reference model in “archetypes”. The archetypes can derive from each other and stack up.
  • There is also the template layer that uses ADL to describe constraints that are applied as transforms to produce constrained class models that are represented as schema. I’m sure they could also be represented as UML PIMs, just like HL7 could choose to do as well


  • The reference model is the CDA schema. No actual UML diagram is widely distributed, though one could be defined (and I think I’ve seen one, though there are some distinct challenges in the data types)
  • The constraints are published as implementation guides with english language statements and schematron constraints.
  • The wire format is the reference model – the single CDA format
  • There is intense interest in using “greenCDA” – these are in effect constrained class models after applying a transform based on constraints


  • In the beginning BRIDG was meant to be  PIM, and constraints on the BRIDG were not expected to happen
  • Now BRIDG is starting to be seen more and more as a conceptual model, which is constrained for particular use (at least, that’s what I see in private communications with CDISC/NCI people)
  • As soon as someone says, let’s make these actual uses formal constraints on the BRIDG model, then the BRIDG eco-system will fully conform to “Design by Contract”

That’s enough for now. These systems are all similar in concept. But they differ wildly i:

  • variations in the description and presentation of the overall approach
  • variations in the details of how things are actually done
  • variations in the choices of technologies for the different pieces
  • focus and balance of the community that adopt them

But in spite of this, in spite of the fact that these variations mean the commonalities are not recognised, they are all variations on the one theme. And they all suffer from the problem of engineering the solution: whatever you do, you have to transform from general to specific, and back.

Implementation Disasters

The inevitable outcome of wide scale adoption of this technique is chaos. Different implementors want to live at different points on the general <-> specific curve, and there’s a variety of options to attempt to externalise costs from one implementor to another.

There’s various approaches to handling this. You can be like HL7: put your head in the sand, claim that it all works (in other words, externalise the costs), and then be real confused about why your brilliant idea isn’t actually solving all the problems in the world.

And this happens precisely because if you buy into the whole notion – learn the ways of the master model, and build a specific software stack to deal with the products – then it actually works pretty well. Please note this: If you embrace the model, the outcomes are solid. And there are many people doing so (HL7 JavaSIG/RIMBAA particularly). (or, to express it differently, if you invest where the costs have been externalised to, then you’ll eventually benefit from the savings that accrue where they were taken from)

But when you treat the design by constraint framework as an interoperability specification to be taken up by projects and/or standards that are going to be implemented across as multitude of applications who just want to use the standards – then they’re just going to feel the pain of the externalised costs, and they’ll never really derive the benefits of the outcome. And the politics will eventually overwhelm you.

People go on and on about the structured vocab, and acts, and various ontological features of the RIM. But I reckon that 90+% of all pushback to v3 implementations that I’ve seen is related to the costs of design by constraint, and what it does to the XML (i.e. instance engineering problems). HL7 externalised those costs very effectively. And that’s an own goal. (And note that the discussion around UEL and PCAST vs CDA walks into things like XML, OIDS in XML, so forth – all things that arise from the way the CDA community does design by constraint).

openEHR walks around this by being explicit about the costs, and not being adopted as a standard. You expect to be writing specific software to make it work, or you only deal with the constrained models that come out the end. Note, again, that this is about externalised costs. Either you pay the cost – learn the reference model, invest in tools and software – or openEHR internalises the costs by handling all the transforms privately (only I think that this approach will be a problem in the long term – implementors are stuck on the wrong side of the power of the reference model).

But if a large project or a national standard turned around and picked openEHR instead of v3 – well, it’s not going to be any different. Design By Constraint will lead to chaos.

OMG, come save us?

I think that this problem really needs OMG.  As I pointed out earlier, this is really a case of design by contract – all we want is sophisticated contracts, and OMG has only provided really crude tools to do this.

Actually, what we are trying to do can be explained differently. UML defines Class diagrams and Instance diagrams. Class diagrams define a set of possible instance by defining their classes and the possible value domains they can have. Instance diagrams define a particular instance of data in terms of the class diagram. We want something in between – a diagram that describes a possible set of instances without taking ownership of their types. Easier said than done, though.

When I make the presentation of this content (the whole series of 4 blog posts) to OMG – and I have done so to some of the UML maintainers at an OMG meeting – their eyes glazed over, and they looked at me like I was an idiot. That’s crazy, they said: you’ll never get engineering continuity and coherence doing this.

Yeah, I agree. But semantic continuity and coherence – how you going to get that? (That’s where we started, what we’re trying to achieve) Well, I came away with the conclusion that engineers aren’t overly concerned about it. Sure, they get the notion of more sophisticated leverageable contracts in design by contract (and they had a good look at ADL too, with interest). But that’s only half my story.

I don’t know: how much is semantic consistency worth? That’s a subject I’ll take up in a later post.

In the mean time, I wish that the downstream price of Design By Contract was better understood by the people doing it, and by the large scale projects that adopt it. It’s not that it’s a wrong thing to do – but you have to know where the costs have gone.


Design by Constraint – not as useful as people think (#3)

This post is part of the Design by Constraint series (first post)

Instances, Designed by Constraint

So let’s take a look at an instance.Here’s an example UML instance of data that conforms to the constrained model:

The first thing to say about the instance is that an instance of data is always described in terms of some definitional model. You don’t simply put the data down:

Ravi's Tandoori Fantasy, 3,
42 Main St Hicksville, Victoria, 3874
Greedy & Mean, Inc, 123-34-35
Ravi, M
Shivra, F

Bit’s of this might be recognizable,  but it needs structure and information about the data items. And this is always be given a reference elsewhere. Many people don’t understand this about XML, because it’s called “self-describing” – but it never is. It achieves it’s description by reference to some other model in the element and attribute names – the only question is whether the other model is implicit or explicit. And we know from long experience how well implicit agreements work.

Any way, the point of interest here is that the data conforms to two different descrptions at once, and can be described either way – by the general reference model, or by the specific constrained model. The easiest way to illustrate this is using XML to represent the data. This first XML describes the data in terms of the general reference model:

  <name>Ravi's Tandoori Fantasy</name>
  <address>42 Main Street</address>
  <address>Victoria 3874</address>
    <name>Greedy & Mean, Inc</name>

This second XML defines the data in terms of the constrained reference model:

  <name>Ravi's Tandoori Fantasy</name>
  <address>42 Main Street</address>
  <address>Victoria 3874</address>
    <name>Greedy & Mean, Inc</name>

The data is the same in either case; the XML names are different, and there’s more information in the general one, whereas in the specific case, that information has been moved out of the instance into the context.

The models may be transformed from one to the other.Assuming full knowledge of the reference and constrained models, and the constraint transform, and that the instance conforms to the constraints, it’s always possible and straightforward to transform the specific instance to the general instance. On the other hand, it isn’t always possible to transform from the general model to a specific model. Firstly, it can take considerable computing power – you have to speculatively (and recursively, often) determine which of a set of constraints an instance conforms to. Actually this is a regular feature of parsing instances, but the ones that rise from design by constraint tend to have deeper resolution points.

In addition, it’s not always possible to unambiguously resolve which constraint an instance conforms to. A typical example of this is found in CDA:

In this model, a manufactured product (on the right) has an entity (on the left) that is either a “LabeledDrug” – a Manufactured material (MMAT), with optionally a code and a name, or a “Material” which is a Manufactured material (MMAT), with optionally a code,  a name, and a lot number. This is not only an ambiguous model (how do you tell which one an instance is?), it is an example of semantics in the model that are not in the instance. So it’s a bad model – ambiguity usually means that – but it’s really difficult to eliminate/prevent these things (there’s some research work around on how to define such ambiguity and write tooling to prevent it).

General vs Specific – which to use?

Which XML should you choose?

—General Model
  • a single form is shared between all systems – even if they have narrow scopes
  • This imposes greater costs across all implementations
  • Narrow implementations will pay higher costs due to the increased capability of the general model – particularly when reading the instance

It’s worth emphasizing as this point – the general XML (check above) – it includes a whole lot of things that aren’t really pertinent to the particular case. They relate the specific case to the general case. The increased cost comes because of the cost of everybody explicitly representing that mappings to the general case. For systems that deal with the general case – that’s a good thing. For systems that don’t – it’s a pure overhead, a tax. And the important question is, what do I get for my tax? (Except for some countries, where the mere fact that it’s a tax makes it bad ;-))

Specific Model:

  • Different implementations will have different scopes / different use-cases, and therefore they’ll use different forms
  • Unless the use-case is limited to a single scope (in which case the general model is spurious anyway), some transform engine will be needed somewhere in the mix

It’s worth noting about the specific model – an inevitable outcome of the using the specific models will be that systems end up handling the same data again and again, but each time with a completely different engineering basis – even if they nearly look all the same. In the end, almost every system that encounters multiple use cases will start abstracting their internals away from the specific engineering towards the general case.

I think that if you handle 1-3 use cases, then specific is better for you. But around 4-5 cases, it becomes worth investing in the general approach. Mileage varies widely depending on complexity and team culture, of course.

But whichever model you choose, it will lead to transforms everywhere – as long as scopes differ, and analyses of requirements differ, there’s going to be transforms. And transforms are expensive. Expensive to specify, develop, and execute. In addition, many system architectures don’t fit transforms easily.

(I don’t actually understand that bit. Do architects really think they won’t be doing transforms? How stupid would that be? But it’s true, I see it all the time. It’s actually an attempt to violate my second law, and externalise complexity away. I know it will fail eventually) (Oh, and also, an alternative approach to solving this general problem is to indulge in the fantasy that there’s some general model that can be imposed on all applications so that this model mismatch doesn’t occur. This one violates my second law multiple ways, and will always fail in the end, but that doesn’t stop people from trying it out.)

There’s yet another option, which is to try to do both at once. Here’s an XML example:

<FamilyBusinessRestaurant type="Restaurant">
  <name>Ravi's Tandoori Fantasy</name>
  <address>42 Main Street</address>
  <address>Victoria 3874</address>
  <accountant type="Person" association="person">
    <name>Greedy & Mean, Inc</name>
    <businessId source="taxId">123-34-35</businessId>
  <family type="Person" association="person">
  <family type="Person" association="person">

This example uses the specific model names, and adds the general case as markup. The same arguments would apply if we reversed that. And this is not just an XML thing – you could do the same using a UML instance diagram (or metaattributes in C# etc):

This approach is the worst of all worlds – the system that builds the instance must know the general model and all the specific models that may apply (because multiple may apply). And there’s no support for this kind of thing using tooling for CASE/MDA (well, maybe a little).The only way to make it happen is custom tooling – which includes internal transforms, and with external transforms here and there


Which brings you back to the conclusion:

Design by Constraint => Transforms everywhere

Next: what does this mean?

Design by Constraint – not as useful as people think (#2)

This post is part of the Design by Constraint series (first post)

More structured Representations


An english representation of the constraint (as found in the previous post) is good, but a structured representation is even better, because this can be leveraged in various ways.

UML provides OCL (Object Constraint Language) as a means for making the constraint against the reference model. Here’s the same set of constraints in OCL:

context Business
 inv: isFamilyBusinessRestaurant
 def let FamilyBusinessRestaurant : Boolean =
  franchise.isNull and
  address->size() >= 3 and address->size() <= 4 and
  corporation.isNull and person->size() > 2 and
  person->size() <= 7 and
  person->collect(isAccountant)->size() = 1 and
  person->forAll(isAccountant or isFamily)

-- how to express "address order matters"?

context Person
  def let isAccountant : Boolean = role = "ACC" and
   corporation.size->() = 0 and sex.isNull and id.isNull
  -- how to express "taxId is renamed "businessId"?

  def let isFamily : Boolean = role = "EMP" and
    id = null and taxId = null and
    corporation.size->() = 0

This OCL could be converted code, and used to check that a particular instance of classes from the reference model conforms to these constraints and is therefore a proper “Family Business Restaurant”. That’s good and useful: a black box that gives a yes/no answer. (What isn’t so useful is that the error messages from an OCL engine in the case of failure are beyond cryptic and obtuse.)

But there’s a problem with OCL: that there’s no way to transform a set of OCL constraints to software modules that know how to produce valid instances, to classes that a compiler can use to force the programmer to build the instance properly.(It’s arguably possible, but certainly extremely difficult – a research project for a big multinational with a 3 letter name, perhaps).

Table Syntaxes

Because of this, various forms of tabular representation are popular. Here’s an example table:








no constraint








order matters








Person “Accountant”




Person “Employeee”

These tables are widespread because it’s relatively easy to use table forms like these to generate useful code.

And that’s a problem with the table form – there’s a lot of subtle interactions between columns (cardinality, collections, and empty values are a big source of subtlety), and variations in how patterns are linked together between tables. In addition, there’s all sorts of interesting extensions to the tables to deal with things like co-occurrence constraints.

As a consequence, there’s a lot of different table syntaxes. XML schema is one form of table presentation that constrains the XML reference model (elements, attributes, text, etc). As a rule, syntax doesn’t matter – syntaxes are interconvertable. It’s the semantics underlying the syntax that make it hard to interconvert between forms. So there’ a lot of different forms, each with slightly different meaning and limitations.


ADL (Archetype description language) is a formally defined constraint language purpose built for constraining reference models. It’s easy to write an ADL statement that is equivalent to the OCL statement above, and you can use this to generate code

	RESTAURANT[at0001] matches { -- family restaurant
		franchise occurrences matches {0}
		address cardinality matches {3..4; ordered} matches {*}
		corporation occurrences matches {0}
		employees matches {
			PERSON[at0002] occurrences matches {1} matches { -- the accountant
				role matches {[at0020]}		-- ACC code
				id occurrences matches {0}
				sex occurrences matches {0}
				corporation occurrences matches {0}
			PERSON[at0003] occurrences matches {2..6} matches {	-- family
				role matches {[at0021]}	-- EMP code
				id occurrences matches {0}
				taxId occurrences matches {0}
				corporation occurrences matches {0}

	term_definitions = <
		["en"] = <
			[at0001] = <
				text = <"family restaurant">
				description = <"some longer description of family restaurant">
			[at0002] = <
				text = <"accountant">
				description = <"some longer description of accountant">
			[at0003] = <
				text = <"family">
				description = <"some longer description of family">
			[at0020] = <
				text = <"ACC code">
				description = <"some longer description of ACC code">
			[at0003] = <
				text = <"EMP code">
				description = <"some longer description of EMP code">

Note: Tom Beale wrote the ADL for me (Thanks very much, Tom). Tom also noted that in ADL (like most of the other constraining frameworks discussed), it’s wrong to rename the taxId to businessId; or else the reference model would need to vamped up to allow for it.

But ADL has it’s limitations. You can’t do anything you can do in OCL with ADL (ADL includes an expression syntax quite like OCL for the kind of things that can’t be built into useful software).

Aside: HL7 v3 static models and ADL are tightly related. You can think of v3 static models as a graphical equivalent to ADL. They are nearly interconvertable – there’s a few semantic differences (ADL does binding between models with one less level of re-direction; Static models allow choices at the root, and ADL doesn’t allow this; static models to terminology binding differently, etc). I’ll explore that similarity later in this series of posts.

Class Model

Or, you can say that really, the constraints aren’t very interesting. What would be really interesting – simple, easy to work with, and clear – would be a simplified class model that just describes the outcome of applying the constraints to the reference model. Like this:

That’s pretty simple – a class model you can do the normal things with. But what’s the relationship between these two class models?

Well, you can call the reference model a metamodel, and think of Restaurant as a metaclass, and FamilyBusinessRestaurant is an instance of this class. And this the first response of all the OMG-type people who look at the diagram above. But it’s not – we originally said that the reference model was a class model that is intended to be treated as a PIM.

The relationship between these two models is summarized by this diagram:

There’s a reference model (UML Class model), and a constraint specification (some other syntax). You perform a transform that applies the constraint to the reference model, and produces a new constrained model (also a UML Class model).

The pattern is allowed to recurse in some contexts – the output constrained class model can be treated as a reference model in a new cycle. (Sometimes the constraint languages are different: RIM -> CDA -> Implementation Guide; and sometimes they are they same: RIM -> (Static Model)n -> Schema)

This is design by constraint – widely use in healthcare.

Note that the transform is usually not reversible – the process of applying the constraint to the reference model is destructive.

Note also that the v3 static diagrams are neither wholly constraint model, nor wholly transformed model – they are a half hybrid. They are primarily anexpression of the constraint, but they have the form of the constrained model.

Design by Contract

We should note at this point that this a form of design by contract. The notion underlying design by contract is simple: a callable procedure/routine/function/operation/method etc or some other defined context takes a somewhat general parameter type – integer, or string, or some kind of class. Because the type allows a wider set of values (value domain) than the method can properly deal with, the context of use constrains the value domain to the set of values that are allowed (hopefully in some computable fashion, though it’s not unusual to find old 3GL code laced with comments capturing this kind of information).

All that we doing here is design by contract with complex and deep parameter types. A generic set of classes that have a wide application are used in particular contexts, and we want to document their limitations in a useful way. It’s that simple – but OMG hasn’t given us a proper computable framework for this problem.

Capturing Design By Contract in UML

So let’s see how far we can get in UML with this approach.

Here the constrained model has been marked up with stereotypes and property strings that capture the reference model links in the UML model. For instance, the FamilyBusinessRestaurant has the stereotype “Restaurant” which signifies that it’s a constraint on the class “Restaurant” in the reference model. There’s a lot more stereotypes and property strings than the visible ones, but the visible ones serve to show the purpose.

This is all fine – and in fact, there’s a UML profile for HL7 v3 that formalises this stuff. But no matter how “proper” a UML profile is, in in the end the UML tools don’t know what the stereotypes and property strings actually mean, and how they influence code generation, then what use is it? (In fact, it’s worse than that, as we’ll see below, because “how they influence code generation” turns out to be an impossible problem.) In order to get tooling support, we need to first get OMG to endorse the notion of design by contract, and publish an appropriate UML profile, one that has good engineering support.

Please OMG….

Instance Behaviour

But before we jut punt the problem over to the OMG, let’s ask what it would mean for instances, this design by constraint thing. After all, standards bodies etc might publish models, but implementers work with instances. And the it turns out that the instances have quite a bit to say about this design by constraint pattern. But I’ll leave this for the next post.

Next: Instances, designed by constraint









no constraint







order matters







Person “Accountant”




Person “Employeee

CDA Stylesheet Control

We’ve been having a rather intense debate within NEHTA about stylesheet control with a CDA implementation community.

The context here is that you have a nationally sponsored CDA implementation guide, and a community that is built around that. The community have trading partner agreements, and there is CCA testing at the point of entry to the community. In addition, the CDA documents that are exchanged within the community will also be archived into some wider form of EHR either immediately, or in the future. (Application doesn’t really matter, but could be Diagnostic Reporting, Prescribe/dispense, Discharge Summary, Shared Health Summary, Procedural note, etc)

The question is how the stylesheets should be managed. Generally, there’s the following 3 choices:

  • Author provides the stylesheet that is used whenever the CDA document is displayed
  • Community agrees to a single stylesheet that is always used
  • The receiving application provides it’s own stylesheet

The CDA specification is actually pretty loose here:

the contents of the Section.text field must rendered per the rules defined in Section Narrative Block (§ 4.3.5 )

rendering of the CDA document header is at the discretion of the recipient

While HL7 provides cda.xsl with the CDA specification, it is not required that documents render “properly” with that stylesheet, though many implementation guides require that a document should render properly with it. Part of the problem is that “properly” can only be understood in terms of section 4.3.5 which is descriptive rather than proscriptive.

In particular, there’s still a lot that is open to stylesheets – colors, fonts, borders on tables, how to squeeze space out of the screen/page, what html structures to use, which browsers to target, and most of all, how to handle attachments. (On a related note – the HL7 cda.xsl has several issues in this space, and only primitive support for handling image attachments.)

What else can you do with a style sheet? Well, you can first of all define your own styles for use in the styleCode attribute – your corporate look and feel, for instance. And on that subject, you can do more corporate branding like including images and stylesheets from your own web site, and make the CDA document rendering look exactly like how you want. And, in fact, you can define entities in the xml that are expanded out to commonly used sentences in the stylesheets and really save space. (Yep, people keep putting this to me as an option at CDA training courses).

So obviously it’s best to let the authors provide their own stylesheets, and send the stylesheets around with the document, and you always use the specified stylesheet when viewing that particular document. After all, this is the point of Keith Boone’s self-displaying CDA.

But wait a minute….

The biggest problem I have with this is that systems can’t just use any stylesheet. Firstly, when it comes to image attachments, how they must be handled depends on the system architecture – do they just spawn a browser as a separate process to view the CDA document (which browser?) – and how do they secure that? Or maybe they use an internal web browser control, and control the way that images are provided from their own resources? Or maybe it’s a web server anyway, and things are even more complicated? Are these systems supposed to auto-import any old transform? And on that subject, how on earth would you secure that?

You can see the implications of this in the long list of things a self-displaying CDA document isn’t allowed to do, such as have images in it.

I’m not sure that you can build an infrastructure where the author is allowed to send custom stylesheets. Even if you could somehow prevent them from abusing that – given that you could even define what abuse was – there’s still too many dangerous things for an author to do and depend on for a receiving system to fail on. Not safe at all.

So maybe the receiver should do it. They could just make their own decisions…. that makes sense, because they are the ones who know how much context is shown by the application, what the screen they are targeting is (yay iPhone!), what standard look and feel they have in their application (fonts, colors, operating systems etc)

But then how can an author be confident that their document renders properly – after all, they’re on the hook for that. How do they test?

I think the best thing is for the community to specify a single transforms. Authors have to test by the standard transform. Receivers have to implement the standard transform as best as they are able to given their Operating System and output constraints.

I don’t know quite how you would do CCA on their use of the transform.I suspect it’s going to come back to human testing in a consensus environment.

NEHTA has had a robust discussion about this issue. Over time we’ve gradually converged one what I think is the least worst approach: for the community to define a single stylesheet, and everyone to target that one as best they can.

Which leaves open for us the question of how much of the CDA header should be displayed by the stylesheet, and how much delegated to the application. Perhaps the answer is that nothing delegated to the application. The application could choose to display it’s current patient details, for instance, but should still be required to display the patient details embedded in the CDA document, since they might have changed…

My iPhone has a life of it’s own

So the latest news is that your iPhone tracks your location, and you can use this to get a view of where you’ve been. So of course, I had to have a look, and here’s my map – where I’ve been in the state of Victoria recently:

Well, it’s a strange thing. I’ve been all over Melbourne. And I’ve driven to Sydney – that’s the line north/east from Melbourne towards the top of the map. And I’ve also been all the way east too. As for the presence down the coast to the west – I haven’t been over that way since September last year – before I even got this phone. How does that work?

There’s a few trips I’ve made that it doesn’t know about. Like a week at Dromana – south from Melbourne around the bay.

But the bit that confuses me is that spur across the top reaching from about Holbrook towards Cooma – I haven’t been on that road for nearly a decade. Perhaps my iPhone made a trip of it’s own without letting me know? The same applies to the scattering of points through the country north of Melbourne – if only I got out as much as my iPhone apparently does. I checked, and my wife’s iPhone gets out on it’s own nearly as much as mine.

Or perhaps the iPhone’s ability to track location is pretty poor in Australia. But I’m sure that’s not Apple’s fault. We can surely blame Telstra instead 😉

p.s. Some people are all worried about using iPhone location tracking data for some kind of investigative purposes. I thought that might be a problem for some. But now I’ve looked at the data – not so much.


Design by Constraint – not as useful as people think (#1)

Design by Constraint is  a framework pattern used in a number of specifications across healthcare, including a number of high profile standards. It’s a great way to deal with the problem of ensuring semantic consistency in a large information design, but the engineering outcomes are rather less than optimal.

Note: This is the first post in a series (probably 3-4 long) that are really a single document explaining design by constraint.

Welcome to “Design by Constraint”

Here are some examples of “Design by Constraint” in healthcare:

Because the specification, implementation and engineering differ so widely in these different cases, it’s hard to recognise that the common pattern exists – but it does, and the same issues surface one way or another in each.

Note: For all I know, similar patterns exist outside healthcare. But I’ve not particularly investigated. However DITA and Docbook are in this space. Perhaps I’ll explore that in a later post.

Reference Model

The fundamental notion of design by constraint is easy to summarise:

Define a common information model called the “Reference Model”, that has general applicability, and then describe constraints on it’s use for particular use-cases.

The notion here is that though the use-cases are quite different, the fact that each is connected to an underlying reference model is a great help to implementation because it imposes a common framework along with semantic consistency.

For this reason, the pattern is sometimes called the “reference model pattern”. But sometimes the reference model isn’t known by those terms (“RIM” in HL7 v3, and BRIDG/CDA/VHIM are not called the “reference model” to my knowledge, but that’s exactly how they are treated), so I use the name “Design by Constraint”.

Advantages of Design by Constraint

Before I go on to describe the method in detail from a UML perspective, and detail the attendant problems it creates, I need to underscore the fact that this pattern is a very elegant and powerful way to solve a particularly difficult problem in information model design: semantic consistency.

If a model is designed by a single person, this might not be a problem (if the person is agile, and anal-retentive – an unusual combination). But as the problem size scales, and time passes, the number of participants rises steeply, and the problem of consistency becomes very difficult to manage.

Design by Constraint solves this problem well (though not perfectly).

How Design by Constraint works

  1. Design a common class model that can be used for everything
  2. Define meta-patterns associated with it, and rigorously enforce their use
  3. Define a language for expressing constraints on the model
  4. Use the language to define constraints for many different use-cases
  5. (optional) Define a transform to convert the constrained use-case model into a new class model

The class model is almost always a UML class diagram. The meta-patterns are usually defined in human language. The language is usually a hybrid language assembled from several different underlying common approaches. Although 5 is labelled as optional, the more time passes, the more likely it is that it will happen. I’ll discuss why this is below.

There’s actually a step #6 that follows logically from the steps above:

  • Implementation chaos ensues

The point of these posts is to describe why this is. For the rest of these posts, I’m going to use a rather simple example: a model that describes the commercial arrangements around a restaurant with the following characteristics:

  • —Restaurants are associated with corporations (many to many)
  • —Restaurants are associated with people  (many to many)
  • —People are associated with corporations  (many to many)

Here’s a simple UML model for this:

This reference model is intended as a PIM: you create object models in your code, or XML documents and schemas, or database schemas, using your standard approach – whether this is by hand or by some sort of tool assisted approach (of which there are many).

Some quick doco to get us through the rest of the discussion:

  • Restaurants have a name, an address, a number of seats, and a flag for whether they are a franchise operation or not. In addition, they must be associated with one or more people and maybe some corporations. (This model does not track the nature of the association)
  • Corporations have a name, and maybe a taxId. Each corporation must be associated with at least one person, and maybe some restaurants
  • Persons have an id, a name, a code for sex (gender), and a taxId. In addition, a person has a role – a code that defines what kind of person they are

Note: this simple model is far from adequate for any particular application except demonstrating my point.

Constraining the Reference Model

This general reference model is too general for many use cases. For almost all use-cases, in fact, a particular subset of this model is used. But the subset needs to be described, because as soon as the reference model becomes large enough to be functionally useful, there are many different possible ways to represent a use case, and any one using the reference (to make or consume information statements) needs to agree on how it’s done.

Describing the subset is the same as applying a set of constraints to the model. These constraints can be represented using human language constraints, but more structured representations are more amenable to being leveraged by tooling support. Let’s take, as an example, the context of a family business restaurant. Here’s a semi-structured english language statement of constraints:
Business: “FamilyBusinessRestaurant”

  • franchise property fixed to null
  • Address: 3-4 lines, order matters
  • No Corporation
  • 1Person called “accountant”, 2-6 called “family”

—Person: “Accountant”

  • role is “ACC”
  • taxId is renamed “businessId”
  • No Corporation, and sex & id are fixed to null

—Person: “Employee”

  • role is “EMP”
  • id & taxId fixed to null
  • No Corporation

It’s worth noting here that the question of what’s a valid constraint differs slightly across the various frameworks. Is it ok to rename fields? Is it ok to fix order? Which data types can be substituted for other data types?

Semantics in the Constraints

One important question is whether the constraining models can contain semantics that are only represented in the constraining model, or whether all the semantics need to come from the underlying reference model. A different way to state this issue is to ask, is it necessary to know and understand the constraining model in order to understand the instance of data, or is it just enough to know the reference model?

In principle, the fundamental concept of “design by constraint” is that you don’t need to understand the constraining model. This allows you to leverage your knowledge of the reference model across multiple contexts without having to understand a particular fine-grained use case. An example of this is with CDA – there is only one document, and you can write a single document viewer that is appropriate to work with every single (proper) CDA document that has ever been written, but there is a profusion of CDA implementation guides describing exactly how information should be structured for particular use cases.

So in principle, the constraining models shouldn’t define semantics that aren’t explicit in the instance of reference model data. Specifically, to use that example above, the constraining model can’t simply say “the first person in a restaurant is the accountant”. Instead, it must say, “the first person has a role code of “ACC”, which means accountant, and this is how you know that the person is an accountant”.

The problem with this is that it’s really difficult to ensure that the constraining model doesn’t introduce new semantics that are not in the underlying data. For example, in the example above, the following semantics are not explicit in the data:

  • That a restaurant is a “Family Business Restaurant”. (? whether this matters in some or all contexts, but it is not explicit)
  • There’s a subtle interaction in the simple stated constraints between family and employee. There’s an assumption in the constraints that employee = family member, but this might not always be true. Whatever the case, the “family” part is not explicit in the data

(This is more obvious in the data examples that follow)

A general rule is that it’s extremely difficult to ensure that a constraining model doesn’t contain semantics that are not explicit in the data instance. In particular, only thorough human review can determine that the constraining model doesn’t contain implicit semantics.

Note that openEHR varies slightly from the simple pattern here: archetypes are constrained models on the openEHR reference model, but in the very abstract parts of the openEHR reference model (elements), they are allowed and required to define semantics that are only in the archetype. The corollary of this is that you cannot understand the data without knowing the archetype. On the other hand, templates, which are also constraining models, are not allowed to introduce new semantics, so that they can be ignored. They also have the same subtle problems mentioned above.

Next post: Structured representations of constraint models.

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.

Can we enforce Healthcare Interoperability standards by law?

Professor Jon Patrick says:

“It’s not enough to say we’re providing standards, we’ve got to have laws that say you cannot place software in a health environment unless it meets standards,” he said. “Then we have to test the software against the standards.”

h/t Bridget Kirkham for the link.

As a consultant who works with both standards and health software development, I’m naturally very much in agreement with Prof Patrick.


There’s two major problems with this, and they’re related. The first is that any significant healthcare software is configurable and customisable. Some software packages are so configurable that they’re actually sold as source code, not a compiled product, and the implementor hires programmers to make the software work for them. Software like that, you can only certify a running installation. But who decides which software needs certification per installation – which is very much more expensive – and which doesn’t, and how do they decide?

The second reason is related to the first. The reason software packages are so different and customisable is that there’s so very much variation in how healthcare is done, how the processes are linked up. And in many cases, the variation is key to improved and more efficient healthcare work flows. Obviously this is less true in primary care than in secondary care – but this is only a matter of degree.

Because of this variation, the standards are descriptive, rather than proscriptive. They are best understand as frameworks for accelerating agreement between parties (again, in primary care this is less evident than in secondary care). This is true of HL7 v2 – all things to all users – and also true of Australian standards published by the IT-14 committees. And it’s just as true about the future NEHTA specifications. They represent steps on a path towards agreement.

Until we can get agreement on consistent practice in clinical medicine, the standards can’t do better than that. But getting consistency at the business practice level is hard. Very hard. People have to forgo their local efficiencies and their particular trading partner agreements on which their existing relationships are built.

This is where IHE offers a different approach: The business/clinical users (purchasers) get together and standardise their business approach first, then they seek a technical standard from the vendors that meets this business approach. Sadly, this order of things  has generally been missing from IHE Australia – and it seems to me that it’s not for lack of trying on the part of my friends who are pushing IHE Australia. Rather, the market players (jurisdictions, care providers, colleges, and business managers – and any other purchasers) either don’t understand the benefits of collective action in these matters, or don’t believe that there will be collective action even if the benefits are known.

I’d like to see laws enforcing interoperability standards with testing in health environments. Not because it would solve all the problems – it wouldn’t. But because it would force us to solve these other problems. Which, I’m afraid, is exactly why it would fail.