SAEAF Revisited

You may recall this box from Demystifying SAEAF ...maybe



Well, I joined a telephone call and web exchange with a number of really bright people who are, like me, still confused about the HL7 Services Aware Enterprise Application Framework or SAEAF as it is known in HL7 circles.

We spent a good bit of time working on the "elevator pitch" about SAEAF.  What we came up with was the following:

“	SAEAF provides a framework for specifying how HL7 products integrate and function from different viewpoints and levels of abstraction. When HL7 products agree upon common viewpoint and abstraction details, they can be used together.

SAEAF needs to be looked at not from the perspective of one HL7 Standard or work product, but from the viewpoint of the HL7 work products as a whole.  Think about each of the edges of the box as parts of a LEGO^® block. A correctly designed HL7 Enterprise Architecture will use common measurements for the connectors that allow each of the blocks to snap neatly together. This illustrates the concept of conformance to the architecture. It requires that we have some ability to test conformance and measure how well different HL7 products stack up against each other.

Synthesis

‘When I use a word,’ Humpty Dumpty said, in a rather scornful tone, ‘it means just what I choose it to mean, neither more nor less.’

‘The question is,’ said Alice, ‘whether you can make words mean so many different things.’
‘The question is,’ said Humpty Dumpty, ‘which is to be master – that’s all.’
-- Lewis Carol, Alice in Wonderland

It's been interesting reading the shift in discussions around REST vs. SOAP in the blogosphere this week now moving towards HTTP and HTML , or device-based connectivity.  See blog posts from John Halamka, Sean Nolan, and Wes Rishel.  My head exploded with insight -- and the sleep that I promised myself is gone by the wayside.

I'm a web, HTML and XML geek from way back.  In 2001 I claimed 7 years of experience with XML (a test my employer passed).  I've got dog-eared copies of the HTTP specifications (as well as HTML and XML specs) sitting on my shelf that are rather aged.  In the thirty years since the development of the OSI seven layer model, we've now seen a shift in how we view HTTP.  Most mappings of the web stack refer to HTTP as an "application layer" protocol, but SOAP, REST, Web Services and Web 2.0 seem to have driven it down the stack to "transport" by layering yet more on top of it.

The complexity of what has been identified as "SOAP" in all these discussions is not SOAP at all, but rather the information models in SOAP.  There's an important difference between the information models that SOAP and RESTful implementations offer that needs to be considered.  These models by the way, are not demanded of SOAP and REST, they just happen to be broadly adopted models that are often associated with these different protocols.

What REST implementations typicall offer that SOAP typically does not is something that HL7 geeks will recognize as a "model of use".  Models of use offer up business friendly names and representations for sometimes fairly complex semantic constructs (and they do it compactly).  The business concepts map closely to the Business Viewpoint of the HL7 SAEAF model.

What ebXML, HL7 Version 3, and similar protocol specifications offer up through SOAP that REST does not is a model of meaning.  The model of meaning maps closely to the Information Viewpoint represented in the HL7 SAEAF model.  Models of meaning are more complex, and contain a lot more explicit information, but they are bigger and harder to understand.  They become a language in which one must express the meaning of "simple" business concepts (although I note those concepts are not really all that simple).

Models of use are easy for people to understand and to perform simple and often very useful computations with (e.g., pretty UI).  Models of meaning are easy to perform complex and often revealing computations with (e.g., clinical decision support).  Geeks like me who've been immersed in various models of meaning don't have large problems speaking those languages and crossing between them, but trying to teach people new languages is rather hard after a certain age.  I seem to have a knack for computer languages that I just wish applied to spoken ones.

The benefits of models of use are conciseness and direct applicability to business processes, but to cross "models of use" boundaries often requires a great deal more translation (e.g., from clinical to financial).  That's because the concepts communicated in a model of meaning assume a great deal of implicit domain knowledge.  The hidden domain knowledge into the model of use makes translations hard.

The benefits of models of meaning are explicit representations of domain knowledge using a controlled information model.  All the possible sematic relationships are explicitly stated and controlled.  This simplifies translation between different models of meaning because one can work at the more atomic level of the controlled information model.  This is why (computer or human) language translators build "parse trees" first, and translate from those "models of meaning".  Models of meaning are more readily marshalled into data storage systems.

