SAEAF Education Series 2: SAEAF Behavioral Framework April 2009

04/21/23 18:17

SAEAF Education Series

2: SAEAF Behavioral Framework

April 2009

SAEAF Education Series

2: SAEAF Behavioral Framework

April 2009

HL7 Services-Aware

Enterprise Architecture Framework

(SAEAF)

Page 2

SAEAF Education Series (1) SAEAF Education Series (1)

• The SAEAF Education Series includes the following:

– 1: Introduction and Overview

• SAEAF Value Proposition: Working Interoperability

• SAEAF Structural Components

– Behavioral Framework

– Enterprise Conformance/Compliance Framework

– Governance Framework

• SAEAF Organizational Implications

– Education

– Change Management

– Alpha Projects

Page 3



– 2: Behavioral Framework

• Contracts, Roles, Collaborations

• Mapping to HL7 Dynamic Model

• Relationship to the Unified Field Theory

• Examples

Page 4



– 3: Enterprise Conformance/Compliance Framework (ECCF)

• A multi-dimensional world

– Conformance

– Compliance

– Consistency

– Certification

– Traceability

– Jurisdiction

– Provenance

• The SAEAF Specification Stack and the ECCF

• ECCF and Governance

Page 5



– 4: SAEAF Governance

• Definitions

• The Governance Challenge

• Contextualizing Governance

• Governance Perspectives

• Types of Governance

• Putting it all together

• Summary

Page 6



– 5: SAEAF Examples

• Service Interoperability Paradigm

• Message Interoperability Paradigm

• Document Interoperability Paradigm

• More topics possible as deck is developed (Feb 09)

Page 7

SAEAF Series Part 2:SAEAF Behavioral Framework

SAEAF Series Part 2:SAEAF Behavioral Framework

• Mandatory Pre-requisites

– Knowledge of SAEAF Education Series Parts 1

• Part 1: Introduction and Overview

• Optional Pre-Requisites (some concepts overlap)

– Part 3, SAEAF ECCF

• HL7 Behavioral Framework and ECCF are intimately linked via…

– Traceability and Levels of Conformance

– Scope of Collaboration

– Specification Stack Topic

– Part 4, SAEAF Governance

• Service-oriented behavioral models insist on boundaries and separations of concerns, which leads to notions of jurisdiction and provenance

Page 8

SAEAF Series Part 2:SAEAF Behavioral Framework (2)

SAEAF Series Part 2:SAEAF Behavioral Framework (2)

• Outcomes

– Understanding and application of primary Behavioral concepts

• Service Roles, Collaborations, Contracts

– What Behavioral Models are (and why they are important) in the context of Working Interoperability (WI)

• Conformance

• Compliance

– Ways to use Behavioral Concepts

• In a Standards Development Organization

• As an Implementer

Page 9

SAEAF Value Proposition (1):Working Interoperability


Interoperability Paradigm (Messages, Documents, Services): specifications which enable two or more (HL7) trading partners to collaborate in the context of a specific business interaction

– No assumptions of size, character, or identity of parties

• Nations, Enterprises, Departments, Individual, Systems, etc.

– No assumptions of exchange details (What, Why, How, etc.)

Page 10



• Interoperability: the deterministic exchange of data/information in a manner that preserves shared meaning

•Two parties interoperate based on a certified “level of shared compliance” to interoperability specifications/standards

• Certified “level of conformance” determine degree of automated interoperability that is possible and/or the difficulty of the transformations that are required to enable interoperability

Agree on “Reference” view

Agree on “Conceptual” view

Agree on“Platform-Independent” view

Agree on“Platform -Specific” viewA

B

DC

F

Component Component

E

Page 11



• Achieving WI is a matter of assembling certain building blocks.

• These building blocks describe

– when information flows across data interchange points,

– how those interchange points are described,

– who or what those interchange points represent

– how the information is bound to data flows,

– interdependencies between separate data flows,

– other aspects of control flow that ensure that data is flowing properly over the course of the interaction and in such a way as to support the business function from which the service specification is derived.

Page 12

OutlineOutline

• Introduction

• Contracts

• Defining a Service Role

• Examples:

– A Degenerate Collaboration and implicit Contract

• A Richer Collaboration Model

• Examples:

– A more explicit Contract and a rich Collaboration

• Service Classifications

• The Unified Field Theory

• The Legacy HL7 Dynamic Model

• SOA ML

Page 13

IntroductionIntroduction

Page 14

Definitions (1): Behavior (1)

Definitions (1): Behavior (1)

• From the Merriam-Webster Dictionary;

– The manner of conducting oneself

– The way in which something functions or operates

• Common Synonyms:

– Protocol; Custom; Pattern; Mores

• Common IT Synonyms

– Conversation (between whom?)

– Sequence (when?, of what?)

– Collaboration (to accomplish something …)

Page 15

Behavioral Framework (BF)Behavioral Framework (BF)

• The Behavioral Framework deals with the way that you describe the computational aspects of distributed systems

• The Framework is a top-down means of expressing the integration from two different perspectives:

– The global view of interactions – conversations between various parties endeavoring to fulfill a business purpose or mission, which the Behavioral Framework calls Collaborations.

• A system implementation may be an orchestration, collaboration, or choreography

– The business capability view – analytical business roles exposing sets of behaviors, which the Behavioral Framework calls a Service Role

• A system implementation of which is known simply as a Service.

Page 16

The Fundamental Use CaseStairway to Heaven: Two parties which to exchange meaningful

information

The Fundamental Use CaseStairway to Heaven: Two parties which to exchange meaningful

information

Agree to Agree

Agree on Concepts

Agree on Models

Same Platform

•Two parties who wish to integrate build things to achieve “Working Interoperability.”

•Interoperability is the deterministic exchange of meaningful information

•Interoperability broaches the “system of systems” viewpoint – it is not a single system architecture

•Understanding where A,B,C,D, and E are requires an Enterprise Architecture

A

B

DC

E

Page 17

The role of the BF in WI (1)The role of the BF in WI (1)

• The essence of the Stairway of Heaven is that the participants work via Contracts

– A SOA analysis of a distributed systems’ environment yields a decomposed set of business-oriented capabilities. These capabilities are advertised and exposed through explicit interface specifications called services*.

– Composing these services together to support common business functionality within a domain is accomplished, at least nominally, through the idea of a contract.

