Interoperability Requirements #5: Behavioral Agreement

May 14, 2011

With the layers we have already considered, we can exchange data, define meaning, agree how to identify things, and then build them into greater structures that define a package that moves between systems. To complete the picture, we need to define what exchanges can happen, when they happen, and how they relate to the business processes they serve (whereby “business processes” actually means clinical processes as well). These things describe the behavior of the systems. If we don’t know this, we’ll have chaos. So it has to be resolved - and generally it is. But it’s only truly resolved at the actual point of integration. For Behavioral Agreement, interoperability consists of building an organised approach to this (that’s right - another model!) that predefines the things that can be predefined, and leaves open the things that are not known until the actual point of integration (and remember, in different contexts, different things are nailed down at different times).

A behavioral model (and/or framework) defines some or all of the following elements:

  • a set of applications/systems
  • a set of known exchanges that can occur between them
  • how these relate to transaction scopes
  • the information structures that are appropriate for each exchange
  • how these relate to the business processes – at what points they occur, and what business requirements there are
  • what kind of consequences follow the exchange, both information and business process consequences
  • how exchanges are acknowledged, and how errors are handled

The scope of a behavioral model includes what is generally referred to as choreography (“the art of designing sequences of movements”) and orchestration (“the automated arrangement, coordination, and management of complex computer systems, middleware, and services” - or musical instruments), but goes beyond these by including other business related information, such as business process consequences.

Behavioral models are most affected by business variability. This is because they are the most concrete of the parts, the highest level. It’s easy to modify applications/scripts/etc to use one field or another (in principle, anyway), but the kind of exchanges and how they relate to business process are very often baked into the product’s conceptual design. An alternate view of the same issue is that you can throw optional fields into an information model with relatively little pain, but you can’t throw optional exchanges into the behavioral model without incurring considerable pain (the only question is who is going to be incurring the pain).

Implementations

Because of the variability of the problem, and the variability of different approaches, there is a wide variability of nomenclature. The general concept of “exchange” may be referred to using language centered around messages, documents, services, objects, programming APIs, interfaces, or more. Each of these language frameworks involve different assumptions about how the conceptual/notional/semantic exchanges map to technology stack, and there are a multitude of actual languages:  UML sequence or activity diagrams, a RESTful approach, or process flow languages such as BPMN, WSCL, WSCI, or CDL.

But the most common form of all is plain old text - the disadvantages of a structured approach is even more evident in behavioral modeling than in information modeling. Of course, so are the problems…

**HL7 Behavioral Frameworks **

V2 has a highly idiosyncratic event model, which is precisely where it comes into it’s own for drive-by interoperability. It’s so lovely and loose and flexible. And that’s also exactly what’s wrong with it for large programs that depend on increasing amounts of v2 event implementations as they grow.

V3 tried to describe this using application roles, and created a permutational explosion of needless complexity in trying to nail this down completely. It’s the biggest reason that v3 failed. We’re still struggling to replace it (more later, when I finally get to SAIF).

But HL7 is been reliably miserable in all our messaging formats at grappling with a key implementer concern: how to handle errors. In v2, it’s really hard to be sure whether you should or shouldn’t resend a message if there’s an error.

Several people have already asked me about SAIF. And SAIF includes a behavioral framework. I’ll comment on that later.