alan boucher

HIMSS.ORG; Integration & Interoperability Web Cast March 2006

Using Service Oriented Architectures to Support RHIO Development

Alan BoucherDirector, Health Care ArchitectureDigital Health Group, Intel Corporation

Using Service Oriented Architectures to Support RHIO DevelopmentMarch 2006 HIMSS.org Web Cast

2

Today’s Agenda

• Service Oriented Architecture (SOA) Overview– Service Oriented Architecture Construction – Interoperability (Semantic, Syntactic & Structural ) – Anatomy of a Business Processes & Services– Expected Benefits of a Service-Based Architecture – SOA and HL7: “One RHIO Services Network”

• The Role of Services in a National Health Care System– Using Best Known Methods

• The Role of Services in RHIOs & RHINs– Service Delivery in a Centralized Model– Service Delivery in a Peer-to-Peer Model– RHIO Architecture Development

• Summary & Next Steps for RHIOs & RHINs


3

• Service-oriented architecture: A design approach to standardize functions or services, so that numerous dissimilar applications and technologies can share them—both inside and outside of the providing entity

• Service: A distinct, self-contained, well-defined function or capability that operates through a contractually defined service interface

• Service Interface: A technology and implementation independent way to systematically define a service’s:

• Features, i.e. capability and output

• Terms, i.e. requirements and input

• and SLA, i.e. operating performance and quality of service

Key principle:Contractual separation of concerns between a

service provider (RHIOs) and Service Consumer’s (Patient, Provider, Payer & Pharma) through an interface

Service Oriented Architecture (SOA) Construction


4

SOA’s & Interoperability• Main Entry: in•ter•op•er•a•bil•i•ty

: ability of a system … to use the parts or equipment of another system

Source: Merriam-Webster web site

• Interoperability

: ability of two or more systems or components to exchange information and to use the information that has been exchangedSource: IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer

Glossaries, IEEE, 1990

Semantic interoperability entails a co-ordination of meaning. Semantics is defined as the meanings ofterms and expressions with regard to content description standards. Hence semantic interoperability is“the ability of information systems to exchange information on the basis of shared, pre-established andnegotiated meanings of terms and expressions,” and is needed in order to make other types ofinteroperability work.

Syntactic Interoperability: Conveying agreed upon grammars for semantics & structure.

The challenges of syntactic interoperability become: a) identifying all the elements in various systems (in RHIOs); b) establishing rules for structuring these elements; (between RHIO entities) c) mapping, bridging, creating crosswalks between equivalent elements using schemas etc.; d) agreeing on equivalent rules to bridge different cataloguing and registry systems

Structural interoperability uses agreed upon framework models, such as HL7 Reference InformationModel (RIM), the Clinical Document Architecture (CDA), the ASTM Continuity of Care Record (CCR) oreven models based on the Integrating the Healthcare Enterprise (IHE) - Cross Enterprise DocumentSharing (XDS) Profile, which stores documents as ebXML.


5

Anatomy of a Business Process

Activity

Trigger•Time•Event

Input•Data Required

for Decision/Action

Output•Data produced by Decision / Action

Decision / Action•Steps completed•Decisions Made Next

Activity /

Process

ProcessApproval &Return DataReceive

RequestTo Acquire

Data

DetermineRequestorCredentials

Send RequestTo RHIO

Rules Engine

MakePolicy

Decision Reject Requestor &Return Event

EHR Lookup Service

Op: InitiateEHRlookup()

IA&M Service

Op: AssertionLookup()

Governance Service

Op: PolicyLookup()

Process EHR Service

Op: GetEHRRecord()

Format EHR Service

Op: FormatEHRCCR()

Process Error Service

Op: ReturnError().OR..OR.

ProcessApproval &Return DataReceive

RequestTo Acquire

Data

DetermineRequestorCredentials

Send RequestTo RHIO

Rules Engine

MakePolicy

Decision Reject Requestor &Return Event

Anatomy of a Service

Activity

Trigger•Time•Event

Input•Data Required

for Decision/Action

Output•Data produced by Decision / Action

Decision / Action•Steps completed•Decisions Made

The anatomy of a servicemaps directly to the anatomy of process.Process & data needs drive requirements

for service interfaces

<The Name>

<operations>Policies

&SLAFeatures (capability + output)

Terms (requirements + input)

Created by

A Service

the RHIO


7

Expected Benefits of SOAMicro

(per adaptation)

$ R

etur

n

Time

DevelopmentProductivity

TTD

With SOA

TraditionalDevelopment