* Note that Services may be realized using Documents and Messages

Page 18

The Role of BF in WI (2)The Role of BF in WI (2)

• The BF is an attempt to explicitly capture the contractual nature of integration by dealing separately and in detail with the notions of

– Services (denoted as Service Roles)

– Compositions of Service Roles for a Business Purpose (denoted as Collaborations)

– Contracts that bind Service Roles to Collaborations

• It allows for a technically neutral specification stack to be implemented in a variety of ways.

Page 19

Behavioral Framework and Behavioral ModelsBehavioral Framework and Behavioral Models

• The BF generates instances of Behavioral Models that are specific to a given business purpose

– HL7 has historically dealt with a Dynamic Model, including Application Roles, Interactions, and Trigger Events

– The BF is an abstraction away from a single model for capturing interactions towards a comprehensive means of capturing the semantics of system collaborations

• Flexible – not technology specific

• Specific – describe semantics precisely and appropriately

• Layered – according to the ECCF specification stack

Page 20

The BF and ConformanceThe BF and Conformance

• Layered - The BF is layered according to the ECCF’s Specification Stack

• Flexible - Both Collaborations and Service Roles are specified independently of any given technology

– They serve as a testable architecture for interoperability for systems (via exposed Services) and between systems (via realized Collaborations).

– This is another way of saying that a given Behavioral Model provides requirements for interoperating with specific components to achieve a business purpose

– Collaborations and Service Roles have Conceptual Components that describe Behavior independently of any Interoperability Paradigm

• Specific – Capable of capturing integration semantics – specifically the computational aspects – at various levels of abstraction, providing provenance, traceability, and consistency.

Page 21

Standardization and the BFStandardization and the BF

• The BF within the SAEAF includes two types of artifacts that follow the familiar specification and constraint pattern

• The table shows semantics captured by each specification

Specification Enterprise / Business VP

Information VP

Computational VP Engineering VP

Service Role Specification

Policy, Business Context

Parameters Operations, Interface

Specifications, Taxonomy, Focal

Class State

Performance, availability, Deployment

Context

Collaboration Specification

Policy, Business Context

Parameters, Error

Management

Collaborations, Logical Message

Control, Dependencies, Proxies, Shared

State

Deployment and

Implementation Patterns,

Encapsulation Boundaries

• These can be balloted to support various domain needs both separately and together

– Contracts are not ballotable, but their format will eventually be fixed by HL7 to

support local implementation as needed

Page 22

ContractsContracts

Page 23

Contracts (1)Contracts (1)

• Etymology: Middle English, from Anglo-French, from Latin contractus, from contrahere to draw together

• The term contract is used colloquially in technical circles both to describe the specification of the behavior of one party in a collaboration (e.g., a WSDL for a web service) or for the sum conversation as a whole (i.e., a collaboration).

• The term contract within the SAEAF explicitly means the artifact scoped to the overarching sets of interactions that support a business purpose and binds together the various participants.

– An artifact that serves to centrally capture essential computational viewpoint semantics (or references to them) for management and reuse

Page 24


• The central organizing principle of the SAEAF’s Behavioral Framework is the notion of integration mediation through contract.

– Bertrand Meyer’s “Design by Contract”

