ServicesInteroperabilityParadigm_v1_01.doc.doc
Upcoming SlideShare
Loading in...5
×
 

ServicesInteroperabilityParadigm_v1_01.doc.doc

on

  • 535 views

 

Statistics

Views

Total Views
535
Views on SlideShare
535
Embed Views
0

Actions

Likes
0
Downloads
7
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    ServicesInteroperabilityParadigm_v1_01.doc.doc ServicesInteroperabilityParadigm_v1_01.doc.doc Document Transcript

    • HL7 Service Oriented Architecture Technical Committee (SOA TC) and the Healthcare Service Specification Project (HSSP) Healthcare Interoperability: A Service-Based Paradigm, Conformance Model, and HL7 Dynamic Model VERSION NO. 1.01 DATE: 5/6/2010 Authors Alan Honey (Kaiser Permanente) alan.p.honey@kp.org John Koisch (Booz Allan Hamilton) koisch_john@bah.com Editor Charlie Mead (Booz Allen Hamilton) mead_charlie@bah.com
    • 1 EXECUTIVE SUMMARY.........................................................................................................................4 1.1 HISTORY...................................................................................................................................................5 2 INTRODUCTION.......................................................................................................................................5 2.1 SERVICE-ORIENTED SOLUTIONS FOR HEALTHCARE .........................................................................................5 3 RM-ODP.......................................................................................................................................................8 3.1 AN OVERVIEW ..........................................................................................................................................8 3.2 THE FIVE VIEWPOINTS................................................................................................................................9 4 THE HSSP/HL7 SOA TC’S “SOA INTEROPERABILITY PARADIGM”.......................................12 4.1 OVERVIEW OF THE SOA INTEROPERABILITY PARADIGM (THE HSSP PROCESS)................................................13 4.2 THE SOA INTEROPERABILITY PARADIGM’S CHOREOGRAPHY DESCRIPTION.......................................................15 4.2.1 CDL – An overview......................................................................................................................15 4.2.2 CDL Tooling................................................................................................................................16 5 MAPPING THE SOA INTEROPERABILITY PARADIGM TO THE FIVE VIEWPOINTS.........17 5.1 THE SPECIFICATION METHODOLOGY...........................................................................................................17 5.2 THE WORK STREAMS ..............................................................................................................................19 5.3 CHOREOGRAPHIES AND RM-ODP..............................................................................................................23 5.4 STANDARDIZATION AND CONFORMANCE ......................................................................................................24 5.4.1 Using CDL to Capture Conformance Statements........................................................................28 6 SOA INTEROPERABILITY PARADIGM METHODOLOGY – DETAIL, ANALYSIS, AND RM- ODP CORRESPONDENCE........................................................................................................................29 6.1 BUSINESS ANALYSIS (ENTERPRISE AND INFORMATION VIEWPOINTS)................................................................29 6.2 SYSTEM REQUIREMENTS AND FUNCTIONAL SPECIFICATION (ENTERPRISE, INFORMATION, COMPUTATIONAL VIEWPOINTS).................................................................................................................................................30 6.3 PLATFORM INDEPENDENT MODELS (PIMS) (INFORMATION AND COMPUTATIONAL VIEWPOINTS) .......................32 6.4 PLATFORM SPECIFIC MODEL (PSM) (ENGINEERING VIEWPOINT)...................................................................34 7 THE SOA INTEROPERABILITY PARADIGM AND HL7 – CURRENT STATE AND EFFORTS ........................................................................................................................................................................36 7.1 TYING THE SOA INTEROPERABILITY PARADIGM TO THE MESSAGING PARADIGM...............................................36 7.2 MAPPING TO V3 USING THE SOA4HL7 ARCHITECTURE ............................................................................39 7.2.1 Request Message items................................................................................................................39 7.2.2 Response Message items..............................................................................................................45 8 THE SOA INTEROPERABILITY PARADIGM AND HL7 – FUTURE STATE..............................46 8.1 BUSINESS ANALYSIS.................................................................................................................................47 8.1.1 Assumptions.................................................................................................................................47 8.1.2 Service Portfolio Planning..........................................................................................................47 8.1.3 Business Process Analysis...........................................................................................................47 8.1.4 Business Information Analysis.....................................................................................................48 8.1.5 Business Capability Definition....................................................................................................48 8.2 SYSTEM REQUIREMENTS AND FUNCTIONAL SPECIFICATION.............................................................................48 8.2.1 Define and Outline Business Flows and Dynamics.....................................................................49 8.2.2 Information Analysis....................................................................................................................51 8.2.3 Define Functional Capabilities – Operations and Information Content.....................................51 8.2.4 Produce Functional Specification...............................................................................................52 8.3 ANALYSIS AND DESIGN (PIM)..................................................................................................................52 8.3.1 Define Detailed System Choreography.......................................................................................53 8.3.2 Define System Capabilities..........................................................................................................54
    • 8.3.3 Information Design......................................................................................................................56 8.4 TECHNICAL SPECIFICATION (PSM).............................................................................................................56 8.4.1 Produce PSM...............................................................................................................................56 8.4.2 Produce Implementation Guide...................................................................................................58 9 THE SERVICE-ORIENTED INTEROPERABILITY PARADIGM’S DYNAMIC MODEL .........58 9.1 HL7 ARTIFACTS AND CDL ARTIFACTS......................................................................................................58 9.1.1 CDL Exchange, HL7 Interactions, and Message Exchange Patterns.........................................60 9.1.2 CDL Guard / Block Conditions and HL7 Trigger Events...........................................................60 9.1.3 CDL Guard / Block Conditions, CDL Workunits, and HL7 Receiver Responsibilities...............61 9.1.4 CDL Expression of the HL7 Application Role.............................................................................61 9.2 CDL WORKED EXAMPLE – LABORATORY ORDERS......................................................................................62 9.2.1 Interactions..................................................................................................................................62 9.2.2 Roles, Relationships, and Participants........................................................................................63 9.2.3 Information..............................................................................................................................65 9.2.4 Information Types........................................................................................................................65 9.2.5 Tokens..........................................................................................................................................65 9.2.6 Channels......................................................................................................................................66 9.2.7 Using CDL to Capture Complex Behaviors................................................................................67 9.3 CDL AS A CHOREOGRAPHY EXPRESSION LANGUAGE FOR HL7 SOA INTEROPERABILITY PARADIGM ................73 9.3.1 PIM-Level Choreography............................................................................................................73 9.3.2 PSM-Level Choreography Tooling..............................................................................................73 9.3.3 Using CDL for Test Driven Interoperability...............................................................................74 9.3.4 Conclusion...................................................................................................................................74 10 APPENDIX A - FUTURE WORK ........................................................................................................74 10.1 REFINEMENT OF THE CDL EXPRESSION LANGUAGE INTO META-MODEL, DESIGN ARTIFACTS, AND RUN-TIME CONSTRUCTS. ................................................................................................................................................74 10.2 REPOSITORY OF RE-USABLE DYNAMIC ARTIFACTS.....................................................................................75 10.3 RESEARCH TO IMPROVE AND EXTEND CDL (E.G. TIE INTERFACE TO OPERATION, ALSO PARTICIPANT REQUIRED ATTRIBUTE OF INTERACTION?)..........................................................................................................................75 10.4 CHOREOGRAPHY ROLLBACKS, EXCEPTION HANDLING..................................................................................75 10.5 TRANSFORMABILITY BETWEEN INTEROPERABILITY PARADIGMS.......................................................................76
    • Healthcare Interoperability: A Service-Based Paradigm, Conformance Model, and HL7 Dynamic Model 1 Executive Summary The Service-oriented Interoperability Paradigm comprises methods for specifying and standardizing services, a dynamic model for detailing interactions between and among these services, and a conformance model. It is contextualized by the RM-ODP (RM – ODP, ISO/IEC IS 10746 | ITU-T X.900) analysis framework. This framework ultimately provides three benefits:  it provides a framework integrating standard services into local development efforts  it provides grounding for the methodology and its analytical underpinnings  it provides the framework for implementing the conformance model The paper is organized in a layered fashion: 1. The foundations of Service-Oriented Architectures (SOA), which describes the foundations of SOA, the SOA Interoperability Paradigm and its dynamic model, particularly as expressed through the use of the WS-I emerging standard of Choreography Description Language (CDL); 2. The Reference Model for Open Distributed Processing (RM-ODP), which describes an ISO standard analytical approach to specifying the architectures that support enterprise distributed processing, a context into which the authors believe HL7 clearly fits;. 3. Mapping of the SOA Interoperabliity Paradigm onto RM-ODP, including a step-by- step analysis that unifies work performed as part of a standardization process and locally as architects and engineers design systems. 4. Finally, the current state and future state of the SOA Interoperability Paradigm is explained. The future state includes the worked example using the methodology and the Interoperability Paradigm. The appendix includes thoughts on future work.
    • 1.1 History This effort arose in part from a “Birds of a Feather” meeting at the Atlanta HL7 Working Group Meeting, with members of SOA SIG, Templates SIG, InM, MnM, and ITS. The topic under discussion was the way that dynamic models were important in standardization overall, and that Service Oriented Architecture’s (SOA) technologies offered some promise of finding a fitting expression language for the dynamic model. During the meeting, several “principles” or “success criteria” were identified to assess the work. These are listed below (in no particular order): 1. Current artifacts can be interpreted into the new format/paradigm along a migration path that can be described to, and understood, straightforwardly by both existing and new users, & also supported by tools. 2. The technical and organizational processes around creating new-style artifacts are no harder than current practice, hopefully easier. 3. Additional value provided by the new way is worth the pain of learning a new way, migration, adopting tools, etc. 4. Results including delivered artifacts are better using the criteria: "Are you happy to implement this?" and "Do they work out in practice (including tooling)?", i.e. (in reverse order) from the inside (techies) and the outside (managers/evaluators).* Additionally, in the long run the focus must be on ease-of-use for those implementing systems using the standard as opposed to those developing it obviously without making the latter prohibitive. Also it should be noted that it is tempting to try to find an over- simplified solution to what is essentially a complex problem, and that the rigor (preciseness) of the specification mechanism is vital in achieving true interoperability. Finally, the INM and MNM committees within HL7 approved the SOA TC’s working to define the SOA Interoperability Paradigm and the related conformance statements. These latter artifacts were fundamental to any dynamic model, and needed to be addressed in parallel. 2 Introduction 2.1 Service-Oriented Solutions for Healthcare The approach outlined below borrows several concepts and ideas from the IT industry at large, as well as from other viewpoints within the HSSP scope. Several concepts bear mentioning at this point for orientation. Service-oriented solutions have three components: behavioral interfaces, semantic signifiers, and business-focused interactions (“choreographies”) of services. For any given solution, these three components are modeled and implemented in support of a particular business process. The resulting models and their realizations take different
    • shapes as they process through a methodology, but they adhere to certain common characteristics. The behavioral interfaces (“services”) themselves tend to abide by several principles that are more or less accepted by the industry:  The behavioral interface specifies one and only one part of a logical interaction. The service consumer is not modeled vis a vis by/in the interface, and is only realized at runtime.  Services are both explicit in their functionality and created within the context of an architecture, capturing efficiencies as well as offering reuse and composability.  The inner workings (i.e. implementation details) of the service are hidden from the consumer. The consumer depends purely on the interface behavior defined in the specification These principles allow behavioral interfaces to be contractually bound either to a specific client, a set of clients, other services, or to grouped sets of interactions, as will be demonstrated below. This contractual binding provides an essential loose coupling between the service itself and the service’s consumers. Some behavioral interfaces are defined in a top-down way, starting with the domain model. It makes sense, then, to see service structures exposing operations like “Create Lab Order” and “Notify of New Appointment.” Additionally, there are behavioral interfaces that are defined in more bottom-up fashion, such as HSSP’s Retrieve, Locate and Update Service (RLUS) and the Entity Identification Service (EIS). These latter two are examples of services that are being standardized through the HSSP Service Specification Framework (SSF), which defines work streams in HL7 and OMG for the functional and technical specification of services. For semantics, actual content models proliferate. However, HSSP has introduced a number of mechanisms, including semantic profiles and semantic signifiers to allow a loose coupling to be achieved between functional constructs and the payloads that are involved in the support of the business process. Semantic Signifiers are those sets of semantic structures expressed using some formalism that supports the operations in a behavioral interface. The Semantic Profile is the mechanism whereby semantic signifiers are constrained and decomposed to fit the business purpose of the service and subsequently bound to the individual functions. These allow functional consistency to be specified with localized information models, which when coupled with explicit service descriptions, increase interoperability. Along the same lines, a service-oriented approach to information modeling supports, if not requires a separation of concerns to be realized. Messaging models should separate business content from interaction support; interfaces should specify the functional semantics to support the larger business process, and both should be expressed as durable capabilities within a service-oriented architecture so that they may be leveraged by choreographies and orchestrations that capture the complex workflows and business processes in healthcare. Information and functionality that are not directly related to the business at hand should be left – as much as possible – to infrastructure and to the
    • platform itself. Message ID’s, acknowledgements, reliability references, and hard-coded endpoints are all things best left out a healthcare information model. Service-oriented Interactions, be they simple or complex, i.e. involving many services, leverage both the behavioral interfaces and their constituent semantic components. These grouped interactions have several generic names within the information technology industry, including orchestrations and choreographies. Of the two, choreography connotes a system-neutral, global view of system behavior, and so is desirable. Conceptually, choreographies embody several vital aspects that provide a foundation for the ideas expressed below:  Choreographies rely on service virtualization, only modeling those effects which are visible to all parties  Choreographies capture inter-system interactions from a global perspective (all services are equal)  Choreographies support logical dependencies and constraints on interactions, so that they can model control-flows and message correlations  Choreographies are modular, meaning that interactions described in a given choreography are re-usable by other choreographies In the separation of concerns between information, behavioral interfaces, and the interactions that leverage these capabilities, SOA provides an architectural framework that allows iterative and incremental model-driven methodologies to play their part in healthcare IT. In particular, it provides a needed level of abstraction that allows the dynamics of healthcare interactions to be captured, modeled, and implemented separately from similar efforts focused on either information or on behavior. It provides an appropriate pattern for semantic discovery through expressly defined interfaces, and allows those interfaces to maintain a level of granularity that is appropriate to the business context. Within the SOA Methodology outlined below, each artifact – information models, functional models, choreographies – is supported by model-driven architecture and design. Further, when full life cycle methodologies are implemented, these models tend to emerge naturally. Given the complexity of the problem, it is worthwhile to map the methodology and its analytical framework onto a “pure” framework as a reality check of its thoroughness and completeness. RM-ODP is such a framework. RM-ODP provides an established ISO standard as a technology- and domain-neutral framework to organize the relevant work streams and artifacts, as well as a pattern for conformance and development that is non-ambiguous and repeatable.
    • 3 RM-ODP 3.1 An Overview The Reference Model for Open Distributed Processing (RM-ODP) is an ISO standard (ISO/IEC IS 10746 | ITU-T X.900 ) that provides an analytical framework for specifying the architecture of a distributed computing environment. A detailed discussion of RM-ODP is beyond the scope of this paper. Readers with an interest can find more information, including the specification itself at http://www.rm-odp.net. RM-ODP was designed to meet the challenges of distributed computing, which the standard enumerates: • Remoteness: Components of a distributed system may be spread across space; interactions may be either local or remote. • Concurrency: Any component of a distributed system can execute in parallel with any other components. • Lack of global state: The global state of a distributed system cannot be precisely determined. • Partial failures: Any component of a distributed system may fail independently of any other components. • Asynchrony: Communication and processing activities are not driven by a single global clock. Related changes in a distributed system cannot be assumed to take place at a single instant. • Heterogeneity: There is no guarantee that components of a distributed system are built using the same technology and the set of various technologies will certainly change over time. Heterogeneity appears in many places: hardware, operating systems, communication networks and protocols, programming languages, applications, etc. • Autonomy: A distributed system can be spread over a number of autonomous management or control authorities, with no single point of control. The degree of autonomy specifies the extent to which processing resources and associated devices (printers, storage devices, graphical displays, audio devices, etc.) are under the control of separate organizational entities. • Evolution: During its working life, a distributed system generally has to face many changes which are motivated by technical progress enabling better performance at a better price, by strategic decisions about new goals, and by new types of applications. • Mobility: The sources of information, processing nodes, and users may be physically mobile. Programs and data may also be moved between nodes, e.g. in order to cope with physical mobility or to optimize performance. In addition, the standard notes the fact that architectures built using the RM-ODP framework will adhere to certain overarching principles and, in particular, are: • Open – Providing both portability (execution of components on different processing nodes without modification) and interworking (meaningful interactions between components, possibly residing in different systems).
    • • Integrated – Incorporating various systems and resources into a whole without costly ad-hoc developments. This may involve systems with different architectures, and different resources with different performance. Integration helps to deal with heterogeneity. • Flexible – Capable both of evolving and of accommodating the existence and continued operation of legacy systems. An open distributed system should be capable of facing run-time changes – for example, it should be capable of being dynamically reconfigured to accommodate changing circumstances. Flexibility helps to deal with mobility. • Modular – Allowing parts of a system to be autonomous, but interrelated. Modularity is the basis for flexibility. • Federatable– Allowing a system to be combined with systems from different administrative or technical domains to achieve a single objective. • Manageable – Allowing the resources of a system to be monitored, controlled and managed in order to support configuration, QOS and accounting policies. • Verifialbe with respect to Quality of Service(QOS) – Covering, for example, provision of timeliness, availability and reliability in the context of remote resources and interactions, together with provision of fault tolerance that allows the remainder of a distributed system to continue to operate in the event of failure of some part. Provision of fault tolerance (and of dependability in general) is necessary within large distributed systems where it is unlikely that all parts of the system will ever be operational simultaneously. • Secure – Ensuring that system facilities and data are protected against unauthorized access. Security requirements are made more difficult to meet by remoteness of interactions, and mobility of parts of the system and of the system users. • Transparent – Masking from applications the details and the differences in mechanisms used to overcome problems caused by distribution. This is a central requirement arising from the need to facilitate the construction of distributed applications. Aspects of distribution which should be masked (totally or partially) include: heterogeneity of supporting software and hardware, location and mobility of components, and mechanisms to achieve the required level for QOS in the face of failures (e.g. replication, migration, checkpointing, etc.). 3.2 The Five Viewpoints RM-ODP defines five “Viewpoints” that collectively define a given architecture specification.. These viewpoints are not hierarchical, i.e. they are not derived from each other. Rather, they each provide a particular perspective (which itself can be layered/hierarchical) of a complete system including its business context and, if desired, its technology binding. Collectively, the perspectives specify conformance points that form quality tests for the other viewpoints, a fact that underscores the ‘nearly independent’ relationship between the various perspectives.. Thus, RM-ODP-influenced work streams can exist in parallel and perspective-specific artifacts can be produced that have rigorous inter-relationships, but that don’t necessarily emerge linearly. This allows the 5 RM-ODP Viewpoints to have validity in a number of life cycle methodologies and
    • philosophies (e.g. the HSSP and other HL7-centric processes). The Five Viewpoints are as follows: Enterprise View: concerned with the purpose, scope and policies governing the activities of the specified system within the organization of which it is a part Information View: concerned with the kinds of information handled by the system and constraints on the use and interpretation of that information; Computational View: concerned with the functional decomposition of the system into a set of objects that interact at interfaces – enabling system distribution; Engineering View: concerned with the infrastructure required to support system distribution Technology View: concerned with the choice of technology to support system distribution Figure 1: The Five Viewpoints of RM-ODP Each viewpoint has a language it which its’ structure and semantics are specified. For example, the Computational Viewpoint discusses flows (interactions and their logical relationships), operations, and interfaces. The Engineering Viewpoint by contrast only discusses Interceptors, Nodes, and Channels. The table below enumerates the concepts that embody each viewpoint (from Part 3 of the standard). For more detail on the Viewpoints and their languages, the reader is asked to refer to Part 3 of the standard. Viewpoint RM-ODP Concept (Partial List) SOA Interoperability Paradigm Concept (Partial List) Enterprise Viewpoint -- roles played by the system; Roles -- activities undertaken by the Business Analysis, Interactions, system; Domain Analysis Model, Story Boards -- policy statements about the Service Portfolio Planning system, including those relating to environment contracts.
    • Information Viewpoint Invariant Schema Domain Analysis Model Static Schema Constrained Information Models Dynamic Schema Domain Analysis Model Computational Viewpoint Signal Interaction, Exchange Operation Functional Model for Service Announcement Dynamic Model (Sequences, logical constructs) Interrogation Dynamic Model (Sequences, logical constructs) Flow Choreography Signal interface Service Operation interface Service Stream interface Service Signal interface signature Messaging Model, Service Specification Operation interface signature Messaging Model, Service Specification Stream interface signature Messaging Model, Service Specification Engineering Viewpoint Capsule Service Implementation Channel PSM, WSDL, CDL Channel Stub PSM Binder PSM Interceptor Service Protocol object SOAP Binding within a PSM Communication interface WSDL, PSM Binding endpoint identifier PSM
    • Technology Viewpoint A technology specification defines -- a configuration of technology the choice of technology for an objects, and ODP system in terms of -- the interfaces between them. A technology specification -- expresses how the specifications for an ODP system are implemented; -- identifies specifications for technology relevant to the construction of ODP systems; -- provides a taxonomy for such specifications; -- specifies the information required from implementors to support testing. -- consists of statements that technology objects are instances of named implementable standards. t 4 The HSSP/HL7 SOA TC’s “SOA Interoperability Paradigm” The Methodology for the SOA Interoperability Paradigm described below can be embedded in/mapped onto the five RM-ODP Viewpoints to both separate work threads and to insure that appropriate bindings exist between those threads’ artifacts. There are several benefits from this approach:  It allows subject experts in each Viewpoint to fully specify the behavior of the distributed healthcare system using differing methodologies without encroaching unnecessarily on other viewpoints, though the work streams themselves may cross. For example, analysts who work within the Information Viewpoint do so during both the Business Analysis and Functional Specification work streams.  Conformance statements emerge from each Viewpoint that ultimately form Contracts and Quality of Service (QoS) statements in the engineering and technical realizations of the system  It allows for conceptual models to be part of a congruent architectural process and to drive solution architectures  It emphasizes the concurrent nature of the SOA methodology and processes
    •  It provides a framework for the creation of service (behavioral interface) standards to coexist beside and interact with artifacts produced through a rigorous SOA-focused methodology The following section describes the SOA Interoperability Paradigm in terms of the concurrent business processes and sets of artifacts, including models and choreographies, that are produced.. 4.1 Overview of the SOA Interoperability Paradigm (the HSSP Process) The following diagram represents the SOA Interoperability Paradigm’s Development Process. This is structured as a set of mostly parallel activities whose artifacts may be derived from each other. Figure 2: Activities in the Interoperability Paradigm's Process Note that for Service Specification, HL7’s activities as a Standards Development Organization are intended to end with, at the most, the Platform Independent Model (PIM). Through the HSSP Service Specification Framework, standardization may continue in other organizations such as the Object Management Group (OMG). However, the activities are expressed here both for completeness and to demonstrate where and how the standardization process melds with further service specification.
    • In the following diagram, the above activities are broken out into their component parts. Orange objects are artifacts produced from the various steps. Blue objects are final specifications and milestones. Where there is a computational transformation available to derive one set of artifacts from another in a previous step, the linkage is shown as a control flow rather than a dependency. Figure 3: SOA Methodology – Including Process (pale), artifacts (gold), models (blue), and bindings
    • 4.2 The SOA Interoperability Paradigm’s Choreography Description The methodology outlined above describes several artifacts that are either balloted in their own right or from which balloted artifacts could be derived. Service specifications are covered elsewhere within the SOA TC literature (see http://hssp.wikispaces.com), and information and content is intended to surface from domain experts residing in SDOs, including HL7. The choreographies discussed in the process above are a means of expressing the dynamics of healthcare interactions, thus forming a model for capturing the inter-service (and inter-system) behavior of healthcare interactions. When combined with an industry accepted expression language like CDL, choreographies can become both a fundamental part of a development strategy as well as a balloted artifact. An excellent summary of CDL is available at (http://ww.bptrends.com/publicationfiles/03%2D05%20WP%20WS%2DCDL%20Barros %20et%20al%2Epdf). If you’re pointing to this overview, why is the next section entitled CDL Overview? The WS specification for CDL is also available at (http://www.w3.org/TR/2005/CR-ws- cdl-10-20051109/). 4.2.1 CDL – An overview The Web Service Choreography Description Language (WS-CDL or simply CDL) is an emerging industry standard for modeling and specifying choreographies. It is an XML- based language that describes business-driven, inter-system collaboration based on observable behaviors. Its current status is as a candidate recommendation produced by the W3C Working group as part of the Web Services Activity. CDL embodies important concepts in distributed systems interactions, including the loose binding of roles and their behaviors to real-world systems, atomic interaction support, logical work flows, and global error handling. CDL and its supporting tooling will be introduced as a rigorous means of expressing the dynamics of healthcare interactions.
    • Figure 4: WS-CDL package format (from bpTrends.com) 4.2.2 CDL Tooling CDL is supported by an open source project, pi4SOA. It is available through SourceForge [http://sourceforge.net/projects/pi4soa]. pi4SOA offers an extension to CDL as well as a visual editor to manage and manipulate the choreography.
    • Figure 5: Pi4SOA allows visual editing of complex interoperability behaviors. This image shows the workflow for entering a lab order (from the appendices). A lab order is not completed until a final result is returned, in spite of arbitrary intermediate returns Choreographies may or may not have logical control points within them, but the visual editor shows that complex behaviors may be modeled and rigorously specified. These models use globally visible logical elements, allowing choreographies to leverage the contractual nature of service-oriented behavioral interfaces. 5 Mapping the SOA Interoperability Paradigm to the Five Viewpoints When RM-ODP is profiled using the SOA Interoperability Paradigm, a clear framework emerges for both specification and standardization of services, and the relationship between the two. This framework includes a pattern for conformance assertions that aligns with the RM-ODP notions of conformance (see Part 2 of the Standard). 5.1 The Specification Methodology Looked at in the context of RM-ODP, the SOA Interoperability Paradigm’s process flows can be seen to cross several different Viewpoints.
    • Enterprise View HSSP SOA Information View Methodology HSSP SOA Artifacts Computational View Engineering View Technology View Figure 6: The HSSP SOA Methodology and the five RM-ODP Viewpoints The Business Analysis (Enterprise Viewpoint) gives definition and scope to the Information-centric components (Information Viewpoint) and the Functional components (Computational Viewpoint). Additionally, a number of different artifacts emerge that both enable the architecture and provide conformance points for quality testing.
    • Roles Behaviors Enterprise View Relationships Invariant Models Static Models Information View HSSP SOA Dynamic Models Methodology Message Spec Comm Logic Computational View Interactions / Operations Contracts / QOS WSDL Schema Engineering View Channels Technology View Figure 7: Sample Artifacts from the SOA Methodology in the RM-ODP viewpoints 5.2 The Work Streams It should be emphasized that these viewpoints have activities and artifacts that may spread across the SOA Methodology. The Enterprise Viewpoint, for example, does not coincide completely with business analysis, but combines with elements from the Information Viewpoint to provide the high-level description that leads to architectures and designs. The Enterprise Viewpoint provides the framework and languge to clearly express the objectives, business goals, and policies that pertain to a given system or service. Note that the work streams for standardization (within an HL7 and OMG context) are not as comprehensive as they would be locally for service specification. Specifically, HL7 would never implement artifacts or engage in processes from the Engineering or Technology Viewpoints. However, these viewpoints are included here to support both the efficacy of the process overall and to demonstrate the intersection between standardization and specification.
    • Figure 8: The Enterprise Viewpoint activities and artifacts Elements of the Information Viewpoint are part of the business analysis process, but taken as a set of activities, the informational components (as defined via the RM-ODP Information Viewpoint) exist past that defined activity. The Information Viewpoint is primarily concerned with defining concepts for the specification of meaning of information stored within and manipulated by the distributed system. The concepts used in the Information Viewpoint include dynamic, static, and invariant schemas. Figure 9: Activities and Artifacts from the Information Viewpoint
    • Defined in part by models and artifacts from the Enterprise and Information Viewpoints, the Computation Viewpoint is primarily concerned with the functional decomposition of the system into objects that interact through well-defined interfaces. It is concerned with the signature of the interface and the interactions that use the interfaces. Note the “Create Messaging Models” activity – this exists in the Computation Viewpoint because it is the functional decomposition of the Information Models using the behavioral interfaces as the denominator. Figure 10: The processes and artifacts proceeding from the Computational Viewpoint The Engineering Viewpoint is focused on enabling the interactions expressed in the Computational Viewpoint and adhering to the quality of service and contractual constraints expressed in other viewpoints. Note that the Engineering Viewpoint is included here for both completeness and to demonstrate the completed mapping of the SOA Interoperability Paradigm process onto the RM-ODP analysis framework. In application, local service specification will certainly include elements from the engineering viewpoint. However, it is really out of scope for HL7 as an SDO to create artifacts or engage in activities from the Engineering Viewpoint.
    • Figure 11: The Engineering Viewpoint's activities and artifacts Finally, the Technological Viewpoint is concerned with describing the system in terms of configurations of technology objects representing the hardware and software components chosen during the technology selection. It also includes a representation of the testable conformance statements that emerge from the other viewpoints (which interactions are valid for example). Note that all processes, artifacts, and models that emerge from the Technology Viewpoint are representative and are included only to demonstrate the the complete implementation of the methodology.
    • Figure 12: A Representative selection of processes and artifacts that would be in Technology Viewpoint 5.3 Choreographies and RM-ODP As noted above, business process modeling, and more particularly choreographies depicted using CDL, play a large role in the SOA Methodology. After all, it is useless to talk about defining and exposing capabilities without discussing the means by which they might be employed. As a concept, choreographies encompass the actual interactions between and among the service endpoints that embody the technical (but not technology-specific) representation (Engineering VP) of business workflow. As such, they offer a simple means to capture business drivers and to preserve them for quality checks later in the development process. In this capacity, choreography is an essential piece to building distributed applications and architectures. Choosing CDL as the expression language for dynamics within the SOA paradigm offers several advantages in addition to the conceptual points, tying together several ODP viewpoints in a single structure.
    • Roles Behaviors Enterprise View Relationships Choreography Description HSSP SOA Static Models Information View Methodology Dynamic Models Message Spec Interactions / Ops Comm Logic Computational View Contracts / QOS WSDL Interface URIs Engineering View Schema Channels Conformance Profile Technology View Choreography Engine Deployment Profiles Technology Stack Figure 13: Choreography Descriptions using CDL preserve artifacts from four of the five RM-OPD Viewpoints. CDL captures roles, their behaviors, and their relationships in unambiguous terms. It realizes those relationships in interactions that are expressed in a variety of message exchange patterns, and ties those exchanges to information. It allows complex business logic to be shared by all systems participating in a choreography, providing a global view to behavior. These points and others make CDL a good choice for expressing inter-system behaviors, if only for specification. However, there is the added benefit of CDL having a run time expression and a set of tooling that encourages the Engineering Viewpoint. 5.4 Standardization and Conformance The HSSP Service Specification Framework (SSF) provides for the standardization of behavioral interfaces using functional and informational profiling. These standards pass through two stages, first as a Service Functional Model (SFM). This SFM forms the foundation for an RFP to be published through the Object Management Group (OMG). The response to this RFP becomes the technical specification around the for the service.
    • Enterprise View s e l i f o r P e c n a m r o f n o C M F S Information View <<Standardization>> HSSP SOA Methodology o t f p S l a i n h c e T Computational View G M O Engineering View Technology View Figure 14: The HSSP SOA Methodology, i.e. the Service Specification Framework, is used to develop Functional and Technical Specifications While the SSF provides an open process to allow business drivers to become technical specifications within the healthcare industry, the production of the SFM and the Technical Specification themselves follow the SOA process outlined above. Within the Enterprise Viewpoint., for example, the SOA Methodology creates a set of storyboards, activity diagrams, and use cases that become Sections 3 and 7 of the SFM. Similarly, Semantic Signifiers and Functional Profiles emerge from the Information and Computational Viewpoints respectively, which in turn become part of the SFM (the essential equivalent of the conceptual model). As detailed in the HSSP SSF, the SFM serves as a starting point for the Technical Specification, which is broken down into platform independent models (PIM) and platform specific models (PSM).
    • SFM: Metadata Section 6 Usage Context SFM: Enterprise View Provenance Section 3 SFM: Semantic Section 2 Signifiers Information View <<Standardization>> SFM: HSSP SOA Section 6 Methodology SFM: SFM: SFM: Functional Section 3 Section 6 Section 7 Profile Business SFM: Computational View Process Section 5 Model TS: PIM TS: PSM Engineering View Technology View Figure 15: The SOA Methodology applied to Standardization produces points of conformance (maroon), key sections of the SFM (blue), and portions of the Technical Specification (green) The conformance points (in maroon) become part of an HSSP Conformance Profile. This becomes part of the Technology Specification (in the Technology Viewpoint) as it identifies testable conformance points and provides the basis for evaluating Quality of Service provided by the implementation.
    • Enterprise View <<Standardization>> HSSP SOA Information View Methodology Computational View Engineering View Semantic Functional Metadata Signifiers Profile Technology View Provenance Conformance Profile Usage Context Figure 16: The Conformance Profile as part of the Technology Specification When combined with the artifacts that emerge from the SOA Methodology, these standardized components (the SFM, the Technical specification, and the conformance points) actually provide structural components that can replace artifacts that would otherwise have to be discovered through local analytical and development processes.
    • Roles Behaviors Enterprise View Relationships Choreography Description HSSP SOA Semantic Sigs Information View Methodology Message Spec Interactions / Ops Comm Logic Computational View Contracts / QOS WSDL Interface URIs Engineering View Schema Channels Conformance Profile Technology View Deployment Profiles Choreography Engine Technology Stack Figure 17: Components from the SFM (blue), the Technical Specification (bright green), and the Conformance Profile (maroon) can support or replace artifacts that come from a localized development process. The Conformance Profile in the technology viewpoint provides testable quality measures that endure from other viewpoints and work threads. 5.4.1 Using CDL to Capture Conformance Statements See other relevant HSSP materials regarding the structure and makeup of conformance statements (http://hssp-infrastructure.wikispaces.com/). CDL captures many of the HSSP conformance concepts within its structures. Profiled correctly, CDL can create a normative structure that would facilitate the use of:  Functional Profiles – As behaviors referenced in roles and called during interactions  Semantic Signifiers - As Information Types  Business Process Model – The CDL sequences, interactions, work units, and other logical structures form the basis for making assertions about how behavioral interfaces are intended to be used in a particular business context  Provenance – Sufficiently abstracted by using CDL roles and relationships
    • In sum, CDL provides the capability (as yet untested) to bind in a late fashion the real world participants in a choreography with the abstracted concepts and behaviors that make up most of the conformance assertions that a SOA requires. 6 SOA Interoperability Paradigm Methodology – Detail, Analysis, and RM-ODP Correspondence Where appropriate, the binding elements that connect one viewpoint’s artifacts with another’s will be called out as part of the methodology. The overall pattern of development will be enumerated, and this pattern will form a consistent framework for organizing and aggregating standards and emergent artifacts into system specifications. 6.1 Business Analysis (Enterprise and Information Viewpoints) This workstream produces the business-focused definition of the service or workflow. It is not explicitly laid out in the diagram above, but serves as an input to the Functional Specification activities. The intent of this set of activities is to briefly define a business context for the subsequent work, standards-based or otherwise. It is not intended to be exhaustive, but should provide enough business context in order to be confident that the defined solution will cover the main business needs. Step Description Viewpoint Artifacts Produced 1) Service Part of HSSP Roadmap / This is part of Service Portfolio Plan. Portfolio Reference Architecture. the Enterprise List of Business and Planning Define the overall structure of Viewpoint Infrastructure Services a business area and the services needed. 2) Define Describe business problem Enterprise Business problem business and identify the set of statement, objectives, problem requirements to be included in measurable goals. the scope. 3) Business Describe the (sample) Enterprise Business Process Process Business Process(es). Since models (BPMN/UML Analysis Services are inherently Activity Diagrams), intended for reuse across Business Events, multiple processes, from a Business Roles, standards development Scenarios/Storyboards perspective, this is only to provide sufficient context. This should NOT identify specific system roles, since this may artificially constrain the architecture choices.
    • Step Description Viewpoint Artifacts Produced 4) Business Define main information Information Domain Analysis Informati requirements in business Model on terms. Analysis 5) Business Define the scope of the Enterprise Initial Business Service Capability service and the overall name Definition Definition and description. Where possible, consider wider needs in order to promote reusability and existence of other services. Can either be based on a Focal (Business) Object (which may show on the Business Process Diagram) or to carry our one of the specific business activities. 6.2 System Requirements and Functional Specification (Enterprise, Information, Computational Viewpoints) This stage produces the requirements and functional specification of the service. From the standpoint of RM-ODP, the Conceptual Model, which is defined herein, joins the Enterprise, Information, and the Computational Viewpoints, taking artifacts from each. Step Description Viewpoint Artifacts Produced 6) Information The Object definitions may Information Domain Analysis already be represented in Domain Information Model Models (e.g. HL7 Domain (Static Models, Models). Review the Domain Dynamic Models, Models looking for those classes Invariant Models) of interest. If the object don’t appear at all or they are incomplete, the Domain Models should be updated. In the case of business functional services, it would be expected that the dynamic model would include states of the business focal objects. 7) Define Map the identified requirements Computat- Capability Functional to the responsibilities and ional Portfolio: Capabilities interfaces of the Service. Fully - Service describe the capabilities in
    • Step Description Viewpoint Artifacts Produced business terms (not as formal - Interface “operations”). Define features as - Capability and either required or optional. Behavior Define extensible features and mechanisms for extensions. In order to determine any behavior required from other services, identify dependencies on interfaces and notifications. Perform gap analysis with current service portfolio 8) Define Based on the Business Process Computat- UML Behavior: Outline description, and identified ional - Actors Behavioral Business Services, identify the Processes scope of system interactions and - Use Cases and the main actors involved (usually - Choreography / Workflow in the form of Use Cases). Collaboration The interactions can then be (represented as a outlined in terms of an overall combination of “choreography”, which provides sequence, activity the context for defining services and state transition and messages, and also diagrams) dependencies on other services, where appropriate. For example, “Laboratory Order”, “Laboratory Observation”, “Person”, “Patient” may be either exposed or used by a Service. To adhere to this level of design (pre-PIM), it should be noted that the desired CDL expression would not contain any optional elements, such as “interface” attributes. Regardless, because of the constraints of CDL, there will be (at present) something of an overlap, but specification can still occur 9) Produce Produce a business level logical / Computat- Conceptual Model Functional functional Service Specifications. ional, - aka HSSP Specification This pulls together the business Enterprise, Service Functional context and requirements and References Model (SFM)
    • Step Description Viewpoint Artifacts Produced functional descriptions into a the complete business level Information description of the Service Viewpoints capabilities. The HSSP SFM artifacts Template is used for this document. In addition to realizations of the Enterprise and Information Viewpoints, the Computational Viewpoint adds functions and operations that support the overall business focus. 6.3 Platform Independent Models (PIMs) (Information and Computational Viewpoints) Within the HSSP Standardization process, the Service Specification Framework (SSF), an RFP would be produced and the RFP response submitters would carry out the remainder of the process. As noted below, this process would be expected to support subsequent development efforts. This stage of methodology serves an important function, namely producing technology- indpendent specifications. This gives the notion of service more validity, since a service defined by an appropriate PIM can find realization by a number of technological platforms, for example JMS or Web Services. At the same time, PIM representations of capabilities within an organization serve as the first (and perhaps most important) testable layer for conformance to standards. A PIM would define, for example, the functional profiles and the semantic signifiers being employed, and would provide the real business context that should align with the stated business context for the service standard. This stage defines the initial system solution, but still at a platform-independent level. Step Description Viewpoint Artifacts Produced 1) Define System Describe the choreography Computational CDL Choreography: Choreography in detail using the CDL (Interaction, Role, (Service constructs, with associated Participant, Interaction and sequence or activity Information Type, Logical diagrams. Relationship, Information Activity) - Refine the interaction Flows) (Graphically solution, for example the modeled as deployment and interaction Sequence, style. Consider and define Collaboration, State logical constraints on Transitions) centralization vs. federation and interaction patterns. (Should be business oriented interactions that surface across system
    • Step Description Viewpoint Artifacts Produced boundaries – not e.g. based on system limitations or performance) 2) Define System Refine the responsibilities Computational Behavioral Interface Capabilities of the components, identify Specification: (Behavioral possible extension needs - Service Interfaces) and needed security features. - Interface Business capabilities are - Operation specified as one or more - Behavior Behaviors. Specification (state The interface details should transitions, pre- be unambiguous, well- conditions, post- defined interfaces (inputs conditions, and outputs of service invariants, applied operations + their functional Templates) constraints and generic - Functional Profiles format) Define features as either required or optional. Refine extensible features and mechanisms for extensions. All business level exceptions should be identified and described for each operation. Functional Profiles of Services should be invoked here to further specify behavior of new and existing services 3) Information Information contents and Information Semantic Signifiers Design semantics (messages) are (Message specified and are definitions, decomposed. For HL7 based Templates etc) models, this will use mechanisms such as CIM, CMET, Message Profiles, and Templates.
    • Step Description Viewpoint Artifacts Produced HSSP SSF defines the Semantic Profile as the means of binding operations to these information models (semantic signifiers) 4) Produce Produce a Platform Computational Platform Platform Independent Model / and Independent Model / Independent Technical Specification. Information Specification (PIM) Model / This provides a detailed Specification level platform independent representation of the service functionality. This is one of the requirements in all HSSP RFPs. 6.4 Platform Specific Model (PSM) (Engineering Viewpoint) The Platform Specific Model is generally out of scope for HSSP Services in the HL7 community as a Standards Development Organization. However, it is well within the scope of providing guidance for creating workable implementations. Step Description Viewpoints Artifacts Produced 1) Platform Refine the required technical Engineering selection capabilities of the solution (XML, and link them to available SOAP, technologies, including BPEL, and necessary routing, protocol WSDL are mediation and other assumed in transformation mechanisms. the diagram) Consider the suitable (Note: this is technology and interfacing slightly options of participating different than systems or existing solutions Technology which are to be used. selection) Select set of technologies to support the service (transport (messaging, enveloping, reliability etc.), interface (functionality, information), security. 2) Messaging Refine the Message Analysis Engineering Message Profiles, Models models (RMIMs, CIMs, Message Models,
    • Step Description Viewpoints Artifacts Produced CAMs, Domain profiles, etc) Schema, sample to actual messaging models messages by tying domain concepts to Semantic Signifiers. implementation considerations (Error If appropriate, Handling, metadata, eg). Be register message sure not to replicate models within the infrastructure that will be deployed provided by the technology architecture implementation (reliability components, for example). Bind the message schema to operations using semantic profiles 3) Produce Identify technology-specific Engineering Interface Contract Platform services – Technology VP, BPEL Endpoints Specific interfaces, operations and Model (PSM) parameters; specify their Message (e.g. responsibilities. SOAP) Headers, Message Payload Refine functional Schema specification with technology-specific features System (e.g. simple or complex orchestration and types, messaging style such Templates as data-oriented or rpc or Fully elaborated process-oriented) choreography (CDL) and Implementation Choreography (e.g. BPEL). 4) Produce Document implementation- N/A Implementation Release specific features of the Guide Documentatio service, infrastructure etc, n/ extensibility options etc. Implementati on Guide
    • 7 The SOA Interoperability Paradigm and HL7 – Current State and Efforts 7.1 Tying the SOA Interoperability Paradigm to the Messaging Paradigm The following diagram represents the full methodology for the SOA Interoperability Paradigm as represented in the SOA4HL7 Informative Guide published as part of the HL7 normative standard. Note that this methodology has been since refined in this document, but is close enough to still warrant inclusion.
    • When considering application of the SOA Interoperability Paradigm methodology to the Messaging Interoperability Paradigm, some of the information or functions that are explicit in the Messaging Dynamic Model would be handled either implicitly in the Operation, by SOA infrastructure, or in a few cases by a top-level construct like a choreography itself. In all cases, the intent is to be able to derive the messaging equivalent if so desired. Specifically:
    •  Sequence Number Protocol would be handled by infrastructure. Currently OASIS WS-RM (also being incorporated into WS-I Secure Reliability Profile) This would become an implementation / configuration choice. (Note OASIS is working on a new specification, WS-RX which brings together WS-RM with WS- Reliability).  Trigger Event is not defined explicitly in the solution in the SOA “solution” model unless an Event Driven / Pub Sub solution was being designed, although Business Events would often be identified as part of business analysis. This would be handled in different ways. In order of preference: 1) If a difference in Trigger Event changed the behavior of the receiver (when all other factors are the same), then different operations would be defined for the separate behaviors – not necessarily for each event (since receiver logic is different, then separate receiver code to handle it would be needed anyway) 2) If the requirement is for the receiver to explicitly persist information on the trigger event, then this is part of the business transaction and hence part of the service payload and would be modeled as such. The (Control-Act – body) explicit separation would not be normally modeled that way in Services, however this is really semantics in that the information would still be there and hence derivable. 3) Handle using infrastructure. This would mean currently - Define an explicit SOAP Header and pass from the SOAP infrastructure to the application. This may be appropriate in scenarios where a service and messaging implementation are tied together within an end-to-end implementation.  Application Role: We understand (from the MDF) that the original intent was to provide a means to enable conformance claims to be grouped together. In this case, it would simply be a set of conformance profiles against one or more Services. This would involve a simple mapping exercise.  Interactions (and Conversations). This topic is somewhat in flux in the messaging solution and may change to some degree in Wrappers R2. Since one of the primary intents with Service Interfaces is to provide reusability and only one side of the Interaction is defined explicitly, there is no specific need to identify or codify Interaction IDs. However, it is usual for interactions to be modeled as part of specifying the service and more so if the implementation is to be orchestrated or choreographed. Note also that the services concept of “interaction” usually means a set of two or more related messages, e.g. both the request and the response in a two way pattern. Alternatives for Interaction ID are similar to those for Trigger Events. (in order of preference): 1) If a difference in Interaction changed the behavior of the receiver (when all other factors are the same), then different operations would be defined for the separate behaviors – not necessarily for each interaction (since receiver logic is different, then separate receiver code to handle it would be needed anyway) 2) If the requirement is for the receiver to explicitly persist information on the interaction, then this is part of the business transaction and hence part of the
    • service payload and would be modeled as such. The (Control-Act – body) explicit separation would not be normally modeled that way in Services, however this is really semantics in that the information would still be there and hence derivable. 3) Handle using infrastructure. This would mean currently - Define an explicit SOAP Header and pass from the SOAP infrastructure to the application. This may be appropriate in scenarios where a service and messaging implementation are tied together within an end-to-end implementation. Note also that Appendix A contains an excerpt from the earlier SOA4HL7 architecture work which carried out a partial mapping from the existing Transmission Wrapper to web services. This analysis may or may not apply in a fully elaborated SOA. For the purposes of the Messaging Interoperability Paradigm, this could also provide some further drill down rationale, although this work was not fully completed at the time. 7.2 Mapping to V3 using the SOA4HL7 Architecture For the purposes of enabling transformations, we will need to be able to define a mapping between the architecture (SOA) and the V3 infrastructures. Each class from the MCCI infrastructure model is considered in turn. The entry point is through the “Message” class. The ControlAct and Query infrastructures are not covered by this analysis. The position taken is that these should used as defined in the current standard or left out entirely. If being used, the infrastructure must treat these structures as the rest of the business payload. Notes: Extension headers for WS-Addressing are mentioned below. WS-Addressing provides “reference parameters” and “metadata” extension headers, plus a generic extension mechanism. These would need further investigation before defining which ones to use in which circumstances. A number of items are identified as “if required” in the descriptions below (e.g. Place,id, Organization.id etc). In general, most of these do not seem relevant within SOA. If specific circumstances did require them, then a mechanism is identified. Most of these could appear in the extension headers referenced above. They would be populated by the adapter based on configuration or look up from a configuration file for the Device, Location or Organization. 7.2.1 Request Message items Message Class - Mandatory Items:
    • Transmission SOA Comments Wrapper Item Message ID WS-Addressing messageId WS-Addressing message id is globally unique other than re- transmission Creation time Use WS-Security Timestamp WS-Security Timestamp is defined in WS-Security as the time that the infoset was serialized for transmission.. Interaction ID Derive from Operation Processing Code N/A May be an issue in messaging paradigm. This is a function of the environment, not service call level Processing N/A May be an issue in messaging Mode Code paradigm. This is a function of the environment, not service call level Accept Ack Inherent in operation or This is rarely (ever?) an instance Code controlled by process level selection, i.e. should be at choreography contract level Message Class - Optional Items: Transmission SOA Comments Wrapper Item Security Text WS-Security and associated This is unspecified in current HL7 specifications documentation Version Code Derive from Service Version Implied by version of service. Profile ID Inherent in Operation Should be inherent in operation definition behavior definition. Sequence WS-ReliableMessaging WS-RM operates at a higher grain Number Sequence Number level (all interactions between two endpoints). I do not believe anything additional is needed. Attachment Text SOAP Attachment
    • A message has exactly 1 Sender and 1 Receiver. Each will be attached to 1 or more Device classes. Sender Class: Transmission SOA Comments Wrapper Item typeCode N/A Just identifies the class as a Sender (mand) telecom (opt) N/A Network addresses are handled by Registry and infrastructure. This is/should be opaque in SOA Receiver Class: Transmission SOA Comments Wrapper Item typeCode N/A Just identifies the class as a Receiver (mand) telecom (opt) N/A Network addresses are handled by Registry and infrastructure. This is/should be opaque in SOA Device Class - Mandatory Items: Transmission SOA Comments Wrapper Item classCode N/A Just identifies the class as a Device Id WS-Addressing From header. Infrastructure may add name qualifier to ensure uniqueness in the WS-Addressing header. May also use in security header if principal identified at this level. Device Class - Optional Items:
    • Transmission Wrapper SOA Comments Item Name N/A This is application metadata that ideally would be looked up (could use WS- from a metadata or security Addressing extensions if system using the id if needed. necessary) Otherwise the infrastructure can retrieve information from configuration files and include in the message. Desc N/A As for “name” (could use WS- Addressing extensions if necessary) existenceTime Probably N/A usage unclear Telecom N/A Network addresses are handled by Registry and infrastructure. This is/should be opaque in SOA manaufacturerModelName N/A As for “name” (could use WS- Addressing extensions if necessary) softwareName N/A As for “name” (could use WS- Addressing extensions if necessary) Each Device may have zero or 1 LocatedEntity Class which in turn has zero or 1 Place Class LocatedEntity and Place Classes (all Place except first item): Transmission Wrapper SOA Comments Item LocatedEntity: N/A Just identifies the class as a Located Entity classCode (mand)
    • Transmission Wrapper SOA Comments Item classCode (mand) N/A Just identifies the class as a Place determinerCode N/A Identifies place as an “instance” (mand) in the model. id (mand) Can use WS-Addressing extensions name (opt) Can be derived from id This is application metadata that ideally would be looked up from (could use WS-Addressing a metadata or security system extensions if necessary) using the id if needed. Otherwise the infrastructure can retrieve information from configuration files and include in the message. telecom (opt) N/A Network addresses are handled by Registry and infrastructure. This is/should be opaque in SOA Each Device may also have zero or 1 Agent Class which in turn has zero or 1 Organization Class (the Organization Class also has an optional associated CMET (R_NotificationParty) Agent and Organization Classes (all Organization except first item): Transmission Wrapper SOA Comments Item Agent:classCode N/A Just identifies the class as an (mand) Agent classCode (mand) N/A Just identifies the class as an Organization determinerCode N/A Identifies organization as an (mand) “instance” in the model. id (mand) Can use WS-Addressing extensions name (opt) Can be derived from id This is application metadata that ideally would be looked up from (could use WS-Addressing a metadata or security system extensions if necessary) using the id if needed. Otherwise
    • Transmission Wrapper SOA Comments Item the infrastructure can retrieve information from configuration files and include in the message. telecom (opt) N/A Network addresses are handled by Registry and infrastructure. This is/should be opaque in SOA Each Message may have zero or more RespondTo classes, each with 1 or more EntityRsp classes. RespondTo Class: Transmission Wrapper SOA Comments Item typeCode (mand) N/A Just identifies the class as RespondTo telecom (opt) N/A Network addresses are handled by Registry and infrastructure. This is/should be opaque in SOA EntityRsp Class: Transmission Wrapper SOA Comments Item classCode (mand) N/A Just identifies the class as an Organization determinerCode N/A Identifies EntityRsp as an (mand) “instance” in the model. id (mand) WS-Addressing “ReplyTo” name (opt) Can be derived from id This is application metadata that ideally would be looked up from (could use WS-Addressing a metadata or security system extensions if necessary) using the id if needed. Otherwise the infrastructure can retrieve information from configuration files and include in the message.
    • Transmission Wrapper SOA Comments Item telecom (opt) N/A Network addresses are handled by Registry and infrastructure. This is/should be opaque in SOA Each Message may have zero or more AttentionLine classes. AttentionLine Class: Transmission Wrapper SOA Comments Item keyWordText (opt) WS-Addressing extension These items are included to allow Headers for body items to be put in the header for content based routing. These can be translated directly into headers used in WS- Addressing if needed. value (opt) WS-Addressing extension These items are included to allow Headers for body items to be put in the header for content based routing. These can be translated directly into headers used in WS- Addressing if needed. 7.2.2 Response Message items The Message may have zero to many Acknowledgment classes Acknowledgment Class (only typeCode is Mandatory): Transmission Wrapper Item SOA Comments typeCode Derive from SOAP A mapping would need to be response and/or transport done (e.g. HTTP OK etc) expectedSequenceNumber use WS- ReliableMessaging messageWaitingNumber N/A
    • Transmission Wrapper Item SOA Comments messageWaitingPriorityCode N/A Each Acknowledgement has one TargetMessage (which contains solely the ID of the acknowledged message) and may have zero to many AcknowledgmentDetail classes (contain error information) TargetMessage Class: Transmission Wrapper SOA Comments Item Id WS-Addressing RelatesTo element AcknowledgmentDetail Class (only typeCode is Mandatory): Transmission Wrapper SOA Comments Item typeCode Use SOAP Fault May be worth defining an explicit structure for the Detail element to carry this information. Code Use SOAP Fault As above Text Use SOAP Fault As above Location Use SOAP Fault As above 8 The SOA Interoperability Paradigm and HL7 – Future State This follows the outlined process in Section 4.1 above and keeps the stages separate and presents the information in a waterfall manner. In reality, there could be iterations and work streams that might be delineated by the RM-ODP Viewpoints. This would likely lead to some compressing of the stages. This example uses only UML and does not include the CDL representations. Section discusses the use of CDL and demonstrates the use of CDL as applied to parts of this example.
    • 8.1 Business Analysis The intent of this set of activities is to briefly define a set of business context for the standards work. It is not intended to be exhaustive, but should provide sufficient business context in order to be confident that the defined solution will cover the main business needs. 8.1.1 Assumptions We will assume that systems exist for POE, Patient Admitting, and encounter management. To varying degrees, the systems are outside the scope of this analysis, though certain capabilities are assumed to exist through exposed interfaces. In the case of encounter management, no capabilities are utilized or enumerated, as they are orthogonal to the stated business case. Nevertheless, this absence could be remedied in future versions of this paper. 8.1.2 Service Portfolio Planning Really beyond the scope of this paper, but we will assume that the following existing or candidate services may have been identified: Entity Identification, Order Management, Laboratory Management. 8.1.3 Business Process Analysis Below is a partial description of a representative business process. Scenario (partial): Patient shows up at clinic / hospital (walk in). Does not know Member number. Registration clerk looks up Patient Identifier using e.g. name, date of birth. Patient then sees Provider, who examines the patient and orders a Lab Test with an external Lab. (The Lab Test is carried out – out of scope. However, at the Lab the Patient again does not have an ID and this is looked up / created within the Lab, which uses a separate set of IDs itself to manage its information internally. The Patient ID is established and cross referenced against the ID supplied by the Hospital (using EIS interfaces in a peer-to-peer fashion). A notification and the Test Result are returned to the Provider. (Subsequent steps out of scope). Variations: Partial result sent, Correct sent result (not shown in diagram below). Business Roles (partial): Patient, Registration Clerk, Provider, (External) Laboratory. Business Process Diagram A representation of this business process is given below as a UML2 Activity Diagram. This is simplified and leaves out several potential steps, but should be sufficient for the purposes of this exercise. Note also at this level that the actual system roles are not yet depicted in order not to prematurely constrain architecture choices1. 1 One example of this is that the Lab Order could be fired directly from the Clinician desktop / portal with a copy sent to the HIS, or basic details could be entered into the HIS which would then generate the order for the external lab system. Such architectural decisions would depend on existing service portfolios as well as
    • Key Business Events: Patient Registration, Encounter/Consultation, Lab Test Ordered, Lab Test Completed. 8.1.4 Business Information Analysis Would refer to and/or update DAMs for Person/Patient and Laboratory if they existed. These have not been produced for the purposes of this study since they are not directly relevant to the issue. 8.1.5 Business Capability Definition These are derived from a mixture of overall Service Portfolio Analysis and the identified Business Roles and Activities and Information Objects. Relevant Services identified are: Entity (Patient) Identification Management: This service manages identities of various entity types and provides a means to resolve identification queries and duplicates. (The existing HSSP EIS specification is assumed with a RIM based Patient semantic profile.) Order Management (Lab): This service allows entry and manipulation of Orders in a medical record system.. Laboratory Management: This service provides management of laboratory tests starting with receipt of a laboratory order. Patient Registration: This service provides capabilities for registering patients for encounters. 8.2 System Requirements and Functional Specification This stage produces the requirements and functional specification of the service and introduces considerations of application systems and services. performance requirements.
    • 8.2.1 Define and Outline Business Flows and Dynamics Firstly, the actors are identified (based on the Business Roles), then the system boundary identified and main use cases are described (again these would be sample use cases for Service standards development scenarios, since Services are intended to be reused across many processes) Actors: Registration Clerk, Provider, Patient (Not shown), External Laboratory Logical Systems: EIS, HIS Use Cases (one example is partially elaborated below; the rest would use a similar format. Note that there are many different templates for Use Case descriptions. Standardizing would be advantageous but not critical): Register Patient For Encounter: Primary Actor Registration Clerk Secondary (Could show the EIS as an external actor for this use case) Actors Pre-Conditions Registration clerk authorized to use system functions Post-Conditions Patient is registered for an encounter
    • Main Flow 1) Registration clerk enters Patient Information, including Patient ID and requests encounter set up 2) System validates eligibility (not shown – probably another included use case) 3) Clerk / System find available Provider and sets up encounter. Alternate Flow 1) Step 1 Patient ID not known so other patient details entered Name, Address and EIS service is called to find the Patient Identity (the clerk could also look up directly through a user interface to EIS before entering details into the HIS, or a context manager could manage this by finding the Patient Record based on the direct EIS call) Business Rules Co-pays must be collected before encounter set up confirmed etc. Other use cases would be Identify Patient, Create Lab Order, Review Lab Results. The outline Choreography is represented below as a sequence diagram: As indicated earlier, there are alternate ways some of the above could be achieved, e.g. the Lab Order could be fired directly from the Clinician desktop / portal with a copy sent to the HIS, or details could be entered only into the HIS which would then generate the order for the external lab system. Similarly, the EIS call could be made via the HIS.
    • 8.2.2 Information Analysis Would refer to and/or update Domain Information Models for Person/Patient and Laboratory. These have not been (re-)produced here since they are not directly relevant to the issue at hand. 8.2.3 Define Functional Capabilities – Operations and Information Content This defines the interfaces and capabilities that are provided by the services. These are not yet expressed as operations since the focus is still at the business level, though it is appropriate to think about logical, business oriented groupings like “Admit” or “Identify Patient.”. In this case, the relevant capabilities are: Find Entities By Trait, Link Entities, List Linked Entities (provided by EIS), Create Order and View Order (provided by Order Management Service) and Receive Lab Order Request and Notify Test Result (provided by a Laboratory Management Service) For EIS, see the existing SFM DSTU for full details. For “Find Entities By Trait”, the description below has been extracted from the SFM. A Patient Semantic profile would be used to define the information model. Description Given a list of Traits (Trait Identifier or Name, Trait Value pairs), this allows for a search of matching Entities. Outputs include a quality of match. Precondition The Traits specified in the list exist in the system Inputs A list of (Trait Name or Trait Identifier, Trait Value) pairs Requested confidence of match Trait Identifiers or Names to be returned (can be different than input -default) Matching algorithm (Optional) List of Entity Type Identifiers (Optional) List of Entity Domain Identifiers (Optional) Outputs An acknowledgement that a list of Entities for the search predicate has been found or no matches. A list of (Entity Type Identifier, Entity Identifier, quality_of_match) matching the search predicate, in order of the quality_of_match, together with requested output Traits. Invariants Postconditions None Exception A Trait Identifier/Name in the input list does not exist Conditions Entity Type does not exist
    • Entity Domain does not exist Aspects left to It is left to OMG RFP submitters whether to define specific queries RFP submitters for specific entity types and trait sets and/or algorithms etc. For XEIS instances, may also be useful to return a list of Entity Domains that were covered and/or not covered by the search. A means needs to be provided for authorized roles to retrieve entities that have an “inactive” status. This may be provided by including status as an input or other mechanism. Default behavior of this operation should return “active” matches. Relationship to Included in Functional profile: Entity Query levels of conformance Miscellaneous The confidence and quality of match inputs and outputs should notes provide the ability to define a two-tiered match threshold criteria, such as "definite match." not requiring human intervention, and "presumptive match," requiring further verification. The response quality could be used to determine which of the thresholds were achieved. Note that these values can be composite data structures, numerical, ontological, etc. The other capabilities would be defined in similar fashion. 8.2.4 Produce Functional Specification As part of standardization activities within the SOA Interoperability Paradigm, , this would involve defining a Service Functional Model (SFM). See the existing EIS, RLUS and DSS DSTUs for examples. For local work, Sections 2, 3, 5, and 7 of the SFM would be sufficient to conceptually define the scope and breadth of the work to create the system. These sections include: • Section 2 – Service Description, Purpose, Context, and Summary Items • Section 3 – Business Storyboards, Use Cases, and Actors • Section 5 – Detailed Functional Model • Section 6 – Profiles of Behavior and Intended Semantic Signifiers (Information Analysis Models) • Section 7 – System Interaction Details 8.3 Analysis and Design (PIM) In the HSSP Service Specification process (SSF), an RFP would be produced and the RFP response submitters would carry out the remainder of the process. This stage defines the initial system solution, but still at a platform independent level.
    • 8.3.1 Define Detailed System Choreography This section specifies the choreography rigorously and in detail. This covers both inter- system interactions and internal system behavior that is observable externally. (Again, in a Services paradigm, this is still exemplary, but could also be used for testing and for further profiling (such as in IHE)). For a full explanation of the Choreography expression, see below. However, it is appropriate at the PIM level to expect the following elements to be expressed: • Roles • Role Behaviors • Relationships between Roles • Information Types • Activities, Interactions, and Work Units In the following diagram, some of the same information is represented using UML sequence diagram notation. Figure 18: Representative Choreography, showing interactions between systems
    • 8.3.2 Define System Capabilities At this stage, the actual Service Interfaces and Operations would be defined based on the capabilities from the service functional model, with any systems considerations applied (but not yet technology or platform specifics). Additionally, the various system components would be choreographed in terms of the sequencing of messages, appropriate separation of concerns, and services from the current organizational service portfolio would have been identified. The HSSP Service Specification Framework process at this stage is equivalent to an idea covered by the RFP Submission, which specifically includes a “platform independent model”. The form that this takes will generally be a UML representation of the Interfaces and Operations with supporting documentation. Additionally, the authors believe that interactions and choreographies can be supported by expressing these system interactions and gate conditions to behaviors in terms of the CDL. When complete, this will fully define the operations, inputs, outputs and behavior for each. A PIM is simply the logical representation of the interfaces and method signatures, along with type dependencies, along with element enumerations on the functional and informational semantics.
    • «datatype» «datatype» «datatype» «datatype» «datatype» «datatype» EntityIndentifyingTraits SystemID EISResultSet errorCode EntityIndentifyingTraitsDefinition EISTrait «interface» EISMgmtAndQueryInterface +CreateEntity(in entityTypeName : string(idl), in SYSTEMID : SystemID, in entityIndentifyingTraits : EntityIndentifyingTraits, out eisRecordID : string(idl)) : errorCode +CreateEntityWithLocalID(in entityTypeName : string(idl), in localRecordID : string(idl), in SYSTEMID : SystemID, in entityIndentifyingTraits : EntityIndentifyingTraits, out eisRecordID : string(idl)) : errorCode +UpdateEntityTraitValues(in entityTypeName : string(idl), in localRecordID : string(idl), in SYSTEMID : SystemID, in entityIndentifyingTraits : EntityIndentifyingTraits) : errorCode +RemoveEntity(in entityTypeName : string(idl), in localRecordID : string(idl), in SYSTEMID : SystemID, in entityIndentifyingTraits : EntityIndentifyingTraits) : errorCode +GetAllEntityTraits(in entityTypeName : string(idl), in localRecordID : string(idl), in SYSTEMID : SystemID, out entityIndentifyingTraits : EntityIndentifyingTraits) : errorCode +FindEntitiesByTraits(in entityTypeName : string(idl), in entityIndentifyingTraits : EntityIndentifyingTraits, out resultSet : EISResultSet) : errorCode +ListLinkedEntities (in entityTypeName : string(idl), in localRecordID : string(idl), in SYSTEMID : SystemID, in entityIndentifyingTraits : EntityIndentifyingTraits, out resultSet : EISResultSet) : errorCode +ListUnlinkedEntities (in entityTypeName : string(idl), in localRecordID : string(idl), in SYSTEMID : SystemID, in entityIndentifyingTraits : EntityIndentifyingTraits, out resultSet : EISResultSet) : errorCode +DescribeEntityTraits(in entityTypeName : string(idl), out entityTraitsDefinition : EntityIndentifyingTraitsDefinition) : errorCode «interface» EISAdminEditorInterface +LinkEntities (in entityTypeName : string(idl), in sourceLocalRecordID : string(idl), in sourceSYSTEMID : SystemID, in targetLocalRecordID : string(idl), in targetSYSTEMID : SystemID, in reasonCode : string(idl)) : errorCode +UnlinkEntities (in entityTypeName : string(idl), in sourceLocalRecordID : string(idl), in sourceSYSTEMID : SystemID, in targetLocalRecordID : string(idl), in targetSYSTEMID : SystemID, in reasonCode : string(idl)) : errorCode +MergeEntities(in entityTypeName : string(idl), in sourceLocalRecordID : string(idl), in targetLocalRecordID : string(idl), in targetSYSTEMID : SystemID, in reasonCode : string(idl)) : errorCode +UnMergeEntities(in entityTypeName : string(idl), in sourceLocalRecordID : string(idl), in targetLocalRecordID : string(idl), in targetSYSTEMID : SystemID, in reasonCode : string(idl)) : errorCode +ActivateEntity (in entityTypeName : string(idl), in localRecordID : string(idl), in SYSTEMID : SystemID, in entityIndentifyingTraits : EntityIndentifyingTraits, in reasonCode : string(idl)) : errorCode +DeactivateEntity(in entityTypeName : string(idl), in localRecordID : string(idl), in SYSTEMID : SystemID, in entityIndentifyingTraits : EntityIndentifyingTraits, in reasonCode : string(idl)) : errorCode «interface»EISMetaDataInterface +CreateTrait(in traitDefinition : EISTrait) : errorCode +FindTrait(in traitName : string(idl), inout traitDefinition : EISTrait) : errorCode +UpdateTrait(inout traitDefinition : EISTrait) : errorCode +ListTraits(out listOfTraitNames : sequence(idl)) : errorCode +CreateEntityDefinition(in entityDefinition : EntityIndentifyingTraitsDefinition ) : errorCode +FindEntityDefinition(in entityTypeName : string(idl), out entityDefinition : EntityIndentifyingTraitsDefinition ) : errorCode +UpdateEntityDefinition(inout entityDefinition : EntityIndentifyingTraitsDefinition) : errorCode +ListEntityDefinitions (in domainFilter : string(idl), in typeClassiferFilter : string(idl), in listOfEntityDefNames : sequence(idl)) : errorCode +ListDomains(out listOfDomains : sequence(idl)) : errorCode +ListConformanceProfiles(out conformanceProfiles : sequence(idl)) : errorCode +ListTypeClassifiers(in listOfTypeClassifers : sequence(idl)) : errorCode «interface»EISVersionInterface +GetCurrentVersionLabel(in entityTypeName : string(idl), in localRecordID : string(idl), in SYSTEMID : SystemID, out currentVersionLabel : string(idl)) : errorCode +SetCurrentVersionLabel( in entityTypeName : string(idl), in localRecordID : string(idl), in SYSTEMID : SystemID, in currentVersionLabel : string(idl)) : errorCode +GetVersionHistory(in entityTypeName : string(idl), in localRecordID : string(idl), in SYSTEMID : SystemID, out currentVersionHistory : sequence(idl)) : errorCode +SetLatestVersionForAll() : errorCode +SetLatestVersionForEntity(in entityTypeName : string(idl), in localRecordID : string(idl), in SYSTEMID : SystemID) : errorCode Figure 19: Sample PIM model (without dump out) from the RFP First Draft Submission for EIS Sample Enumeration: • FindIdentityByTrait: This operation provides the means to provide a broad search of all records in the EIS which match some criteria in the identifying attributes (such as find all records who match the name “Jones, Bob” • Order Entry: (Lab Semantic Profile). Operations: Enter New Order, View Order • Order Management: (Lab Semantic Profile). Operations: Create Order, Notify Result (also deal with partial results and promise notification)
    • Other components of the behavior specification that would be expected are state transitions (if appropriate), pre-conditions, post-conditions, and invariants. These might also have an expression in the logical operations governing work units within a CDL package (see below). 8.3.3 Information Design Again, the information design is not the central focus of this paper. For HSSP services, “Semantic Signifiers” are used to define information semantics, which are basically references to existing static information models: For EIS and RLUS, these are currently being defined by RFP Submitters. For the Order interactions, V3 DIMs or RMIMs would be used as a basis if the profile was for v3 structures. 8.4 Technical Specification (PSM) This section introduces platform specific considerations, i.e. in this case Web Services (WSDL, SOAP, HTTP). 8.4.1 Produce PSM The PSM is essentially a mapping from the PIM (above) given some set of technical considerations. For example, once WSDL + SOAP + HTTP is chosen as a platform, then certain bindings will need to be applied to turn behaviors into grouped operations, and a semantic profile will need to be applied to turn the Information Analysis Model into a set of schema that may be used as parameters. This mapping may be automated, but it need not be. The implementation of a PSM conforms to one conformance profile. That is, it uses a set of semantic signifiers to facilitate business focused functionality. It also is tied to one informative usage context, presumably that for which it was designed either through the standardization process or through local specification processes. Below is a sample extract from a PSM from the EIS RFP Draft Submission CreateIdentityWithSuppliedID This is a variation on the CreateIdentity method that accepts a Supplied ID as opposed to generating an ID and returning it in the output message. It has the same message structure as CreateIdentity. Notes on the use of 2.3.1 PID segment in . PIM PSM Inputs IdentityQualifier This is mapped to MSH.4 in HL7 v2.5. EntityIdentifier. This is mapped to PID.3, first element in the list Unordered set of Traits (Data Structures consisting of a single Use a standard HL7 v2.5 ADT message to or hierarchic structure of name-
    • PIM PSM value pairs) hold the traits. Force Insert Outputs Acknowledgement HL7 ACK. Error Entity reference already exists (error Conditions based on ID match) Entity reference may already exist (warning) – returns ID(s) and set of traits for matched identity Mandatory traits not supplied A trait in the list does not exist in the system metadata for the Entity Type There are duplicates in the trait list Invalid data type or code value for trait Additional Details Figure 20: Sample Mapping from PIM to PSM At this point, it is appropriate to expect more detail from the choreography as well. • Channel Types and Channels • Exchanges (and Exchange Patterns) • Participants Depending on the usage of CDL in a given context, it would also be appropriate at this stage to utilize tooling to test a given set of interactions and possibly to capture the choreography in some technology specific way (a state machine, for example). See below for more information. Note also that Section 7 includes cross-reference material extracted from earlier SOA4HL7 architecture work which considered some of the transmission wrapper items and how they may be supported using SOAP headers.
    • 8.4.2 Produce Implementation Guide An implementation guide is an optional but valuable step that may be obviated by good tooling, models, documentation, and a solid publication process. The implementation guide takes on particular importance when utilizing a choreography description. The SOA Interoperability Paradigm seeks either a late binding to service interfaces or (at the least) a loose coupling between the named interface implementations. Therefore it is important to be as specific as possible with regard to sequencing of messages and to the expected behaviors implied by these messages. CDL as an expression language manages this well, but without using it specifically it is still possible to capture this important information. In addition, the SOA Interoperability Paradigm supports highly granular separation of concerns. It is not necessarily possible to simply assume some sort of capability – authorization, for example – to exist within a system boundary. Implementation Guides offer a way to demonstrate the delta between policies, standards, and implementations. 9 The Service-oriented Interoperability Paradigm’s Dynamic Model This section will explore in detail the component parts of CDL as the basis for the dynamic model for the Service-oriented Interoperability Paradigm. For the HL7 audience, CDL contains many concepts that are familiar. In some cases, there is a nearly one-to-one correlation with concepts in the HL7 dynamic model, while other ideas are broken down to component parts. It can be argued however, that CDL provides concepts that are more widely accepted within the industry, not only because of its status as a candidate release through the W3C, but also because of its mappability to other industry standard workflow artifacts such as BPEL and WSDL. While CDL benefits from a service-oriented approach, it is sufficient to describe complex inter-system behavior in other contexts as well. For this reason as well as its clarity, CDL may serve as an expression language for dynamics not only for the Service-oriented Interoperability Paradigm, but probably to any other interoperability paradigm (messaging or documents) as well. Put another way, not every endpoint is a service, but it is likely that every endpoint could be described using or bound to CDL artifacts. 9.1 HL7 Artifacts and CDL Artifacts CDL contains many key components that can be used to capture behavior. This section will compare the relevant CDL artifacts with HL7 artifacts. HL7 Element CDL Element Notes Interaction Exchange Message Exchange Pattern Logical Constructs HL7 does not explicitly
    • (sequences, parallels, define communication or choices) and interactions message exchange patterns as modeled constructs. However, CDL offers several components that can be used to realize simple or complex messaging patterns. Trigger Event Guard and Block Where trigger events are Conditions, workunits logical, automated constructs, CDL models them as logical expressions set against either events or content variables. Receiver Responsibilities Guard and Block Receiver responsibilities are Conditions, Workunits expressed as logical constructs that are realized from a global point of view. There is no sender / receiver bias in the expression. Application Role Role, Relationship, Using CDL, applications Channel Type, Interaction, would participate as roles in and Participation relationships that are realized through interactions that utilize a channel type. Applications – as such – do not appear in CDL, though they may appear as Participants. Figure 21: Dynamic Model correlation between HL7 and CDL CDL solves several problems that have stood as barriers to HL7 defining its own formal dynamic model:  It allows the expression of system responsibilities in a rigorous way that is acknowledged by all systems  While CDL itself does not explicitly include the concept of Application Role, the concept is nevertheless subsumed by the CDL. See Section 9.1.4 for details.  It allows rigorous expression of multiple communication patterns that are supported by messages, but not limited to messaging  It allows for both conceptual and platform-independent expressions of behavior
    •  It provides re-usable constructs that could be referenced during standardization efforts  It provides for a loose coupling between run-time artifacts and interactions, allowing multiple systems to assume multiple roles within a choreography for a given deployment context.  It provides a rich expression of complex inter-system behavior that is resolvable as a single artifact which may be versioned, managed, stored, and re-used Should CDL mature in the future, there are several more benefits that would accrue:  It would be supported by open-source tooling  It provides for a fairly simple set of visual tools to describe and express complex inter-system behavior  CDL would provide a defined mechanism to derive PSMs from PIMs  CDL would provide a defined mechanism to generate run-time artifacts from PSMs  CDL intrinsically supports service-oriented constructs like those provided for elsewhere in the HSSP scope Without getting into the specifics of expression, a brief analysis and comparison follows. 9.1.1 CDL Exchange, HL7 Interactions, and Message Exchange Patterns HL7 Interactions define a message being sent from one endpoint to another. CDL defines an exchange as a message that is sent to realize all or a portion of an interaction. The interaction’s one to many relationship with exchanges allow various messaging patterns to be realized in various ways. A rigorous coupling is established between an interaction and roles within a relationship, which is important both for conformance to be established as well as bindings to be established between behavioral interfaces and the realization of an interaction. The CDL exchange then becomes the behavioral concept and the driver of the logical behavior that the choreography embodies, allowing the CDL interaction to perform its separate function. 9.1.2 CDL Guard / Block Conditions and HL7 Trigger Events HL7 Trigger Events are behaviors interacting with a system’s stateful constructs to initiate a message of some form. CDL allows for role’s behaviors to be realized as operations on interfaces (see the CDL Role, Interaction, and Channel Types). Additionally, these behaviors may be invoked through a causal relationship using either an event (a timer or a signal) or data. The logical patterns of behavior invocation can be set, for instance, against either explicit state variables or against variables that are visible only to certain roles. These are referred to as guard conditions within CDL. As might be expected at this point, those variables are scoped to exchanges (“send” and “receive” variables). The CDL exchange is then the explicit conveyor of behavior within
    • a choreography, not roles, endpoints, relationships, or interfaces. They become the control mechanisms for invoking a CDL Workunit, which in turn couple roles, relationships, and interactions. 9.1.3 CDL Guard / Block Conditions, CDL Workunits, and HL7 Receiver Responsibilities In the same way that guard conditions can realize trigger events computationally, they may also be used to explicitly state receiver responsibilities. These responsibilities might be expressed as a variable that is set to some value given the fulfillment of some set of conditions. In the example below, the “isOrderFinal” is used to trigger the final notification of the provider, which is expressed within a CDL Workunit.. Of particular note is the option that these “system state” variables might be scoped to every other system participating in the choreography, or they might not. Conformance to HL7’s dynamic model requires conformance to the defined set of receiver responsibilities without ever offering dependable mechanisms to express the fulfillment of those responsibilities. CDL’s use of conditional workunits allows thse components to be bound to all participants, and thus to share a common notion of receiver responsibilities in a rigorous fashion. Additionally, and arguably of more value in a SOA, is the contractual relationship that can be made explicit between systems participating in a choreography and the choreography itself, rather than the n-to-1 contractual relationships required in fact from a less-than-rigorous and less-than-explicit realization of the HL7 receiver responsibilities. For more on the concept of receiver responsibilities, see below. 9.1.4 CDL Expression of the HL7 Application Role For the purposes of the Service Oriented Interoperability Paradigm, an Application Role actually solves several problems to do with the intersection of conformance, specification, and interactions. However, the HL7 expression of an Application Role describes none of these completely, and tends to cloud the issue with regard to both specification, realization, and conformance because of its lack of comprehensiveness and specificity. For the purposes of CDL, applications would participate as roles in relationships that are realized through interactions that utilize a channel type. Applications, as such, do not appear in CDL. The issue of conformance between real world systems and this arrangement within CDL is best captured by the idea of participant. A participant is a real world actor that takes on one or more roles. Because the participant only appears at the package level of a choreography description, this allows it to be defined in terms of design construct rather than being tightly bound to any particular technological construct. Note that CDL interactions participate in relationships, allowing the conformance loop to be closed. The CDL role exposes certain behaviors without any reference to an interaction per se. Rather, relationships tie roles together through those exposed behaviors. A relationship exists between two roles, but those roles can expose one, some, or all of their behaviors
    • within a relationship. This decomposition is a convenient mapping between HL7 DM and CDL for the purposes of defining run-time constructs that have some equivalency. Those relationships in turn are bound to interactions within a choreography that is not dependent on but defines the exchanges (the behavior) valid unto itself. More than one choreography, via its interactions, variables, and exchanges can realize a set of roles and their relationships. Another part Application Role is the notion of receiver responsibilities. From the standpoint of service specifications that form an encapsulation boundary and that rigorously maintain a separation of concerns, the notion of receiver responsibilities has no means of expression within the behavioral interface itself, nor should it. However, from a SOA perspective, allowing a formal expression of these responsibilities in terms of guard and blocking conditions globally is appropriate, which is exactly the perspective expressed in CDL. Perceived from the global perspective rather than as an arbitrary expression on a service endpoint, these conditions become part of the global “contract” by which systems, services, and actors participate in a choreography. The responsibilities can be realized as expressions that become part of the computable quality components of service oriented interoperability. With CDL, the concept of receiver responsibilities becomes not only a desirable construction in terms of a dynamic model, but often a computable one as well. But to be clear, it is bound to some rigorous expression of grouped behaviors (realized through CDL workunits, sequences, and interactions) and their logical expression (CDL choreography) rather than to the roles or even the relationships themselves. This is an appropriate abstraction and separation of concerns. 9.2 CDL Worked Example – Laboratory Orders Based on the example and analysis in Section 5, part of the choreography is here worked out in more detail. The focus is on communication of concepts first and a focus on accurate representation of the actual scenario second. For a rigorous treatment of CDL, see the referenced works. This section examines the simpler building blocks of CDL first, and then explores ways that they can be used in concert to capture complex behaviors. By necessity, these components are presented only in the order in which they seem to hang together best. This means that certain concepts are introduced in a cursory fashion that are dealt with more rigorously later in the paper. 9.2.1 Interactions Interactions form the core execution unit of choreographies. They bind roles to a participation, and embody that participation in both an operation on an interface and, to an extent, the message exchange pattern that will be utilized. <interaction name="findPatient" channelVariable="findPatientC" operation="findEntityByTrait">
    • <participate relationshipType="admitEntityIdentification" fromRoleTypeRef="admitRole" toRoleTypeRef="mpiEntityIdentificationRole"/> <exchange name="findEntityRequest" action="request"> <send variable="cdl:getVariable('patientTrait','','')"/> <receive variable="cdl:getVariable('patientTrait','','')"/> </exchange> <exchange name="findEntityResponse" action="respond"> <send variable="cdl:getVariable('patient','','')"/> <receive variable="cdl:getVariable('patient','','')"/> </exchange> <exchange name="findEntityFault" faultName="EntityNotFound" action="respond"> <send variable="cdl:getVariable('findEntityFault','','')"/> <receive variable="cdl:getVariable('findEntityFault','','')"/> </exchange> </interaction> 9.2.2 Roles, Relationships, and Participants Roles provide a containing element for desired behaviors. Behaviors correspond to an interface that will have one or more granular operations. Note that the interface attribute is optional with a behavior, making it a cornerstone of conformance. Note also the use of service standards in the behaviors. The names in “dot notation” emphasize that the interface will support behaviors according to published functional profiles for the Entity Identification Service standard. Roles appear in the above interaction as references within the participation. <roleType name="orderManagerRole"> <description>The Order Manager is the abstract component that manages orders, order notifications, and so on</description> <behavior name="OrderEntry" interface="HIS.OrderEntry.wsdl"> <description>Includes createOrder</description> </behavior> <behavior name="OrderStatus" interface="HIS.OrderStatus.wsdl"> <description>Includes Confirmation, Partial Result, Result Correction, and Final Result</description> </behavior> <behavior name="Notify"> <description>Supports the notification of provider</description> </behavior> </roleType> <roleType name="labSystemIdentityIdentificationRole"> <behavior name="EIS.BasicLinkQuery" interface="Lab.EIS.BasicLinkQuery.wsdl"> <description>Includes findIdIdentityByTrait, findIdIdIdentityByTraitSimple, listLinkedIdentities</description>
    • </behavior> <behavior name="EIS.Link" interface="Lab.EIS.Link.wsdl"> <description>Includes linkEntities</description> </behavior> </roleType> The Roles that are created in the sample choreography are enumerated in the following table: Role Behavior Operation mpiEntityIdentificationRole EIS.Query findEntityByTrait registrarRole Register Register labSystemEntityIdentificationRole EIS.Query findEntityByTrait EIS.Link linkEntities labSystemOrderManagerRole OrderEntry createOrder orderManagerRole OrderStatus receiveOrderConfirmation receiveOrderPartialResult receiveOrderResultCorrection receiveOrderFinalResult OrderEntry enterOrder providerRole Notification receiveNotification Figure 22: Roles, Behaviors, and Operations Roles are referenced explicitly within relationships. The following relationship is named for its two constituent roles. <relationshipType name="orderManagerLabSystemOrderManager"> <description>Allows lab orders to be managed</description> <roleType typeRef="orderManagerRole" behavior="Order Status"> <description>asynchronous order processing interfaces that are explicit wrt orderState</description> </roleType> <roleType typeRef="labSystemOrderManagerRole" behavior="Order Entry"> <description>The labSystem has a single behavior exposed to the orderManagerRole</description> </roleType> </relationshipType> <relationshipType name="labSystemOrderManagementLabIdentityIdentification"> <description>Allows the lab system order management system to resolve Identity identifiers</description> <roleType typeRef="labSystemOrderManagerRole" behavior="IdentifyPatient"/> <roleType typeRef="labSystemIdentityIdentificationRole" behavior="EIS. BasicLinkQuery EIS.Link"/> </relationshipType>
    • Participants create a grounding between actual implemented service structures and roles. So, for example, the HospitalInformationSystem WSDL could contain both orderManagerRole behaviors and notifyerRole behaviors. <participantType name="AdminSystem"> <roleType typeRef="admitRole"/> </participantType> <participantType name="HIS"> <roleType typeRef="orderManagerRole"/> <roleType typeRef="notifyerRole"/> </participantType> As noted in the interaction (above), the roles and relationships are tied to the interactions. More connections will be seen below. 9.2.3 Information Information drives the choreography in a number of ways. For the purposes of describing the components of the sample operation, there are several pieces of clinical information that are important, including:  Patient  Order  PatientTraitSet  Provider  OrderResult  Registration 9.2.4 Information Types Information types are first order constructs within a CDL package that may be referenced by the entire choreography. <informationType name="order"> <description>A Lab Order represents the focal class for an order management system</description> </informationType> 9.2.5 Tokens At their simplest, tokens provide an alias for information. That information can be equated with the root class of information, or, using XPath statements, be identified within information types. TokenLocators provide path information to these other elements.
    • <token name="orderToken" informationType="order"> <description/> </token> <token name="orderID" informationType="order"> <description/> </token> …. <tokenLocator tokenName="orderID" informationType="order" query="order/ID"> <description/> </tokenLocator> Tokens and tokenLocators provide for visibility of elements important to the global choreography, allowing correlating behavior to be based on one or more elements like “orderID.” 9.2.6 Channels Information is tied to roles through channels. The roles expose behavior, which is explicit through the URI in a deployment instance. As will be seen below, the interaction is tied to a channel variable to complete the loop. <channelType name="orderManagerReceiveOrderResultFinalChannel"> <description/> <roleType typeRef="orderManagerRole" behavior="OrderStatus"> <description/> </roleType> <reference> <description/> <token name="URI"> <description/> </token> </reference> </channelType> <channelType name="mpiIdentityIdentificationFindIdentityByTraitChannel"> <description/> <roleType typeRef="mpiIdentityIdentificationRole" behavior="EIS.BasicLinkQuery"> <description/> </roleType> <reference> <description/> <token name="URI"> <description/>
    • </token> </reference> </channelType> 9.2.7 Using CDL to Capture Complex Behaviors The above components are used together within the CDL package. They are facilitated through the invocation of a choreography. 9.2.7.1 Choreographies In our sample package, the behaviors are modeled as two choreographies for the purposes of illustration and to demonstrate how choreographies might be reusable constructs. The first choreography (“AdmitPatient”) is simple in that it describes simple sequential behavior with two simple interactions. To capture the business notion that one must precede the other, these are bound together using a CDL sequence. <choreography name="AdmitPatient"> <description/> <relationship type="admitEntityIdentification"> <description/> </relationship> <relationship type="admitPatientRegistration"> <description/> </relationship> <variableDefinitions> …. </variableDefinitions> <sequence> <interaction name="findPatient" channelVariable="findPatientC" operation="findIdIdentityByTrait"> <participate relationshipType="admitIdentityIdentification" fromRoleTypeRef="admitRole" toRoleTypeRef="mpiIdentityIdentificationRole"/> <exchange name="findIdIdentityRequest" action="request"> <send variable="cdl:getVariable('patientTrait','','')"/> <receive variable="cdl:getVariable('patientTrait','','')"/> </exchange> <exchange name="findIdIdentityResponse" action="respond"> <send variable="cdl:getVariable('patient','','')"/> <receive variable="cdl:getVariable('patient','','')"/> </exchange> <exchange name="findIdIdentityFault" faultName="IdIdentityNotFound" action="respond"> <send variable="cdl:getVariable('findIdIdentityFault','','')"/>
    • <receive variable="cdl:getVariable('findIdIdentityFault','','')"/> </exchange> </interaction> <interaction name="registerPatient" channelVariable="registerC" operation="register"> <participate relationshipType="admitPatientRegistration" fromRoleTypeRef="admitRole" toRoleTypeRef="registrarRole"/> <exchange name="registerPatientAsynch" action="request"> <send variable="cdl:getVariable('registration','','')"/> <receive variable="cdl:getVariable('registration','','')"/> </exchange> </interaction> </sequence> </choreography> One note: there is no fault tolerance built into the asynchronous registration notification. This demonstrates a reliance within the SOA Interoperability Paradigm on available infrastructure such as WS-RM or other reliability frameworks. 9.2.7.2 Variables Before diving into complex controls available within CDL, it is worth examining the role that variables play in the previous example, and how they may be extended to capture complex behavior. Variables are scoped to choreographies, but are situated to roles. By default, if a roleType is not defined within a variable, then it is situated at all roleTypes. This situation does not bear on the semantics of the variable, and in the current version of CDL, does not imply any sort of implicit information sharing. To share information, values would have to be passed through channels that explicitly exchange the information via parameterizations. <choreography name="AdmitPatient"> …. <variableDefinitions> <variable name="findPatientC" channelType="mpiIdentityIdentificationFindIdentityByTraitChannel"> <description>References the admit URI</description> </variable> <variable name="registerC" channelType="registrarRegisterPatientForEncounterChannel"> <description>References the register URI</description> </variable> <variable name="patientTrait" informationType="patientTraitSet"> <description>request parameter for findIdentityByTrait</description> </variable> <variable name="patient" informationType="patient">
    • <description>response parameter for findIdIdentityByTrait </description> </variable> <variable name="findIdIdentityFault" informationType="findIdIdentityByTraitFault"> <description>Fault type for findIdIdentityByTrait</description> </variable> <variable name="patientID" informationType="patient"> <description/> </variable> <variable name="providerID" informationType="provider"> <description/> </variable><variable name="registration" informationType="registration"/> </variableDefinitions> …. </choreography> Variables are created for reference in the interaction, and can be of either information type or channel type. Channel Typed variables are referenced by the interaction, and information typed variables are referenced by exchanges within the interaction. For more complex behaviors, CDL allows for control variables to be included in the variable definitions. Below are the variable definitions for the second choreography, “EnterLabOrder.” <variableDefinitions> <variable name="enterOrderC" channelType="orderManagerEnterOrderChannel"/> <variable name="order" informationType="order" roleTypes="orderManagerRole labSystemOrderManagerRole"> <description>The order includes the order and the patient</description> </variable> <variable name="patientID"> <description/> </variable> <variable name="orderID" informationType="order" roleTypes="orderManagerRole labSystemOrderManagerRole"> <description/> </variable> <variable name="orderResult" roleTypes="orderManagerRole labSystemOrderManagerRole"> <description/> </variable> <variable name="providerID"> <description/> </variable>
    • <variable name="isOrderFinal" informationType="Boolean" roleTypes="labSystemOrderManagerRole"> <description>Manages order finalization for the choreography</description> </variable> <variable name="patientTrait" informationType="patientTraitSet"> <description>request parameter for findIdIdentityByTrait</description> </variable> <variable name="patient" informationType="patient"> <description>response parameter for findIdIdentityByTrait </description> </variable> <variable name="findIdIdentityFault" informationType="findIdIdentityByTraitFault"> <description>Fault type for findIdIdentityByTrait</description> </variable> <variable name="linkEntitiesFault" informationType="linkEntitiesFault"> <description>Fault type for linkEntities</description> </variable> <variable name="listLinkedEntitiesFault" informationType="listLinkedEntitiesFault"> <description>Fault type for listLinkedEntities</description> </variable> <variable name="enterOrderLabC" channelType="labSystemCreateOrderChannel"/> <variable name="findIdIdentityC" channelType="labIdentityIdentificationFindIdentityByTraitChannel"/> <variable name="linkIdIdentityC" channelType="labIdentityIdentificationLinkEntitiesChannel"/> <variable name="listLinkedEntitiesC" channelType="labIdentityIdentificationListLinkedEntitiesChannel"/> <variable name="orderConfirmC" channelType="orderManagerReceiveOrderConfirmationChannel"/> <variable name="partialResultC" channelType="orderManagerReceiveOrderPartialChannel"/> <variable name="orderCorrectionC" channelType="orderManagerReceiveOrderResultCorrectionChannel"/> <variable name="orderFinalC" channelType="orderManagerReceiveOrderResultFinalChannel"/> <variable name="notifyProviderC" channelType="providerReceiveNotificationChannel"/> </variableDefinitions> The “isOrderFinal” Boolean is a control variable to block the responses from the labOrderManagerRole to the orderManagerRole. Only when “isOrderFinal” = True will the notification be sent to the provider. This sort of global control of inter-system
    • behavior is part of what makes CDL so well-suited for use both as a specifying artifact and behavioral description. Unlike in the other choreography, certain variables within the EnterLabOrder are scoped explicitly to roles. For example, there is no need for the labEntityIdentificationRole to have knowledge of an order. 9.2.7.3 Logically expressing Workflow using Workunits, sequences, and Conditionals Using the logical constructs of CDL, it is now possible to create the complex behavior. <sequence> <interaction name="enterOrder" channelVariable="enterOrderC" operation="enterOrder"> <description>Provider enters order with order management service</description> <participate relationshipType="providerOrderManager" fromRoleTypeRef="providerRole" toRoleTypeRef="orderManagerRole"/> <exchange name="enterOrderAsynch" action="request"> <send variable="cdl:getvariable('order','','')"/> <receive variable="cdl:getvariable('order','','')"/> </exchange> </interaction> <sequence> <description>Resolve Patient Identity</description> …. </sequence> <interaction name="enterOrderWithOptionalConfirmation" channelVariable="enterOrderLabC" operation="createOrder"> <description>Send the order to the LabSystemOrderManager</description> …. </interaction> <parallel> <assign roleType="labSystemOrderManagerRole"> <description type="documentation">Initialise Loop and Blocking Variable</description> <copy name="isOrderFinal"> <description type="documentation">Set isOrderFinal to false</description> <source expression="false()"/> <target variable="cdl:getVariable('isOrderFinal','','')"/> </copy> </assign> <workunit name="receiveOrderResults" repeat="isOrderFinal = false">
    • <description>While the order is not final, these asynchronous responses are appropriate: Confirmation, Partial Result, Result Correction, Final Order Result</description> <choice> <sequence> <description>Order Confirmation</description> …. </sequence> <sequence> <description>Order Partial Result</description> …. </sequence> <sequence> <description>Order Result Correction</description> …. </sequence> <sequence> <description>Order Final Result</description> <interaction name="finalOrderResult" channelVariable="orderFinalC" operation="receiveOrderFinalResult"> <participate relationshipType="orderManagerLabSystemOrderManager" fromRoleTypeRef="labSystemOrderManagerRole" toRoleTypeRef="orderManagerRole"></participate> … </interaction> <assign roleType="labSystemOrderManagerRole"> <description type="documentation">Finalize Loop Variable</description> <copy name="isOrderFinal"> <description type="documentation">Set isOrderFinal to true</description> <source expression="true()"/> <target variable="cdl:getVariable('barteringDone','','')"/> </copy> </assign> </sequence> </choice> </workunit>
    • <workunit name="notifyProviderOfOrderResults" guard="isOrderFinal = true" block="true"> <description>Only notify if the Final Order Result is available</description> …. </workunit> </parallel> </sequence> A thorough treatment of each of these artifacts can be found in the CDL documentation, 9.3 CDL as a Choreography Expression Language for HL7 SOA Interoperability Paradigm 9.3.1 PIM-Level Choreography The above expression of behavior has elements of Conceptual Model, PIM, and PSM. See Section 4 for a discussion of how CDL helps to form a structure to embody existing service standard work and to tie it to localized artifacts.. 9.3.2 PSM-Level Choreography Tooling For the purposes of the SOA Interoperability Paradigm, the CDL expression can be the imported into the open source tool, Pi4SOA. The Pi4SOA tooling allows certain extensions to the CDL standard that don’t limit the efficacy of CDL as an expression of inter-system behavior. Rather, the extensions allow the choreography to be tailored for particular environments – interaction operations can be bound to queues or operations on a WSDL for example. The Pi4SOA expression of the choreography can be considered the PSM, especially since it allows conformance testing and encourages test-driven development.
    • 9.3.3 Using CDL for Test Driven Interoperability The CDL tooling (pi4SOA) provides the ability to both express choreographies and to test them in a rigorous way. This allows the CDL expression to not only embody PIM and PSMs- level expressions of business process modeling, but in conjunction with other models and artifacts, to form a vital piece of a fully elaborated architecture. This architecture has sufficient quality components to be developed in an implementations phase and tested in a quality assurance phase. 9.3.4 Conclusion CDL offers a granular approach to capturing inter-system behaviors. It provides a rigorous way to capture the logical flow of business from initiation to end result. Roles, relationships, and supported behaviors are defined, and are expressed separately from either their real-world system components or their actual implementations. CDL thus provides a way to specify behavior both locally and within the context of standardization. This allows systems to contractually bind themselves to globally defined behaviors, and to preserve the virtualization of capabilities. It should be emphasized that as a release candidate, CDL is immature in some aspects. However, the authors feel that this immaturity in no way reduces its capability to rigorously describe complex system interactions related to healthcare practice. However, in usage, CDL poses some potential problems in terms of usability. These should be addressed either in conjunction with the healthcare community or in parallel. 10Appendix A - Future Work CDL as is represents a quantum leap forward in terms of expressing behavior in a way appropriate for healthcare. It has components that are usable for both standardization and implementations. It fits well within a number of methodologies, and has extension points that work well with the well-modeled information components that characterize HL7. However, several areas of work remain to be performed. 10.1Refinement of the CDL expression language into meta-model, design artifacts, and run-time constructs. CDL within this framework offers many benefits, but the tooling and the methodologies supported by the pi4SOA toolkit are slightly at odds with the SOA Interoperability Paradigm, or more generally, full architectural specifications. The pi4SOA community should be encouraged to evolve tooling either specifically for healthcare or for the industry in general that adopts the RM-ODP viewpoints and their representations in Model Driven Architecture. For example, a PIM level choreography expressed in CDL would have tremendous applicability for HL7 Dynamic Models, especially around the concept of Application Roles.
    • By the same token, the CDL expression language includes constructs that blur the distinctions between model and meta-model. For example, the data typing that occurs at the choreography level may be better expressed in a layered model approach, or the hazy ties between CDL role-behaviors, their interfaces, the channel’s URI, and the interaction’s operation. See Section 10.3 below. 10.2Repository of Re-Usable Dynamic Artifacts In part, this is being addressed by the SOA TC’s quest for a profile registry, but that quest needs to be extended from semantic signifiers to fully elaborated functional profiles as well. Note that this cannot happen unless the loose coupling is achieved between the implemented interface, the operation, and the behavioral constructs of the CDL expression. 10.3Research to improve and extend CDL (e.g. tie Interface to Operation, also Participant required attribute of Interaction?) There are at least eight areas of deficiency that the authors have identified in the current version of CDL. 1. The binding of behaviors to roles within relationships 2. The weak binding of operations to specific interfaces via channels and interfaces. 3. There needs to be a separation between a platform independent representation of behavior and the run time expression of this behavior (an operation or combination of operations on one or more interfaces) 4. The lack of strong ties between participants within a package and participants within choreographies. Additionally, the non-existent binding between participants and supported roles should be explicit. 5. The lack of support for extended Message Exchange Patterns, especially those supported by WSDL 2.0 6. Rigorous and Deterministic Mapping between CDL and WS-BPEL, specifically the control structures in WS-BPEL that do not have one-to-one corollaries on the CDL side. 7. The lack of a meta-structure that can bind participants to real world systems 8. An examination should be made of other ways to tie HSSP conformance profiles (functional, semantic signifiers, and usage context) to CDL elements. 10.4Choreography Rollbacks, Exception Handling A number of elements from CDL were not included in this analysis, particularly the portions that define choreography rollbacks and exception handling. These elements are worth exploring in future work, especially as they offer behaviorally rich alternatives to a pure messaging paradigm.
    • 10.5Transformability between Interoperability Paradigms Work should be done to explore the applicability of CDL to the other interoperability paradigms defined in HL7