1. 6/3/2016 11:23 AM April 9, 2009 OHT Architecture Project: Update and Integration with HL7 SAEAF

2. Page 2 OHT Architecture Project Q2 2009 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 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 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 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 Editions Dependencies Pressures Statistics Contributing Participants: NCI, Infoway, NHS, NextJ, IHTSDO, NEHTA, HL7

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

4. 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. http://www.openhealthtools.org/Documents/Open%20Health%20Tools%20- %20Development%20Process.pdf 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.)

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

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

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

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

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

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

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

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

13. 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” view A B D C F Component E

14. Page 14 RM-ODP (1) ISO Standard (RM – ODP, ISO/IEC IS 10746 | ITU-T X.900 ) 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.

15. 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 Information Business / Enterprise Computational Engineering 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.

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

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

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

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

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

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

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

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

24. 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, ProceduresLocalized Information Model,Transforms, Schema Collaboration scripts, Orchestrations, Realized Interfaces Execution Context, Platform Bindings, Deployment Model Technology VP tests Conformance Statements collected in cells

25. 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 Conformance Statements Constrained Conformance Statements Constrained Conformance Statements Compliance Conformance Technology Conformance Assertions source target source target

26. 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, CDAEHR-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

27. Page 27 Abstraction Layers Viewpoint Reference Specifications/Materials (2) Technology Specification Stack E /B Info Comp Eng Conceptual Platform Independent Platform Specific HL7 Reference OHT Reference

28. Page 28 Reference Specifications/Materials (3) Technology Conformance Specification Stack Reference specifications/standards -- each specified with its own Specification Stack -- can be “plugged in” in any SS cell. Compliance of these standards is often not validated until Conformance is formally tested. Conformance Statement Compliance Conformance Statement Conformance Statement Compliance compliance SDO2 Reference compliance SDO1 Reference

29. Page 29 Viewpoint The ECCF Specification Stack (5): Mature Topic Technology Specification Stack E /B Info Comp Eng Abstraction Layers Concptual Platform Independent Platform Specific 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

30. Page 30 Abstraction Layers Conceptual Platform Independent Platform Specific ECCF Specification Stack (6): Mature Topic Technology conformance 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

31. Page 31 The ECCF Specification Stack (7): Mature Topic Technology conformance 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 assertions Conformance Statements compliance SDO2 Reference compliance SDO3 Reference 3 rows: Con, PIM, PSM 4 columns: RM-ODP VPs

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

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

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

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

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

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

38. Page 38

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

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

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

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

43. 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 3 rd -party to avoid conflict-of-interest E.G. “Operation X bind to the RIM attribute Observation.value with a value set specified in LOINC as ….”

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

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

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

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

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

49. Page 49 RM-ODP, ECCF and Conformance vs Compliance (2) Technology: the 5 th 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.

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

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

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

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