– Martin Fowler’s Accountability Pattern (http://martinfowler.com/apsupp/apchap2.pdf)

• Commissioning Agent

• Responsible Agent

– The goal is that each party designs the contract by which others engage with their component

• This interoperability drives all other system design

Page 25

Contracts (3)Bridging between Design- and Run-Time

Contracts (3)Bridging between Design- and Run-Time

• Contracts serve to provide a binding between design time requirements and constraints and run-time components, facilitating exchanges of information

– May be pre-defined or implicit (that is, defined but not created as an artifact)

– Design-time constraints include:

• Integration semantics

• Required Roles

• Required Participations

• Legal issues

• Quality-of-service

• Jurisdictional

• Policy components

Page 26


Agree on “Reference” view

Agree on “Conceptual” view

Agree on“Platform-Independent” view

Agree on“Platform -Specific” viewA

B

DC

F

Component Component

E

•The participants on the Stairway must work together via agreed contracts (real or implicit)•The basis of each contract is a collaboration that binds together roles. •Some participants will be playing a defined business role to support the collaboration

•Each participant playing a business role is variably conformant to a specification

•There are likely multiple Stairways to any given collaboration

Page 27


• The BF provides a way to talk about

– Business Roles (aka Service Roles)

– Collaborations

– Participations in those collaborations

• In some cases, these participations are playing both a business role and a run-time role

Page 28

Contracts (6): Roles and Participations


Page 29



• Note the separation of business roles and run-time roles

– Business Roles are roughly equivalent to HL7 Legacy Application Roles (more on that later)

– Run-time roles are of two types

• Commissioning Agent – requesting some capability

• Responsible Agent – providing some capability

– Contracts bind the different parties and their capabilities / needs to patterns of behavior

Page 30

Contracts (8): Roles and Participations Example

Contracts (8): Roles and Participations Example

• Commissioning Agent

– Needs to create a lab order; needs to provide sufficient semantics to create the lab order

• Responsible Agent

– Service Role: Lab Order Service being used as a Lab Order Manager

– Participation: has the responsibility to create a new lab order when provided appropriate information

• The Contract defines the roles, their participations, the interactions, and the goals.

Page 31

Contracts (9): More ….

Contracts (9): More ….

• Contracts can also deal with some platform-independent and platform-specific elements of behavior

– Platform – Independent: behaviors, behavior groupings, shared state machines, pre-defined interactions, nested behaviors, and references to relevant Collaboration Specifications

– Platform – Specific: Deployed components, defined operations, parameter format, quality of service, service level agreements, identified instances, shared tokens

Page 32

Contracts (10)Summary (1)


• Contracts serve to provide context in the form of quality and functional requirements around deployment of components involved in interoperability scenarios

– Describe the logical pieces (Collaboration, Service Role dependencies … more later)

– Describe performance expectations and agreements

– Provide traceability to industry standards

– Provide a testable set of components that validates the conditions of interoperability

• The conformance statements of the specifications are asserted to have been met at the Interchange points

Page 33



• The Behavioral Framework helps to answer …

– Who

– What

– When

– How

• The essential question is …

• Who does What ….. When and How?|

Service Roles|

Collaborations| |

________Contracts________

Page 34

• Perhaps most importantly, contracts offer another place to capture essential integration semantics

– In some paradigms like services, binding a service interface to a commissioning agent early is inappropriate

• contracts provide a means to describe the essentials of interactions without creating siloed, one-off interfaces

– Contracts may be nested (that is, referenced by commissioning agents) to provide fulfillment

• Notice that Responsible Agents may reference a Contract

• Like a Purchase Order or a Gift Card

• Avoids “hard wiring” components into pre-configured spaghetti



Page 35

Defining a Service RoleDefining a Service Role

Page 36

Defining a Service Role(1)Defining a Service Role(1)

• Service Roles provide a domain-focused way of defining a given capability (called a topic) and their relevant semantics that are essential and business relevant

– A capability – exposed as an instance of a service - may be described in terms of the semantics required to integrate that capability into some larger behavioral pattern

• Adopting / adapting a Service Role Specification is the key to outlining sets of reusable and durable business capabilities for an organization

• Note: There is a body of work that preceded the SAEAF in this regard …

– HSSP’s SFM

– HL7 SOA WG’s SOA4HL7

– HL7 SOA WG’s SOA Interoperability Paradigm’s Methodology

Page 37

Defining a Service Role(2):Essential Semantics

Defining a Service Role(2):Essential Semantics

• Organized by Topic

• Enterprise Viewpoint:

– Scope of the Service, Policy Considerations

– Relationships with other Roles and Collaborations

• Information

– Domain Concepts Parameters for Operations Schema / Objects

– State Machine for Focal Class (Optional)

• Computation

– Functional Profiles, Interface Specifications

• Business Operations Logical Operations Functions

– State Transitions for Focal Class (Optional)

– Other Collaborations

• Engineering

– Deployment Considerations

– Libraries

Page 38

Defining a Service Role(3):Essential Concepts for Specification

Defining a Service Role(3):Essential Concepts for Specification

Page 39

Defining a Service Role(4): Notes on the Model

Defining a Service Role(4): Notes on the Model

• Service Role Specifications include the following essential components:

– Behavioral Specifications (via BehaviorTypes)

• Business Operations Logical Operations Functions

– Behavior Groups (via BehaviorProfileTypes)

• Functional Profiles, Interface Specifications

– Collaboration Participations, either as ….

• informational examples of Responsible Agents (to other members of one or more Collaborations)

• as the Commissioning Agent (defining its own Collaboration Type and nested Contracts) via actual exchanges of information (via ExchangeTypes and InteractionTypes).

– Explcitly part of the “realization” part of the specification, and not exposed in the interface itself.

Page 40

Defining a Service Role(5):Notes on Deployment

Defining a Service Role(5):Notes on Deployment

• It is simplest to think of a service = web service

– A deployed piece software component that does something

• ... But a Service Specification may be deployed by multiple systems in multiple places, or even by the same system multiple times for multiple clients

– An organization may want ONE Source of Record for X Data, and then there needs to be a single URL to get that Data

• …. But even then, there are likely multiple deployed service components to aid with performance, etc.

• … And there may be multiple “Write” interfaces that need to be coordinated to insure data integrity

– Example: An organization may want each of it’s hospitals to deploy a common service specification to help with reporting

• NCI: Each Cancer Center deploys commonly specified reporting interfaces to support accrual reporting

Page 41

Service Roles (6)Incremental approach to defining WI through Conformance:

Service Roles (6)Incremental approach to defining WI through Conformance:

•Two parties who wish to integrate build on the Specification Stack to achieve “Working Interoperability” centered around a single topic

•C and D have the easiest time interoperating because they agree on interoperable components based on a platform-specific specification. This is most desirable, but not a precondition to interoperability. (They still have work to do …)

•Should B wish to interoperate with D, B will need to write adapters that provide semantic interchanges for policy, behavior, and information, and technology, which would be derived from examining the related specification.

•B and F can interoperate by agreeing on a Conceptual Specification, but F will have to write adapters to provide semantic interchanges (as above).

•A has the farthest to go to interoperate with anyone else. Adapters will have to be written to accommodate constraints from several layers

Reference

Conceptuals

Platform-Independent

Platform -SpecificA

B

DC

F

Component Component

E

Service Role (Capability) Topic

Page 42

Service Roles (6)Summary(1)


• Service Roles provide a means of specifying core capabilities that are important to a domain

• They represent a governable structure (see Governance) that encapsulates essential semantics of integration

• They represent a commonly defined capability that may be adopted or adapted by an organization to either achieve WI (or to come into some level of compliance)

Page 43



• Service Roles provide for the explicit solution to a particular topic

• They are intended to provide an encapsulation barrier behind which something happens

– …. But they don’t infringe on contract semantics or on Collaborations between other services

– They are durable, reusable components that support a unity of purpose. They exist in the context of other durable, reusable components that support other purposes.

Page 44

A Degenerate Behavioral ModelA Degenerate Behavioral Model

Page 45

The Degenerate Behavioral Model (1):Service Roles and Relationships

The Degenerate Behavioral Model (1):Service Roles and Relationships

• When specifying behavior for a Service Role, notional (or better) clients are considered

– For Example, Lab Order Manager Service needs a Lab Order Placer

– The BF refers to these as RoleRelationships

• RoleRelationships are the first place where we see the Interoperability Paradigms appear

– Messaging – RoleRelationships are Well Defined, Normative

– Services – RoleRelationships are Informative at best

• RoleRelationships provide the basis for top-down analysis to support a Service Role Specification

Page 46

The Degenerate Behavioral Model (2): From EIS Conceptual Model

The Degenerate Behavioral Model (2): From EIS Conceptual Model

7 User Scenario Interaction Details7.1 Create a new patient7.2 Link/Merge entities7.3 Update demographics7.4 Inactivate entity from general searches7.5 Activate (inactive) entity to general searches7.6 Unlink entity7.7 Look up a patient7.8 Unattended Encounter7.9 Remove entity from the system7.10 Look up patient across regional network7.11 Look up a patient specifying a specific external organization7.12 Link entities across regions within an organization

… This TOC is from the EIS Conceptual Model ….

• These entries in the Table of Contents are the lists of Business-level interactions and operations that are defined for EIS

•They represent the sum of behaviors that are considered relevant for Identification Management

}

