December 2009 DRAFT

[ct1][KGS2]

HL7 Services-Aware Enterprise Architecture Framework (SAEAF)

Enterprise Conformance and Compliance Framework (ECCF)

HL7 Architecture Board (ArB)

December2009

Table of Contents

1The ECCF: Overview

2The ECCF Problem Statement

3ECCF Foundational Concepts

3.1Specification Stack

3.2Conformance: Statements, Assertions, and Certification

3.3Compliance

3.4Certification

3.5Consistency

3.6Traceability

3.7Compatibility

3.8Localization

3.9Jurisdiction

3.10Provenance

3.11Technology: Viewpoint, Bindings and Implementations

3.12A Comparison of Conformance and Compliance Lexicons: ECCF vs. HL7 Implementation and Conformance Work Group

4Completeness of a Specification Stack Instance

4.1Applying the ECCF

4.2Mature vs. Immature Specification Stack Instances

4.2.1Traceability of Conformance Statements in a Mature Specification Stack Instance

4.2.2Traceability of Conformance Statements in an Immature Specification Stack Instance

4.3Conformance Certification: Mature vs. Immature Specification Stacks

5The ECCF and Enterprise Architecture Specifications

5.1The ECCF as the “Skeleton” of an EAS

6The Value of the ECCF

7Appendix I: Incorporating Reference Specifications in a Specification Stack Instance

8Appendix II: Harmonization and Mapping between the ECCF and HL7’s Implementation and Conformance Work Group

8.1.1Additional Notes on Table 1

9Appendix III: ISO terminology: Conformance and Compliance

9.1Consistency of ISO and ECCF Terms

1The ECCF: Overview

As discussed in the SAEAF Introduction and Overview, the Services-Aware Enterprise Architecture Framework (SAEAF) consists of four core “sub-frameworks:”

  • Information Framework (IF)[1]*
  • Behavioral Framework (BF)
  • Enterprise Conformance and Compliance Framework (ECCF)
  • Governance Framework (GF)

(* The Information Framework document will be developed from existing materials regarding the SAEAF conextualization and usage of the Reference Information Model (RIM), data types, vocabulary Best Practices, Clinical Document Architecture, Clinical Statement Pattern, HL7 Core Principles, etc.)

This document discusses in detail is focused on a detailed discussion of the motivation for, and the structure, content, and use of, the ECCF. When appropriate in the course of discussions within this document, relevant details of the other core SAEAF “sub-frameworks” are mentioned. However, these references should not be viewed as definitive explanations of the other SAEAF sub-frameworks, as the details of each of these sub-frameworks are presented in separate documents within the larger “SAEAF Book” (of which this document is a part).

The Enterprise Conformance and Compliance Framework (ECCF) provides a structure – i.e. the ECCFSpecification stack (SS)– for identifying, defining, organizing, and relating a set of artifacts that collectively define the relevant semantics of a specification of a software component or other system-of-interest. The term “relevant semantics” means “all aspects of the specification that have an impact on achieving Working Interoperability,” and includes both static and dynamic/behavioral semantics. The term “specification” is intentionally left vague at this point in the discussion as an indication that the scope of a given collection of artifacts bounded by an instance of an ECCF SS(also called the scope/topic of the SS instance) – referred to as the “topic[ct3]” of the SS instance -- varies depending on the granularity, intent, and/or context of the specification.

At this point in the discussion, It is sufficient to say that the term may apply to a single service (business, utility, infrastructure, or other type) within a Services-Oriented Architecture (SOA), a particular message or document, or a general “capability” of a system or organization (for example,e.g. “a party engaged in a double-blind clinical trial.”). Note that although the last example is certainly not the most common application of the ECCF, it is a viable application of the ECCF and is included to help illustrate the overarching conceptual description of the ECCF.:

The ECCF provides an organizational framework within which a number of inter-related aspects of a given instance of a specification stack are explicitly represented at multiple layers of abstraction. Explicit representational statements within artifacts are formally defined as conformance statements. An implementation of a given specification as realized through a given technology binding (or other operational embodiment depending on the specific SS topicscope/topic) asserts one or more conformance assertions which are pair-wise -associated toconformance statements. Individual conformance assertions can then be formally evaluated as True or False.Because conformance statements may be made from a number of perspectives and at varying levels of computational abstraction, the ECCF provides a layered, quantitative approach to assessing the degree of difficulty and specific amount of effort required to enable two trading partners to attain Working Interoperability.Ein a context where each partner is providing the other with a relevant ECCF SS instance. ((Ssee SAEAF Introduction and [ct4] Figure 1.)Figure[ct5] 1).

