ServicesInteroperabilityParadigm_v1_01.doc.doc

530 views
469 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
530
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

ServicesInteroperabilityParadigm_v1_01.doc.doc

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. 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.
  5. 5. 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
  6. 6. 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
  7. 7. 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.
  8. 8. 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).
  9. 9. • 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
  10. 10. 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.
  11. 11. 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
  12. 12. 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
  13. 13.  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.
  14. 14. 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
  15. 15. 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.
  16. 16. 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.
  17. 17. 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.
  18. 18. 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.
  19. 19. 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.
  20. 20. 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
  21. 21. 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.
  22. 22. 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.
  23. 23. 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.
  24. 24. 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.
  25. 25. 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).
  26. 26. 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.
  27. 27. 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.
  28. 28. 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
  29. 29. 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.
  30. 30. 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
  31. 31. 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)
  32. 32. 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
  33. 33. 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.
  34. 34. 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,
  35. 35. 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
  36. 36. 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.
  37. 37. 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:
  38. 38.  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
  39. 39. 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:
  40. 40. 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
  41. 41. 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:
  42. 42. 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)
  43. 43. 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
  44. 44. 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.
  45. 45. 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
  46. 46. 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.
  47. 47. 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

×