Page 47

The Degenerate Behavioral Model (3): Example … Summary

The Degenerate Behavioral Model (3): Example … Summary

EIS (North)

XEIS (Solar System)

Find Entity With Traits(Person, Frank)

Find Entity by Traits (Patient, Frank, Solar System)

Return Frank

HIS (Jupiter)

Return Frank

PabloSearch (Frank)

Find Entity by Traits(Patient, Frank)

No match

Search (Frank, Solar System)

Return Frank

CreateEntity

Link Entity

Service Role Service Role Service Role

RoleRelationshipRoleRelationship

RoleRelationship

CommissioningResponsible

Page 48

The Degenerate Behavioral Model (4): Example … Focus on Role Relationships

The Degenerate Behavioral Model (4): Example … Focus on Role Relationships

EIS (North)

XEIS (Solar System)



Return Frank

HIS (Jupiter)

Return Frank

PabloSearch (Frank)


No match


Return Frank

CreateEntity

Link Entity


RoleRelationshipRoleRelationship

RoleRelationship

Page 49

The Degenerate Behavioral Model (5): Example … Focus on Commissioning and Responsible Agents

The Degenerate Behavioral Model (5): Example … Focus on Commissioning and Responsible Agents

EIS (North)

XEIS (Solar System)



Return Frank

HIS (Jupiter)

Return Frank

PabloSearch (Frank)


No match


Return Frank

CreateEntity

Link Entity


CommissioningResponsible

Page 50

The Degenerate Behavioral Model (6):Notes on the Example

The Degenerate Behavioral Model (6):Notes on the Example

• The union of these sequences of interactions form the behavioral model that is expressed in the ECCF’s specification stack for a Service Role

– Specifically the conceptual and platform independent specifications for a Service or Message

• Only one RoleRelationship in the example (Identity Requester to Identity Manager) that is logically repeated between different instances of the Service, and only a few in the Service Role Specification

• This is very simple

– Only one relevant RoleRelationship to accomplish any particular business purpose

– One Service Role

– Several (but not many) Behavioral Groups to identify logically consistent sets of behavior

Page 51

The Degenerate Behavioral Model (7):The Contract Revisited

The Degenerate Behavioral Model (7):The Contract Revisited

• In this degenerate example, the contract is implicit and pretty simple

– It is simple because the Collaborations needed to fulfill the business purpose rely on a single Service Roles Behavioral Groups

– The Responsible Agent is commonly specified (that is pretty much why we define service roles – so that we can encapsulate repetitive behavior)

• We would expect the portion of the contract to be well defined by a WSDL as a part of the overall contract

• The commissioned goals are simple (for example, “identify person given x demographic data”)

• Only one RoleRelationship involved to achieve any given goal (note, though, that the instances of that relationship may be nested, as in the example)

– A single business role played both Commissioning and Responsible Agent

• Nested Commissioning behavior to the right was hidden from Commissioning Agents to the left

– The Service Role is managing all states of domain objects, if there are any at all

• The deployed service would link, merge, create, delete, etc various identities

• Errors from these behaviors are straightforward

Page 52

Collaboration SpecificationsCollaboration Specifications

Page 53

Collaboration Specifications (1)Towards a richer way of specifying behaviors

Collaboration Specifications (1)Towards a richer way of specifying behaviors

• So what do we do if …..

– there are multiple RoleRelationships involved in achieving a business goal?

– there are shared states and / or shared objects among systems?

– There is the need to proxy behaviors or control behaviors using decision logic?

• For example, Complex Error Management

• For example, multi-site clinical trial registration

– There are multiple Service Roles defined as dependencies?

Page 54

Collaboration Specifications (2)Service Roles and Collaborative Behaviors

Collaboration Specifications (2)Service Roles and Collaborative Behaviors

• Roles have behaviors that support certain collaborations, and collaborations require certain role’s behaviors to fulfill their purpose.

– These things may be bound explicitly or implicitly, at run time or design time, through the use of contracts.

– “Inside looking out”

• Collaborations are sets of specified behavior that serve some particular business need. They embody some of the semantics of a given business process, but in the context of the Behavioral Framework, may explicitly depend on and support the integration semantics embodied in Service Role Specifications.

– Rely on specified Services to perform certain functions (which may in turn be collaborations in which the services perform the role of the Commissioning Agent) or to expose certain information.

– “Outside looking in”

Page 55

Collaboration Specifications (3)Computational Viewpoint

Collaboration Specifications (3)Computational Viewpoint

• The Collaboration Specification stacks are primarily computational constructs (from the Computational Viewpoint in the SAEAF).

– Informed heavily by Enterprise / Business and Information Viewpoints

• The Collaboration Specification takes a top-down view of what the distributed system is trying to accomplish, captures the semantics for integration, names dependencies

– Named Business purposes

– Error management

– Message sequence dependency

– Shared States / Objects

– Quality of interoperability

• The Collaboration Specification is an abstraction away from “3 tier design” to thinking about interoperability first

– Design by Contract (Meyer)

Page 56

Collaboration Specifications (4)Essential Semantics (1)


• Activity Types - . Activity Types may have a relationship with similar Activity Types. They may also contain a Trigger Type that will describe a derived Activity Relationship. Any Activity Type may be exposed by a Behavior Type.

– Collaboration Types

– Work Unit Types

– Interaction Types

– Exchange Types

Page 57



• Collaboration Types are the highest level of encoded Activity Types.

– They contain descriptions and may reference certain milestones.

– Scoped to a particular business process.

• Work Unit Types are logical collections of Interaction Types.

– They may reference composite Milestones (that is, collections of milestones that represent an intermediate step in fulfilling a business process).

Page 58



• Interaction Types are sets of exchanges scoped by a single Commissioning Agent and a single Responsible Agent.

– Interaction Type is the concrete, granular representation of a service’s participation in a given business context.

– They fulfill a particular milestone in the business process that is encoded by the Collaboration Type.

Page 59



• Exchange Types capture the finest grained components of behavior exchanging information that go back and forth between a Commissioning Agent and a Responsible Agent.

• Exchange Types may have a relationship to other Exchange Types (because they are specializations of the Activity Type) so that they may be either synchronous, asynchronous, or long running.

• Exchange Types may (should) express an exception condition between information sharing partners that flowed from an exception condition tied to a Service’s behavior. Exchange Types call on Behaviors Types to pass information or to expose capabilities.