Figure 1: Working Interoperability.Any Interoperability Paradigm – messages, documents, or services – can be used in a given WI context. (See SAEAF Introduction and Overview for a detailed discussion.).

Thus, tThe ECCF can thus be characterized as “the infrastructure supporting the SAEAF Stairway to Heaven.” (Ssee SAEAF Introduction and Overview and Figure 2Figure 2.).

Figure 2: SAEAF Stairway to Heaven.(Figure 2: see SAEAF Introduction for a detailed discussion) KAREN – please re-lable the “base” of the Stairway to Heaven IN ALL DOCUMENTATION “Agree on common EA Framework as Reference. Also, be sure the levels are named CIM, PIM, and PSM and appropriately defined in the legend of the Stairway graphic.

Legend for Figure 2:

  • A – F represents the trading partners.
  • PSM = Platform-Specific Model (Physical)
  • PIM = Platform-Independent Model (Logical)
  • CIM = Computationally-Independent Model (Conceptual)

Figure 3shows a “mapping” between the Stairway to Heaven and the overall structure of the ECCF specification stackSS.

Figure 3: Relationship between the levels of the “SAEAF Stairway to Heaven” and the rows in the ECCF specification stack. The thickness of the arrows indicates the level of explicitness of one partner’s specification. T, i.e. thicker arrows indicate that a partner is “higher” up the stairway and that the other partner is able to work with a more explicit information relationship to the specific WI context. (SS columns have been collapsed for clarity.)

See text[ct6] and SAEAF Introduction and Overview for further explanation of the use of Reference Model for Open Distributed Processing (RM-ODP) and Model Driven Architecture (MDA) in defining the structure of the SS’s structure.

2The ECCF Problem Statement

Although a robust, scalable, supportable, extensible, and implementable EAS requires all of the critical components specified in the SAEAF, the ECCF in general – and specification stack instances in particular – supply the “skeleton” of an EAS.

With the overarching goals of i) achieving Working Interoperability within a specification-specific context, andii) defining standards for expressing the details of a given specification or standard so that it can be used beyond the walls of the organization developing the specification, the following scenario constitutes the essence ofthe ECCF problem statement:

  • Group A (for example, e.g. SDO or Organization A) develops Specification X. (If Group A is an SDO, it publishes Specification Xas Standard X.)
  • Development organizations C and D want to implement Standard X.
  • Group B (for example, i.e. an oOrganization or SDO) has previously developedSpecification/Standard Y.
  • Group A wants to say, “Specification X usesSpecification Yto satisfy requirement R.”
  • Both Group A and Group B would like to enable a trusted3rd-party to make the either or both of the following statements with a high degree of certainty:
    i) Specification Y is “correctly referenced and utilized” by Specification X.
    ii) Specification X is “correctly implemented” by Implementations I1 (by C) and I2 (by D).

In order toTo make either of thesetwo statements in a non-ambiguous manner, one needs to have non-ambiguous answers for the following questions:

  • What does “correctly referenced and utilized” mean?
  • What does “correctly implemented” mean?

In turn, answers to these questions lead to the question of how one can explicitly specify “correctness” criteria.An additional wrinkle in the discussion involves the question of whether the goal is to attain automated certification of “correctness,” or whether one can restrict the certification process to human or human-assisted.(In the world of HL7, other SDOs, and national-level healthcare IT programs, the maximum amount of automated certification is the desired goal simply because of the scale of certification efforts that are required.)

Given that goal, one is led to a virtuallyinescapable conclusion:

If explicit definitions and processes are not established –using, for example, a framework like[ct7] the ECCF SS -- implicit assumptions willnot be made explicit until implementation-time or run-time. In addition, when they are made explicit, the explicitness is often determined in inconsistent ways, e.g. through decisions by people (for example, e.g. developers, data base designers, etc.) who are not qualified to made the explicit decisions required. As a result, the original assumption is made explicit (interpretated) in such a manner as to expose produce inconsistencies[ct8] between software interfaces purporting to be focused on similar problems, the final result being that achieving Working Interoperability is often an expensive, time-consuming, basically one-off effort.

