SAEAFISCS

Levels of Interoperability Service Contract Specifications(ISCS) Return to SAEAF Table of Contents

Introduction

HL7 : Enterprise Conformance and Compliance Framework (ECCF) A Framework for Quantitative Specification and Assessment of Enterprise Integration Capabilities --

• Enterprise Architecture
• Conformance Assertions
• Compliance Assessment

2008 07 24

John Koisch (Booz Allen Hamilton)

Charlie Mead (Booz & Company)

Added by Tony 20:28, 13 August 2008 (UTC)

Overview

The ultimate goal of an Enterprise Conformance and Compliance Framework (ECCF) is to have a testable, traceable, and tractable approach to specifying and quantitatively measuring – through human, semi-automated, or fully automated processes depending on the context – the conformance of a given application, tool, service, or software component to a given enterprise architecture specification within a given organization or organizational context. In particular, Conformance Testing is applied against a defined set of Conformance Assertions defined at specific Integration Points and results in a set of Compliance Measurements that determine whether an organization, application, tool, service, and/or infrastructure component is Conformant or Non-Conformant. In particular, the notion of Conformance vs Non-Conformance to a given Enterprise Architecture Specification is determined with respect to a set of Conformance Assertions collected in a Conformance Specification. Based on the set of Conformance Measurements, the organization or component is classified as being compliant at a particular Compliance Levels.

In the context of HL7, the ECCF will enable effective governance and expectation management within the federated topology that characterizes the HL7 community, including its component people, organizations, and software systems. In addition, HL7 will utilize the ECCF to deal effectively, coherently, and non-ambiguously with the various exceptions, requests, and localized needs of the adopters of HL7 applications, tools, services, and/or infrastructure components, while at the same time facilitating intra-and cross-enterprise semantic interoperability as desired or required in a particular context.

ECCF Definitions

Following are definitions of the core concepts involved in discussing the ECCF and its component parts:

• Enterprise Architecture Specification (EAS): Identifies and defines the ideas, people, processes, and artifacts that together comprise the framework for defining, designing, building, and deploying technologies that realize and support an organization’s mission, vision, strategies, and operation. An Enterprise Architecture Specification is a multi-dimensioned, multi- variant construct that, among other things, specifies the way that the organization’s information technology is both perceived and utilized by both its internal organizational stakeholders (including both people and systems) and external trading partners (including both people and systems). (This contextualizing of an EAS to one that is ultimately manifest in one or more technologies/implementations distinguishes the EAS referred to in the context of this discussion to the non-technical EAS which defines the ‘business architecture’ of a given organization.)
• Conformance Assertion: A testable, verifiable statement made in the context of a single RM-ODP Viewpoint (ISO Standard Reference Model for Open Distributed Processing, ISO/IEC IS 10746|ITU-T X.900). In particular:
  • Conformance Assertions may be made in four of the five RM-ODP Viewpoints, i.e. Enterprise, Information, Computational, and/or Engineering.
  • The Technology Viewpoint specifies a particular implementation /technology binding that is run within a ‘test harness’ to establish the degree to which the implementation is conformant with a given set of Conformance Assertions made in the other RM-ODP Viewpoints.
  • Conformance Assertions are conceptually non-hierarchical. However, Conformance Assertions may have hierarchical relationships to other Conformance Assertions within the same Viewpoint (i.e. be increasingly specific). They are not, however, extensible in and of themselves.
  • Extensibility of a given Conformance Specification in the context of an EAS is defined through additional Conformance Assertions from the Enterprise, Information, Computational, Engineering and/or Technology Viewpoints (most commonly the latter two) as manifested in specific instances of Platform Specific Models.
  • Localization indicates custom modifications or other alterations (including ignoring) specific Conformance Assertions in a local context which results in non-compliance to the overarching EAS. Specific Localization semantics will be identified in the context of the Conformance/Compliance assessment process.

• Conformance Specification: A collection of Conformance Assertions made in the context of an EAS.
• Integration Point: A physical realization of a Conformance Assertion that allows verification of the Assertion. Compliance testing for Conformance/Non-Conformance to a particular Enterprise Architecture Specification occurs exclusively at defined Integration Points.
• Conformance Measurement: A binary-valued variable that reports whether a particular technology binding’s implementation of an application, tool, service, and/or infrastructure component satisfies a particular Conformance Assertion, i.e. is Conformant or Non-Conformant based on one or metrics defined by the Conformance Assertion as being essential for Conformance to the Assertion.
• Compliance Assessment: A process which results in a single descriptor – a Compliance Level --applied to a specific application, tool, service, or infrastructure component in the context of an Enterprise Architecture Specification. Compliance is a function of:
  • A set of static Conformance Assertions collected as a Conformance Specification; and
  • An accompanying set of dynamic processes that define the responsibilities and activities involved in performing Conformance Measurements. The Compliance of a given application, tool, service, and/or infrastructure component within the context of an Enterprise Architecture Specification is expressed as a Compliance Level. In cases where different components of an overall system are assessed to be compliant at different Compliance Levels, the lowest level of compliance shall be used for description of the overall system.
• Compliance Level: A classification of the degree of “compatibility” of a given application, tool, service, and/or infrastructure component to a Conformance Specification. Compatibility Levels establish categories of compatibility which reflect HL7 requirements for semantic interoperability both internally (i.e. within the HL7 community) as well as with other organizations.
• Candidate Component: an application, service, tool, or infrastructure component that is evaluated for compatibility with the HL7 EAS.

Figure 1: A representation of the relationships between a Candidate Component implementation (i.e. Organization, Application, Service, Tool, or Infrastructure component) and the HL7 Enterprise Architecture Specification. Within the EAS, a Conformance Specification provides the basis for measuring Compliance and, as a result, determining a Candidate Component’s Compatibility Level. Note that the EAS in which a Conformance Specification exists is only concerned with the Candidate Component’s functionality at defined Integration Points and only indirectly system design and architecture. However, the development of these components is intended to be developed and managed in an iterative and incremental software engineering process (such as UPF). This loose coupling is a key distinction between the current HL7 Compatibility Guidelines and the ECCF defined in this document.

With the publication of the HL7 Enterprise Conformance and Compliance Framework (ECCF), HL7 is defining both the framework and structure around which specific Conformance Assertions – specified as part of the HL7 Core Enterprise Architecture Specification – will be declared by the Composite Architecture Team(s) using the RM-ODP paradigm, and a set of processes whereby a given application, tool, service, and/or infrastructure component’s implementation technology binding can be measured and certified as having a particular Compliance Level.

(Note: There will never be a “complete set of Conformance Assertions” that can be frozen because they completely describe the domain of the Enterprise Architecture (or, for that matter, the Enterprise Architecture of any domain as fluid as that of Translational Medicine.) Rather, the set of Conformance Assertions that collectively define the Conformance Specification described in this document will be continuously, iteratively, and incrementally defined and evolved through interactions and collaborations between the various project teams, vendors and HL7 /HL7 community stakeholders, and the domain-specific Composite Architecture Teams (CAT’s) that are being put in place to specify and govern HL7 enterprise architecture.)

HL7 context for the ECCF:

