HL7 Interoperability Paradigms Fundamental Methodological ...

04/10/23 00:55

April 9, 2009

OHT Architecture Project:Update and Integration with

HL7 SAEAF

Page 2

OHT Architecture Project Q2 2009Content

•Architecture principles •Tool classification mechanisma set of templates, patterns and processes that enable interoperability of OHT tools. •Identification of potential barriers•Recommendation of a governance process for the harvesting, categorization and custodianship of architecture artifacts.• Executed internal and external

communication plan

•Architectural Principles Q2/09•Tooling Architectural Vision Q3/09 •Architectural Framework Q3/09•Tooling Classification and Governance recommendations Q4/09

-Principles, Architecture Framework-Specification Stack w examples-Tool classification-Recommendations to the Board

•Expectation for detailed Technical Architecture Solutions•Expectation for Architectural Framework that allows for a ToolingArchitecture to emerge throughProjects•Desire to reuse tooling components•Desire to relearn from best practices•Customer expectations to optimize and align Tooling investments

•Funding for Architecture Project team members •Active cooperation from other OHT Project Committers•Successful communication to OHT projects Q2/Q3

Added

Deleted & Changed

Milestones

Packaging EditionsDependencies

Pressures

StatisticsContributing Participants: NCI, Infoway, NHS, NextJ, IHTSDO,

NEHTA, HL7

Page 3

Architecture Project Charter (1)

• The objective of the OHT Architecture Project is to enable the adoption, development, and deployment of an evolving set of interoperable tools.

– Tools are defined as any software component that is not a clinical end-user application, although such software components may form part of an end user application. Tools are intended to be useful and usable for their intended purpose and to inter operate with each other.

• Definition of “tool” intentionally left somewhat loose as that is not the primary focus of the AP. Rather it is enabling interoperability.

• These tools support the development and deployment of software that enables computable semantic interoperability in the health-care/life sciences/clinical research domains.

– Recognition that CSI can occur in a multitude of ways and complexities

• One-way data export

• Integrated real-time behavior coordination

Page 4

Architecture Project Charter (2)