RHIOBenefit

Program “development time to release” improves greatly based on services leveraged in design

Program “development time to release” improves greatly based on services leveraged in design

Macro (subsequent adaptations)

$ R

etur

n

Time

RHIOValue

SOA savings realized

Traditional savings

Expected aggregate effects are more $$ available for new RHIO capabilities & improved business processes for RHIO participants

Expected aggregate effects are more $$ available for new RHIO capabilities & improved business processes for RHIO participants

Servic

e Re-

use


8

SOA and HL7: “One RHIO Services Network”RHIO’s may implement their interoperability models in HL7 V3, yet many participating

organizations still use HL7 V2, X.12, NCPDP & others.

How will HL7 “play” in an SOA implementation?

• RHIO SOA framework’s should be built with industry standard (commonly acceptable) infrastructures, tools & methods (commercial & open source)

• HL7 should be implemented on an SOA framework as;– Content: HL7 defines information content and should be a separate element from Messaging

• e.g. RHIO data should be separated from transport, messaging & infrastructure, which will evolve over time. SOA messaging architecture’s typically support varying messaging & transports, including web services.

– Support multiple standards related to RHIO records (HL7, DICOM, X.12, NCPDP etc)

– Develop “common” HL7 service extensibilities:• Business - Patient Consent, Record Locators, RHIO Entity Identification, Semantic Libraries &

Normalization • Infrastructure – Authentication & Authorization, Governance & Policy, Security, Auditing• Data Services - Data Mining, Disease Management, Outcomes-based Medicine, Pharma

Interactions, e-Pharma Gateways• Financial Services - Scheduling Services, SMB Concierge, Claims Mgmnt, HSA, CMS etc..• Gov’t extensibility – Epidemic / Pandemic Management, Bio-terrorism, DHS, CDC etc


9

The Role of Services in a National Health Care SystemGoal 1: Inform Clinical Practice: Incentives for EHR adoption and create tools that ensure 100% success in EHR implementation and use.

Goal 2: Interconnect Clinicians: Identify interoperability as a major milestone for achieving improved health care delivery; encourage regional health care information exchanges and a National health information network.

Goal 3: Personalize Care: Foster patient-centric care delivery and more informed health care consumers.

Goal 4: Improve Population Health: Encourage the collection, analysis, and dissemination of timely and accurate information that impact public health.

© 2005 The Interoperability Consortium

ONCHIT ONCHIT

NHIN Framework and Standards

CertificationOf RHIOs

CertificationOf RHIOs

ServicesServices

NHIC – BoardPrivate

NHIC – BoardPrivate

National Health Information Corporation (NHIC)

National Health Information Corporation (NHIC)

P & PP & P CertificationCertification

Certified Private Companies & HISPs

Certified Private Companies & HISPs

Services Bus

Services Bus

StandardsStandards

RHIOsData Models, Data ExchangeGovernance, Policy, Auditing

Orchestration, Transformation & Business Rules



ProvidersProvidersPayors (including CMS)

Employers

Payors (including CMS)

Employers

Citizen ServiceCitizen ServiceDoctorsDoctors

PharmaPharma

Exposed Services (Pub / Sub)Exposed Services (Pub / Sub)

Organizational Information between RHIOs & the NHIN


PMO

National Health Technology Standards and

Certification (NHTSC)

National Health Technology Standards and

Certification (NHTSC)

Contract Contract


© 2005 The Interoperability Consortium


11

Best Known Methods… learning from the NHS UK

Major IT Project for 50M+ UK NHS Patients & Citizens

(the ~Size of California)

•Live, interactive 24x7 patient record service across care settings and organizations

• Service-Providers deliver support and software for patient record and infrastructure services

• Services delivered based on patient confidentiality and security

• Performance and Security are core to TMS & SPINE design

• Services allow for horizontally scaleable infrastructure

• Services decrease deployment time for individual clusters\

• Services accelerate implementation of Gateway require zero-coding for local clusters

• Services improved stability, resilience and availability

Data Services forSecondary Uses

Services Services Services Services Services

SHAs / Trusts / Units /Primary Care / Social Carecare & servicesfor patients

LSPsdeliver a range of local applications, services & functionality

TMSprocesses all messages

SPINE (NASP)delivers national services

Electronic Booking

PersonalDemographicService (PDS)

Personal SPINEInformation

Service (PSIS)

Electronic Transmission of

Prescription

A Cluster

Bi-directional Message Traffic

NHS CareRecord Service

Local Data & Applications

