This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "SAEAFISCS"

From HL7Wiki
Jump to navigation Jump to search
 
(23 intermediate revisions by one other user not shown)
Line 1: Line 1:
 
'''Levels of Interoperability Service Contract Specifications(ISCS)'''
 
'''Levels of Interoperability Service Contract Specifications(ISCS)'''
 
[[Services_Aware_Enterprise_Architecture_Framework|Return to SAEAF Table of Contents]]
 
[[Services_Aware_Enterprise_Architecture_Framework|Return to SAEAF Table of Contents]]
 
+
= Introduction =
 
HL7 : Enterprise Conformance and Compliance Framework (ECCF)
 
HL7 : Enterprise Conformance and Compliance Framework (ECCF)
 
A Framework for Quantitative Specification and Assessment of  
 
A Framework for Quantitative Specification and Assessment of  
Line 9: Line 9:
 
* Compliance Assessment  
 
* Compliance Assessment  
 
2008 07 24  
 
2008 07 24  
 +
 
John Koisch (Booz Allen Hamilton)  
 
John Koisch (Booz Allen Hamilton)  
Charlie Mead (Booz & Company)
 
  
 +
Charlie Mead (Booz & Company)
  
The HL7  Enterprise Conformance and Compliance Framework (ECCF)  
+
Added by [[User:Ajulian|Tony]] 20:28, 13 August 2008 (UTC)
= Introduction =
 
 
== Overview ==
 
== Overview ==
 
The ultimate goal of an Enterprise Conformance and Compliance Framework  
 
The ultimate goal of an Enterprise Conformance and Compliance Framework  
Line 269: Line 269:
  
 
===Platform-Level Compliance – Level 3 ===
 
===Platform-Level Compliance – Level 3 ===
There can be more than one Platform Specification for each Design Specification  
+
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:  
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  
 
* Implementable technology stacks  
 
* Implementation Guides  
 
* Implementation Guides  
Line 282: Line 278:
 
* Test Harnesses and test messages  
 
* Test Harnesses and test messages  
 
* Publication of the Platform Specification  
 
* Publication of the Platform Specification  
* Collected conformance assertions by viewpoint that represent the
+
* Collected conformance assertions by viewpoint that represent the architectural requirements for the system
architectural requirements for the system
+
 
 
Activities supporting the production of these artifacts include:  
 
Activities supporting the production of these artifacts include:  
* Actual implementation of the Platform-Bound Specification (and  
+
* 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.  
optionally the technology stack if available) or an implementation that is  
+
* The usage of the HL7 ICP (see below) to create the message serialization models  
directly complies with a provided implementation guide. This includes  
+
* The instantiation of message models, content models, serialization models, and functional end points in coordinated message exchange patterns to realize real business value  
the usage of deployment configurations for standardization, localization,  
+
* Conformance with the collected conformance assertions that are part of the Platform Compliance Level  
and / or extension as deemed appropriate.  
+
* The utilization, as appropriate, of installation tools and deployment patterns  
* The usage of the HL7 ICP (see below) to create the message serialization  
+
* The adoption of test harnesses as part of the specification to insure compliance
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===
 +
[[image:ECCF_Compliance_levels.jpg|Table 1]]
  
===Compliance Levels: Tabular Summary===
 
Artifacts,
 
Source of Conformance Tools, etc.
 
Compliance
 
Level
 
Assertions/Specifications
 
used to evaluate
 
Compliance
 
Associated
 
RM-ODP
 
Viewpoint
 
Assertion
 
Type or
 
Character
 
supporting
 
Compliance
 
Assessment
 
ECCF and HL7  N/A N/A Organizational
 
Development Best acceptance of
 
Practices (e.g. MDA, ECCF and HL7
 
0
 
(Domain)
 
semantic clarify, etc.) 
 
Development
 
Best Practices
 
(e.g. MDA,
 
semantic
 
clarify, etc.)
 
Conceptual Functional Enterprise, Business Business
 
Service or Application
 
Specification
 
Information,
 
Computational
 
Rules
 
(Enterprise),
 
Architecture
 
Models and
 
Information Domain
 
Semantics Analysis Model
 
I
 
(Blueprint)
 
bound to
 
Functional
 
Profiles
 
(Information),
 
([e.g. BRIDG,
 
etc]), ISO
 
Datatype,
 
meta-data, and
 
Interaction terminology
 
