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.
Re “a set of known exchanges that can occur between them”… I would say that support for ‘a set of possible exchanges that can occur between them’ is the main thing. Described by services interfaces and state models. Anything too prescribed is something will be broken by reality.
remember that this is simply the requirements to even talk. I think that while you are right, you are looking ahead of my limited scope here
There is one other requirement to behavioral interoperability. You need to rigorously define interaction points in terms of the other requirements such that they may be reused. This is where Application Roles explicitly failed – they defined a business end point, but no computable context, and certainly no testable conformance statements. By the same token, Application Roles are not reusable in any contexts other than those described in the specification. Existing paradigms in the industry (like SOA services or web2.0 technologies) can’t be mapped to AR’s without winks that are so long and extended that they cannot be differentiated from napping.
The SAIF BF, fwiw, spends a lot of time on this and one other related issue. The related issue is not one that is an interoperability, but is one about manageability and architecture. That is, how to behavioral components map to each other. This is something you see in information modeling all the time – a person demographics concept is represented in both the RIM and as an OpenEHR archetype. However, it is not clear how a Admission event is related to a Patient Registry service, or whether there is overlap (or subsumption!) with a Person Demographics Management Service. Worse, it is unclear whether an Admission Event or a Patient Registry service can be tied to a patient’s leave of absence to go home or not (to borrow one of Grahame’s examples).
Put simply, the SAIF BF tries to provide a language to describe both of these things: business processes and their reliance on reusable modules of architecture to accomplish them. One of the chief problems here that the meta model has to be able to rub its tummy and its head at the same time – describing behavior and identifying behavior are two related but different things.
Take the example of ordering a cheeseburger. The contract says that if you order one, you will get a cheeseburger. But it might also say that success is conditional – cheddar cheese is not acceptable! And it might discuss compensating behavior – if you don’t have gouda cheese, feta is fine. But this compensating behavior is definitionally reusable, and it needs to be described as such. And of course those are just identifications. Describing the behavior (“Did you actually go to the grocery store to check for Gouda cheese, please?”) is something else. Where is the conformance? Well, where isn’t it?
At any rate, we have a tractable answer to this, but we also have to find a way to make it usable.
#John: all of these pertain to manageability of a discussion, not a pre-requirement, though I generally agree that these things are needed to manage it
#Grahame: I think there is little distinction in the creation of any instance. But when you have to scale out or up, I would say that they are prerequisites. I only point this out because behavioral modeling, like information modeling, needs to fall back on commonalities and generic qualities in order to make it work.