Definition of Compliance Levels The fundamental operative vision of HL7 is the sharing of clinical and research data and information between integrated ‘compatible’ systems across the translational medicine and research continuum. The depth, breadth, and complexity involved in realizing this vision operationally was first addressed in the HL7 Compatibility Guidelines with its associated tooling and infrastructure. The ECCF is the next step in achieving the goal of “integration and information sharing from bedside to bench and back.”

In particular, the ECCF evolves from the experience of multiple aspects of that solution set, both in terms of what was successful (e.g. the registration and advertising of static semantics), and in terms of gaps that were identified (e.g. lack of interaction semantics, specific technology dependencies, etc.). It seeks to further delineate distinct quantitative boundaries within which compliant organizations and the technical systems they build or buy advance the main mission of the enterprise (“curing cancer through informed (clinical) research”), while simultaneously deriving benefit from the overarching notion of a “unified topology” of (mostly) federated and distributed systems.

The motivation for the notion of “compatibility” – and, in certain well-defined contexts and situations, semantic “interoperability” – in intra-and inter- enterprise systems is essential to defining and governing an enterprise and its supporting architecture. It shapes the implementation, extensibility, durability, and usability of the enterprise’s component software systems. A well-defined conformance/compliance-assessment strategy – including a set of conformance specifications exhibiting quantifiable integration points --facilitates the development of compatible software solutions both within and across the enterprise despite the existence of numerous requirements that, at least at some level, may seem disparate or even at odds with each other.

The idea of conformance is deceptively straightforward: it relates an implementation of a system to an implementation-independent standard that has been defined and accepted by an organization within a particular jurisdiction. A compliant system is simply a system that realizes, uses, or depends on the ability of the system to satisfy certain Conformance Assertions as defined in a Conformance Specification that exists within an Enterprise Architecture Specification. This discussion defines the two essential components of an ECCF, i.e., the two complementary constructs that together define both the structures and static semantics against which conformance assertions can be made, as well as the behaviors and dynamic processes by which tools, services, applications, or infrastructure components can be tested to be compliant or non-compliant to the stated conformance criteria. In particular, the two (sub)Frameworks that collectively define the ECCF are:

• Enterprise Conformance Specification Framework (ECSF) (Section 2). The ECSF is based on relevant aspects of both the ISO standard RM-ODP and the OMG’s Model-Driven Architecture (MDA) approach to component development. The ECSF specifies the details necessary for a developer, owner, or other stakeholder of a particular tool, service, application, or infrastructure to be able to quantitatively specify relevant aspects of the component and/or utilize existing aspects as they apply in the overall context of the HL7 ’s Enterprise Architecture Specification. The quantitative comparison of Compliance Assertions made by the Candidate Component’s development team and the existing Enterprise Architecture Specification enables (as described below), the HL7 ’s Composite Architecture Team(s) to determine the Compliance Level of the Candidate Component. This process includes the information necessary for a stakeholder to determine how effectively they will be able to semantically interoperate within the HL7 context, as well as specifying the modifications they might choose to make to increase their compliance and therefore their interoperability. (NOTE: in this context, the term ‘semantically interoperate’ means the ability to share data, information, and/or coordinate functionality with other tools, applications, and/or services within the HL7 topology in either an automated, dynamic, or pre-coordinated fashion.) The ECSF can be thought of as the framework in which the ‘static’ aspects of conformance assessment are detailed.
• Enterprise Compliance Assessment Process (ECAP) (Section 3). The ECAF defines the roles, processes, and tools necessary to quantitatively test and report on specific instances of tool, service, application, and/or infrastructure compliance (or non-compliance) of a Candidate Component to the conformance criteria developed in the context of the ECSF.

In combination, the ECSF and the ECAP will allow HL7 to effectively govern the HL7 community with respect to the design, development, deployment, or purchase of technologies to support the translational medicine/translational research vision of HL7 . Figure 2 delineates the Compliance Levels that frame the HL7 ’s ECSF and ECAP.

Figure 2: Layers of Specified Conformance and Compliance that emerge from the ECSF

These layers are additive such that conformance to Level 1 implies conformance to Level 0, Level 2 implies Level 1 and 0, and so forth. They are discussed in detail below.

The purpose of the Level specifications is twofold:

• To quantitatively define a means for organizations to integrate with HL7 without necessarily adopting common technology stacks, implementations, or other technology bindings; and
• To provide the basis for a still-emerging architectural maturity model that allows for a layered and objective assessment of the artifacts that collectively enable intra-and inter-enterprise architectural compliance in the context of semantic interoperability.

Specifying Conformance Assertions: The HL7 Enterprise Conformance Specification Framework (ECSF)

Overview

At the heart of the ECCF is the Enterprise Conformance Specification Framework (ECSF), a tiered approach based on the OMG’s Model-Driven Architecture (MDA). As part of its commitment to the formal specification of Enterprise Architecture, HL7 has adopted this layered, systematic approach to defining specifications for all of the technical components that collectively define its enterprise architecture, i.e. its applications, services, tools, and infrastructure components. This section discusses this framework in detail. It is important to note that the following discussion is a description of the framework in which Conformance Assertions are made and Compliance is assessed. It is not, per se, a statement of a particular set of Conformance Assertions. As noted above, these will be developed – and continue to evolve --over the coming months through the collective efforts of development teams, vendor and community input, and CAT oversight and guidance.

Context for Conformance Assertions

Conceptually, the ECSF is defined by overlaying three “specification contexts.” Note that although any of the three could be taken on its own merits, the elimination of any one from the whole blurs the overall focus of what it means to be “compliant” within the realm of the HL7 /HL7 enterprise architecture. These are depicted in the Figure 3 and discussed below. Figure 3

Figure 3: The three specification contexts that collectively define the overall context in which Conformance Assertions and Compliance Assessments are defined and performed. The red dot identifies the collective/fused point-of-view of the three that collectively define the HL7 ECSF

Enterprise Architecture

At the HL7 , enterprise architecture (i.e. enterprise architecture perspective as opposed, for example, to a narrower system architecture or a non- computationally-based ‘human business’ perspective) provides a broad context from which to approach defining an ECCF and, as a consequence, asserting enterprise-wide Conformance Assertions. In particular, the enterprise architecture perspective focuses on the enterprise-wide processes, people, ideas, and artifacts that define the activities, information, and integration contexts that are involved in achieving both intra- and inter-enterprise interoperability (i.e. interoperability between applications, tools, services, and/or infrastructure components) for the purpose of supporting discovery “from bedside to bench and back.” For example, the HL7 Enterprise Architecture defines certain components and pieces of infrastructure that are essential to nearly all of its business, e.g., an enterprise representation of a person. Thus, a standardized set of descriptors and behaviors/interactions with Person instances are deemed to be fundamental to the way that technology is defined, developed, and deployed. In particular, a quantitative awareness of the Conformance Assertions associated with a Person ensures that all applications, tools, services, and/or infrastructure components that utilize the Person concept use common architectural and implementation patterns, thereby enabling consistent Person semantics within either a federated or centralized deployment topology. This may mean, for instance, that a person's identifier is unambiguously represented so that cross-organizational clinical research can be facilitated. Enterprise Architecture requires this level of consistency even though it may not emerge solely from a user’s or single- component-developer’s perspective.

In summary, the HL7 Enterprise Architecture specification context makes the “Enterprise” a stakeholder in every project to facilitate the discovery and definition of those requirements that make the whole more than simply the sum of its combined parts.