Semantics bindings, HL7
 
defining Specification
 
Functional
 
Profiles
 
Registry
 
Platform-Independent Information, Same as Candidate
 
(Logical) Service or Computational, Blueprint + Component
 
Application Specification Engineering Service
 
II
 
(Design)
 
(including fully specified
 
dynamic/interaction model)
 
Deployment
 
topology and
 
configuration,
 
[Deployment
 
Specification
 
(Logical
 
Model),
 
Architecture
 
technologies] and
 
Implementation
 
patterns
 
III
 
(Platform)
 
Technical stack,
 
Deployment Models,
 
Software Configurations,
 
[Hardware]
 
Enterprise,
 
Information,
 
Computational,
 
Engineering,
 
[Technology]
 
Same as
 
Design +
 
Assertions
 
are directly
 
testable
 
Full testing
 
environment
 
including
 
harness, test
 
data, etc.
 
through
 
deployed
 
conformance
 
points
 
 
Table 1: Compatibility Levels including relationships to HL7 Infrastructure components and  
 
Table 1: Compatibility Levels including relationships to HL7 Infrastructure components and  
 
conformance points
 
conformance points
  
= Measuring Compliance: =
+
= Measuring Compliance: The HL7  Enterprise Compliance Assessment Process (ECAP) =
The HL7  Enterprise Compliance Assessment  
+
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.  
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 ==
Compliance Certification is the process that establishes that a particular  
+
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.  
technology binding adheres (‘is compliant with’) one of the four Compliance Levels  
+
[[Image:ECCF_Compliance_cert.jpg|Figure 3]]
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.  
 
[[ECCF_Fig3a.jpg|Figure 3]]
 
Figure3:AnoverviewoftheConformanceAssessmentprocess.
 
AdoptionofECCF-definedConformanceSpecificationsDesignandImplementationofCandidateComponentDesiretointegratewithHL7CapabilitiesCertificatinProcess(ComplianceLevelassignment)
 
This activity is realized over a spectrum modulated by the degree at which an
 
organization desires to comply with HL7  Enterprise Architecture
 
Specifications.
 
  
 +
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 ==
 
==Governance ==
A critical success factor in implementing the ECCF is the notion of 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.  
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  
+
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.).  
necessary to move beyond simply specifying interoperability grammars based on  
+
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.  
tooling, interoperability “guidelines” open to variable interpretation or  
+
 
implementation, and /or mechanisms for forcing certain implementation patterns  
+
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.  
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 ===
Composite Architecture Teams (CATs) provide periodic architectural  
+
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:  
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;  
 
* Consumption of relevant pre-existing Conformance Specifications;  
* Milestone-based assessment of Conformance Specifications being created  
+
* Milestone-based assessment of Conformance Specifications being created by the team for use beyond their project’s scope;  
by the team for use beyond their project’s scope;  
+
* Facilitated communication between relevant parties concerning the integration of systems and shared components;
* 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).  
In addition, the CATs provide the Enterprise ongoing input and architectural  
+
 
recommendations regarding emerging Compliance Specifications, including  
+
Collectively, these activities serve to insure that the enterprise is a stakeholder in each project’s design and architecture.  
constraints on usage and strategies that develop due to a particular architectural  
+
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.  
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 ====
 
====Bootstrapping ====
The operationalization of CAT Governance may occur, in certain situations, over  
+
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.  
the course of a Candidate Component’s development lifecycle, thereby enabling  
+
 
the Component’s development team assert compliance to its own artifacts. This  
+
[[Image:ECCF_bootstrapping.jpg|Figure 7]]
ability of the EAS to be “bootstrapped” is supported by an open, transparent  
+
 
Compliance Assessment Process performed by an impartial CAT team. This  
+
'''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.'''
sequence is outlined in the diagram below.  
 
  
[[ECCF_Fig7.jpg|Figure 7]]
 
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 ====
 
====Conformance Review Process ====
The Conformance Review process deserves special mention as one of the  
+
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.  
oversight/governance activities of a CAT. This process begins with a project’s  
+
[[Image:ECCF_conformance_test.jpg|Figure 8]]
establishing its models for deployment, which serve to provide direct traceability  
+
 
between the business capabilities that the project is attempting to utilize and the  
+
'''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'''
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.  
 
[[ECCF_Fig8.jpg|Figure 8]]
 