Page 60

Collaboration Specifications (8)Collaboration Specifications (8)

Page 61

Collaboration Specifications (9)Notes on the Model

Collaboration Specifications (9)Notes on the Model

• The BehaviorType class is from the Service Role Specification

– It is tied explicitly to other ActivityTypes in this model, since you can expose complicated behaviors through a Service Behavior

– More importantly, it is tied directly to ExchangeTypes, since Collaborations rely on underlying services for essential functionality to fulfill their Milestones

Page 62

Collaboration Specifications (10)Notes on the Model (2)

Collaboration Specifications (10)Notes on the Model (2)

• Channel Type expresses the ability of a deployed component to pass information for some business purpose.

– At the Conceptual Design level, these express a constraint on the ways information might be thus passed. For example, radiological images may imply the need to share information via a File Transfer Protocol.

– At the platform-independent and platform-specific levels, they represent actual channels

• Trigger Types, roughly synonymous with HL7’s Trigger Event, are not only present for backwards compatibility, but because the invocation of a given Activity Type may imply the need for subsequent Activity Types.

– More Later

Page 63

Collaboration Specifications (11)A Portion of an Instance Model

Collaboration Specifications (11)A Portion of an Instance Model

• Quasi - Instance Models (without run-state) are helpful to see what an actual Collaboration Specification looks like

• The Collaboration’s ties to Service Roles is through Interaction Types

– Define specifically how the Service is being used and what for.

– A single interaction is scoped by a Commissionign Agent and a Responsible Agent

– Services Roles play the Responsible Agents in a SOA

Page 64

Summary of the Three EssentialsSummary of the Three Essentials

Page 65

Summary of the Three Essentials… (1) All of the pieces

Summary of the Three Essentials… (1) All of the pieces

• The Behavioral Framework has defined three pieces necessary to capture integration scenarios

– Contracts

– Collaborations

– Service Roles

Page 66

Summary of the Three Essentials… (2)The Lifecycle of a Standard

Summary of the Three Essentials… (2)The Lifecycle of a Standard

• These three things can be used in combination or singularly to define behavior through various parts of the lifecycle of a standard

Service Role Collaboration Contract

Domain WG Define Core business capability (with unity of purpose) and essential Business / Information Viewpoint semantics

Define Core Collaborations (with Dependencies) and essential Business Viewpoint semantics

N/A

Foundation WG

Elaborate on Computational and Engineering Viewpoints; provide the definition of the encapsulation boundary for the core capability

Elaborate on inter-system behavior; define classification of dependencies (services)

Craft Contract parts to reflect Computational and Engineering viewpoint concerns

Implementing Organization

Adopt / Adapt / Deploy Service Role Specification to provide standardized mechanisms for exposing and accessing organizational capabilities that align well with industry standards

Utilize Collaboration Specifications as implementation guides for constructing interoperability architectures, understanding dependencies, and aligning organizational structures with industry standards

Create, Publish, and advertise contracts to manage interoperability responsibilities and dependencies

Page 67

Incremental approach to defining WI through Conformance:Commonly Specified Collaborations

Incremental approach to defining WI through Conformance:Commonly Specified Collaborations

•Two parties who wish to work together to achieve a business purpose can work from a common Collaboration Specification

•If this Collaboration Specification is based on Service Role Specifications, then the effort to achieve WI can be mapped (at least theoretically) by examining each integration point and accumulating how many “steps” need to be traversed per Capability Topic

•The Collaboration Specification, in addition to naming structural dependencies, contains important semantics of its own

•Quality of interoperability

•Named Business purposes

•Error management

•Message sequence dependency

Reference

Conceptual


Platform -Specific

AB

DC

FComponent Component

E

Collaboration Topic

Reference

Conceptual


Platform -Specific

AB

DC


E

Reference

Conceptual


Platform -Specific

AB

DC


E

Reference

Conceptual


Platform -Specific

AB

DC


E

Reference

Conceptual


Platform -Specific

AB

DC


E

Page 68

Example: A more explicit Contract and a rich Collaboration

Example: A more explicit Contract and a rich Collaboration

Page 69

Example: A more explicit Contract and a rich Collaboration (1)

Example: A more explicit Contract and a rich Collaboration (1)

• The National Cancer Institute (NCI) supports Cancer Clinical Trials

• Transcend is an architecture model that identifies various capabilities (Service Roles) and creates Collaborations between them to facilitate a Clinical Trial’s management for a Study Coordinator

Page 70

Example (2)Transcend

Example (2)Transcend

• The Transcend Integration Architecture binds together the following logical components:

– Clinical Data Management System (CDMS)

– Electronic Clinical Health Record (eCHR)

– Specimen Management Capability

– Treatment Plan Management Capability

– Imaging Management Capability

– Adverse Event Management Capabilities

– Protocol and ARM Management Capabilities

– Subject Management Capabilities

Page 71

Example (3)Transcend Integration Architecture Behavioral Packages

Example (3)Transcend Integration Architecture Behavioral Packages

• The Blue Packages represent Collaborations focused on Imaging and Specimen Management

• The Green Packages are Collaborations that directly support clinical workflow

Page 72

• Conceptual Collaboration for Enrollment in Transcend

– It is not platform-independent yet because there is no error management

• Note the exposed interfaces on Services and collaborations for different capabilities

• The sequencing of messages is vital

• Note the logical component roles being played by different systems

– This shows a given configuration … other systems could realize those roles

Example (4)Example (4)

Page 73

Example (5)Transcend Summary

Example (5)Transcend Summary

• A few things to note about Transcend

– It is system agnostic, but tightly coupled to capability

– It has “in house” components that play several logical roles (Note: This is not uncommon in legacy scenarios)

– Different stakeholders

• For the NCI, Transcend is a set of patterns with dependencies

– Implementation

– Design

• For Cancer Centers, Transcend must be transparent working system

• Transcend is using CDA / Forms

– …. But those “Forms” call multiple subsystems for fulfillment

– …. a lot of behavior is hidden behind fairly simple mechanisms

Page 74

Service ClassificationsService Classifications

Page 75

Service Classifications (1)Introduction (1)


• The purpose of a service classification scheme is to provide a framework that simplifies the effort of integration.

• A service classification context should not be a monolithic construct that muddies the waters of service development.