Computable Semantic Interoperability

The goal of Computable Semantic Interoperability (CSI) is to provide the quantitative foundations for the semantic components (e.g. data, information, process, etc.) that support the Enterprise Architecture. CSI is facilitated – but not guaranteed --by four essential aspects of the technical components within a realized architecture:

1. )A common domain analysis model of shared static semantics (static and dynamic).
2. ) The binding of each attribute in the static information model to a robust data type specification (e.g. the HL7 V3 Abstract Data Type Specification / the ISO 21090 Data Types Standard).
3. ) A rigorous and reproducible methodology for binding static attributes to terms from concept-based terminologies.
4. ) A formally-defined process for defining the static structures and interaction profiles that collectively define the particulars of the information exchanged between trading partners.

Note, however, that although the above framework as traditionally applied (e.g. in object-oriented design/programming) is concerned with both static and dynamic semantics, it does not specifically address how specific information exchanges or component interactions are described, registered, advertised, discovered, bound to particular solutions, or governed. These concerns are addressed within the specification context of Services-Oriented Architecture and its focus on the specification of service interfaces (“contracts”).

Services-Oriented Architecture

A Services-oriented Architecture specification context provides a superstructure for the rigorous binding of semantic constructs to technical artifacts which may then be composed (“choreographed”) into any number of semantically valid processes/workflows (“orchestrated”) to provide a specific business-oriented solution. In particular, the SOA specification context utilizes coarse-grained, business-focused interface specifications (“contracts”) which can be used to define a robust, flexible Enterprise Architecture Specification that can agilely adapt to a changing IT environment. SOA provides a concrete implementation pattern for the architecture by building on four concepts:

1. ) Contracts which specify the semantics of a given service
2. ) Business-focused Interfaces which realize contracts
3. ) Governance which focuses on the interface
4. ) Service specifications are technology-independent

Note that a “system” in the context of a SOA represents a reusable component within the larger Enterprise Architecture (e.g. an application, service, tool, and/or infrastructure component). Unless otherwise specifically stated, the following discussion uses the terms component and system interchangeably.

Designing by Contract – Conformance Specifications

The idea of “Design-by-contract” was first formally articulated by Bertrand Meyer nearly 20 years ago. As it is applied to enterprise component integration, the term denotes the idea that software components should interact by voluntary participation in a well-defined contract. More recently, referring to Martin Fowler’s Accountability Pattern (circa 1998), one would identify one of two components participating in the contract as the Commissioning Party (CP) in the interaction and the other as the Responsible Party (RP). In theory, contract-based integration takes into account all of the semantics of integration as well as the context in which the integration takes place. The HL7 ECSF defines sets of semantically-explicit component specifications that drive integration and interoperability using the five RM-ODP Viewpoint specifications and their interoperability assertions (previously defined as and equivalent to Conformance Assertions) defined at specified Integration Points (see Fig. 1).

The Five RM-ODP Viewpoints -Assertions and Specifications

While architectural specifications can be defined in a number of ways, the ECSF specifies its conformance points for integration by using the Reference Model for Open Distributed Processing (Reference Model for Open Distributed Processing; ISO / IEC 10746; [http://www.rm-odp.net]. Figure 4: RM-ODP's multi-dimensional structure defines five non-orthogonal, non- hierarchical Viewpoints that can work separately or in conjunction to define a system and allow for specific Conformance Assertions concerning the Why? (Business Enterprise), What? (Informational), How? (Computational), and Where? (Engineering/Deployment) of a particular software component. The fifth Viewpoint – Technology – represents a technology binding that realizes attempts to satisfy the Conformance Assertions made in the other Viewpoints and can thus be thought of as answering the question True?

As shown in the figure above, RM-ODP defines five non-orthogonal, non- hierarchical Viewpoints, any one of which is capable (at least in theory) of completely describing a given system. The non-orthogonal nature of the five RM- ODP Viewpoints allows each to inform and be informed by the others through Conformance Assertions. All assertions are quantitatively verified in the Technology Viewpoint with the end result being a measure of system compliance to a defined set of conformance specifications defined in the context of an ECCF.

The value of this multi-dimensional specification process is, at least, two-fold:

1. ) The essential point that any system can be completely and validly specified using any single Viewpoint, which means that there is equivalence between all Viewpoints; and
2. ) Conformance assertions made by one Viewpoint may be consumed by the others.

In practice, this means that it is incumbent that the specification process ensure that one Viewpoint’s assertions not be ignored, de-prioritized, or not aligned by or to the others, i.e. each Viewpoint is of equal importance (from an Enterprise Architecture perspective) when compared with the others’, i.e. the process serves as a check on the overall consistency of the collection of Conformance Assertions from all Viewpoints. In a fundamental way, this interplay between the Viewpoints serves as a Quality Requirement whose Fit Metric is the collective set of Viewpoint assertions that circumscribes the specification’s definition, specification, design, and implementation.

Note that RM-ODP defines four types of Integration Points that serve to focus the viewpoint specifications. This classification is not materially important to the description of the ECSF, but is included here for future reference. The four types are: i) Programmatic (establishes a point of integration at which one component may be substituted for another); ii) Perceptual (A reference point at which there is some interaction between the physical world and the component); iii) Interworking (A reference point that allows communication between two or more systems); and iv) Interchange (The point at which an external storage medium is introduced into a system). Integration Point types may be used in the future to further classify the Compliance Assessment Processes.

Applications and Service Specifications

Components within the Enterprise Architecture can be sorted into two broad categories: Service Providers (analogous to RPs in the Fowler pattern) and Service Consumers (analogous to CPs in the Fowler pattern). (NOTE: a single component may function in both roles.) Software development of either type of component is facilitated by tooling that supports the Enterprise Architecture Conformance and Compliance Framework (ECCF) and its goal of providing a rigorous semantic description, registry, advertising, discovery, and usage of each component.)

The HL7 ECCF can be viewed as a (modified) instance of the OMG’s Model Driven Architecture (MDA) approach. The models are specified using the five RM-ODP Viewpoints as a general framework, and as such, represent a collection of Conformance Assertions arising from the Enterprise, Informational, and Computational Viewpoints. When realized through engineering (also known as the ‘deployment topology’ or ‘Engineering Viewpoint’) and technology bindings (aka ‘Technology Viewpoint’), they represent sets of testable and verifiable Integration Points. These MDA-driven models emerge incrementally through the software engineering process, and in many ways simply serve as containers for the Viewpoints’ specifications. These containers (also known as ‘service or application specification models’) serve as concrete structures that can be evaluated through an overarching enterprise architecture governance process. The models/containers for both Service and Application Specification are shown below.

Figure 5: Models provide continuity and traceabilty between levels of specification. The three containers for the models – conceptual, logical, and platform – serve to provide simple formats for governance

Functional Specifications(FSS) are intended to provide the business context and motivation for the component’s development and use. Conformance Assertions are presented in the Functional Service or Application Specifications and include the Functional and Quality Requirements pertaining to the enterprise and the traceability between those and the informational and computational components. Functional Specifications include some or all of the following:

• Vision
• Scope
• Business Context and justification
• Storyboards
• Use Case Specifications (Activity Diagrams)
• Use Case Realizations
• Business Operations, including traceability
• Business Interfaces
• Information Model Bindings
• Architectural Proof-Of-Concept/Mockup
• Wire Frame Diagrams
• Dependencies
• Glossary