Figure8:Exampleconformancetestingprocess.Notethatconformancetestingisanactivity
 
that has high visibility with the cross-enterprise teams. This part of the process is expanded  
 
from the previous diagram  
 
 
====CAT-Proxy Project Architects ====
 
====CAT-Proxy Project Architects ====
A project’s awareness of Enterprise Architecture is facilitated by the embedding  
+
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.
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 ===
 
=== Additional Examples of CAT Governance ===
 
====Business Case Facilitation ====
 
====Business Case Facilitation ====
The specifications themselves, driven by the business needs and capabilities of a  
+
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
particular domain, may serve as a mechanism that motivates an organization to  
+
 
adopt the interoperability standards of HL7 ’s Enterprise Architecture. In  
+
'''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.'''
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  
+
[[Image:ECCF_Business_case.jpg|Figure 4]]
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  
+
'''Figure4:Sample Deployment Facilitation.  The CAT interacts with a consuming organization that can state its business, architecture, and technological requirements.'''
case of the Platform Specifications with Technology Bindings, to deploy. Each  
 
implementation is tested for compliance.2  
 
2 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.  
 
[[ECCF_Fig4a.jpg|Figure 4?]]
 
  
Figure4:Sample Deployment Facilitation.The CAT interacts with a consuming organization that can state its business, architecture, and technological requirements.
 
 
====Project Development Dependencies ====
 
====Project Development Dependencies ====
Projects developing new capabilities within the HL7 / HL7  network  
+
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.  
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  
+
[[Image:ECCF_proj_dev.jpg|Figure 5]]
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  
+
'''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'''
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.  
 
[[ECCF_Fig5a.jpg|Figure 5?]]
 
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 ====
 
==== Vendor Facilitation ====
In another situation, one or more Vendors may have identified a number of core  
+
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.  
capabilities within the HL7 Enterprise Architecture that provide valid roads  
+
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.  
to market and interactions with their customers. In some cases, the desire could  
+
[[Image:ECCF_vendor_faciliatation.jpg|Figure 6]]
be to create a simple tool or application, while in others, an entire suite of  
+
 
applications and coupled tools.  
+
'''Figure6:The Vendor adopts the HL7 specifications, implementing them in their own product line'''
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.  
 
[[ECCF_Fig6.jpg|Figure 6]]
 
Figure6:TheVendoradoptsthe HL7 specifications,implementingthemintheirownproductline
 
 
== Compliance Measurement ==
 
== Compliance Measurement ==
 
=== Compliance Levels – a Process Perspective ===
 
=== Compliance Levels – a Process Perspective ===
Line 634: Line 401:
 
deterministically defined by virtue of the fact that each Integration Point in any  
 
deterministically defined by virtue of the fact that each Integration Point in any  
 
integration scenario will be semantically aligned with similar business processes  
 
integration scenario will be semantically aligned with similar business processes  
including the quantitative specification of defined Integration Points.  
+
including the quantitative specification of defined Integration Points.
 +
 
 
=Infrastructure Supporting Conformance =
 
=Infrastructure Supporting Conformance =
In the context of an enterprise, conformance and compliance should be facilitated  
+
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:  
by an infrastructure that reflects adopted organizational standards and best  
 
practices. These might include:  
 
 
* architecture and design patterns  
 
* architecture and design patterns  
* registries and registration processes (for example, the registration of class  
+
* registries and registration processes (for example, the registration of class models or of services)  
models or of services)  
 
 
* implementation patterns (like information constraint patterns)  
 
* implementation patterns (like information constraint patterns)  
* the specifications that emerge from the ECSF themselves.  
+
* 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  
+
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.  
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  
+
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:  
expected to be supported by tooling that reflects the specification process, the  
+
* 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).  
models that support it, and the RM-ODP-calibrated components that make up  
+
* 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.  
the models. For example:  
+
* Constraint Patterns (see Information Viewpoint Constraint Pattern discussion below) may be facilitated by wizards or something less structured like a UML Profile.
* Modeling tools might eventually be expected to generate reports that  
+
* Advanced Service description, registration, and discovery might be facilitated using tools to capture dynamic semantics as well as static semantics (see below).  
conform to different RM-ODP viewpoints that in turn support the  
+
* Compliance testing could be enabled by aggregating the various integration points defined through the specification process
different levels of specification (see diagram below).  
+
[[Image:ECCF_Table2.jpg|Table 2]]
* 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
 
