Healthcare SOA Reference Architecture by accinent


									                        Healthcare SOA Reference Architecture
                         April 15-17, 2008 - Chicago, IL USA
    Crowne Plaza Chicago O'Hare, 5440 North River Road, Rosemont, Illinois 60018
          Wed. 16 April 08, Session 3, 1:45 - 3PM, Speaker Code: [16-13 ].

                        Abstract for “OMG SOA in Healthcare” Workshop,

     Nancy Orvis, Chief Operational Architect, DOD Military Health System (MHS),
   Integrated Requirements and Design (IRD) Directorate
  Mary Terlep, Healthcare Subject Matter Expert and President of HEI Consulting, LLC
                              supporting DOD MHS IRD
  Stephen Hufnagel, Enterprise Architect, TIAG contractor supporting DOD MHS IRD,
                                15 Mar 08, Version D

Federal Agencies (e.g., The Military Health System (MHS), Veterans Administration (VA), Indian Health
Service (IHS)) are mandated to have Healthcare Information Technology Standards Panel (HITSP)
conformant interoperable Electronic Healthcare Records (EHR) and systems. Our strategy is to focus on
HITSP conformant interoperability at the service level.
A Reference Architecture supports a reuse-based management approach to architectural specifications
within a particular domain (e.g., healthcare) and across domains. It also provides a common vocabulary
(e.g., EHR-S + Financial + ERP + Other healthcare sub-domains) with which to discuss requirements
traceability to design specifications, implementations, deployments, tests and certifications; with the aim to
stress lexical and semantic consistency throughout the Business Capability Lifecycle (BCL).
The Healthcare SOA Reference Architecture (H-SOA-RA), is being built on commercial healthcare models
(e.g., HL7 EHR System Functional Model (EHR-S) + Financial + Electronic Resource Planning (ERP)
healthcare sub-domains) and Thomas Erl’s SOA layers. The objective of the H-SOA-RA is to assure
semantic interoperability at the Service Level and consistency within and among systems’ architectural
specifications, resulting in aligned, interoperable and agile enterprise architectures and their system
components. The H-SOA-RA allows logical specifications of business transformation architectures (BTAs)
and their associated investment portfolios; it allows system component flexibility/options in the ultimate
physical “best-of-breed component” implementations, when funding is available.
This reference architecture is intended to support the transformation of a behavior model’s business actors
and their capabilities (e.g., business process model or use case) into system structural models of
components and their technical actors (e.g., system functions and services). In particular this H-SOA-RA
focuses on constructing system components from candidate reusable services (e.g., composite services,
entity services, application services, agnostic or common services.). Healthcare Information Technology
Standards Panel (HITSP) constructs (e.g., data components, transaction packages, transactions and their
associated standards specifications) are architectural constraints, which are intended to assure Electronic
Healthcare Record (EHR) interoperability.
The H-SOA-RA is being standardized within the HL7 Healthcare Service Specification Project (HSSP)
[]. The H-SOA-RA standardizes the lexicon of the healthcare Software and
Service Definition Framework (SDF), assuring lexical and semantic interoperability between the operational
or functional vocabulary and system design’s component and method-or-service vocabulary. This logical H-
SOA-RA is refined to physical implementations using an Integrated Requirements and Design (IRD) Model
Driven Architecture (MDA) approach to specify an associated SDF; "Including concepts from: CBDI Forum
Service Architecture & Engineering (SAE) Meta Model for SOA".
Reference architectures generally have lists of:
   1) System Functions or Services (aka, methods),
   2) Reusable components composed of one or more encapsulated objects and
   3) Policies, standards and constraints.
In a constrained system design (e.g., net-centric Service Oriented Architecture (SOA)), reference
architectures can be used to allocate functional capabilities and their system functions to system
components, while maintaining architectural constraints, resulting in an allocated design baseline.
Reference architectures can be defined at different levels of abstraction:
- A deployment reference-architecture might show different pieces of equipment on a communications
    network, each component providing gross functionality (e.g., Application Server, Database Server,
- A business reference-architecture decomposes business-process views, which shows technical actors,
    demonstrates the interactions of procedures (or methods) within a computer program defined to
    perform very specific activities or tasks. Our approach is to have the H-SOA-RA constrain the
    Functional Allocation at the Specification view.
- An inheritance reference-architecture might include compile-time modules, which can be constructed
    into run-time components.
Speakers Biography:
Stephen Hufnagel PhD, Architect and System Engineer is the Military Health System (MHS) representative
to the Health and Human Services (HHS) Healthcare Information Technology Standards Panel (HITSP). In
that capacity, he is the co-chair of the HITSP Provider Perspective Technical Committee responsible for the
development of HITSP Interoperability Specifications. Nancy Orvis, MHA, is the MHS Chief Operational
and Data Architect, and MHS point of contact for Health Standards Development Organizations (SDOs). In
that role, she is co-chair of the Health Level Seven Government Projects SIG, and she is currently serving
on the HL7 Architecture Review Board this year. Mary Terlep is a Healthcare Subject Matter Expert
specializing in the EHR. Together they have extensive experience in the commercial and military
healthcare IT arena. They are working with the Veterans Administration to establish an enterprise
architecture strategy for Electronic Healthcare Record (EHR) interoperability.

To top