RHIO Gateway Services BusRHIO Gateway Services Bus

ProvidersProviders

Citizen ServicesCitizen Services

IPAs, DoctorsIPAs, Doctors

PharmaPharma






NHINNHIN


Employers


Employers


12

Internet

OrchestrationMessaging Bus

ServiceContainer

Data Transform

Business Rules, Algorithms

Meta Data Store

Audit, Monitoring & Management

AAA, Data Security

Que

ue

Que

ue

XM

L F

irew

all

Payor, Provider, Pharma, PhysicianOrganizations

RHIOs & RHINs


Que

ue

Que

ueService

Container

Data Transform


Meta Data Store


AAA, Data Security

XM

L F

irew

all

Deployable Business RulesDeployable Business RulesRHIO Standard Transforms (XSLTs)RHIO Standard Transforms (XSLTs)Publish & Subscribe ServicesPublish & Subscribe ServicesDevelopment of Common Services & Development of Common Services & Libraries, Directories & RegistriesLibraries, Directories & Registries

Isochronous & Isochronous & Asynchronous Asynchronous messagingmessagingReliable Messaging & Reliable Messaging & Queue ManagementQueue Management

SOAP Encapsulated SOAP Encapsulated XMLXMLHTTP SSLHTTP SSLVPN SSLVPN SSLVPN PtPVPN PtP

Applying Best Known Methods..Deployable RHIO Service Technologies

HL7 WrapperHL7 v2.x, v.3, HL7 CDA, ASTM CCR,

openEHR etc..

HL7 WrapperHL7 v2.x, v.3, HL7 CDA, ASTM CCR,

openEHR etc..

HL7 Content Modelor

XML, ebXML, other

Option: File Exchange Formats could be <encapsulated> XML

in the cloud

High-Level Service Operations in RHIOs & RHINs

Data / WebService Provider

PublishedWeb & Data Services

Access based on Object IdM

Assign Data ResourcesBased on

HISP or RHIO / RHINObject Identity (IdM)

HISP/ RHIO / RHIN Data AccessData Provider

RHIO / RHIN

Services Directories

Data / Web Service

Requestor HISP Objects:

Physicians, Providers, Payor’s GVT Entities and

Commercial Services

WbS Management, Routing & Governance Services

Federated Services Model

Federated Services Model

Business Integration

Layers

Bind or Latent Bind Web Service & Data

Components to Object IdM

Polic

y, Id

M &

WbS

Invo

catio

n

RHIO Object IdM Access



14

Services create New Opportunities for RHIOs

RHIO Participating Organizations RHIOs & RHINsOrchestration

Messaging Bus

ServiceContainer

Data Transform


Meta Data Store


AAA, Data Security

Que

ue

Que

ue

XM

L F

irew

all


Que

ue

Que

ueService

Container

Data Transform


Meta Data Store


AAA, Data Security

XM

L F

irew

all

RHIO Access Portal

Patient BrowseContainer

RecordLocatorServices

RHIOStorage

PayorAuthorizations

PatientConsent

ProviderDirectory

ClaimsProcessing

RHIO UDDI Services Registry

DataAnalytics

Loosely-Coupled Services

Primary CarePhysician

BillingSpecialist

SpecialistPhysician

Service Request

Search Authorization

Authentication WorkflowsPolicy & Consent

Mgmt

Identity

Additional RHIO Services

Storage Audit CommercialMessaging

Content Mgmt Physician Concierge Services

RHIOs must build self-sustaining business models through Services

RHIOEntityPeer

RHIOEntityPeer

RHIOEntityPeer

RHIOEntityPeer

Trust

RHIOEntityPeer

RLS Lookup and AccessPeer-to-Peer Data & Transformation

(RLS) Data Providers – Doctors, Facilities, Payors etc..

GW

RLSMeta-data

RLSMeta-data

RLSMeta-data

GW GW GW

Peer TrustDNS Like Services

SOAP SOAP SOAP SOAP


Patient DirectoryConsent Services

ProviderDirectory

ClaimsProcessing


DataAnalytics

PayorAuthorizations

Peer-to-Peer RHIO SOA Model

Service Abstraction Layer

RHIO RHIO

HISPGovernance

HISPGovernance

NHIN

Service Abstraction Layer

NHINNHIN

GW

GW GW

GWTrust Domain

Trust Domain

Trust Domain

“On behalf of” Trust

Doctor

GW

Provider Pharma Payor

GW GWWeb/GW

Patient

Web

Doctor

GW

Provider Pharma Payor

Web GW

Patient