The ECCF then, is focused on making assumptions explicit in a traceable, layered manner as explained in the remainder of this document. The following Section3 defines each of the ECCF Foundational Concepts[ct9] that collectively define the organizational and content semantics of the ECCF. As evidenced by the moniker “ECCF,” the core concepts of conformance**and compliance**are central to this discussion. The use of these terms is summarized in the following operational scenario, whose overarching motivation is an unbending focus on enabling scalable, tractable Working Interoperability:

  • Conformance statements: SDO S1working in Jurisdiction A defines Specification A.
  • Conformance statem,emts: SDO S2 working inJurisdiction B defines Specification B.
  • Compliance assertion: SDO S2applies a constraint pattern to Specification A for use within Specification B.
  • Conformance assertions: Developers implement Specification A.
  • Conformance assertions: Developers implement Specification B.
  • Certification of conformance**: 3rd-party evaluates Specification A and/or Specification B for correctness.
  • Validation of compliance**: Specification A is correctly referencing and using Specification B.

** See Appendix III for a discussion of ISO terminology and standards relavent to the ECCF’s use of the terms Conformance and Compliance, and, in particular, for a brief discussion of the most recent ISO concept relating these terms: conformity.

3ECCF Foundational Concepts

The following are the essential ECCF Foundational Concepts:

•Specification stack

•Conformance: Statements, Assertions, and Certification

•Compliance

•Consistency

•Traceability

•Compatibility

•Localization

•Jurisdiction (discussed in greater detail in Governance Framework documentation)

•Provenance (discussed in greater detail in Governance Framework documentation)

Each of these concepts defines one or more aspects of the content and content inter-relationships within an instance of the ECCS specification stack. As such, an understanding of the ECCF Foundational Concepts is essential to effectively use the ECCF effectively in the context of enabling Working Interoperabilty.

Several of the concepts have been addressed by ISO in several the standards dealing specifically with the broad topic of what ISO refers to as “conformity.” A discussion of the mapping of the ECCF Foundational Concepts to ISO is contained in Appendix III. This section on ECCF Foundational Concept’s Section concludes with a concept-by-concept comparison of the ECCF Foundational Concepts with terms defined by the Implementation and /Conformance Work Group (IC WG) of HL7 with the goal of attaining harmonization to a single set of terms for use within the HL7 community.

A discussion of the mapping of the ECCF Foundational Concepts to ISO is contained in Appendix III. Additional notes on the mapping exercise can be found in Appendix II.

3.1Specification Stack