Logical specifications(LSS) focus heavily on refining the computational and informational specifications. The information models are transformed from analysis models to an implementation model, while the computational elements focus on detailed designs of the interfaces involved in the appropriate semantic exchanges. To the degree possible, the conformance assertions are presented in a Platform Independent Model (PIM) and focus on the granularity and composition of the interface specifications for services or the workflow components for applications without applying the details of a particular technology. Logical specifications include some or all of the following:

• Design Guidelines
• Business Focus
• Interfaces
• User Interfaces
• User Workflows
• Operations
• Implementable Models
• Choreography and Dynamic Model

Platform-bound specifications(PBSS_ bind the logical specification to a platform specification creating a Platform Specific Model (PSM), thus surfacing the engineering and technology viewpoints. The PSM is intended to primarily provide a set of testable integration points that provide direct traceability through the models’ structure from the business requirements and enterprise viewpoint specifications. Thus, a particular application is contextualized within a validated enterprise need and policy; or a particular service realization embodies reusable informational and computational specifications, that in their turn, directly trace business requirements. Platform-bound specifications include some or all of the following:

• Platform Guidelines
• PSM
• Business Focus
• Interface Realizations
• User Interfaces
• Presentation Logic, Session Logic
• Workflow Realizations
• Operations
• Message Schema
• Choreography

A fully specified system includes all three models, embodying assertions from all of the RM-ODP Viewpoints. The package allows direct traceability from business drivers through to technical realizations.

Specifying Conformance for Compliance Assessment

As noted above, Conformance Assertions are associated with specific Integration Points at which a particular behavior and information binding must occur. Conformance specifications are provided as part of the Enterprise Architecture and are consumed by projects with the intent of creating compliant systems. Project teams building components that are identified through the governance process as essential to supporting the Enterprise Architecture are notified as such, and are expected to create specifications that are built in accordance with the Enterprise Conformance Specification Framework (ECSF) and can therefore be validated through the Enterprise Compliance Assessment Framework (ECAP). The ECSF defines four Compliance Levels (see Table 1). As discussed below, each Level has associated with it a number of artifacts or formal specifications which can be evaluated through Architectural governance processes to determine the level of Compliance of a particular organization (Domain Level) or component (Blueprint, Design, or Platform Compliance):

Domain-Level Compliance – Level 0

Specification models as described above are not involved in the Domain Level of Enterprise Architecture Compliance. Rather, this level assesses organizational compliance to the basic bedrocks around which the HL7 Enterprise Architecture Specification is defined. Artifacts for submission for Domain-Level Compliance include:

• Organizational Architecture Maturity Survey.
• Compliance with HL7 Best Practices for Component Development/Deployment.
• Adoption of HL7 Enterprise Architecture Specifications
• Adherence to the ECCF, including the ECSF and ECAP Activities supporting the production of these artifacts include:
• The adoption of a common domain model, data type specification, and terminology bindings as determined by the enterprise.
• When creating (as opposed to simply consuming) conformance specifications, the adoption of the Enterprise Specification framework.
• The usage of appropriate components of the infrastructure, including tooling, architectural patterns, development patterns, and implementation patterns.
• The usage of appropriate components of the extant or emerging architecture.

Blueprint-Level Compliance – Level 1

Project teams create Blueprint Candidate Conformance Specifications to achieve Blueprint-Level Compliance by creating Conceptual Functional Models of one or more components that their system exposes. Artifacts submitted for Blueprint-Level Compliance include:

• Named dependencies on other parts of the HL7 architecture
• Relevant standards and their implications
• Implementation considerations
• Publication of the Blueprint Specification
• Collected conformance assertions by viewpoint that represent the architectural requirements for the system

Activities supporting the production of these artifacts include:

• To the extent possible, they must establish dependencies on other Blueprint-level capability specifications for both services and applications.
• The usage of functional service and application specifications for reusable, business-focused capabilities
• Adherence to the assertions of Computable Semantic Interoperability, including referencing a common domain model (or its elements) and the utilization of a robust data type specification in the creation of an analysis model for the specification.

Design-Level Compliance – Level 2

Project teams create Design Conformance Specifications by refining Blueprint Specifications and by creating Platform-Independent (logical) Models. The refinements should be focused by the Information Viewpoint (by creating an Implementable Model from the Information Model) and the Computational Viewpoint (Operations grouped into interfaces, as well as rigorous descriptions of behavior). Artifacts submitted for Design-Level compliance include:

• Applicable Implementation Patterns
• Applicable Architectural Patterns
• Design considerations
• Suggested technology bindings and consequences
• Publication of the Design Specification including collected conformance assertions by viewpoint that represent the architectural requirements for the system

Activities supporting the production of these artifacts include:

• To the extent possible, they must establish dependencies on other Blueprint-and Design-level capability specifications for both services and applications.
• The adoption of appropriate Logical Specifications
• For services, the utilization of registered logical service contracts, as well as publication of subsequent service contract information that is bound to the project’s implementation artifacts.
• The utilization of specified dynamic models for the use cases that are implemented by either the application or the service. This dynamic model can include either the intended usage, the virtualized behavior, or both.
• The usage of the HL7 ICP (see below) to create the implementable information models
• The adherence to certain architectural patterns that are expressed or implied through the use of existing specifications. For example, this might mandate that certain information classes are handled in a particular way, or that certain services adhere to certain HL7-specific business rules.

Platform-Level Compliance – Level 3

There can be more than one Platform Specification for each Design Specification in that each Platform Specification constrains the Design Specification by specifying technology. A Platform Conformance Specification includes one or more Platform-Specific Models, as well as some or all of the following artifacts, all of which are submitted for Platform-Level Compliance:

• Implementable technology stacks
• Implementation Guides
• Deployment Models
• Deployment Configurations and configuration parameterizations
• Behavioral bindings
• Software releases in Deployment Packages
• Test Harnesses and test messages
• Publication of the Platform Specification
• Collected conformance assertions by viewpoint that represent the architectural requirements for the system

Activities supporting the production of these artifacts include:

• Actual implementation of the Platform-Bound Specification (and optionally the technology stack if available) or an implementation that is directly complies with a provided implementation guide. This includes the usage of deployment configurations for standardization, localization, and / or extension as deemed appropriate.
• The usage of the HL7 ICP (see below) to create the message serialization models
• The instantiation of message models, content models, serialization models, and functional end points in coordinated message exchange patterns to realize real business value
• Conformance with the collected conformance assertions that are part of the Platform Compliance Level
• The utilization, as appropriate, of installation tools and deployment patterns
• The adoption of test harnesses as part of the specification to insure compliance

Compliance Levels: Tabular Summary

Table 1: Compatibility Levels including relationships to HL7 Infrastructure components and conformance points

Measuring Compliance: The HL7 Enterprise Compliance Assessment Process (ECAP)

As discussed above, the ECCF specifies a set of layered Integration Points at which Enterprise Architecture Compliance can be measured / assessed. The Enterprise Compliance Assessment Process (ECAP) contextualizes these specifications by defining a set of processes and associated governance for compliance assessment including the generation and review of artifacts and utilization of testing patterns, thereby allowing conformance asserted by a given component to be tested in the context of the Enterprise Architecture Specification. An overview of the process is shown in Figure 8. The following sections discuss the Governance of the Compliance Assessment activities, and presents several Compliance Assessment processes which differ --not in final outcome or in adhering to the overarching ECAP-based Compliance Assessment to existing Conformance Specifications – but rather in their participants and motivations.

Compliance Certification

Compliance Certification is the process that establishes that a particular technology binding adheres (‘is compliant with’) one of the four Compliance Levels defined within the ECCF. It is expected that Compliance Certification activities will be managed by the relevant Composite Architecture Team (CAT), i.e. the CAT that has provided oversight and input into the assertions that define the capability being sought. Compliance Certification is based on a number of factors, including, but not necessarily limited to, business context, intended usage, deployment context, and implementation considerations.

Figure3:An overview o fthe Conformance Assessment process.

This activity is realized over a spectrum modulated by the degree at which an organization desires to comply with HL7 Enterprise Architecture Specifications.

Governance

A critical success factor in implementing the ECCF is the notion of governance. Although the term “governance” can have one of several meanings in any one of several contexts, the ECCF uses the term to describe processes and artifacts necessary to move beyond simply specifying interoperability grammars based on tooling, interoperability “guidelines” open to variable interpretation or implementation, and /or mechanisms for forcing certain implementation patterns to be utilized by software development teams. In particular, the ECCF is designed to address the problem that governance implemented around such strategies is eventually outpaced by the sheer volume of specific requirements that are either not met by the implementation patterns or omitted from a particular interpretation of a guideline, leading to exceptions, omissions, and ultimately unpredictable semantic interoperability, i.e. these exceptions, taken together, undermine the value of, and motivation for developing, a conformance strategy in the first place. The end-result of this ‘under-specified’ conformance environment is often the situation in which tools, services, application, and infrastructure only partially realize their value, duplicate functionality, and/or do not meet interoperability expectations.

In contrast, ECCF governance is designed to allow HL7 to view the concept of ‘compatibility’ in the larger context of technology neutrality and enterprise architecture. The ECCF – through the instantiation of its component the ECSF (Section 2) and the ECAP (this Section) --allows HL7 to follow a unified enterprise compliance strategy focused on its overarching Enterprise Architecture Specification. (NOTE: Although this document discusses ECCF from the perspective of structure, function, and governance within HL7 , it is expected that it can be used as an ECCF model in other contexts, e.g. commercial pharmacy, “BigHealth,” etc.). Governance is both a facilitating and an authoritative process that imposes the specification process (discussed in the ECSF detail above) and its products on projects within HL7 ’s jurisdiction. Thus, one aspect of Governance is the publication by the CATs of the required Conformance Specifications. These must be adhered to by a development organization creating a Candidate Component in order to achieve a particular level of Compliance.

The degree to which a developer of a Candidate Component chooses to adhere to the Conformance Specifications will be directly and quantitatively manifest through specific evaluation of compliance with specific Conformance Assertions. In fact, it is expected that one of the outcomes of ECAP-based Governance will be the practice of project teams adopting existing compliance-validated artifacts as a manifestation of a maturation of the overall process of producing interoperable components in the HL7 / HL7 enterprise architecture. Additional governance contexts include motivation from business contexts, vendor input, etc. An example of several contexts is illustrated in the sections that follow.

Composite Architecture Teams

Composite Architecture Teams (CATs) provide periodic architectural governance to project teams building Candidate Components. Each CAT is composed of representatives of the five Viewpoints and is chaired by a Governance Domain Chief Architect. The CAT provides the following oversight/governance to project teams:

• Consumption of relevant pre-existing Conformance Specifications;
• Milestone-based assessment of Conformance Specifications being created by the team for use beyond their project’s scope;
• Facilitated communication between relevant parties concerning the integration of systems and shared components;

In addition, the CATs provide the Enterprise ongoing input and architectural recommendations regarding emerging Compliance Specifications, including constraints on usage and strategies that develop due to a particular architectural path taken by a project team for well-documented reasons (e.g. deployment decisions driven by performance or regulatory requirements).

Collectively, these activities serve to insure that the enterprise is a stakeholder in each project’s design and architecture. Note that there are many aspects of development that, while within the purview of the CAT, are not intended to be influenced through the architectural governance process and may thus be actually ‘governed’ very little over the course of a particular development lifecycle. For example, a given project’s desire to use a particular database solution would only be subject to CAT governance if its selection materially affected the consumption of a conformance specification. The basic flow of the CAT governance described is shown in Figure 7.

Bootstrapping

The operationalization of CAT Governance may occur, in certain situations, over the course of a Candidate Component’s development lifecycle, thereby enabling the Component’s development team assert compliance to its own artifacts. This ability of the EAS to be “bootstrapped” is supported by an open, transparent Compliance Assessment Process performed by an impartial CAT team. This sequence is outlined in the diagram below.

Figure7:Overview of th eCATProcess,including its activities in context and with the project team.Note the mapping between a project’s RUP phases and the governance activities.

Conformance Review Process

The Conformance Review process deserves special mention as one of the oversight/governance activities of a CAT. This process begins with a project’s establishing its models for deployment, which serve to provide direct traceability between the business capabilities that the project is attempting to utilize and the actual technical components that either consume or expose these capabilities. The Project Architect, in conjunction with the project team, defines the conformance assertions that the Quality Assurance process will verify during the course of testing. Conformance is asserted against functional profiles, i.e., against a set of usage-specific, business-appropriate constraints on the service. This means in practice that while a service specification may cover many use cases, only a subset need to be defined, modeled, and implemented for a service to be tested, and it will only be tested against those uses that are appropriate. Once testing is completed, the CAT will provide documentation of testing and subsequent Level assignment based on the verification of these assertions. A graphical representation of this process is shown in Figure 8.

Figure8:Example conformance testing process. Note that conformance testing is an activity that has high visibility with the cross-enterprise teams. This part of the process is expanded from the previous diagram

CAT-Proxy Project Architects

A project’s awareness of Enterprise Architecture is facilitated by the embedding of one or more architects in the project’s development activities as part of an architecture team. The team’s architect (or architects) actively represents the CAT in the day-to-day activities of the project, serving as enterprise architect, architectural mentor, and facilitator. Activities may include the authorship of specifications, the integration of third-party standards into the project’s designs, and the assembly of conformance assertions from the specifications underlying the final implementation. The diagram above serves as an example of the project architect’s role in the conformance testing process.

Additional Examples of CAT Governance

Business Case Facilitation

The specifications themselves, driven by the business needs and capabilities of a particular domain, may serve as a mechanism that motivates an organization to adopt the interoperability standards of HL7 ’s Enterprise Architecture. In the example in the diagram below, an organization has identified a key business case for interoperating with HL7 . The CAT may, in this case, facilitate the discovery of the key artifacts that support the organization’s need. At each specification level, the organization makes a decision to build or buy, and in the case of the Platform Specifications with Technology Bindings, to deploy. Each implementation is tested for compliance.2

Note: It may be the case that certain products may achieve partial, in fact near-total, compliance out of the box. This will be evaluated on a product-by-product basis.

Figure4:Sample Deployment Facilitation. The CAT interacts with a consuming organization that can state its business, architecture, and technological requirements.

Project Development Dependencies

Projects developing new capabilities within the HL7 / HL7 network may identify a requirement for capabilities that already exist within the specification catalog. In these cases, it is the CAT’s role to insure that the capability is developed in a compliant fashion. In the example below, the CAT determines that the project has a dependency on an already specified capability within the HL7 Enterprise Architecture. The project team with the embedded project architect must evaluate the specification stack, including technology if it exists, to determine reusability. If the CAT determines that there are limitations in the existing implementation, then it may decide to define a new technology binding. This will in turn be tested for compliance to insure congruence with the Enterprise Architecture.

Figure5:Sample project facilitation.The CAT team determines that a required capability has already been specified, and the project team must evaluate the specification for usability

Vendor Facilitation

In another situation, one or more Vendors may have identified a number of core capabilities within the HL7 Enterprise Architecture that provide valid roads to market and interactions with their customers. In some cases, the desire could be to create a simple tool or application, while in others, an entire suite of applications and coupled tools. In the example below, a vendor is provided with various specifications from HL7 , which they use to create a set of compliant components. Customers of the vendors’ products can then interoperate with the HL7 network using these components “out of the box.” This also provides owners of existing vendor components a quantitative way of informing their vendor of component enhancements that need to be made to an existing installed component to make it HL7 Enterprise Architecture (e.g. HL7 ) compliant.

Figure6:The Vendor adopts the HL7 specifications, implementing them in their own product line

Compliance Measurement

Compliance Levels – a Process Perspective

As noted above, the ultimate goal of a compliance assessment strategy is to have a tractable approach for requiring and measuring compliance with an organization’s published standards. While Compliance Measurement does have an authoritative aspect in that it may provide certain gates that project teams must work through, its main concern is to provide the foundations necessary for successful and effective development within the framework of an organization’s adopted standards.

It should be stressed that in any large organization, compliance assessment processes need to be implemented in such a way as to allow the greatest benefit to both the organization and the trading partners. In some cases, it will doubtless be of benefit for full technological solutions to be adopted by both the organization and the trading partners. However, this cannot be the only solution for integration since data and information may be shared in many ways, and component behavior may be coordinated in many contexts, i.e. integration must not be limited to those trading partners that have adopted the same technologies as the organization itself.

Project teams defining, designing, implementing a particular component – and it should be emphasized that the term ‘project teams’ can be used to designate either in-house development or vendor-based development targeted for compliance into the HL7 Enterprise Architecture --come into compliance by using Conformance Specifications in the design and implementations of their own systems. This process might be expected to be facilitated by tooling in a number of forms – see below for potential areas where tooling might support the ECSF and ECAP.

Compliance at any of the three ‘non-organizational’ Compliance levels can only be quantitatively validated via one or more actual implementations. For Platform solutions, this provides complete traceability between the implemented technology stack, as well as the Blueprint and Design specifications from which it is derived. In contrast, Compliance to either the Blueprint or Design level may be asserted and verified through the CAT-based review of appropriate artifacts which must include a testable implementation. While these implementations may not seamlessly integrate with other expressed HL7 capabilities from the HL7 Services Catalog (see Section 4), the practice of integration will be deterministically defined by virtue of the fact that each Integration Point in any integration scenario will be semantically aligned with similar business processes including the quantitative specification of defined Integration Points.

Infrastructure Supporting Conformance

In the context of an enterprise, conformance and compliance should be facilitated by an infrastructure that reflects adopted organizational standards and best practices. These might include:

• architecture and design patterns
• registries and registration processes (for example, the registration of class models or of services)
• implementation patterns (like information constraint patterns)
• the specifications that emerge from the ECSF themselves.

From the standpoint of conformance and compliance, these infrastructure components are primarily concerned with defining as many as are practically possible quantitatively verifiable Integration Points. Appropriate tooling should reflect these defined Integration Points by either enabling the creation of components that scale or reuse the specifications that emerge from the ECSF or by testing those components for compliance, that is, enabling the ECAP.

For example, the three Architectural Review stages (Figure 7) are eventually expected to be supported by tooling that reflects the specification process, the models that support it, and the RM-ODP-calibrated components that make up the models. For example:

• Modeling tools might eventually be expected to generate reports that conform to different RM-ODP viewpoints that in turn support the different levels of specification (see diagram below).
• Registration of various artifacts, such as contracts and service jurisdictions that emerge from the specification process, might be expected to follow a pattern similar to the current one for static semantic registration, providing integration points that are both testable and durable.
• Constraint Patterns (see Information Viewpoint Constraint Pattern discussion below) may be facilitated by wizards or something less structured like a UML Profile.
• Advanced Service description, registration, and discovery might be facilitated using tools to capture dynamic semantics as well as static semantics (see below).
• Compliance testing could be enabled by aggregating the various integration points defined through the specification process

Table 2: Specification Levels and Associated RM-ODP Viewpoints

The following section identifies a number of existing or hypothesized-as-needed Infrastructure Components that facilitate the cataloging of Integration Points of various systems as well as the evaluation of Candidate Component Compliance to the Conformance Assertions associated with these Integration Points. Note that while in the near term verification may occur through a combination of strictly human and / or strictly machine processes (depending on the nature of the particular Conformance Assertion being tested), ultimately the viability of a conformance and compliance strategy rests on discovering efficiencies of scale through tools and repeatable processes.

Domain Models

Biomedical Research Integrated Domain Group (BRIDG) Model

The BRIDG Model, a collaborative effort of stakeholders from the Clinical Data Interchange Standards Consortium (CDISC), the HL7 Regulated Clinical Research Information Management Technical Committee (RCRIM TC), the National Cancer Institute (HL7), and the US Food and Drug Administration (FDA), develops and maintains a shared view of the static semantics that collectively define a shared domain-of-interest, i.e. the domain of “Protocol- driven research involving human, animal, or device subjects and all associated regulatory artifacts.” (NOTE: the BRIDG Model does not currently define shared dynamic semantics; however, this has long been a desired component of the model and it is expected that in the future, the model will contain shared service definitions/conceptual specifications in the domain of protocol-driven research.)

Thus, the BRIDG Model provides a robust semantic grounding on which to base static representations of data within the Clinical Trial Management System Work Space (CTMS WS), as well as from which to derive the dynamic relationships that this data exposes. As of Release 2.0, each attribute in the static class diagrm of the BRIDG Model is bound to the ISO Data Type Specification (which is itself semantically equivalent to the HL7 Abstract Data Types (ADT) specification), thereby providing a robust model for datatypes that can be combined to express more complex semantic concepts. “BRIDG Sibling Models” are planned for other Work Spaces, with the expectation that these models will be harmonized around the semantics that are shared across Work Space boundaries (“sibling model touch points’).

Static Semantic Conformance

Through the caDSR, EVS, HL7 Thesaurus and HL7 Meta-Thesaurus infrastructure components, HL7 currently provides a robust infrastructure for cataloging and advertising static semantic around which Information Viewpoint assertion can be quantitatively validated for a given technology binding. Within the ECCF, these components provide essential portions of an infrastructure that supports a semantic SOA scaled to the enterprise and focused on CSI. In some cases, this infrastructure is supported by tooling and workflows, which, in turn, support specific implementation patterns and governance processes.

Metamodel Registry (caDSR – Data Standards Repository)

HL7 utilizes an implementation and extension of the ISO Standard 11179 Metamodel Registry specification to gather and share meta-data about ‘common’ (shared) data elements and their bindings to controlled terminologies. Combined with the Enterprise Vocabulary Services (EVS), the HL7 Thesaurus and HL7 Meta-Thesaurus (see below), caDSR provides a central registry which is home to a consistent representation of static semantics in the HL7 domain.

Terminology Registration and Binding Patterns (HL7 static semantics infrastructure (caDSR, EVS et al))

Currently, there are two primary, tightly-linked services offered by HL7 that support the need defining, maintaining, versioning, and providing a robust semantic infrastructure (robust, non-ambiguous representation of concepts, attributes, and relationships) around ‘terminologies/controlled medical vocabularies,’ i.e caDSR and EVS (and including the HL7 both the HL7 Thesaurus and the HL7 Meta-Thesaurus. Terminologies in the Thesaurus may be bound to registrations of metadata within caDSR and ultimately linked to controlled terms via the Enterprise Vocabulary Services (EVS) tool suite, thereby providing a consistent and non-ambiguous (when supplemented by human curation efforts) method of specifying static semantics and binding them to controlled value domains in business-specific contexts.

Query Language for Distributed Persistence Model (DQL)

HL7 utilizes a common implementation pattern for registering semantics and exposing them on caGRID. This effectively creates a logical persistence model that provides location and technology transparency by abstracting these two concepts away from the descriptions available through the metamodel repository. Thus configured, queries may be implemented on caGRID by querying for concepts that are annotated to data types within the metamodel registry. This provides a powerful pattern for the discovery and access of data. Note however, that this query model is better suited for some solutions than others, specifically those that can benefit from binding static semantic concepts at the data element level rather than those that require a high degree of run-time contextualization and/or interaction negotiation.

Dynamic/Interaction Semantic Conformance

There is an emerging set of components that support dynamic/interaction semantics within the enterprise. By and large, these provide parts of the framework that, first, support some form of traceability between the behaviors and functionality expressed through analysis and user input, and, second, by providing certain computational and engineering constructs to facilitate the implementation of behavioral components in the EAS.

CTMS Business Architecture Model (BAM) and Enterprise Visionary Use Cases

The Clinical Trial Management Suite’s (CTMS) BAM and the Enterprise’s Visionary Use Cases both provide context for interoperability within the clinical trials domain of translational medicine. They serve to identify --and to some degree specify --the way that business is (or should be) conducted by people/organizations/systems involved in cancer clinical trials, regardless of the tools, applications, or locations that underlie those activities. By surfacing these business cases, a more global context for various applications and services may be provided that tends to be partitioned across individual project, application, or service boundaries. For example, it is one thing to understand the business of adverse event reporting, but it is another to examine the multitude of business processes that have some dependency on AE reporting. It is expected that the CTMS BAM effort as well as other, similar efforts in other (sub)domains of the translational medicine continuum, will provide both insight and input into the development of various service specifications and Viewpoint-specific Enterprise Architecture assertions.

Logical Dynamic Models

The ECCF defines that part of the Logical Specification, and part of Design-Level Compliance, is the utilization of dynamic models in specifying the behavior and functions that support a given capability. These dynamic models include the notions of:

• when data flows
• the kinds of parties that it flows between
• interdependencies between data flows
• dependencies that this process requires

These elements need to be specified so that appropriate integration points may be defined. In certain cases, for example, it is enough for an application to simply define a dependency on certain named capabilities (say, a “Protocol Service” or a particular operation on that service). In other cases, a business process may be so defined as to specify intricacies and dependencies on other parallel processes.

The dynamic model provides a consistent means of expressing certain contextual factors (business rules) that help to explain the consumption or providing of services, such as pre-conditions, shared states, error conditions, and so on.

SOA Service Taxonomy

The SOA Taxonomy defined for HL7 provides a framework within which services reside. It represents a hierarchical set of service classifications that represent common patterns of implementation and usage, providing a set of rules that cover such issues as peer communication, referencing, granularity, and how to separate concerns. These classifications provide the basis for solving common problems apparent in the architecture, if not the implementations. In particular, the proposed Service Taxonomy defines four types of services, related to each other in a hierarchical manner:

• Process Services are virtualized business processes that represent reusable patterns of behavior. Very often, these represent realized sets of business rules that an organization has agreed upon. They are generally not concerned with the states of domain entities other than insofar as they affect the state of the process as a whole. They tend to be coarsely granulated, limiting the number of external calls made to both enhance performance and to allow for the business process in question to be appropriately scoped.
• Capability Services represent a unified, contiguous set of functions that expose some piece of business functionality explicitly and unambiguously. In general, they are concerned with business focal classes (domain classes) and their state transitions.
• Core Services are generally “function calls” or based on exposing sets of information. The functional profiles of the service are generally not focused on the state of the underlying information or in the trigger events that modify the state of that information. They tend to be focused along different lines -typically along the lines of an information profile (a RIM- based patient class, a CDA-based CCD).
• Infrastructure Services are the collections of functionality that is technology focused. In general, Infrastructure Services should not encompass business or process logic, or virtualize key domain concepts, but should expose reusable technical functionality (an email service, for example).

Figure 7: The proposed HL7 Service Taxonomy showing four types of services: Process, Capability, Core, and Infrastructure. Arrows represent consumption.

Other Infrastructure Components

(NOTE: THIS SECTION IS EXPECTED TO UNDERGO FURTHER DEVELOPMENT AS THE ECCF IS IMPLEMENTED AND DEPLOYED)

HL7 Service Description Specification

In order to be consumed/utilized by clients, Service Instances which are technology-specific manifestations of specific Service Specifications, must be described and advertised. The service description specification itself must align – or at least not be inconsistent with – other meta-meta-data standards which define the essential characteristics of a service and are/will be produced by organizations such as OASIS, CBDI, OMG, etc. Expected details expressed in specification meta-data include contract-based notions of topics such as:

• location
• role
• responsibilities
• jurisdiction
• visibility
• security context
• static, functional, and behavioral semantics
• interface specifications
• message exchange patterns
• interaction participants
• identification

HL7 Service Specification Catalog

Service, tool, and application specifications need to be cataloged and advertised for consumption. In the case of services, these specifications are expected to align with the service descriptions that describe actual implementations/technology bindings. Independent of technology, these service specifications provide a primary advertising forum for HL7 capabilities. By linking technical capabilities to business drivers, stakeholders, and motivations, the HL7 Service Specification Catalog serves as the beginning of the conversation focused on why and how HL7 capabilities can be incrementally or totally consumed by its various stakeholders, including --but not necessarily limited to --cancer centers, vendors, investigators, patients, etc.

Information Constraint Pattern (ICP)

The Information Constraint Pattern represents a common means of defining a set of Information Viewpoint assertions that are conformant to overarching domain models (e.g. the BRIDG Model). For example, this constraint pattern discusses in detail the means by which a domain analysis model (DAM) is bound to terminology, constrained to an implementable model, transformed to a serialization model, and ultimately forms type-specific representations of static data that will be transferred and shared in support of the HL7’s various capabilities.

Operationalization and Transition from Current HL7 Compatibility Guidelines

This section will be collaboratively developed once the core ECCF and its structures and function have been discussed, elaborated, and understood by the core stakeholders.

Migration of Legacy Components and the existing HL7 Compatibility Guidelines

The layered approach to compliance defined and described by the ECCF provides potential guidance regarding the existing implementations of applications, tools, and services in the context of the existing HL7 Compatibility Guidelines. These components exhibit certain integration points that provide testable realizations, usually of the Information (i.e., static semantics) and Engineering (implementation patterns, discovery patterns, deployment models) Viewpoints. Thus, the migration path for these “legacy” components might include the following:

• The creation of Functional and Design Specifications for certain capabilities.
• The evaluation of these specifications, focusing especially on the Enterprise and Computational Viewpoints.
• Retrofitting these capabilities into the expanding Conformance Infrastructure (see below) as deemed appropriate.

In this light, the existing HL7 Compatibility Guidelines should be considered as a specialized subset of the Information and Engineering Viewpoint, with supporting tooling, implementation patterns, etc. As it is likely that these specializations will continue to play a large role in the creation of certain capabilities within the HL7 Enterprise Architecture Specification, they should be contextualized within the ECCF with the understanding that, in some ways at least, they have already passed through a governed, ECAP-like process.

For example, an existing application that exposes a data service that only nominally plays a part in any distributed queries may opt, once evaluated from the Enterprise point of view, to only provide services that are more functionally decomposed in nature (in the context of the Grid technology binding, these would be analytic services). By the same token, the power of distributed queries may be increased by an order of magnitude once focused on particular solutions that may operate behind specified interfaces that interoperate more seamlessly with other components.

Comparison with Gold Compatibility Guidelines

As noted above, the HL7 Compatibility Guidelines can be considered a specialized subset of the Information and Engineering Viewpoints, with the addition of some Computational Conformance Assertions as well. The Gold Compatibility Guidelines aim at the standardization, harmonization, and adoption of Grid API’s; Vocabularies, Terminologies, and Ontologies; Data Elements; and Information Models. Harmonization of these components promises, within the technology bindings and deployment scenarios represented by the Grid, to improve the integration of well-described capabilities by both emerging and existing systems. Additionally, it would be expected that adherence to this set of guidelines improves the quality of interoperability between these systems and those deployed in a different context (for example, on a different technology stack or between other Grid flavors). In other words, they represent an advanced degree of maturity that can be relied upon – in certain circumstances – to decrease the time and effort of integration while at the same time improving the quality of the results. Within the context of the ECCF, the Gold Compatibility Guidelines represent a set of Engineering, Computational, and Informational Viewpoint Conformance Assertions associated with any given Platform-Bound specification. In the case of the HL7, the platform of choice is the Grid. When these assertions are realized as integration points across a number of deployments, certain economies of scale emerge that are well-designed for a particular set of problems. The table below summarizes several of the Silver and Gold requirements in the context of the ECSF (from [Compatibility Guidelines].

Viewpoint	Conformance Assertion	EAS Implication
Informational	-Controlled vocabularies reviewed and approved by HL7 VCDE workspace for use in silver applications are used for all appropriate data collection fields and attributes of data objects.	Infrastructure supporting reuse
	-Concept identification should be compatible with the HL7 Identifier and Resolution Scheme	Binds a portion of the Information Viewpoint to the Implementation Patterns from the Computational Viewpoint
	CDEs are registered as ISO/IEC 11179 metadata components in the HL7 Context of the cancer Data Standards Repository (caDSR).	Infrastructure supporting reuse, advertising, discovery, and a pattern of semantic definition
	-Data elements must be expressed in caGrid standard metadata format	Infrastructure supports best practices
	-Object-oriented domain information models are expressed in UML as class diagrams and as XMI files, and are reviewed and validated by the VCDE workspace.	Supports Infrastructure and Implementation Patterns, including the Distributed Query Model (see above)
	The classes, attributes and relationships of the information model are registered in the caDSR and correspond to the CDEs used by the system	Infrastructure supports best practices
	-Classes and attributes must be semantically annotated using terms from a controlled vocabulary that has been approved by the VCDE workspace.	Infrastructure supports best practices, supports semantic query and discovery models
	-Information model must be expressed in the caGrid standard metadata format.	Infrastructure supports best practices, supports semantic query and discovery models
Computational	-Well-described APIs approved by the HL7 Architecture workspace provide access to data in the form of data objects that are instances of classes represented by a registered domain model.	The Service should support the Distributed Query Model (see above)
	-Services provide public access to caGrid standardized service metadata and have capability to register it with a caGrid Index Service.	Service should support the caGRID service description specification as well as the caGRID advertising and discovery mechanisms
	-Data-oriented services provide query access using the caGrid standardized query interface and language.	The Service should support the Distributed Query Model (see above)
	-Concept identification in systems must use the HL7 Identifier and Resolution Scheme	Support of the Implementation Pattern for Vocabularies and Terminologies
Engineering	-Electronic data formats corresponding to a registered domain model approved by the HL7 Architecture workspace are supported wherever messaging is indicated by the use cases.	Supports deployment topologies and technology bindings; tight couplings between registered domain / information models and wire formats
	-Messaging protocols approved by the HL7 Architecture workspace are supported wherever messaging is indicated by the use cases.	Supports deployment topologies and technology bindings is indicated by the use cases.
	-APIs are exposed as operations of a Grid service; Object-Oriented client APIs are available for invoking those operations.	Supports deployment topologies and technology bindings
	-Service operations use XML as data exchange format, and are invoked using standardized protocols and communication channels.	Supports deployment topologies and technology bindings
	-Secure services must use the caGrid standardized mechanisms for authentication, trust management, and communication channel protection.	Supports deployment topologies and technology bindings
	-Vocabularies must be accessed through a standard caGrid Vocabulary API	Supports deployment topologies and technology bindings
	-XML schemas must be bound to the classes in the information model and are registered to Global Model Exchange (GME) service.	Supports deployment topologies and technology bindings

Table 3: Gold (and relevant Silver) Compatibility Guidelines as Conformance Assertions in the ECSF. Note that assertions of reuse are not stated here, but are implied through the use of infrastructure and overriding assertions of policy (Enterprise Viewpoint) urging reuse and scalability.

Note that these assertions can and should be viewed within the context of the overarching Enterprise Architecture Specification. That is, they provide for the binding of particular solutions to a technology that meets certain quality and functional requirements for deployments, and as such can confirm and validate the assertions from the RM-ODP viewpoints. To the extent that any particular solution can meet these assertions (in particular the Engineering assertions) without sacrificing its ultimate purpose, it can substantially benefit from the technology binding as a mature implementation and deployment pattern that provides mature solutions to many engineering problems. The binding of solutions to the Grid raises two questions, however, that must again be examined in view of the EAS. First, how can various infrastructure components that bind to the Grid be utilized and implemented outside of that particular deployment context. In other words, which of the Computational and Informational assertions are applicable given a different set of Engineering assertions? This issue in particular is a vital one (see section 4 above) in supporting interoperability across deployments that are compliant to various levels of the ECCF.

By the same token, the EAS raises the question of what additional features the Grid Technology Binding might provide so as to increase the range of solutions that could benefit directly from the above assertions. It is hoped that the Logical Specifications that arise from a number of different projects can provide detailed architectural requirements that can in turn provide for a technology binding that can be increasingly reused.