Presentation on theme: "Enterprise Architecture Framework"— Presentation transcript:
1Enterprise Architecture Framework HL7 Services-AwareEnterprise Architecture Framework(SAEAF)SAEAF Education Series Session 1: Introduction and Overview September 2009
2SAEAF Education Series Overview The SAEAF Education Series includes the following sessions:Part 1: Introduction and Overview to SAEAFPart 2: Behavioral FrameworkPart 3: Enterprise Conformance and Compliance FrameworkPart 4: SAEAF GovernancePart 5: SAEAF Examples
3SAEAF Education Series (1): Part 1: Introduction and Overview to SAEAF The Introduction and Overview includes the following topics:SAEAF backgroundSAEAF Value Proposition: Working InteroperabilitySAEAF Facts and the Lens of SAEAFSAEAF, Service-Oriented Architecture (SOA), and Enterprise Architecture (EA): Core PrinciplesHistory of Services in Health Level 7 (HL7)Implications of putting SAEAF into practiceSummary
4SAEAF Education Series (2): Part 2: Behavioral Framework The Behavioral Framework session includes the following topics:Contracts, Roles, CollaborationsImplementation Patterns for the Behavioral FrameworkMapping to HL7 Dynamic ModelMore topics are possible in the future.4
5SAEAF Education Series (3): Part 3: Enterprise Conformance and Compliance Framework The Enterprise Conformance and Compliance Framework (ECCF) session includes the following topics:The multidimensional world of:ConformanceComplianceConsistencyCertificationTraceability, Jurisdiction, and ProvenanceLayered Specifications and Layered ECCFRelationship of ECCF to SAEAF Governance5
6SAEAF Education Series (4): Part 4: SAEAF Governance The SAEAF Governance session includes the following topics:Role of Technical Steering Committee (TSC)Role of Architect Board (ArB)Role of Other Standards Developing Organizations (SDO)Organizational ImpactsMore topics will be added in the future.6
7SAEAF Education Series (5): Part 5: SAEAF Examples The SAEAF Examples session includes the following topics:Service Interoperability ParadigmMessage Interoperability ParadigmDocument Interoperability ParadigmMore topics will be added in the future.7
8SAEAF Series Part 1: Introduction and Overview to SAEAF (1) PrerequisitesNo SAEAF prerequisitesEssential: Familiarity with the problems of achieving working interoperability in the healthcare / life sciences / clinical research domainHelpful: General knowledge of HL7OutcomesUnderstanding of the organizational principles and contexts around which SAEAF was developedGeneral understanding of core components of SAEAFPreparation for all other SAEAF Education materials
9SAEAF Series Part 1: Introduction and Overview to SAEAF (2): What is SAEAF? The HL7 Services-Aware Enterprise Architecture Framework (SAEAF) provides consistency between all HL7 artifacts, and enables a standardized approach to Enterprise Architecture development and implementation, and a way to measure the consistency.SAEAF is a way of thinking about producing specifications that explicitly describe the governance, information, and behavioral semantics that are needed to achieve computable semantic working interoperability. The intended information transmission technology might use a services, messaging, or document exchange approach.
10SAEAF Series Part 1: Key Definitions Artifact: Any portion of a specification that is controlled and can be versioned.For example, an artifact can be a model, a document, or an XML schema, for example.Services-aware: The definition and use of services technology and the interoperability standards, including the exchange of messages and sharing of documents.
11Background (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 also include messages or documents as Interoperability Paradigms.Make HL7 EAF services-aware, not services-specific.
12Background (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 meetings in June, July, August, 2008Transparent process with open attendance: Published agendas, minutes, and work-in-progress artifacts.Jump-Start goal: How should services and other IP artifacts, such as messages and documents, be defined, specified, implemented, and governed within HL7.September 08: CTO and TSC requested that the initial results of the Jump-Start process be presented at the Vancouver workgroup (WG) meeting.
13Background (3): Jump-Start Participants HL7 ArB:Yongjian Bao, GE HealthcareJane Curry, Health Information StrategiesGrahame Grieve, Jiva MedicalAnthony Julian, MayoJohn Koisch, NCICecil Lynch, OntoReasonCharlie Mead, CTO NCINancy Orvis, DoD MHSRon Parker, Canada Health InfowayJohn Quinn, Accenture, CTO HL7Abdul Malik Shakir, Shakir ConsultingMead Walker, Health Data and InteroperabilityOther attendees:Alex DeJong, SiemensEd Larsen, HITSPGalen Mulrooney, JP Systems, VAScott Robertson, KaiserRich Rogers, IBMAnn Wrightson, NHS UKParticipants brought a wide range of perspectives to the discussion.
14Background (4): A “Services-Aware Enterprise Architecture for HL7” The Jump-Start deliverables include the following:“Services-aware” EA framework “informed by” service specification considerations and industry experienceIdentification and initial specification of required infrastructure that is currently missing or incomplete in HL7Behavioral Framework (BF)Enterprise Conformance and Compliance Framework (ECCF)Governance Framework (GF)Operational vision for SAEAF deploymentIntegration with existing HL7 and HSSP processes include:Complimentary to existing relationships (for example, OMG)Extension to message and document Interoperability Paradigms
15Background (5): A “Services-Aware Enterprise Architecture for HL7” Implications of putting SAEAF into practice:Organizational impact within HL7 and between HL7 and other organizationsTooling impactAdditional SAEAF considerations include:Use and reuse of existing HL7 artifacts:Reference Information Model (RIM)Data typesClinical Document Architecture (CDA)Refined Message Information Models (RMIMs)VocabularyElectronic Health Record System Functional Model (EHRS-FM)The TSC is responsible for organizational change within HL7 and the ArB is responsible for organizational relationships outside HL7.
16Background (6): A “Services-Aware Enterprise Architecture for HL7” SAEAF is services-aware but not services-specific.SAEAF is not Service-Oriented Architecture.The three HL7 Interoperability Paradigms (HL7 Unified Field Theory) consider:MessagesDocumentsServicesThe SAEAF work draws on “service-aware principles,” such as:Contracts, roles, and collaborations (“behavior”)Conformance and complianceGovernance
17SAEAF Background (7) September 2008 Initial SAEAF draft is released. TSC formally adopts SAEAF as “path forward” for EAS.Board of Directors endorses the SAEAF and TSC position.TSC proposes “Alpha project” for SAEAF deployment.April 09: Staffed and funded.Candidate projects identified (all IPs).Details of project are in a separate deck (5) and document.Focus is on education and change management.ScalabilityGovernanceBackward compatibility17
18SAEAF Implementation: Timeline High-level rollout timeline (TSC approved)Sept WGMArB OOCJanuary WGMMay WGM200820092010September WGM –Planning and socializationSAEAF initial comment periodJanuary WGM – Impact and education, drafts for commentArB OOC and May WGM – Refine SAEAFSept WGM – Refine SAEAF, launch Alpha projectThe ArB out-of-cycle (OOC) meetings were held in March and July 2009 to refine SAEAF. The deliverables are now stable enough to try them out in real projects.18
19SAEAF Value Proposition (1): Working Interoperability Is the collection of structures, processes, and components that support Computable Semantic Interoperability in a Conformance and Compliance Framework.SAEAF facilitates the explicit and layered expression of the set of static, functional, and behavioral semantics that collectively enable Working Interoperability.The specifications for enabling Working Interoperability must be defined in such a manner so as to ensure that they are usable, useful, and durable. These specifications are implementable in a variety of deployment contexts in a repeatable, understandable manner.
20SAEAF Value Proposition (2): Working Interoperability Interoperability Paradigm (messages, documents, services):These specifications enable two or more HL7 trading partners to collaborate in a specific business interaction.No assumptions are made for size, character, or identity of parties (nations, enterprises, departments, individuals, systems)No assumptions of exchange details (what, why, how)
21SAEAF Value Proposition (3): Working Interoperability Agree on “Reference” viewAgree on “Conceptual” viewAgree on“Platform-Independent” view“Platform -Specific” viewABDCFComponentEA – F: Trading partnersInteroperability: The deterministic exchange of data and information in a manner that preserves shared meaning.Two “trading partners” interoperate based on a certified “level of shared compliance” to interoperability standards.Certified “level of conformance” determines the degree of automated interoperability that is possible or the difficulty of the transformations that are required to enable interoperability.Shared meaning means that the details are worked out in advance so that both the sender and receiver understand the meaning in common.
22SAEAF Facts (1)Architecture: “A set of resources, relationships, and processes that collectively define a system and its products-of-value.”HL7 deals with both internal and external architectures:HL7’s goal is producing products of value (specifications) that make it easy to accomplish working interoperability with external architectures.HL7 specifications are enabling working interoperability in the healthcare, life sciences, and clinical research areas. (These architectures are all external to HL7.)The internal architecture is “how does HL7 do its job” and the external architecture is how the healthcare systems interoperate. Each organization that considers itself an enterprise has its own architecture. Interoperating organizations have a collective architecture. They are all architectures external to HL7. Refer to the cloud picture two slides ago which depicts architectures within architectures.
23SAEAF Facts (2)SAEAF…Has structural, relationship, and process implications for architecture #1.Is a set of frameworks for producing specifications that support aspects of HL7 architecture #2.SAEAF is not meant to be a “complete” Enterprise Architecture.SAEAF focuses on the critical interoperability aspects of HL7 specifications in each of the three HL7 Interoperability Paradigms.Defines the artifacts and specification semantics needed to support interoperability in healthcare, life sciences, and clinical research.
24SAEAF Facts (3) The 3 component frameworks of SAEAF include: Behavioral Framework (deck 2)Specification of integration semantics of IT componentsLinkage of integration semantics to real-world behaviorsConformance and Compliance Framework (deck 3)Layered to enable “degrees” of conformance and complianceGovernance Framework (deck 4)Internal HL7 governanceHL7 relationships to other organizations that specify standardsRelationships among parties that are implementing working interoperability.Informational Framework (in development)NOTE: The formal “Static Framework” is not listed because of the maturity of the HL7 Reference Information Model (RIM), abstract data type (ADT), and Clinical Document Architecture (CDA) specifications, which are used to describe static semantics in HL7 specifications.The Informational Framework, which is in development, leverages existing Information Framework artifacts, such as RIM, data types, and HL7 core principles.
25SAEAF Facts (4)SAEAF…is now stable enough to begin “pilot” implementations which:Produce SAEAF-compliant message, document, and service specifications.Use and provide feedback for SAEAF-centric education.Perform through Change management processes for SAEAF.Report to the TSC or its designate.The focus of TSC activities going forward is:EducationChange managementAlpha projects in all Interoperability Paradigms
26The Lens of SAEAF (1): Contextualizing SAEAF SAEAF represents the intersection of SOA, MDA, CSI, Distributed Systems Architecture, and HL7 (HDF, Core Principles). SAEAF provides goals, artifacts, portions of a methodology, and a framework for defining the HL7 EA, a robust, durable business-oriented set of constructs that provide extensibility, reuse, and governance.Service-OrientedArchitectureHealth Level 7Computable SemanticInteroperabilityReference Modelfor Open DistributedProcessingModel DrivenArchitectureSAEAF
27The Lens of SAEAF (2): Services-Oriented Architecture Service-Oriented Architecture (SOA)SAEAF is “services-aware;” not “just about services.”Service awareness (at the architecture level) has a need for:Behavioral Framework built around contracts and roles.Well-defined Conformance and Compliance Framework.Focus on Governance.Attention to “separation of concerns” (static vs. dynamic).Technology-independent specifications.
28The Lens of SAEAF (3): Model-Driven Architecture Model-Driven Architecture (MDA) enables the following:Levels of abstraction that layer complexity from conceptual through logical to implementationSupports SOA thinkingSupports partitioning of artifacts to layers of Conformance and Compliance FrameworkSolid tooling support
29The Lens of SAEAF (4): Computable Semantic Interoperability Computable Semantic Interoperability (CSI)Pillar #1: Common model across all domains-of-interestPillar #2: Model #1 bound to robust data-type specificationPillar #3: Methodology for binding terms from concept-based termsPillar #4: A formally-defined process for specifying the static and behavioral semantics of the interoperability scenarioMultiple domains of interest are unified by reflecting common models that are universally applied.
30The Lens of SAEAF (5): Computable Semantic Interoperability Computable Semantic Interoperability (CSI)Individual domains-of-interest may share common concepts (for example, person).CSI informs the generation of SAEAF artifacts.Facilitates expression of explicit semantics across multiple domain models (for example, multiple Clinical Domain Models that are constructed in separate clinical domains).
31The Lens of SAEAF (6): RM-ODP Reference Model for Open Distributed Processing (RM-ODP)ISO standardViewpoints and ontology for human semantic interoperability and for creating specifications of distributed systems
32RM-ODP (1): ISO Standard (RM – ODP, ISO/IEC IS 10746 | ITU-T X.900 ) SAEAF uses the Reference Model for Open Distributed Processing (RM-ODP) as its common language for categorizing the various artifacts.Five viewpoints in which Conformance Statements are made:Enterprise and business viewpointInformational viewpointComputational viewpointEngineering viewpointViewpoints in which Conformance Statements are validated (conformance tested):Technology viewpointThe viewpoints are not hierarchical and might cover the same area of interest (also called “non-orthogonal”). Conformance Statements are what must be tested. Conformance Assertions are made against technology that must be tested to validate.
33RM-ODP (2): ISO Standard (RM – ODP, ISO/IEC IS 10746 | ITU-T X.900 ) Why?What?How?Where?SAEAF Specification Stack is made up of Conformance Statements and Compliance Validations.In SAEAF, the artifacts are constructed via constraint patterns sorted by RM-ODP Viewpoints. For more details, see the ECCF deck.True?
34RM-ODP (3): ISO Standard (RM – ODP, ISO/IEC IS 10746 | ITU-T X.900 ) Non-hierarchical and Non-orthogonalEach viewpoint often can contain a hierarchy of layered information.InformationBusiness & EnterpriseComputationalEngineeringTechnologyThe viewpoints are each covering the same domain-of-interest at the same level of detail, and are congruent. Non-orthogonal means that the viewpoints are focused on the same thing. The layered (Hierarchical) levels are part of the MDA concept but not a part of RM-ODP. That’s why SAEAF is a synthesis of the multiple architectural lenses.
35The Lens of the SAEAF (7): Health Level 7 SAEAF takes several enterprise architecture best practices and approaches, and contextualizes them to HL7, as follows:Use of existing HL7 artifactsCore principlesHL7 Development Framework (HDF)Refined Message Information Models (RMIM)And othersAwareness of HL7 business contextDedication to HL7 mission and goals of Working Interoperability
36SAEAF, SOA, and EA (1): Core Principles Objectives of the SAEAF project:Facilitate organization-wide development of service specifications:Enable Unified Field Theory; that is, contextualizing and using SAEAF principles, processes, and practices in the development of other HL7 specifications (messages, documents, and services).Define explicitly and support:Behavioral Framework (deck 2)Contract-based integrationFunctional specificationConformance and Compliance Framework (deck 3)Traceability of requirementsExplicit expression of policy and governance (deck 4)
37SAEAF, SOA, and EA (2): Core Principles SAEAF draws on a “combination of forces.”Existing HL7 artifacts (RIM, ADTs, CDA, and so on)RM-ODP methodology and framework as the lingua francaApplication Model-Driven Architecture (MDA)Commitment to and framework for achieving Computable Semantic Interoperability (CSI)Necessity of a Conformance and Compliance Framework“…the micrometer, T-square, and plumb-bob of an Enterprise Architecture…”Service-awareness using SOA perspectives and explicit framework
38SAEAF, SOA, and EA (3): Core Principles Given the value proposition (Working Interoperability), the following requirements show the need for:Definition of data and information to be exchangedDefinition of functions that enable or perform the exchangeTraceable mappings of functions to real-world events and business processesReference terms and language for sorting and discussing the aboveEngineering deployment topologies and technology bindings to achieve Working Interoperability
39Semantic interoperability Syntactic interoperability (interchange) SAEAF, SOA, and EA (4): Core Principles Syntactic vs. Semantic InteroperabilityMain Entry: in·ter·op·er·a·bil·i·ty Ability of a system ... to use the parts or equipment of another system.interoperability: Ability of two or more systems or components to exchange information and to predictably use the information that has been exchanged.Source: Merriam-Webster web siteSyntax StructureSemantics MeaningSource: IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990]Semantic interoperabilitySyntactic interoperability (interchange)Semantic Interoperability means reliable, predictable exchange of meaning between two parties, be they machine or persons.
40SAEAF, SOA, and EA (5): Core Principles Pillars of CSI Common model is across all domains-of-interest.Information Model vs. Data ModelDomain Analysis Model – Semantics of shared conceptsIncludes optional dynamic or behavioral semanticsFunctionsBehaviorInteractionsStatic Model is bound to a robust data-type specification.HL7 V3 Abstract Data Type specification (R2)ISO Data Type specification
41SAEAF, SOA, and EA (6): Core Principles Pillars of Computable Semantic Interoperability Methodology is for binding terms from concept-based terminologies.Domain-specific semantics bound to cross-domain conceptsA formally-defined process specifies the static and behavioral semantics of the interoperability scenario, for example:RM-ODP- and MDA-based Service Specification MethodologyService interfaces and interactions semantics (contracts, service roles, interactions)Methodology for specifying exchange or wire formatCSI Pillars form a key component of Working Interoperability.
42SAEAF, SOA, and EA (7): Core Principles Integration vs SAEAF, SOA, and EA (7): Core Principles Integration vs. InteroperabilityImplementers need a framework to provide:Computable Semantic Interoperability (CSI) –Measurable goals“Plug and play” patterns of implementationIncremental adoption that yields incremental benefitImplementable specificationsIncluding governance as modeled, testable specificationsReflect the semantics of integration (CSI)Conformance and Compliance ModelImplementation needs to fit with the way organizations model, use, and test components.Implementation Guides (“Are you ready? How does this work with our new ABC Interface Engine?”)
43SAEAF, SOA, and EA (8): Core Principles Integration vs SAEAF, SOA, and EA (8): Core Principles Integration vs. Interoperability“Enterprise Architecture is more than just an implementation or technology perspective.”Each instance of integration is simple, though not necessarily easy.Engineers of any single system understand it well enough to allow integration with any other system.Integration is an manufacturing and implementation issue, such as deployment of computational components.Interoperability is an engineering and architectural concern that creates multiple context-specific integration solutions.The complexity and high-change rate of healthcare information requires Working Interoperability; and therefore, requires an Enterprise Architecture Specification.
44SAEAF, SOA, and EA (9): Core Principles Enterprise Integration Paradigms Service and services-aware perspectives use integration semantics that need to be explicit.Integration semantics:Static (“the data”)Functional (“What data goes in and comes out?”)Behavioral (“Who interacts with whom?”)Business Context (“Who is interacting where and why?”)Integration semantics approximate RM-OPD viewpoints:Static informationalFunctional and behavioral computationalBusiness context enterprise, computational, engineeringIntegration points between interacting components are testable and enforceable.SAEAF focuses on the necessary semantics needed to ensure interoperability between components. The terms static, functional, behavioral, and business context are often used to refer to the working of a complete application.
45SAEAF, SOA, and EA (10): Core Principles Summary: Services and Service Awareness (1) Services and services-aware perspectives are supported by various artifacts that:Allow them to be specified technologically neutrally.Support conformance.Provide a framework for specification of various semantics.Are necessary for integrating systems across the enterprise.
46SAEAF, SOA, and EA (11): Core Principles Summary: Services and Service Awareness (2) Services and services-aware perspectives are not technology-specific per se.These perspectives are a framework for approaching the problem of how to design distributed capabilities (sharing information and functions).SAEAF is not defining just “services;” SAEAF is defining an approach to describing services.SAEAF is using perspectives from the SOA world; hence the phrase “services-aware perspective.”Services are not equivalent to Web Services.SAEAF is a way to describe interoperability regardless of the technology solution. SAEAF applies to services, messages and documents - interoperability using any of those information-sharing technologies. This is called the “Unified Field Theory.”Web Services are a specific technology. “Services” are more general; they may be implemented with Web Services or they may be other types of distributed components that use messaging for integration.
47SAEAF, SOA, and EA (12): Core Principles Services and Service Awareness (3) Because services cannot directly use the object-oriented principles (for example, encapsulation, polymorphism, and inheritance), it is necessary to construct a set of principles that support service-oriented definition and design.Enterprise Architecture is the framework that provides the service-specification foundation and, thus plays a critical role in successful service design. This information is in the Behavioral Framework document in deck 2.
48SAEAF, SOA, and EA (13): Core Principles Summary: Services and Service Awareness (4) The following principles are considered essential for enterprise-level service specifications, which explicitly define testable, verifiable four-dimensioned service contracts:VirtualizationCompositionUnity of purpose and separation of concernsParsimonyTechnology independenceSpecification supports a layered conformance policy.These principles are validated and coordinated in the Service Classification Scheme, as well as in crafting individual services using Specification Best Practices.
49History of Services in HL7 (1) Early efforts included:Electronic Business using eXtensible Markup Language (ebXML)Web Service Profile for HL7In 2005, the Health Services Specification Project (HSSP) set these goals:HL7 established an agreement with the Object Management Group (OMG) to share intellectual capital to support the cooperative development of healthcare-specific services.HL7 would specify requirements and some analysis artifacts (Service Functional Model).OMG would create the technical specification with industry.The slides on the history of services show how HL7 is building on the IT industry ideas about services. HL7’s customers asked HL7 to define service specifications.
50History of Services in HL7 (2) In support of HSSP, HL7 formed the SOA work group.HL7 produced several Service Functional Models (SFMs) balloted as Draft Standard for Trial Use (DSTUs):Resource Locate and Update Service (RLUS)Entity Identification Service (EIS)Decision Support Service (DSS)Clinical Research Functional Query Service (CRFQS)These SFMs are currently in-progress:Privacy and Security Services (PASS)Service Provider Registry (SPR)
51History of Services in HL7 (3): Alignment of SAEAF and HSSP: Artifacts The artifacts produced by SAEAF and HSSP are similar. However, their processes are quite different.The Service Functional Model (SFM) is essentially the same as the SAEAF Analysis Specification artifact.SFM should be readily interchangeable for coordinating HL7 SAEAF and HSSP.
52History of Services in HL7 (4): Alignment of SAEAF and HSSP: Process HSSP shows how HL7 and OMG can work together to produce specifications. HL7 wants to reuse semantics and OMG wants to reuse application components.The Service Specification Framework served as one of the inputs into the SAEAF.SAEAF extends the HL7 portion of HSSP by defining Logical and Platform specifications within HL7.Functional profiles and semantic profilesOMG is interested in aligning these SAEAF artifacts with OMG artifacts.SAEAF allows artifacts to be built outside of HL7.Both the SAEAF and the HSSP processes support Model-Driven Architecture (MDA) and constraint patterns.Functional profiles specify subsets of expected operations from a computational viewpoint.Semantic profiles specify subsets of the overall information content needed to support the functional profiles.SAEAF offers the opportunity to use profiles in more of the standards specifications, regardless of which technical interoperability technology is being used.
53History of Services in HL7 (5) HL7, services, HSSP, and OMGThe HSSP process provides one way of intersection between HL7 and OMG.The HSSP process is an example of creating constrained specifications that are based on the SAEAF Analysis Specification outside of HL7.Other intersections include MDA, SOA ML, United Modeling Language (UML), and Business Process Definition Metamodel (BPDM).The HSSP process is encouraged and facilitated by greater specification on the HL7 side.The ongoing HL7/OMG relationship is considered important to both organizations.
54History of Services in HL7 (6) The HSSP process exposed other Standards Developing Organizations (SDOs) to the initial aspects of HL7 Service Specifications.SAEAF enables HL7 standards to “stand on their own” or be built in collaboration with other organizations (for example, OMG).These standards are consumable and implementable within the context of a formal Conformance and Compliance Framework.The ArB drew heavily on HSSP and the NCI’s caBIG® experience in developing the SAEAF.caBIG = Cancer Bioinformatics Grid
55History of Services in HL7 (7) Services – even as abstractions – have helped surface gaps in the HL7 pantheon of work products:Explicit representation of functional and dynamic (behavioral) semantics.Flexible integration points with multiple system architectures.The development of the SAEAF drew heavily on service-based constructs.
56History of Services in HL7 (8): ArB Position on HSSP (1) Following discussions with HSSP representatives, the ArB affirms that the HSSP framework is in conceptual alignment with the HL7 SAEAF for both processes and artifacts.In particular, the MDA-based process, such as the HSSP Service Specification Framework, produces a Service Functional Model, a Platform-Independent Model, and a Platform-Specific model that are, in principle, in alignment with the HL7 SAEAF. Note that this alignment is between the overarching HSSP process and artifacts -- which by definition include at least two participating organizations (for example, HL7 and OMG) -- and HL7 as the sole producer of SAEAF-compliant processes and artifacts.
57History of Services in HL7 (9): ArB Position on HSSP (2) This distinction is important because it is likely that the SAEAF framework will result in processes and artifacts produced completely within HL7 which are not necessarily defined in the HSSP, thereby resulting in some degree of non-alignment. As the SAEAF artifacts and processes mature, it remains an open question as to how (or if) any variations between the SAEAF and the HSSP will be addressed.
58Implementing SAEAF – Impact of Change (1): Intra-HL7 Implications (1) HL7 Interoperability Paradigms (messages, documents, and services)A fully-specified Domain Analysis Model (DAM) is the critical success factor on the road to WI. The DAM:Provides traceability to logical and physical levels.Binds informational and computational viewpoints.Serves as placeholder for the remaining conformance statements for the RM-ODP viewpoints.Serves as placeholder for additional policy or governance topics.The HL7 Development Framework introduced the Domain Analysis Model (DAM) five years ago. The DAM specifies information content and the expected exchange patterns. One of the implications of adopting SAEAF is that when it is fully rolled out, all specifications must have DAM content that describes the requirements that the design artifacts are meeting.58
59Implementing SAEAF – Impact of Change (2): Intra-HL7 Implications (2) This process is used to develop interoperable applications. This figure shows how information about requirements is used to produce conformance statements that are traceable through each transformation, producing increasingly technical specifications.Figure 11: Differences and similarities between the specifications delimited by the major category of HL7Interoperability Paradigm (services, documents, and messages). Note that a common set of analysis-levelartifacts collectively define a conceptual level of compliance. Different analysis-derived artifactsthen specify the design and implementation details of each Interoperability Paradigm. In all cases, elements of the SAEAFmap to a well-defined “phase” of a standard software development project.59
60Implementing SAEAF – Impact of Change (3): Intra-HL7 Implications (3) The diagram shows the common Domain Analysis Model (DAM) artifacts for all Interoperability Paradigms.DAM provides a more formal framework for the CDA-based notion of “highly-informational vs. less-informational” exchanges of information.HL7 Clinical Document Architecture: Single standard for computer processable and computer manageable dataLess “Informational” SystemsHighly “Informational” Systems*(Wes Rishel, Gartner Group)Figure 12: The Integration Points for Highly Informational Systems may meet different Quality and Functional Requirements than the systems themselves. Thus Highly Informational Systems may expose non-computable information, and vice versa.60
61Implementing SAEAF – Impact of Change (4): Intra-HL7 Implications (4) HL7 Work GroupsMuch of recent reorganization aligns well with SAEAF:Project-based activity vs. static “vertical” organizationPromotion of fully-specified services to the level of “equal” with messages and documents requires a group to develop the details of specific normative specifications for services.The Service Specification Normative artifacts includes:Normative artifact for Contract.Normative artifact for Service Role Specification.61
62Implementing SAEAF – Impact of Change (5): Inter-HL7 Implications (1) HL7 has a number of explicit (memorandum of understanding) and implicit relationships with other SDOs.ArB recommends that these relationships all be made as explicit as possible regarding SAEAF.For specific examples and more details, see the SAEAF Introduction and Governance documents.62
63Implementing SAEAF – Impact of Change (6): Inter-HL7 Implications (2) Object Management Group (OMG)SAEAF artifacts might accelerate OMG ability to produce implementations of “healthcare services.”HL7 could supply “full Conceptual and PIM-level” artifacts as input into OMG RFP process.SAEAF expects to significantly leverageMDA-based transformsSOA Pro/UML Metamodel for Services (UMPL)Business Process Definition Metamodel (BPDM)Business Process Modeling Notation (BPMN)The Behavioral Framework documentation contains an analysis of SOA ML.63
64Implementing SAEAF – Impact of Change (7): Inter-HL7 Implications (3) CBDI ConsultancyArB used CBDI Service taxonomy to inform SAEAF.W3CSAEAF will leverage CDL and WS-* specifications.Orlando meeting marked kick-off of HL7, OMG, W3C, and HCLS collaboration.OASISArB will continue to monitor the Normative SOA architecture for input from both a “pure services” and “services-aware” perspective.CBDI = Component Based Development and IntegrationCDL = Choreography Description LanguageHCLS = Health Care and Life SciencesOASIS = Organization for the Advancement of Structured InformationOMG = Object Management GroupSOA = Service-Oriented ArchitectureW3C = World Wide Web Consortium64
65Implementing SAEAF – Impact of Change (8): Inter-HL7 Implications (4) Joint Interoperability Council (JIC)HL7ISOEuropean Committee for Standardization (CEN)Clinical Data Interchange Standards Consortium (CDISC)CSI Pillar #2 is supported by ISO 21090, a product of JIC effort.HL7 plans to move SAEAF into the JIC dialogue.National Institute of Standards and Technology (NIST) is introducing ECCF into NIST testing of HL7 artifacts and systems.65
66Implementing SAEAF – Impact of Change (9): Tooling and Open Health Tools (1) Focusing on Working Interoperability and the critical role of architecture.Adopting SAEAF ECCF for use in tool specification.Mission and CharterTo enable the adoption, development, and deployment of an evolving set of interoperable tools. These tools support the development and deployment of software that enables computable semantic interoperability in the health-care, life sciences, and clinical research domains. 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 interoperate with each other.66
67Implementing SAEAF – Impact of Change (10): Tooling and Open Health Tools (2) Mission and Charter (cont’d)The OHT Architecture Project operates under the Open Health Tools Development Policy and Process (described atThis project 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 and architecture framework that will enable the evolutionary development of an OHT Platform architecture consistent with the various enterprise architectures built and deployed by OHT stakeholders.67
68Implementing SAEAF – Impact of Change (11): Tooling and Open Health Tools (3) Mission and Charter (cont’d)Deliverables include:A set of architecture principles.A tool classification mechanism that enable stakeholders to contribute and have access to architecture artifacts that underlie the tools.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 internal and external communication plan.68
69SAEAF Summary (1)SAEAF is not a replacement for, or an alternative to, HL7’s existing products, engagements, or offerings.SAEAF is an effort to reframe, encompass, and support existing HL7 work streams, and to focus them around a more explicit framework for expressing interoperability semantics.SAEAF is the result of a shared belief by the HL7 CTO, ArB, and TSC that the Health Enterprise requires this level of specificity and rigor to achieve scalable, agile interoperability.HL7 is establishing a leadership position in this discussion.
70SAEAF Summary (2)HL7 SAEAF aligns with strategic direction of national health-centric organizations:US Department of Defense / VAHealthcare Information Technology Standards Panel (HITSP)Canada Health InfowayNCI CBIIT (caBIG®, BIG Health®)National e-Health Transition Authority (NeHTA)HL7 SAEAF aligns with other industry standards:WS-CDLSOA ProHISA
71SAEAF Summary (3)The HL7 Services-Aware Enterprise Architecture Framework (SAEAF) provides a framework for specification of standardized “artifacts that enable Working Interoperability,” which the HL7 community can use regardless of the chosen Interoperability Paradigm (messages, documents, and services).The SAEAF defines specific artifacts that provides traceability from requirements through analysis to design and implementation.SAEAF-compliant specifications align with conformance levels specified in a Conformance and Compliance Framework (CCF) that enable HL7 consumers to adopt HL7 specifications in different contexts at different levels of interoperability.The formal constraint pattern is being postponed until the SAEAF rollout is further along.The conformance levels correspond to the conceptual level, platform-independent design, and platform-dependent design.
72SAEAF Summary (4)The HL7 Services Aware Enterprise Architecture Framework identifies and defines the language, processes, and artifacts for:An Enterprise Architecture appropriate for an SDO using services or services-aware thinking as a backbone concept.Developing and deploying standards to enable Working Interoperability.Services (and SOA) are not technology per se; they are:A framework for approaching how to design distributed capabilities (information and functionality sharing).Not equivalent to Web Services (although service constructs as well as other Interoperability Paradigm constructs may be realized using Web Services technology).
73SAEAF Summary (5): The Lens of SAEAF The intersection of HL7, MDA, Distributed Systems Architecture, SOA, and CSI provide a goal, the artifacts, portions of a methodology, and the framework for defining SAEAF. SAEAF is a robust, durable business-oriented set of constructs that provide extensibility, reuse, and governance.Service-OrientedArchitectureHealth Level 7Computable SemanticInteroperabilityReference Modelfor Open DistributedProcessingModel-DrivenArchitectureSAEAF
74SAEAF Summary (6): Conclusion SAEAF: A “Services-Aware Enterprise Architecture for HL7”“Services-aware but not services-specific”Consideration given to three HL7 “interoperability paradigms” (“HL7 Unified Field Theory”)MessagesDocumentsServicesThe SAEAF work draws on “service-centric principles,” such as:Contracts and behaviorSeparation of concernsConformance and complianceGovernance