OHT Architecture Project:
Update and Integration with
HL7 SAEAF
April 9, 2009
3/22/2016 12:30 AM
OHT Architecture Project Q2 2009
Pressures
•Expectation for detailed Technical
Architecture Solutions
•Expectation for Architectural
Framework that allows for a Tooling
Architecture to emerge through
Projects
•Desire to reuse tooling components
•Desire to relearn from best practices
•Customer expectations to optimize
and align Tooling investments
Content
•Architecture principles
•Tool classification mechanism
a 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
Added
Deleted & Changed
communication plan
Dependencies
•Funding for Architecture Project
team members
•Active cooperation from other
OHT Project Committers
•Successful communication to
OHT projects Q2/Q3
Packaging Editions
-Principles, Architecture Framework
-Specification Stack w examples
-Tool classification
-Recommendations to the Board
Statistics
Contributing Participants: NCI,
Infoway, NHS, NextJ, IHTSDO,
NEHTA, HL7
Milestones
•Architectural Principles Q2/09
•Tooling Architectural Vision Q3/09
•Architectural Framework Q3/09
•Tooling Classification and
Governance recommendations Q4/09
Page 2
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 enduser 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 3
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 4
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 5
OHT Architecture Project Q2 2009
4Q09
3Q09
Tooling Classification & Governance recommendations
Draft Framework & Current State Examples
Architecture Principles & Best Practices
2Q09 -harmonized with current projects
1Q09
Informal Organizational Meetings – Orlando/Paris
4Q08 First Conceptual Meeting
Page 6
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 7
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 8
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 9
SAEAF Background (4)
Jump-Start Participants
•
HL7 ArB
•
Other
– Yongjian Bao, GE Healthcare
– Alex DeJong, Siemens
– Jane Curry, Health Information
Strategies
– Ed Larsen, HITSP
– Grahame Grieve, Jiva Medical
– Anthony Julian, Mayo
– John Koisch, NCI
– Galen Mulrooney, JP Systems, VA
– Scott Robertson, Kaiser
– Rich Rogers, IBM
– Ann Wrightson, NHS UK
– Cecil Lynch, OntoReason
– Charlie Mead, CTO NCI
– Nancy Orvis, DoD MHS
Participants brought a wide range of
perspectives to the discussion
– Ron Parker, Canada Health Infoway
– John Quinn, Accenture, CTO HL7
– Abdul Malik Shakir, Shakir
Consulting
– Mead Walker, Health Data and
Interoperability
Page 10
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 11
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 12
SAEAF Value Proposition (2):
Working CInteroperability
(WI)
D
E
B
A
Component
Component
Agree on
“Platform -Specific” view
Agree on
“Platform-Independent” view
Agree on “Conceptual” view
F
Agree on “Reference” view
• 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
Page 13
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
Why?
Information View: concerned with the kinds of information
handled by the system and constraints on the use and interpretation of
that information;
What?
Computational View: concerned with the functional
decomposition of the system into a set of objects that
interact at interfaces – enabling system distribution;
How?
Engineering View: concerned with the infrastructure required to, and distribution
of, the computing resources defined in the Computational View.
Where?
Technology View: concerned with the choice of technology
to support system distribution and operation
True?
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 14
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
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.
Technology
Page 15
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 16
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 17
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 18
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 19
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 20
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 21
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 RMODP Viewpoints.
Page 22
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 23
The ECCF Specification Stack (3)
(Exemplar artifact types that capture WI Semantics)
Topic
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-
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.
Rules, Procedures
Localized Information
Model,Transforms,
Schema
Collaboration scripts,
Orchestrations, Realized
Interfaces
Execution Context,
Platform Bindings,
Deployment Model
Specification
Independent
Platform-
Specific
Technology VP tests Conformance Statements collected in cells
Page 24
The ECCF Specification Stack (4):
Conformance, Compliance, Consistency, Traceability
Consistency
Topic
Specification
Enterprise /
Business
Viewpoint
Information
Viewpoint
Computational
Viewpoint
Engineering
Viewpoint
Conceptual
Platform
Independent
Platform
Specific
source
Constrained
Conformance
Statements
Compliance
Constrained
Conformance
Statements
Compliance
source
target
Traceable
Conformance
Statements
target
Conformance
Technology
Conformance
Assertions
Page 25
Reference Specifications/Materials (1)
(Exemplar Artifacts)
Reference
Specification
HL7 Reference
Enterprise /
Business
Viewpoint
Information
Viewpoint
Computational
Viewpoint
Engineering
Viewpoint
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 26
Reference Specifications/Materials (2)
HL7 Reference
OHT Reference
Abstraction Layers
Viewpoint
Specification Stack
Technology
Page 27
Reference Specifications/Materials (3)
Compliance of these
standards
is often not validated until
Conformance is formally
tested.
SDO2 Reference
SDO1 Reference
Conformance Compliance
Conformance ComplianceConformance
Statement
Statement
Statement
Specification Stack
Conformance
Reference
specifications/standards -each specified with its own
Specification Stack -- can
be “plugged in” in any SS
cell.
Technology
Page 28
The ECCF Specification Stack (5):
Mature Topic
Mature specifications are (in part)
mature because they are
comprehensively and relevantly
compliant to other standards
Abstraction Layers
X
X
X
X
X
X
Viewpoint
X
X
X
X
X
X
Specification Stack
Technology
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
Page 29
ECCF Specification Stack (6):
Mature Topic
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
Abstraction Layers
Conformance Statements
Conformance Statements
Conformance Statements
Conformance Statements
conformance
Specification Stack
Technology
Page 30
The ECCF Specification Stack (7):
Mature Topic
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)
3 rows: Con, PIM, PSM
4 columns: RM-ODP VPs
SDO3 Reference
Conformance assertions
Conformance Statements
SDO2 Reference
Conformance Statements
Consistency and Traceability not
explicitly shown
Conformance Statements
Specification Stack
conformance
Red arrows represent validation of
Conformance Statements
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)
Technology
Page 31
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 32
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 33
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 34
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 35
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 36
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 37
Page 38
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 39
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 40
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 41
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 42
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 43
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, agreedupon 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 44
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 45
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 46
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 47
RM-DOP, ECCF and
Conformance 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 48
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 49
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 50
RM-ODP, ECCF
and Conformance vs Compliance (4):
• Conformance
The Meaning of “Certification”
– 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 51
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 52
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
Page 53