[[ECCF_Table2.jpg|Table 2]]
 
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
 
  
 +
'''Table 2: Specification Levels and Associated RM-ODP Viewpoints '''
  
particular Conformance Assertion being tested), ultimately the viability of a  
+
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.  
conformance and compliance strategy rests on discovering efficiencies of scale  
 
through tools and repeatable processes.  
 
 
==Domain Models ==
 
==Domain Models ==
 
=== Biomedical Research Integrated Domain Group (BRIDG) Model ===
 
=== Biomedical Research Integrated Domain Group (BRIDG) Model ===
The BRIDG Model, a collaborative effort of stakeholders from the Clinical Data  
+
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.)
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,
 
  
 +
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’).
  
which, in turn, support specific implementation patterns and governance  
+
==Static Semantic Conformance ==
processes.  
+
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) ===
 
===Metamodel Registry (caDSR – Data Standards Repository) ===
HL7 utilizes an implementation and extension of the ISO Standard 11179  
+
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.  
Metamodel Registry specification to gather and share meta-data about ‘common’  
+
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.
(shared) data elements and their bindings to controlled terminologies. Combined  
+
 
with the Enterprise Vocabulary Services (EVS), the HL7 Thesaurus and HL7  
+
===Terminology Registration and Binding Patterns (HL7 static semantics infrastructure (caDSR, EVS et al)) ===
Meta-Thesaurus (see below), caDSR provides a central registry which is home to  
+
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.  
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) ===
 
===Query Language for Distributed Persistence Model (DQL) ===
HL7 utilizes a common implementation pattern for registering semantics and  
+
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.
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 ==
 
==Dynamic/Interaction Semantic Conformance ==
There is an emerging set of components that support dynamic/interaction  
+
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.  
semantics within the enterprise. By and large, these provide parts of the  
+
===CTMS Business Architecture Model (BAM) and Enterprise Visionary Use Cases ===
framework that, first, support some form of traceability between the behaviors  
+
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.  
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 ===
 
===Logical Dynamic Models ===
The ECCF defines that part of the Logical Specification, and part of Design-Level  
+
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:  
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  
 
* when data flows  
 
* the kinds of parties that it flows between  
 
* the kinds of parties that it flows between  
 
* interdependencies between data flows  
 
* interdependencies between data flows  
 
* dependencies that this process requires  
 
* 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  
+
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.  
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  
+
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.  
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 ===
 
===SOA Service Taxonomy ===
The SOA Taxonomy defined for HL7 provides a framework within which  
+
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:  
services reside. It represents a hierarchical set of service classifications that  
+
* 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.  
represent common patterns of implementation and usage, providing a set of  
+
* 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.  
rules that cover such issues as peer communication, referencing, granularity, and  
+
* 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).  
how to separate concerns. These classifications provide the basis for solving  
+
* 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).  
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).  
 
  
[[ECCF_Fig7a.jpg|Figure 7]]
+
[[Image:ECCF_SOA_Service_Taxonomy.jpg|Figure 7]]
Figure 7: The proposed HL7 Service Taxonomy showing four types of services: Process,  
+
Capability, Core, and Infrastructure. Arrows represent consumption.  
+
'''Figure 7: The proposed HL7 Service Taxonomy showing four types of services: Process, Capability, Core, and Infrastructure. Arrows represent consumption. '''
 
==Other Infrastructure Components ==
 
==Other Infrastructure Components ==
 
('''NOTE:''' THIS SECTION IS EXPECTED TO UNDERGO FURTHER DEVELOPMENT AS THE ECCF IS IMPLEMENTED AND DEPLOYED)  
 
('''NOTE:''' THIS SECTION IS EXPECTED TO UNDERGO FURTHER DEVELOPMENT AS THE ECCF IS IMPLEMENTED AND DEPLOYED)  
 
===HL7 Service Description Specification ===
 
===HL7 Service Description Specification ===
In order to be consumed/utilized by clients, Service Instances which are  
+
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:  
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  
 
* location  
 
* role  
 
* role  
 
* responsibilities  
 
* responsibilities  
 
* jurisdiction  
 
* jurisdiction  
 
 
 
* visibility  
 
* visibility  
 
* security context  
 
* security context  
Line 855: Line 479:
 
* interaction participants  
 
* interaction participants  
 
* identification  
 