– Should be consistent with a set of principles that provide architectural and design guidance on the usage and crafting of services.

– Should provide an easily understood and consistent set of guidelines that provide clarity and reusability.

• Ultimately, the Service Classification System describes certain patterns

– defines certain limits based on experience, best practice, engineering / design. and the architecture

– constrain and extend the otherwise green-field of software engineering in the context of standardized services

Page 76



• Service Classifications are common practice for an organization

– a scheme for services that establishes

• defined patterns of conduct

• reusable business rules

• layers of commonality

• architectural and design patterns for building solutions

• It is a hierarchical set of classifications that represent common patterns of implementation and usage, providing sets of rules that cover such issues as

– peer communication

– Referencing

– Granularity

– Separation of concerns

Page 77

Service Classifications (3)Classifications

Service Classifications (3)Classifications

• Classifications

– Process

– Capability

– Core

– Utility

• These classifications are heavily borrowed from different classification systems

– CBDI

– Thomas Erl

Page 78

Service Classifications (4)Process Services (1)


• Virtualized business processes that represent reusable patterns of behavior

– Realized sets of business rules that an organization has agreed upon

– Generally not concerned with the states of domain entities other than insofar as they affect the state of the process as a whole.

• Tend to be coarsely granulated

– Limiting the number of external calls

• Enhances performance

• Allow for the business process in question to be appropriately scoped

• By definition, they are usually “stateful” services (though that may be implemented in a number of ways).

Page 79



• External behavioral specification exposes some type of behavior as laid out in a collaboration specification, acting as a Commissioning Party for certain behaviors.

• When these Collaborations revolve around some shared state for the business process (which may be thought of as a transaction state), that state may be exposed through the interface.

• May nest contracts and Collaborations

– Can describe a dependency on a particular profile of a Service Role, though it would not be appropriate to discuss the technical details of its implementation.

Page 80

Service Classifications (6)Capability Services (1)


• Well-specified domains such as healthcare often define focal classes (or domain classes or business objects) that represent some domain concept.

– Generally are characterized in part by some series of information models that are tied to a state machine.

Page 81



• Capability Services expose states of instances of these focal classes through run-time constructs that realize their external behavioral specifications.

• Role as a Responsible Party in a given Collaboration is bound to a focal class and its state machine

– How that state machine traverses its states is a matter of implementation, not standardization.

Page 82

Service Classifications (8)Core Services (1)

Service Classifications (8)Core Services (1)

• Core Services expose information models without regard for the complexities of the underlying states of the information

– A publishing model for core domain concepts / objects

– Publishing may coincide with a single state on a more complex state machine

– Built to service various queries that need authoritative information

• Responsible Agent Alignment of ECCF with work of Frank Oemig (as well as other HL7 conformance testing work).

•

Page 83

Service Classifications (9)Utility Services (1)

Service Classifications (9)Utility Services (1)

Page 84

The Unified Field TheoryThe Unified Field Theory

Page 85

The Unified Field Theory (2)The Unified Field Theory (2)

• The Unified Field Theory is a comprehensive approach to dealing with healthcare interoperability standards that included implementations using documents, messages, and services either in combination or singularly.

• The BF supports the Unified Field Theory by providing the ability to capture the computational semantic differences that are the result of choosing one paradigm over another for a particular business usage

– In some ways, the easiest way to choose one paradigm over another is to look at computational semantics (or the computational semantics implied by a pre-set deployment (for example, message oriented middleware or an ESB))

– Most importantly, the BF denotes three places to capture behavioral semantics and defines their relationship to each other

• Improves the chances of reusability and explicitness in implementation

Page 86

The Unified Field Theory (3)The Unified Field Theory (3)

• Three Interoperability Paradigms

– Messages - the transmission of semantically rigorous, contextually self-contained information structures according to pre-determined trigger conditions along well known interaction paths

– Documents - a business-oriented container that becomes the focal class that may be exposed through a service interface (for administration, querying, and manipulation), or transmitted via a

message

– Services - a structured behavioral interface being exposed that provided fine grained control of some capability, often a focal class such as an order or a transactional process. These capabilities would, in turn, be invoked through smaller, function-oriented message structures that retain the semantic rigor of HL7 models without realizing the entirety of the semantic in the message structure.

Page 87

The Unified Field Theory (4):A Common Conceptual Specification

The Unified Field Theory (4):A Common Conceptual Specification

• It should be emphasized that Conceptual Specifications (either Service or Collaboration) are agnostic with regards to these paradigms.

– A given Conceptual Specification provides a basis for conformance regardless of ultimate implementation.

– This includes both Service Roles and Collaborations

Page 88

The Unified Field Theory (5):Services

The Unified Field Theory (5):Services

• Services provide structures to handle certain aspects of interoperability

– Synchronous v Asynchronous

– Defined Interface Specifications

– Evolved error and behavior control

• Services allow for a domain-relevant capability to be exposed in a durable and extensible manner in an organization and managed

• Services provide reasonable ways of addressing some difficult topics

– Querying, shared state management,

• In the BF, no pre-determined Service Role acting as Commissioning Agent

Page 89

The Unified Field Theory (6):Messages

The Unified Field Theory (6):Messages

• Messaging as a paradigm involves coarsely granulated messages that align well with event-oriented, pre-configured business triggers.

– These are specializations of Collaboration Types

– Well defined Service Roles as both Commissioning and Responsible Agent

– Well-defined by legacy HL7 Interactions, but can benefit from the richer behavioral groups that the BF brings

Page 90

The Unified Field Theory (7):Documents

The Unified Field Theory (7):Documents

• Define a business-oriented container that becomes the focal class that may be exposed through a service interface

– Administration, querying, and manipulation

– Optionally transmitted via a message.

• The Documents “paradigm” provides an effective mapping from real-world scenarios to information constructs, especially via a stack of increasingly constrained specifications, allowing a simplified behavioral interface that aligns well with real world behaviors.

Page 91

Unified Field Theory (8):Notes on the following models

Unified Field Theory (8):Notes on the following models

• The model details an instance of a contract, binding two logical service role types together into a collaboration type that would be realized with messages.

– The Collaboration Specification is an attribute of the Contract

– The Service Role Specifications are attributes of the Commissioning and Responsible Agents

Page 92

The Unified Field Theory (9):A Contract in a Messaging Environment