• The OHT Architecture Project operates under the Open Health Tools Development Policy and Process (described at http://www.openhealthtools.org/Documents/Open%20Health%20Tools%20-%20Development%20Process.pdf ) and is chartered by the Board to articulate and adopt a formal architecture framework, architecture principles and best practices that are focused on relevant interoperability and the use of standards.

• As its initial goal, the Architecture Project will develop an architecture framework

– which will enable the evolutionary development of an OHT Platform architecture

• consistent with the various enterprise architectures built and deployed by OHT stakeholders. (i.e. supporting appropriate CSI)

• (Frameworks must be specified top-down. EAS then develops bottom-up.)

Page 5

Architecture Project Charter (3)

• Deliverables include:

– a set of architecture principles.

• Focus on CSI rather than “architecture in general”

– a tool classification mechanism that enables stakeholders to contribute and have access to architecture artifacts that underlie the tools

– a Conformance/Compliance Framework adapted to tooling interoperability, including an explicit Specification Stack

– a set of templates, patterns and processes that enable interoperability of OHT tools

– identification of potential barriers to interoperability and recommendations to overcome them

– a recommendation to the board of a governance process to assist in the harvesting, categorization and custodianship of architecture artifacts

– an executed internal and external communication plan

Page 6

4Q08

2Q09

1Q09

3Q09

4Q09

First Conceptual Meeting

Informal Organizational Meetings – Orlando/Paris

OHT Architecture Project Q2 2009

Architecture Principles & Best Practices-harmonized with current projects

Draft Framework & Current State Examples

Tooling Classification & Governance recommendations

Page 7

SAEAF Background (1)A “Services-Aware Enterprise Architecture for HL7”

• April 08: HSSP-sponsored “Services in Healthcare” conference, Chicago, IL (attended by HL7 CTO)

• May 08: HL7 CTO asks the HL7 ArB to “develop a straw-man proposal for services development within the context of an HL7 Enterprise Architecture”

– “Specify the artifacts and processes necessary to allow HL7 to define specifications for SOA integration.”

– “Define an HL7 Enterprise Architecture Framework (EAF) which contextualizes HL7 specifications in a SOA environment.”

– Consider services first, but don’t exclude messages or documents as Interoperability Paradigms

• “HL7 EAF should be services-aware, not service-specific”

Page 8

SAEAF Background (2)A “Services-Aware Enterprise Architecture for HL7”

• Summer 08: HL7 Executive Committee agreed to sponsor three face-to-face “ArB EAF Jump-Start” meetings

– Modeled after “Left-Hand Side of the RIM” project (1998)

– Three 3-day F2F meetings in June, July, August, 2008• Transparent process

– Open attendance

– Published agendas

– Published artefacts and works-in-progress

• September 08: CTO and TSC requested that initial results of the Jump-Start process be presented at the Vancouver WG meeting via a series of joint-WG meetings and open ArB sessions

Page 9

SAEAF Background (3)A “Services-Aware Enterprise Architecture for HL7”

• Jump-Start Deliverables (largely contained in the collection of SAEAF documents) to include (but not be limited to):

– EA framework “informed by” service specification considerations and industry experience (“services-aware”)

– Identification and initial specification of required infrastructure currently missing or incomplete in HL7

• Behavioral Framework (BF)

• Enterprise Conformance & Compliance Framework (ECCF)

• Governance Framework (GF)

– Operational vision for SAEAF deployment • Integration with existing HL7 and HSSP processes

– complimentary to existing relationships (e.g. OMG)

– extension to message and document Interoperability Paradigms

Page 10

• HL7 ArB

– Yongjian Bao, GE Healthcare

– Jane Curry, Health Information Strategies

– Grahame Grieve, Jiva Medical

– Anthony Julian, Mayo

– John Koisch, NCI

– Cecil Lynch, OntoReason

– Charlie Mead, CTO NCI

– Nancy Orvis, DoD MHS

– Ron Parker, Canada Health Infoway

– John Quinn, Accenture, CTO HL7

– Abdul Malik Shakir, Shakir Consulting

– Mead Walker, Health Data and Interoperability

• Other

– Alex DeJong, Siemens

– Ed Larsen, HITSP

– Galen Mulrooney, JP Systems, VA

– Scott Robertson, Kaiser

– Rich Rogers, IBM

– Ann Wrightson, NHS UK

Participants brought a wide range of perspectives to the discussion

SAEAF Background (4)Jump-Start Participants

Page 11

SAEAF Value Proposition (1):Working Interoperability

Interoperability Paradigm (Messages, Documents, Services): specifications which enable two or more (HL7) trading partners to collaborate in the context of a specific business interaction

– No assumptions of size, character, or identity of parties• Nations, Enterprises, Departments, Individual, Systems, etc.

– No assumptions of exchange details (What, Why, How, etc.)

Page 12

SAEAF Value Proposition (2):Working Interoperability

• Working Interoperability:

– The collection of structures, processes, and components• that support Computable Semantic Interoperability

• in the context of a Conformance/Compliance Framework.

• SAEAF facilitates the explicit and layered expression

• of the set of static, functional, and behavioral semantics that collectively enable Working Interoperability.

• Specifications developed to enable Working Interoperability

– are defined in such a manner so as to ensure that they are• usable, useful, durable, and that they are

• implementable in a variety of deployment contexts

– in a repeatable, comprehensible manner.

Page 13

SAEAF Value Proposition (2):Working Interoperability (WI)

• WI: the deterministic exchange of data/information in a manner that preserves shared meaning

• Two parties interoperate based on a combination of• certified “level of conformance” to formal Conformance Statements (CnS)

• stated “level of explicit compliance” to integrated specifications or standards expressed via Compliance Statements (CmS)

• “levels” help quantify degree-of-difficult in achieving WI

Agree on “Reference” view

Agree on “Conceptual” view

Agree on“Platform-Independent” view

Agree on“Platform -Specific” viewA

B

DC

F

Component Component

E

Page 14

RM-ODP (1) ISO Standard (RM – ODP, ISO/IEC IS 10746 | ITU-T X.900 )

Enterprise View: concerned with the purpose, scope and policies governing the activities of the specified system within the organization of which it is a part

Information View: concerned with the kinds of information handled by the system and constraints on the use and interpretation of that information;

Computational View: concerned with the functional decomposition of the system into a set of objects thatinteract at interfaces – enabling system distribution;

Engineering View: concerned with the infrastructure required to, and distributionof, the computing resources defined in the Computational View.

Technology View: concerned with the choice of technology to support system distribution and operation

Why?

True?

Where?

How?

What?

An instance of a SAEAF Specification Stack is made up of Conformance Statements which are asserted as valid by a technology binding and verified by Certification. ECCF cells contain artifacts -- developed de novo or drawn from pre-existing specifications -- that are (often) generated via Constraint Patterns. They are sorted by RM-ODP Viewpoints.

Page 15

RM-ODP (2) ISO Standard (RM – ODP, ISO/IEC IS 10746 | ITU-T X.900 )

• Non-hierarchical and Non-orthogonal

– Each Viewpoint can (and most often will) contain a hierarchy of “layered” information

– Distinguish Conformance vs Compliance Statements• CnS validated/certified via technology implementation

• CmS (often implicitly) validated(i.e. transformation is correct)

• Both may generate hierarchical“layers” in a SS instance

InformationBusiness /

EnterpriseComputational

Engi

neer

ing

Technology

An instance of a SAEAF Specification Stack is made up of Conformance Statements which are asserted as valid by a technology binding and verified by Certification.

ECCF cells contain artifacts -- developed de novo or drawn from pre-existing specifications -- that are (often) generated via Constraint Patterns. They are sorted by RM-ODP Viewpoints.

Page 16

The SAEAF ECCF Context (1)

• Group A develops Specification X

• Group A publishes Specification X

– Developers want to implement Specification X

• Group B develops Specification Y

• Group A wants to say “Specification X uses Specification Y”

• ECCF Context Certify that

– Specification X is “correctly implemented”

– Specification Y is “correctly referenced”

Page 17

The SAEAF ECCF Context (2)

• Problem:

– What does “correctly implemented” mean?

– What does “correctly referenced” mean?

– How can we define these concepts explicitly?• Support repeatable/reproducible certification of “correctness”

– Computational

– Human-assisted

• If explicit definitions and processes are not established -- e.g. via the ECCF -- implicit assumptions will be inconsistently made explicit as they are realized in technology components, and are usually only apparent at run-time

Page 18

The SAEAF ECCF Context (3)

• Answers based on three inter-related but separate concepts

– Conformance

– Compliance

– Consistency

• Each defines “one or more relationships between components/artifacts in an instance of the Specification Stack”

– “transformations”• Constraint (most common)

• Extension (must be well-defined to sustain WI)

• Other

– “dependencies” (use of one Specification by another)

Page 19

The SAEAF ECCF Context (4)• Conformance

– Conformance Statements certified/validated by Technology realization/binding

• Compliance

– Compliance Statements implicitly validate that Source artifact is correctly transformed

• between Specification Stack levels-of-abstraction

– Conceptual-layer Information Model (DAM) is transformed to PIM Class Model

• transformation of a single, cell-specific artifact

– Generalized Constraint Pattern» Restriction of possible value sets on an attribute

Page 20

The SAEAF ECCF Context (5)

• Consistency

– Does involve the logical notions of “if I have A, I need to have B”• Activity Diagram in Computational VP which exposes a data gram must

consistently use the semantics of a

• Class Diagram in Information VP in which the specific semantics of the data gram are represented

– Does not involve “transformations” between specification artifacts

• Transformations are about Compliance

– not Conformance

– not Consistency

Page 21

ECCF Terms of Art

• Specification Stack

• Conformance Statement (and associated Assertion)

• Conformance Certification (validation of Assertions)

• Compliance Statement (and associated Transformation)

• Compliance Certification (usually implicit)

• Consistency (logical coupling of SS artifacts for single topic)

• Traceability (vertical per-column navigation of SS instance)

• Jurisdiction (see Governance presentation)

• Provenance (see Governance presentation)

Page 22

The ECCF Specification Stack (1)

• The ECCF Specification Stack

– Classifies artifacts by RM-ODP Viewpoints

– Specification levels engineering level-of-abstractions• Conceptual Level – Concept (Requirements/Analysis) Model

• Platform-Independent – Logical Model

• Platform-Specific – Implementable Model

– not an implementation per se An instance of a SAEAF Specification Stack is made up of Conformance Statements which are asserted as valid by a technology binding and verified by Certification.

ECCF cells contain artifacts -- developed de novo or drawn from pre-existing specifications -- that are (often) generated via Constraint Patterns. They are sorted by RM-ODP Viewpoints.

Page 23

ECCF Specification Stack (2)

• A given instance of the ECCF Specification Stack is scoped to a given “topic”

– A coherent (consistent) collection of artifacts which define a “standard” for achieving Working Interoperability

• Enterprise Architecture Specification: “a layered set of ECCF Specification Stacks, each focused on a separate topic.”

– Multiple dependencies between stack instances including• Reuse

• Constraint

An instance of a SAEAF Specification Stack is made up of Conformance Statements which are asserted as valid by a technology binding and verified by Certification.

ECCF cells contain artifacts -- developed de novo or drawn from pre-existing specifications -- that are (often) generated via Constraint Patterns. They are sorted by RM-ODP Viewpoints.

Page 24

The ECCF Specification Stack (3)(Exemplar artifact types that capture WI Semantics)

Topic

Specification

Enterprise / Business Viewpoint

Information Viewpoint

Computational Viewpoint

Engineering Viewpoint

Conceptual Business Context, Reference Context

Domain Analysis (Information) Model

Collaboration Analysis, Functional Profile(s), Service Roles and

Relationships

Existing Platform capabilities

Platform-

Independent

Business Governance

Project-oriented Domain Information Model, Constrained Information Model,

Localized Information Model, Hierarchical Message Definition

Collaboration Types, Interface Specification

and Functional Groups, Interaction Types and

Collaboration Participations, Contracts

Parts

Existing Platform models, libraries, etc.

Platform-

Specific

Rules, Procedures Localized Information Model,Transforms,

Schema

Collaboration scripts, Orchestrations, Realized

Interfaces

Execution Context, Platform Bindings, Deployment Model

Technology VP tests Conformance Statements collected in cells

Page 25

The ECCF Specification Stack (4): Conformance, Compliance, Consistency, Traceability

Topic

Specification

Enterprise / Business Viewpoint

Information Viewpoint

Computational Viewpoint

Engineering Viewpoint

Conceptual

Platform

Independent

Platform

Specific

Traceable

Consistency

ConformanceStatements

Constrained ConformanceStatements

Constrained ConformanceStatements

Compliance

Compliance

Conformance

Technology

ConformanceAssertions

source target

source target

Page 26

Reference Specifications/Materials (1)(Exemplar Artifacts)

Reference

Specification

Enterprise / Business Viewpoint

Information Viewpoint

Computational Viewpoint

Engineering Viewpoint

HL7 Reference

EHR-FM, Clinical Statement Pattern

RIM, CDA EHR-FM, Behavioral Framework

Platform Architectures,

RIMBAA

• A given Reference artifact may be used, applied, referenced, transformed or otherwise leveraged by any cell of the Specification Stack (within the same VP)

– Reference Specifications do not reside in a “layer” of the Specification Stack per se

• “Surround” or “provides input to” instances of the SS

– Other SDOs or “organizations with significant operational jurisdiction” (e.g. govt programs) may also produce (and require) Reference Specifications/Materials

Page 27

Abstraction Layers

Viewpoint

Reference Specifications/Materials (2)

Technology

Specification Stack

E /B

Info

Com

p

Eng

Conce

ptual

Platfor

m

Indep

ende

nt

Platfor

m Spe

cific

HL7 Reference OHT Reference

Page 28

Reference Specifications/Materials (3)

Technology

Con

form

ance

Specification Stack

Reference specifications/standards -- each specified with its own Specification Stack -- can be “plugged in” in any SS cell.

Compliance of these standardsis often not validated untilConformance is formally tested.

ConformanceStatement

ComplianceConformanceStatement

ConformanceStatement

Compliance

com

plia

nce

SDO2 Reference

com

plia

nce

SDO1 Reference

Page 29

Viewpoint

The ECCF Specification Stack (5):Mature Topic

Technology

Specification Stack

E /B

Info

Com

p

Eng

Abstraction Layers

Concp

tual

Platfor

m

Indep

ende

nt

Plat

form

Sp

ecific

X

X

X

X

X

X

X

X

X

X

X

X

X denotes artifacts that HL7 or another SDO (or relevant jurisdiction) has defined

O denotes things that an implementer must define (none shown … thus mature)

Note that implementers will always have to define some things (e.g. local governance) when adopting a standard, preferably documented in a compliant specification

Mature specifications are (in part) mature because they are comprehensively and relevantly compliant to other standards

Page 30

Abstraction Layers

Conce

ptual

Platfor

m

Indep

ende

nt

Plat

form

Sp

ecific

ECCF Specification Stack (6):Mature Topic

Technologyco

nfor

man

ce

Specification Stack

Because of the topic’s maturity, realizing the CnSs referenced by the Red arrows in Technology results in realizing the CnSs referenced by the black arrows

Conformance Statements

Conformance Statements

Conformance Statements

Conformance Statements

Page 31

The ECCF Specification Stack (7):Mature Topic

Technology

conf

orm

ance

Specification Stack

Green arrows represent (implied) Compliance to other standards (asserted in isolation)

Black arrows represent Conformance Statements made at multiple levels of abstraction(L R flow indicates movement through Conceptual, PIM, and PSM)

Red arrows represent validation of Conformance Statements

Consistency and Traceability not explicitly shown

Compliance and Traceability between the levels of the Specification Stack is documented via the Provenance.

Natural alignments are identified (e.g. EHRs-FM and Computational components via use of SDO3)

Conformance Statements

Conformance Statements

Conformance assertions

Conformance Statements

com

plia

nce

SDO2 Reference

com

plia

nce

SDO3 Reference

3 rows: Con, PIM, PSM

4 columns: RM-ODP VPs

Page 32

The ECCF and Governance

• The ECCF can only be effective when associated with a well-defined Governance Framework (GF)

– SAEF Education Series Part 4

• In the context of multiple SDOs or other jurisdictional organizations developing Specifications/Standards that are shared across multiple Specification Stacks, effective Governance is a Critical Success Factor.

Page 33

Conclusions (1):The Value of an ECCF

• The enemy of WI is implicit Conformance Statements (CnS)

– A specification that does not explicitly document all the viewpoints at the various levels of abstraction forces implementers to make assumptions about the missing CnSs

• Missing CnSs will be explicitly realized in an implementation but may not be documented in any specification

• Loss of traceability

• The greater the distance on the Stairway to Heaven, the more difficult the transforms required to achieve WI– In some cases, CSI adapters MAY NOT be able to be built

• For example, you cannot act on data that was never collected, or was collected with incompatible meaning

Page 34

Conclusions (2):The Value of an ECCF

• ECCF provides a structured way to

– Certify Conformance: implementation testability to stated Conformance Statements

– Certify Compliance: explicit transformation/utilization of Specification/Standard artifacts

• An organization adopting an ECCF can build explicit Specifications/Standards that are compliant to other Specifications/Standards

– Each Specification/Standard encapsulates important business rules

• Now able to be considered enterprise architectural requirements

Page 35

Conclusions (3):Certifications and Life Cycle

• In the interoperability world, certification of Conformance occurs at a different point in the lifecycle than the certification of Compliance or Consistency

– Conformance certified at technology binding time

– Compliance certified at ballot or specification creation

– Consistency empirically certified through lifecycle

• Traceability makes the “most sense” when it can be validated “from the top to the bottom of the Specification Stack”

Page 36

Conclusions (4):The Value of an ECCF

• Precise specifications also enable stakeholders to quantitatively assess systems or components to determine whether they are explicitly conformant with the identified standards and therefore compliant to the other interoperability standards referenced in a given Specification Stack.

Page 37

Conclusions (5):A Final Metaphor

• The ECCF as a framework defines a set of “standards of measurement” from which an EAS can be developed

– Similar to plumb line, level, ruler, measurement systems in the “hard” building traces

• The results of applying the ECCF (and its associations with Governance and the Behavior Framework) in an enterprise context results in a set of inter-related Specification Stacks

– i.e. an Enterprise Architecture Specification (EAS)“You can’t build a skyscraper by nailing together 1000 dog houses.” (Grady Booch)

“You can’t build a skyscraper with just a hammer and a saw.” (John Koisch)

Page 38

Page 39

Definitions:Provenance and Jurisdiction

• Jurisdiction: The boundary and scope of authority of a person or group. May be bound by a geographical boundary and/or a specific domain of influence.

– The artifacts which populate a Specification Stack by definition fall under an implicit or explicit Jurisdiction

– SDOs are one example of a Jurisdiction• Government authorities

• Enterprises

• Collaborating participants within the scope of working interoperability

– See SAEAF Education Series Part 4 (Governance)

Page 40

Definitions:Provenance

• Provenance: Documentation that identifies the traceability of the history of each artifact in a specification from it’s origination as requirements documentation through to implemented technical components - may be included within the specification or by reference to an external artifact– Also includes other standards and reference artifacts

that are used / referenced by an artifact (compliance)

• Demonstrates accountability– Traceability is an “instance-level” concept

– Provenance is a “collection-level” concept• See SAEAF Education Series Part 4 (Governance)

Page 41

Definitions (0):HL7 use of Conformance vs Compliance

• Terms often used interchangeable and ambiguously

– HL7 V2.x (x < 5):• “compliance” using MSH as the first segment

– HL7 V2.y (y > 4), V3:• “conformance” “testable” as to ability to fulfill to stated specification

• SAEAF utilizes both terms

– Conformance of a technology binding to a given Conformance Statement (CnS) is claimed via Conformance Assertion (CnA)

– Compliance of an artifact transformation defined by a Constraint Pattern (for example)…but wait, there’s more…

Page 42

Definitions (1):Conformance

(http://www.nehta.gov.au/dmdocuments/IF_2%200.pdf)• Boolean value signifying the ability of a given implementation to satisfy a

specific Conformance Statement (CnS)

• For a given CnS, an implementation is conformant IF it satisfies (“validates”) the specified CnS

– Conformance is granular» Asserted and certified for a single Conformance Statement

– Ideally certification is accomplished via automation» Certain CnSs may require human interaction for certification

– Conformance is focused on implementation “stronger” than Compliance

• Conformance does not a priori depend on the existence of a “standard” (in the formal sense of the term)

– Specification containing CnSs is all that is required

Page 43

Definitions (2):Conformance Statement vs Assertions

• A Conformance Statement (CnS) is testable and verifiable statement about a system capability

– A system asserts conformance to a given CnS via a Conformance Assertion (CnA)

– Assertion of specific capability can be verified as True or False at specific test points in an implementation, referred to in RM-ODP as “conformance points”

• Overall process is Conformance Certification

• Usually done by 3rd-party to avoid conflict-of-interest

• E.G. “Operation X <MUST, MAY,…> bind to the RIM attribute Observation.value with a value set specified in LOINC as ….”

Page 44

Definitions (3):Compliance

(http://www.nehta.gov.au/dmdocuments/IF_2%200.pdf)• Given an existing Source artifact, a Target artifact is said to be

compliant IF it has been derived using known, agreed-upon derivation methods. More specifically…

– The statement “HL7 XML is compliant with W3C XML” means that “All valid HL7 XML message instances are also conformant to W3C XML.”

– “The Target artifact is compliant with the Source artifact IF all conformant implementations of the Target are also conformant with the Source.” (from RM-ODP standard)

• Extensions may introduce new CnSs and affect Conformance

– e.g. Web Services security specifications must be compliant with Web Service messaging (SOAP) if a security application is to support communication using SOAP

Page 45

Definitions (4):Compliance (cont)

• Navigation between levels of the SS is via transformations and therefore about Compliance.

• One type of transformation involves CnSs made at one level to those made at another level.

– The results of these valid transformations will be traceability of a given CnS

• the traceable path may be a one-to-many-to-many path as the successively more concrete levels (rows) of the SS are vertically traversed

• In the end, however, overall Conformance (and not Compliance) will be asserted by a technology binding and certified/validated as True or False.

Page 46

Definitions (5):Consistency

• Addresses Specification Stack integrity and logical consistency

– Coherence of artifacts across Viewpoints• E.G. An Activity Diagram in the Business VP of the Conceptual layer of the SS

utilizes a datagram passed between 2 activities The Information VP of the Conceptual layer must contain a class diagram

which explicitly defines the static semantics of the datagram The Computational VP of the Platform-Independent layer should contain a

direct (or traceable) realization of the business behavior depicted in the Activity Diagram which utilizes the static components defined by the Information VP

– Not as formally defined as Conformance or Compliance• Critically important for communication among multiple enterprise stakeholders

– Cannot (at present) be validated automatically

Page 47

Definitions (6):Certification

• A description of a specific process

– Conformance Certification (implementation)

• the common use of the term -- validation of Conformance Assertions

– Compliance Certification (artifact transformation)• usually verified during Conformance Certification

– Consistency Certification (artifact coherence)• usually verified during Conformance Certification

• The process itself

– “The system is going through Conformance Certification”• Commonly only applied to Conformance Certification

Page 48

RM-DOP, ECCF andConformance and Compliance (1)

• Conformance Statement

– Organized within four RM-ODP “Viewpoint Specifications”• Business, Information, Computation, Engineering

• Viewpoint Specifications

– Collected per topic

– Grouped by levels of abstraction• Conceptual (Requirements/Analysis)

• Platform-Independent (Logical)

• Platform-Specific (Implementable)

– Not an implementation per se

Page 49

RM-ODP, ECCF and Conformance vs Compliance (2)

• Technology: the 5th Viewpoint

– A specific technology binding that asserts -- via Conformance Assertions -- conformance to one or more Conformance Statements (CnSs) gathered from the other Viewpoints

• Compliance (redux): RM-ODP uses the term compliance to indicate that the same software component can conform to more than one standard

– Standard A is compliant with Standard B if

– all conformant implementations of Standard A are

– also conformant to Standard B» HL7 XML is compliant with W3C XML if all valid HL7 XML message instances are also

conformant to W3C XML.

Page 50

RM-ODP, ECCF and Conformance vs Compliance (3)

• Conformance

– A Conformance Assertion made by a technology binding claiming fulfilment of a specific Conformance Statement (CnS) must be certified (“validated”) as True or False

• Compliance

– Compliance is not about technology binding

– Compliance is about transformations between artifacts– Transformations often implement constraint patterns

» ECCF row row, i.e. Levels-of-Abstraction in MDA» ECCF intracellular, i.e. adoption of a specification for use by another

• Consistency and Traceability (defined later) are also important

• Collectively, these terms navigate instances of the ECCF Specification Stack

Page 51

RM-ODP, ECCF and Conformance vs Compliance (4):

The Meaning of “Certification”• Conformance

– the “traditional” dimension-of-application of the term

– Certification body is (usually) done by an independent from organization claiming Conformance

• Claims made via one or more Conformance Assertions) to one or more Conformance Statements (collected in instances of Specification Stacks)

• Certification verifies CnAs as True

• Conformance Certification is a statement to verify Trust

Page 52

RM-ODP, ECCF and Conformance vs Compliance (5):

The Meaning of “Certification”• Compliance Certification

– Not formally done• “compliance certification” is not an “operational reality” in most cases

• e.g. of “formal” compliance certification: “HL7 XML ITS is compliance with W3C XML specification”

– Transformations are often not formally defined

– Validity of a given transformation may not be known• verifiable until Conformance Certification, balloting, or other “formal”

testing/validation/certification processes

– Compliance navigates an ECCF SS either “vertically” or “horizontally”

• Vertically (row-to-row downward: decreasing LoA

• Horizontally (intracellular): constraints/localizations

Page 53

RM-ODP, ECCF and Conformance vs Compliance (6):

Summary• By formalizing the notions of Conformance, Compliance, and

Certification, the ECCF provides

– a multi-dimensional framework and vocabulary to…• document explicit assumptions and three levels of abstraction

• integrate specifications or standards developed outside of the SS per se

– and to utilize these external standards in any cell of an ECCF SS

– a model for enabling formal compliance certification in special cases where it may be warranted prior to technology binding and conformance certification