* identification  
===HL7 Service Specification Catalog ===
+
===HL7 Service Specification Catalog ===
Service, tool, and application specifications need to be cataloged and advertised  
+
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.  
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) ===
 
=== Information Constraint Pattern (ICP) ===
The Information Constraint Pattern represents a common means of defining a set  
+
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.
of Information Viewpoint assertions that are conformant to overarching domain  
+
 
models (e.g. the BRIDG Model). For example, this constraint pattern discusses in  
+
=Operationalization and Transition from Current  HL7  Compatibility Guidelines =
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  
 
This section will be collaboratively developed once the core ECCF and its  
 
structures and function have been discussed, elaborated, and understood by the  
 
structures and function have been discussed, elaborated, and understood by the  
 
core  stakeholders.  
 
core  stakeholders.  
 +
 
==Migration of Legacy Components and the existing  HL7  Compatibility Guidelines ==
 
==Migration of Legacy Components and the existing  HL7  Compatibility Guidelines ==
The layered approach to compliance defined and described by the ECCF  
+
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:  
provides potential guidance regarding the existing implementations of  
+
* The creation of Functional and Design Specifications for certain capabilities.
applications, tools, and services in the context of the existing HL7   
+
* The evaluation of these specifications, focusing especially on the Enterprise and Computational Viewpoints.
Compatibility Guidelines. These components exhibit certain integration points  
+
* Retrofitting these capabilities into the expanding Conformance Infrastructure (see below) as deemed appropriate.
that provide testable realizations, usually of the Information (i.e., static  
+
 
semantics) and Engineering (implementation patterns, discovery patterns,  
+
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.  
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
 
https://gforge.nci.nih.gov/frs/download.php/3948/caBIG_Compatibility_Guid
 
elines_v3.0_FINAL.pdf).
 
Viewpoint Conformance Assertion EAS Implication
 
Informational -Controlled vocabularies reviewed Infrastructure supporting
 
and approved by caBIG VCDE
 
workspace for use in silver
 
applications are used for all
 
appropriate data collection fields
 
reuse
 
and attributes of data objects.
 
-Concept identification should be
 
compatible with the caBIG 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
 
caBIG 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
 
Infrastructure supports
 
best practices
 
  
 +
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.
  