Web Web/GW


Record Locator ServicesRHIO Storage

Payor Authorizations

Patient Consent

Provider DirectoryClaims ProcessingData Analytics

SearchAuthorization, Authentication & Auditing

Custom Service-based Workflows

Identity


Commercial MessagingPhysician Concierge Services


Record Locator ServicesRHIO Storage

Payor Authorizations

Patient Consent

Provider DirectoryClaims ProcessingData Analytics

SearchAuthorization, Authentication & Auditing

Custom Service-based Workflows

Identity


Commercial MessagingPhysician Concierge Services


Centralized RHIO SOA Model

Structured Data, stored in each RHIN,Accessed & Transformed via RHIO Services


17

PROCESSDRIVEN

STRATEGYFOCUSED

PLATFORMDEFINITION

SERVICEORIENTED

Th

e R

HIO

Bu

sin

ess

Architecture

RHIOBUSINESS STRATEGY

SERVICE ORIENTED INFRASTRUCTURE & COMPOSITION

PLATFORM COMPONENTRY

JAVA .Net LAMP

RHIO BUSINESS PROCESSEXECUTION AND MONITORING

Packaged Apps.

RHIO Business Architecture Segmentation

http://www.momentumsi.com/index01.html



18

RHIO SO Architectural Considerations


PlatformArchitecture

Black Boxed Architecture

DomainArchitectures

• Application • Integration • Data

• J2EE• .Net

• Packaged Apps• ASP / leased systems

ReferenceArchitectures• Model 1• Model 2

CandidateArchitectures

• The Proposed RHIO Architecture

SolutionArchitecture

• The Actual RHIO Architecture

Gray Boxed Architecture• Semi-Packaged Apps • App Frameworks

ArchitecturalRequirements

Specific RHIO

Objectives

ArchitecturalConstructs

• Participants • Patterns• Practices

ArchitecturalThemes

• Model Driven • Service Oriented• Process Driven

DeploymentArchitectures

• Network• Computing• Distribution

RHIOArchitectureModels



19

Summary & Next Steps• Evolution to SOA is inevitable in most industries;

• RHIOs have a green field opportunity to drive “industry change”

• SOA’s impact is profound but evolutionary – won’t be fully realized on initial deployment

• SOA development is a journey with multiple phases of increasing maturity

• The aim of any SOA should be based on clear Business Benefit and Implementation Goals up front.

• RHIOs must;

• Develop architectural decisions in a consistent & standardized way

• Develop SOA methodologies for interacting with all entities & organizations in viable process driven manner

• Enable new business processes and capabilities for all entities whether they be large or small;

• Business - Patient Consent, Record Locators, RHIO Entity Identification, Semantic Normalization

• Infrastructure – Authentication & Authorization, Governance & Policy, Security, Auditing• Data Services - Data Mining, Disease Management, Outcomes-based Medicine, Pharma

Interactions, e-Pharma Gateways• Financial Services - Scheduling Services, SMB Concierge, Claims Mgmnt, HSA, CMS etc..• Gov’t extensibility – Epidemic / Pandemic Management, Bio-terrorism, DHS, CDC etc

Alan BoucherDirector, Health Care ArchitectureDigital Health Group, Intel Corporation

HIMSS.ORG; Integration & Interoperability Web Cast March 2006

Using Service Oriented Architectures to Support RHIO Development


21

Backup


22

SOA Philosophies

1. Consumers and Producers are Loosely Coupled

• Provide Functional Encapsulation

• Factor Out Non-Functional Concerns

• Force Ubiquity at the Edge of the Service

• Performance is an Implementation Decision


23

SOA Philosophies

2. Leverage Network Computing and Resource Virtualization

• Network the Services

• Provide mediation in the network

• Resolve resources at runtime (latent bind)


24

SOA Philosophies

3. Systems are Loosely Bound

• Integration and Composition are One

• Functionally Structured

• Operationally Amorphous


25

SOA Philosophies

4. RHIO Service Networks Scale Efficiently

• The RHIO Vocabulary is Managed

• Facilitate Service Use and Reuse

• Create Federated Solutions


26

SOA Philosophies

5. SOA Enables new Opportunities

• HC Enterprise Boundaries are Removed

• Unstructured Data Finds Structure and Meaning

• The Value of Data is Redistributed

• All Service Network Users have the same Value / Impact in the System

alan boucher

Documents

serviceoriented architecture

service consumerspatient

service maps

entity service

servicebased architecture

service oriented architectures

rhios rhins service

rhio soa frameworks