The Unified Field Theory (9):A Contract in a Messaging Environment

Page 93

The Unified Field Theory (10):Notes on a Contract in a Messaging Environment (1)


• In a Messaging environment, it is likely that both roles will be bound early in the analysis through to run time, though the roles themselves have no physical corollary

– that is, there is no deployed physical Service, for example, that plays the actual role

• Thus the message contains its own context

– This binding happens through Message Managers (which handles message receiving, parsing, dispatching, port management, and so on) and Handlers (that handle management of the semantics)

Page 94



• Implementing with Managers and Handlers has several consequences:

– This early binding means that the Contract deployed in a Messaging Paradigm says that only certain Business Roles may bind with other Business Roles (an Order Placer with an Order Manager, for example).

– The diagram shows that what is testable (the Interchange Point) depends on things that are implicitly defined. This obfuscates traceability since what is traceable is not directly tied to the contract.

– The MessageHandlers realize BehaviorTypes, but it is not clear (except through introspection) how and to what extent the Behaviors align with the Collaboration Specification inherent in a contract.

Page 95

The Unified Field Theory (12):A Contract in a Services Environment

The Unified Field Theory (12):A Contract in a Services Environment

Page 96

The Unified Field Theory (13):Notes on a Contract in a Services Environment (1)


• The model details an instance of a contract, binding two logical service role types together into a collaboration type that would be realized with messages.

– The Collaboration Specification is an attribute of the Contract; The Service Role Specifications are attributes of the the Commissioning and Responsible Agents

• In a Services environment, only the Contract’s Responsible Agent will be bound early to a Service Role. The Commissioning Agent has certain characteristics that may optionally be specified (a Behavior to manage asynchronous communications, for example, or a particular Quality of Service arrangement).

• However, even with services, Contracts can embody essential characteristics of behaviors and the requirements for the end-state. As a consequence, Contracts can serve both to embody the requirements for commissioning a capability exposed by a service and for describing the notion of nested capabilities virtualized by a responsible agent.

Page 97



• Note several characteristics of the Services environment:

– The deployed Service is a physical corollary to the logical RoleType discussed in the Contract.

– What is testable regarding integration semantics (behavior, information type) is realized as an Interchange Point that is a primary element. That is, the Interchange Point directly and traceably realizes a Contract Role of Commissioning Agent or Responsible Agent.

– The deployed Service, because of its expression mechanisms and the late binding of the Commissioning Agent, makes its integration semantics more accessible to more varied consumers

– Because of the more explicit integration semantics, the Service Contracts may reference other Contracts explicitly (the Responsible Agent may refer to other Contracts).

Page 98

• The BF is meant to be a framework for semantics

– rich when you need richness

• PSMs of Collaborations

• Specifications for implementing at an organization

– skinny when you don’t need much at all

• Conceptual Collaborations, Service Role elaborations

– Contextualizes Service Roles, Contracts, and Collaborations and makes explicit their relationship to each other.

The Unified Field Theory (15):Implementing the BF

The Unified Field Theory (15):Implementing the BF

Service Roles Collaborations| |

________Contracts________

Page 99

The Unified Field Theory (16):Implementing the BF (2)


• It is duly noted that the richer parts of the BF are not intended to be used in every situation

– Sometimes it’s enough to build a Service Role and know that some of the integration semantics are intended to be held in other components (contract or collaboration specification)

– There are still pieces that are extremely verbose

• A fully specified collaboration is extensive and explicit for an implementation and deployment team

Page 100



• Service Role Patterns

– Publishing a state transition

• ADT messages, clinical report stream

– Managing a state machine

• EIS, registries

– Request / Fulfillment

• Orders, prescriptions, dispensing

– Query

• RLUS, Decision Support

– Publish Business Process

Page 101



• Content Models vs Messaging Models

• Legacy HL7 defined a different content model for every interaction in v2 and v3

– Business Process is bound early by a unique combination of interaction + content

• The SAEAF’s approach supports Legacy HL7, but Services decouple business models from implementations

– Business Process is bound late(r) by unique content and multi-purpose interactions

• potentially combined with no human intervention at run time

– CDA’s are a special case

• Vision (r3) is that there is a single content model for all interactions

• All of these have their place and purpose, and should be used appropriately

Page 102



• Services provide for the ability to find engineering and design efficiencies in several parts of the architecture

– Call out more granular building blocks

– More reusable solutions that have durability because of Service Classification Schemes

– Adaptable to many contexts

• Messages as a paradigm are manufactured solutions that are fully appropriate for a single purpose in a single context

– They rely on an organization adapting to that manufactured context since it is bound so early

Page 103

The Legacy HL7 Dynamic ModelThe Legacy HL7 Dynamic Model

Page 104

The Legacy HL7 Dynamic Model (1)The Legacy HL7 Dynamic Model (1)

class Behav ioral Model

Storyboard

artifactIdnamenarrative

Interaction

artifactIDnamenarrativestructuredNameinteractionType

ApplicationRole

artifactIDnamedescriptionstructuredName

SendingApplicationRole

::ApplicationRoleartifactIDnamedescriptionstructuredName

Reciev ingApplicationRole


TriggerEv ent

artifactIDnamedescriptiontypestructuredName

InteractionBasedTriggerEv ent

::TriggerEventartifactIDnamedescriptiontypestructuredName

StateTransitionBasedTriggerEv ent


UserRequestBasedTriggerEv ent


StaticModel

artifactIDnametype

Receiv erResponsibility

reason

Application

ConformanceStatement

StoryboardExample

narrative

InformationStructure

disjoint = false

1..*

1..*

sends

sender 1

1..*

receives

receiver 1

1..* {ordered} 0..*contains

1

0..*

0..*

0..*

0..*

fulfi l ls

1

0..*

invokes

0..1

0..*

invokes

0..1

0..*

fulfi l ls

0..*

0..*

0..*

intiates

1

Name:Package:Version:Author:

Behavioral ModelBehavioral Modelv01r04AbdulMalik Shakir

Page 105


• These concepts from the HL7 Dynamic Model have corollaries in the Behavioral Framework

Legacy Dynamic Model SAEAF Behavioral Framework

Interaction maps to …. Exchange Type

Application Role maps to …. Interchange Point in an instance, or to a Role Type conceptually

Receiver Responsibility maps to …. Goal, Milestone, Collaboration State Machine