model are registered in the caDSR  
+
==Comparison with Gold Compatibility Guidelines ==
and correspond to the CDEs used  
+
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.
by the system  
+
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 [[https://gforge.nci.nih.gov/frs/download.php/3948/caBIG_Compatibility_Guidelines_v3.0_FINAL.pdf)|caBIG Compatibility Guidelines]].
-Classes and attributes must be  
+
<table border="1">
semantically annotated using terms  
+
<tr bgcolor="c0c0c0"><td>Viewpoint</td><td> Conformance Assertion</td><td> EAS Implication</td> </tr>
from a controlled vocabulary that  
+
<tr bgcolor="b9ffb9"><td>Informational</td><td>-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. </td><td>Infrastructure supporting reuse</td></tr>
has been approved by the VCDE  
+
<tr bgcolor="b9ffb9"><td>&nbsp;</td><td>-Concept identification should be compatible with the HL7 Identifier and Resolution Scheme </td><td>Binds a portion of the Information Viewpoint to the Implementation Patterns from the Computational Viewpoint </td></tr>
workspace.  
+
<tr bgcolor="b9ffb9"><td>&nbsp;</td><td>CDEs are registered as ISO/IEC 11179 metadata components in the HL7 Context of the cancer Data Standards Repository (caDSR).</td><td> Infrastructure supporting reuse, advertising, discovery, and a pattern of semantic definition </td></tr>
Infrastructure supports  
+
<tr bgcolor="b9ffb9"><td>&nbsp;</td><td>-Data elements must be expressed in caGrid standard metadata format</td><td> Infrastructure supports best practices </td></tr>
best practices, supports  
+
<tr bgcolor="b9ffb9"><td>&nbsp;</td><td>-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.</td><td> Supports Infrastructure and Implementation Patterns, including the Distributed Query Model (see above) </td></tr>
semantic query and  
+
<tr bgcolor="b9ffb9"><td>&nbsp;</td><td>The classes, attributes and relationships of the information model are registered in the caDSR and correspond to the CDEs used by the system</td><td> Infrastructure supports best practices </td></tr>
discovery models  
+
<tr bgcolor="b9ffb9"><td>&nbsp;</td><td>-Classes and attributes must be semantically annotated using terms from a controlled vocabulary that has been approved by the VCDE workspace.</td><td> Infrastructure supports best practices, supports semantic query and discovery models </td></tr>
-Information model must be  
+
<tr bgcolor="b9ffb9"><td>&nbsp;</td><td>-Information model must be expressed in the caGrid standard metadata format.</td><td> Infrastructure supports best practices, supports semantic query and discovery models </td></tr>
expressed in the caGrid standard  
+
<tr bgcolor="ffff7f"><td>Computational</td><td> -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.</td><td> The Service should support the Distributed Query Model (see above) </td></tr>
metadata format.  
+
<tr bgcolor="ffff7f"><td>&nbsp;</td><td>-Services provide public access to caGrid standardized service metadata and have capability to register it with a caGrid Index Service.</td><td> Service should support the caGRID service description specification as well as the caGRID advertising and discovery mechanisms </td></tr>
Infrastructure supports  
+
<tr bgcolor="ffff7f"><td>&nbsp;</td><td>-Data-oriented services provide query access using the caGrid standardized query interface and language. </td><td>The Service should support the Distributed Query Model (see above) </td></tr>
best practices, supports  
+
<tr bgcolor="ffff7f"><td>&nbsp;</td><td>-Concept identification in systems must use the HL7 Identifier and Resolution Scheme</td><td> Support of the Implementation Pattern for Vocabularies and Terminologies </td></tr>
semantic query and  
+
<tr bgcolor="ffd133"><td>Engineering</td><td> -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.</td><td> Supports deployment topologies and technology bindings; tight couplings between registered domain / information models and wire formats </td></tr>
discovery models  
+
<tr bgcolor="ffd133"><td>&nbsp;</td><td>-Messaging protocols approved by the HL7 Architecture workspace are supported wherever messaging is indicated by the use cases.</td><td> Supports deployment topologies and technology bindings is indicated by the use cases. </td></tr>
Computational  
+
<tr bgcolor="ffd133"><td>&nbsp;</td><td>-APIs are exposed as operations of a Grid service; Object-Oriented client APIs are available for invoking those operations.</td><td> Supports deployment topologies and technology bindings </td></tr>
-Well-described APIs approved by  
+
<tr bgcolor="ffd133"><td>&nbsp;</td><td>-Service operations use XML as data exchange format, and are invoked using standardized protocols and communication channels.</td><td> Supports deployment topologies and technology bindings </td></tr>
the caBIG Architecture workspace  
+
<tr bgcolor="ffd133"><td>&nbsp;</td><td>-Secure services must use the caGrid standardized mechanisms for authentication, trust management, and communication channel protection.</td><td> Supports deployment topologies and technology bindings </td></tr>
provide access to data in the form  
+
<tr bgcolor="ffd133"><td>&nbsp;</td><td>-Vocabularies must be accessed through a standard caGrid Vocabulary API</td><td> Supports deployment topologies and technology bindings </td></tr>
of data objects that are instances of  
+
<tr bgcolor="ffd133"><td>&nbsp;</td><td>-XML schemas must be bound to the classes in the information model and are registered to Global Model Exchange (GME) service.</td><td> Supports deployment topologies and technology bindings </td></tr>
classes represented by a registered  
+
</table>
domain model.  
+
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.
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 caBIG Identifier and  
 
Resolution Scheme  
 
Support of the  
 
Implementation Pattern  
 
for Vocabularies and  
 
Terminologies  
 
Engineering  
 
-Electronic data formats  
 
Supports deployment
 
corresponding to a registered  
 
domain model approved by the  
 
caBIG Architecture workspace are  
 
supported wherever messaging is  
 
topologies and  
 
technology bindings;  
 
tight couplings between  
 
registered domain /  
 
information models and  
 
indicated by the use cases.
 
wire formats  
 
-Messaging protocols approved by  
 
the caBIG Architecture workspace  
 
are supported wherever messaging  
 
Supports deployment  
 
topologies and  
 
technology bindings  
 
  
 +
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.
  
is indicated by the use cases.
+
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.
-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.
 

Latest revision as of 20:12, 13 January 2014

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

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

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

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 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

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

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. Figure 3

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.

Figure 7

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. 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.

Figure 4

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.

Figure 5

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. Figure 6

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

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

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.