The importance of models of meaning in healthcare IT comes into play when we start talking about clinical decision support.  I illustrated one of these examples in Gozinta and Gosouta back in August.  In short, the "model of use" described in the guideline needs to be translated into a "model of meaning" representation in order to compute the guideline through a decision support rule.

So, I think I've successfully convinced myself that we need both model of use and model of meaning in the HIT standards space.  The simple business oriented representations are needed to make implementations easier for engineers.  The more complex information models are needed to compute with.

I think I see a way through the muddle, but it will take some time.  The right solution will not just adopt the first model of use that comes to us.  We will need to put some thought into it.  I believe that we can provide some motion towards an answer that could begin to use in 2013 (or earlier), would be easily adapatable with solutions deployed for 2011.

But if we move towards a model of use in communication patterns, we run into a translation problem that someone has to address.


In a nutshell, WE need to fully specify (in a normative way) translations from model of use to model of meaning and back.  The former is easy (with a common model of meaning), the latter more difficult.  Compilers are easy (use to meaning), but decompilers are hard (meaning to use).  When I say WE, I've got all my big hats on: HL7, IHE and HITSP.  And, we need to agree on a common model of meaning (and this we is the SCO, for which I have no hat).  The HL7 RIM is a really good start for a reference information model in healthcare (Wes and I both know that you can say almost anything in HL7 V3, and I have the V3 model to prove it.)

Having a common reference model provides the interlingua that will truly allow for interoperable healthcare standards.  If all models of use can be expressed in one (and nearly only one) model of meaning based on a common reference model, then translation between the models of use becomes a real possibility.  I know I can translate the "transports" that we've all been talking about into a model of use that would make a number of nay-sayers really happy.

There's also a way to use the same WSDL to enable either SOAP or RESTful transports which makes interfacing a lot easier and more negotiable.  The last problem is how to secure all of this RESTfully, which I'm somewhat unsure of.  I'm not sure it's safe to leave in the hands of the giants that gave us SOAP and WS-* (and insisted on XDS.b) but maybe they've learned their lesson

There's a lot more engineering that is needed to really make this work, and this blog posting is already too long to go into all the details.  The solution isn't simple (making hard problems easy never is) and it needs to address a lot of different business considerations.  There's also a need to address the migration issues for the current installed base (not just one, but at least 10 different HIE's in the US are using the HITSP protocols, many in production, and that doesn't count the Federal agencies, and a heck of a lot more internationally have been using the IHE specifications upon which the HITSP protocols are built for even longer).

My main concerns about all of this discussion is CHURN and disenfrancisement.  Over the past five years we've taken huge steps forward, and this seems like a big step backwards.  It may be a step backwards that prepares for a huge leap ahead, and because of that, I'm willing to engage.  I get what REST can do (this blog and my whole standards communications campaign are built on RESTful protocols).  The concern about disenfranchisement is the suggestion that a group of uber architects could do this quickly and outside the bounds of a governance model that organizations like IHE, HITSP and HL7 impose.  If this is to work, it needs the buy-in of those organizations, and their constituencies.  It needs to have two key goals:  simplicy and compatibility with the industry investments of the last five years.  XML was a three year long project that replaced SGML and changed the world.  It had those same two key goals.

If we can synthesizes models of meaning and models of use together, we will truly have a model of meaningful use.

I'll probably get a heap of flack for this post tomorrow (or at least the pun), but what can I say? 

Demystifying SAEAF...maybe (SAIF)

The HL7 ARB and its CIO have mandated that we will use the (Services Aware) Enterprise Architecture Framework within HL7 to improve processes within the organization and to make our specifications the widest implemented.in the industry.  As a Cochair of the HL7 Structured Documents TC, it was pretty clear to me in Kyoto that we (SDWG in HL7) would need to make the next release of the HL7 Clinical Document Architecture project one of the Alpha projects for this new framework.  Nobody yet knows what this entails, but Austin Kreisler and I dug into this last night over dinner.  As I read through one of the presentations made by the ARB to several workgroups in HL7, I began to understand what it is.  We prepared a presentation based on that understanding for HL7 Structured Documents that was presented this morning, and spend a good bit of time talking about the SAEAF goals for CDAR3. 