Trigger Event maps to …. Trigger Type

Information Structure maps to …. Information Model referred to by the Static Information Model Reference

Storyboard maps to …. Collaboration

Application maps to …. Candidate Component

Page 106


The mappings appear as stereotypes in the model.

class Behav ioral Model

«Interaction»Storyboard

artifactIdnamenarrative

«Exchange»Interaction

artifactIDnamenarrativestructuredNameinteractionType

«InterchangePoint»ApplicationRole

artifactIDnamedescriptionstructuredName

«ProviderInterchangePoi...SendingApplicationRole


«ConsumerInterchangePoint»Reciev ingApplicationRole


TriggerEv ent

artifactIDnamedescriptiontypestructuredName

InteractionBasedTriggerEv ent


StateTransitionBasedTriggerEv ent


UserRequestBasedTriggerEv ent


«ConstrainedInformationMod...StaticModel

artifactIDnametype

Receiv erResponsibility

reason

«SoftwareUnit»Application

ConformanceStatement

StoryboardExample

narrative

«ImplementableInformationModel»InformationStructure

disjoint = false

1..*

1..*

sendssender 1

1..*

receives

receiver 1

1..* {ordered} 0..*contains1

0..*

0..*

0..*

0..*

fulfi l ls

1

0..*

invokes

0..1

0..*

invokes

0..1

0..*

fulfi l ls

0..*

0..*

0..*

intiates

1

Name:Package:Version:Author:

Behavioral ModelBehavioral Modelv01r04AbdulMalik Shakir

Page 107

SOA Modeling Language (1) :An Alternative to Modeling Services

SOA Modeling Language (1) :An Alternative to Modeling Services

• OMG Standard to provide a UML Profile for Describing Services

• Discussed at length by the ArB during the Summer Sessions (2008) as a potential way forward to modeling some / all of services.

Page 108

SOA Modeling Language (2) :Introduction

SOA Modeling Language (2) :Introduction

• OMG Standard to provide a UML Profile for Describing Services

• Discussed at length by the ArB during the Summer Sessions (2008) as a potential way forward to modeling some / all of services.

• This section is a brief summary comparison of the concepts presented in the HL7 Behavioral Framework and SoaML. It should be construed as a work in progress to facilitate an eventual formal mapping.

Page 109

SOA Modeling Language (3):Summary

SOA Modeling Language (3):Summary

• There is some overlap, but the purposes are different.

– SoaML focuses on representing a Service as it is physically implemented in software

– Little explicit differentiation across the different stages of specification and development

• The HL7 Behavioral Framework is heavily focused on the Specification of Services and Collaborations at three well defined layers (Analysis, Conceptual Design and Implementation Design).

– Supports different Interoperability Paradigms

• It also explicitly represents the specification artifacts in the model, which SoaML does not.

Page 110

SOA Modeling Language (4):Summary (2)

SOA Modeling Language (4):Summary (2)

• There is several areas of alignment

– The notion of defining a collaboration, interface, channel, milestone

Page 111

SOA Modeling Language (5):Concept Comparison (1)


SoaML SAEAF Behavioral Model Comments

Service Service Mapping is approximate.SoaML defines a Service as a “port on a participant”

which is a very run time physical view and limited.

HL7-BF defines a Service as an abstract specification.

Service Contract Collaboration Contract Collaboration Specification:

- Conceptual- Design- ImplementableISRS

SoaML defines the notion of a Service Contract in terms of binding a Service Consumer to a Service Provider. This is limited in that it does not seem to explicitly recognize the separation of the specification of the service itself vs the specification of uses of the service in collaborations. It also has no separation of the different stages of specification.

Collaboration Collaboration Type Collaboration is used in the generic UML sense for SoaML. This equates close enough with the HL7 BF notion of Collaboration Type

Collaboration Use Collaboration Participation SoaML: Candidate component fulfills role/contract.HL7 BF defines a Collaboration Participation which is

effectively the same.

Page 112




Service Interface SoaML:

Includes both required and provided interface operations.

Text seems to confuse realization and interface

The text in SoaML is unclear to me on the distinction between a required interface on a Service Provider vs a required interface on a Service Consumer. I cannot make much sense of this approach. I believe that for specification purposes, provided interfaces along with Collaboration specifications are sufficient and clearer.

UML Interface Behavior Group

Interface

External Behavior Specification

In SoaML, a UML Interface is a “provided” interface. This equates to the HL7 BF notion of Interface (or the more abstract Behavior Group)

Page 113




Participant Participant

Application / Software Unit

Role Type

Candidate Component

The SoaML notion of Participant seems to cover both the abstract notion of role and the actual participant playing the role. HL7-BF has made these separate constructus explicit.

Service Role Specification:

- Analysis Spec

- Design Spec

- Implementable Design Spec

The actual Service Specification is not explicitly identified in SoaML.

Behavior SoaML does not explicitly define the individual operation level.

Service Realization Specification

Not really covered in SoaML. Can represent component structures and behavior using activity diagrams etc, but not really described

Page 114




Service Point Responsible Agent

Interchange Point

SoaML: Provided Interface

Again HL7 BF differentitates the “role” notions from the actual points.

Request Point Commissioning Agent

Interchange Point

SoaML: Required Interface

Again HL7 BF differentitates the “role” notions from the actual points.

Port Interchange Point HL7 BF does not explicitly represent ports since this is at the implementation level.

Work Unit Type HL7 BF does not explicitly represent ports since this is at the implementation level.

Interaction Type HL7 BF does not explicitly represent ports since this is at the implementation level.

Role Relationship Type No real structure of collaborations represented in SoaML. It is partially dealt with in the notion of the Collaboration and the Service Point and the Request Point.

Page 115




Exchange Type No real structure of collaborations represented in SoaML

Service Channel Channel Equivalent

Message Type CIM/LIM Equivalent

Domain Analysis Model No representation of information model in SoaML

Attachment Not explicit Technology Viewpoint issue, not covered in HL7 BF except as “payload” and “payload type”

Capability Service (Conceptual layer)

SoaML: business abstraction of a Service

Milestone Milestone SoaML: identifies a place for instrumentation to measure fulfillment of behavioral goals in an ordinal fashion. HL7 BF identifies a milestone as a goal of an interaction within the scope of a logical work unit.

Page 116