Figure 4 shows a generic/template ECCF specification stack (SS) template.The specification stack is a 3-row x 4 column matrix (table), whose content – a collection of artifacts whose content collectively and unambiguous defines a particular scope (aka also called the Specification stack instance’s scope/topic[ct10]). Thus, an SS instance has a scope defined by a coherent collection of functionality and content within a particular Working Interoperability (WI) context.(It is important to note that although the RM-ODP vViewpoints are, by definition, non-hierarchical and also non-orthogonal, the collections of artifacts within a single SS cell can be – and usually are – arranged in a hierarchy.

Structually, the rows of the SS are levels-of-abstraction, which map to the Object Management Group’s (OMG) Model-Driven Architecture (MDA) framework:

  • , i.e. Computationally-Independent Platform model (CIM)
  • Platform-Independent model (PIM)
  • Platform-Specific model (PSM)

The columns represent four of the five Reference Model for Open Distributed Processing (RM-ODP)viewpoints[KGS11]:

  • Business/Enterprise
  • Informational
  • Computational
  • Engineering

The fifth vViewpoint – Technology – is present as a “technology binding of an implementation to a specification,” and is explained in more detail in the discussion of Conformance. (See the SAEAF Introduction[ct12] for a discussion of the relevant aspects of RM-ODP in the SAEAF context.) In summary, the ECCF’s 3-row x 4-column matrix/table that forms the structure of the ECCF,and the cells of an instance of a SS contain a layered set of related of artifactswhose content is specific to a content is scope-/topic-specific.

See the SAEAF Introduction[ct13] and Overview for a discussion of the relevant aspects of RM-ODP in the SAEAF context.

Figure 4: A prototype ECCF specification stack (SS) with exemplar example artifacts for a specific software component with well-defined scope. KAREN – this graphic needs “localization” strips and row re-labeling.

Of particular importance in the context of Working Interoperability are scope-/topic-specific conformance statements, which arecontained within and /expressed by the various artfiacts of an SS instance. As mentioned in the discussion of the ECCF Problem Statement[ct14], a given technology implementation of (also calledaka “technology binding to”) a particular SS instance makes pair-wise conformance assertions that can be validated and certified.(The conformance assertions are usually certified by an independent 3rd-party organization devoted to ConformanceCertification activities) as True or False, a fact that follows from the fact that both conformance statements and conformance assertions are Boolean-valued.

In addition, often it is often the case that specific SS artifacts for a given cell (and therefore associated with a given scope/topic) are generated via one or moreconstraint patterns, which are [ct15]applied to existing artifacts from a previously-defined specification which is now contextualized within the specific sSpecification-sStack-of-interest. The ECCF requires that these contrained specification artifacts to be sorted by RM-ODP viewpoints and MDA levels-of-abstraction, thereby enabling the constrained artifacts to be utilized used in a manner that is identical to the SS instance’s “primary” artifacts. That is t, i.e. there is no inherent difference between a “de novo” SS artifact and a “re-used”/constrained artifact from an external SS instance.

(See Appendix I for a more detailed discussion on the inclusion of external specifications within an SS instance. Also, see the glossary in the SAEAF Introduction and Overview for a definition of constraint pattern.)

3.2Conformance:Statements, Assertions, and Certification

The ECCF hasadopted the following definition of conformance[ct16] (and its associated specific terms)from RM-ODP and as developed by the Australian National E-Heath Transition Authority (NeHTA): [2] **

“Conformance relates a specificimplementationof a specificationirrespective of whether or not the specification is a”standard.” Conformance is an quantitative assessment of how completely and accurately a given implementation fulfills the requirements stated in the specification. Conformance is evaluated at specific foci in the implementation -- Conformance-- Conformance Points as identified in the specification-of-interest. Evaluation is a Boolean statement, i.e. it is either True or False.

** See Appendix III for a discussion of recent ISO terminology regarding conformance, compliance, and certification.

As can be seen from the above definition, Conformance denotes the “validity” of a given software component relative to a stated set of requirements – i.e.that is, the “correctness” ofa specific implementation or technology binding of a specific SS instance. The specification is required to express its requirements in the form of conformance statements. A particular implementation then makes pair-wise conformance assertions which that may be evaluated – through either human or (preferably) automated testing – to be either True or False. Specifically, if a givenconformance assertionis verified as True, the software component is said to be “conformant” or “conforming to,” or “in conformance with” the pair-wise conformance statement (Figure 5). Clearly, this means that the notion of Conformance is certified at a granular level equal to that of the conformance statement.

The following is an example of a testable and verifiable conformance statement, to which given software component would claim conformance via a conformance assertion:

“Operation X <MUST> bind to the RIM attribute Observation.value with an ISO 21090 data type of <CD> and a value set specified in LOINC as ….”

Figure 5: Ideally, conformance certification is done through automated means, which implies that conformance statements must be expressed in a computable way. [KGS17]Blue arrows show Conformance Statements for a given SS. Red arrows show conformance assertions for a given technology binding. The gray stripes represent “localization.”

From the preceeding discussion it should be clear that the ECCF enables – but

certainly does not guarantee – automated conformation evaluation and /certification of a given specification instance bound to a given technology implementation. Although automated testing is certainly is possible if the conformance statements of the sSpecification stack instace are correctly expressed at the Platform-Specific model (PSM) level of the SS. In addition, note it should be noted that the overall relevancy of PSM-level statements is substantially increased when at some of the conformance statements are, in fact, traceable derivatives from conformance statements at Logical/PIM and Conceptual/CIM levels of the SS instance. The v, i.e. value increases the more “mature” a SS instance is, i.e. the more the collection of SS cells are populated with the appropriate artifacts.

Conversely, however, it is often useful – from the perspective of Working Interoperability – to be able to discuss Conformance via conformance statements, which only exist at the CIM or PIM levels of the ECCF,since because the existence of conformance statements at these levels indicates the presence (and associated rigor) of explicit assumptions even if a PSM has not yet been specified. Conformance statements made at the CIM or PIM levels are, however, usually most often only able to be fully evaluated through a combination of human-only or human-and-automated testing once an implementation has been built.