I am now sharing some of my understanding here.  My sole purpose in leading the charge for this in HL7 is that I know that the blow was coming, and it is far easier to deflect it or redirect it if I lead into it.  Having worked through the example, I think one of the key problems that we've had in understanding this is a problem in how the information has been communicating.  I'm hoping to address some of those issues here.
Here's what I've learned thus far:

The key to implementing SAEAF in HL7 is in understaning the matrix which describes the different content that needs to appear (or not appear) within an HL7 standard.  The matrix appears below:

Now of course, it has to show up using all of these terms that only Enterprise Architects understand, and I don't have twenty years of enterprise architectural experience to understand it, and neither does most of the existing audience in HL7, never mind the audience we left behind.

However, after about an hour of reading (a lost art in this world of powerpoint), I began to understand what they (the ARB) were getting at.  It doesn't require an understanding of RM-ODP (although it helps), enterprise architecture, or all the current buzzwords around Service Oriented Architectures, or Architectural Frameworks.

What it does require is to answer twelve key questions about what you are developing as a specification.  Those twelve (3 x 4) key questions revolve around what I call the dot product of seven key concepts (3 + 4).  Ed Note: The dot product of two vectors (column and row heads) is the sum of the products of all terms in each vector.

The first three concepts deal with levels of abstraction:  Conceptual (20,000 feet), platform independent (conceptual after the first level of analysis), and platform dependent (realization of the analysis).  The next four concepts look at different viewpoints (areas of concern or perspectives).  These are the business perspective (which should need no further explaination), the information or semantic viewpoint (the specialist perspective, in this case, healthcare), the computational viewpoint (in this case, what we used to call the systems analysis perspective), and the engineering viewpoint (or programmer's perspective).  I may be somewhat off-base in my own analysis of what these particular viewpoints are, but that is because I'm not someone whose up on all the latest terminology here, however, this is close enough to start with.

So, an HL7 specification needs to indicate what it provides (or doesn't provide) for this dot product of the abstraction levels and the perspectives.  This needs to be explicit for each product of HL7, so that we are clear upon the product boundaries.  Asking the question is important, even if the answer is "no, we provide nothing here".  It gets the workgroup to think about that component, to see if there is something we should provide, and if not, who might actually be providing it for us (for example, one workgroup might not have an implementation if all they are providing is a functional model and requirements, whereas another workgroup might implement functional models produced by the first).

The next step is to ensure that the specification clearly has done the appropriate analysis to define the scope of work to be peformed.  This then needs to be reviewed (e.g., by a review board that checks that the results make sense architecturally) and verified.  The next step is to start developing the various artifacts.  Now, the results of each of these tasks is going to be targeted at individuals with specific skill sets.  The conceptual business level artifacts are going to be targeted at project sponsors, those responsible for understanding high level requirements and making funding decisions (C-levels, product managers, et cetera), whereas the engineering and implementation level artifacts are going to be targeted at application developers.

This results in a second matrix, which I show below.  I think this matrix will be much more comprehensible for many,  because it is buzzword free, and uses terms that should be comprehensible to most of the HL7 audience.  If I didn't get it right, please let me know.  The basic concept of this diagram is to identify the target audience for each of the different components of the dot product.  The importance of understanding who the target audience for each of these components is that it helps us establish whether we've hit or missed the mark with the different parts of an HL7 specification when it is evaluated.

Now, I'll provide a caveat.  I have no clue how close I've hit the mark with my own analysis of the SAEAF matrix that the HL7 ARB has produced.  I'm more than happy to hear your feedback.

Another realization that I had two nights ago while discussing SAEAF with some ARB members is that we need some way to measure our success or lack thereof with this work.  I think it would be very helpful for the ARB to pick a few key past projects from HL7 and, using the project scope statements, identify the architectural artifacts that they expected the project to produce, and THEN evaluate the results of the project.  It might be useful to look at three together as a group initially to identify objective criteria that could be used in a real evaluation.  Then the reviews should be undertaken by people (more than one) unfamiliar with the projects doing the first and second evaluations (it might be interesting to see how those who are familiar with the projects do compared against those that aren't).

   Keith