ArB Dynamic Model Page

this is not an approved project yet

Introduction

New Dynamic Model work here .... New_Dynamic_Model

ArB is tasked with helping HL7 resolve the Dynamic Model Problem. This is a well established problem that we have been grappling with for a while.

This page is the home for the ArB project to do whatever it is we need to do to "solve" the Dynamic Model Problem.

Definition of the Problem

Within HL7, the ability to effectively describe the business interactions [Which business interactions?] between and among systems [which systems?] is an essential component in specifying interoperability, [why?] yet a means of expressing this description eludes us. An adjunct to this primary problem is the question of *what* is necessary to sufficiently describe these interactions. [We must have the courage to not try to address this until we have actually defined the primary problem.]Finally, what qualities of this dynamic model would make it durable, extensible, scalable, and effective?

Definition:: The business of HL7 is to support business functions in those situations in which, because there are multiple systems in the picture, data must be exchanged between those systems.

we document those functions using storyboards, and talk about more fulling doing this with other things such as use cases and activities. (see HDF). HL7 message/document/SOA ?? specifications define the data that will be exchanged.

The dynamic model addresses

1. when the data flows,
   • This has long been addressed with the notion of trigger events.
2. a definition of the kinds of parties that data flows between,
   • is supposed to be handled for messaging with application roles (which is supposed to be a limited way of characterizeing system behavior), but there has never been any consensus on how to define what would be a proper application role. I think CDA has no comparable concept, I believe SOA has, but do not know the jargon.
   • The closest thing we know of (from the messaging space) that sort of works is the concept of Actor as used by IHE Profiles
3. interdependencies between separate data flows,
   • there has long been a split between those who just want to model flow/response, and those who want something more elaborate. However, we have some history addressing this, by using receiver responsibilities to chain together interactions in the messaging world. CDA has not such concept. SOA probably does.
4. other things that have to happen so that the flowing data is properly used to address the business functions that are to be supported.
   • Some think this is out of scope. Some think it is not, but I know of no suggestions to address it beyond simple verbiage.

So, does this describe the area of the dynamic model? What has it left out? What extraneous has it added?

What to Describe

As part of the Templates Specification, the idea of Interoperability Paradigms was put forth[1]. (The description of what this is should be included. People should be able to read the actual content of the moddel instead of seeing a reference to something else.]The ultimate vision is that the same artifacts can be used whether one works with messages, documents, or services.

The SOA Interoperability Paradigm [2] utilizes the Choreography Description Language (CDL) to capture its dynamic model. This bridges the gap noted above by:

• identifying a set of artifacts accepted by other industry standards
• identifying an expression language that uses these artifacts
• utilizing that expression language to capture the essence of the HL7 dynamic model

The artifacts identified by the SOA Dynamic Model (CDL):

• Packages (potentially equivalent to IHE Interoperability Contract Specification)
  • Roles and their behaviors
  • Relationships between two Roles
  • Information Types and the Channels by which they are transmitted
  • Participation by Real World Systems in Roles
  • Interfaces that realize behaviors
• Choreographies
  • Interactions that are part of Relationships
  • Exchanges that are combined to support Interactions
  • Sequences of Workunits that combine Interactions into logical workflows

I think the notion of starting with the SOA model is fine. But, the ARB representation of the model should describe it, and not simply be a pointer to a discussion somewhere else. Also, in our model do we need 1) packages, 2) roles, 3) role behaviors, 4) relationshipbs between roles, 5) Information types, 6) channels, 7) participations, 8)interfaces, 9) behaviors, 10) interactions, 11) exchanges, 12) sequences, and 13)workunits? Our model should describe and justify each thing that it uses. Ohh, logical workflow too.

BTW, here is what it says in the Core principles area of the ballot: "The dynamic model specifies who exchanges information and why, and refers to a set of static model to define the information that is exchanged for a particular scenario."

This does seem too simple. I do feel that the 13-14 different base things above may be too much. But, until we have the model actually described, it is premature to speculate.

Success Criteria

What does the dynamic model need to achieve?

• Must have a loose coupling between a rigorous expression of behavior and the systems that realize those interactions
• Must *not* specify system behavior, but only shared behavior
• Should represent a contract of behavior(s) between systems
  • Global expressions of specific aspects of the consequences of exchanges (what HL7 would call receiver responsibilities)
• Should provide a loose coupling between information expressions and the information types
• Should have a supporting set of tooling
• Should be open source, based on open standards
• Must provide HL7 with a means of expressing "dynamics" both as part of other standards and as ballotable artifacts themselves
• Must provide a clear path to implementing standardized artifacts
• Should provide those involved with local specification of healthcare systems the means of expressing dynamics in such a way as the local specification can be harmonized with standards
• Must be expressed in such a way that it can be profiled/constrained in such a way that the expression of the parent dynamic model can be proven to be a true superset of the expression of the profiled/constrained dynamic model.

attic

1. 1: What is the "dynamic model problem"? What are the issues that are included within it? If the problem was solved, what would that give us? (That is, what would the solution look like?)

In his Response to Ioanna, Grahame said: "Take, for example, the dynamic model - one of the reasons that this is not progressing is because it's shared between many committees. We have been asked to progress this, though we're not sure what this means. I don't think that ArB is supposed to be responsible for actually doing everything associated with the dynamic model. We are supposed to provide... something... that progresses this."

I would like to suggest that a (the?) root cause of the tangle is that we lack a common understanding of what the dynamic model is supposed to do. I think the biggest thing the ARB can do is to insist that those who are interested come up with a common description of the problem they are trying to solve. (DMW)