12/31/2013 11:20 AM Service-oriented Architecture What Does it mean to Healthcare Enterprises? May 2006 Ken Rubin EDS Co-Chair, OMG Healthcare Domain Task

04/10/23 19:55

Service-oriented Architecture What Does it mean to Healthcare Enterprises?Service-oriented Architecture What Does it mean to Healthcare Enterprises?

May 2006May 2006

Ken RubinEDS

Co-Chair, OMG Healthcare Domain Task Force

Co-Chair, HL7 Services-oriented Architecture [email protected]

Ken RubinEDS

Co-Chair, OMG Healthcare Domain Task Force

Co-Chair, HL7 Services-oriented Architecture [email protected]

© 2006 HSSP Project, http://hssp.wikispaces.com

Reuse with attribution permitted Page 2

A little personal background… A little personal background…

• 15+ years of IT experience

• ~10 years health informatics experience

• Roles:

– Veterans Health Administration Enterprise “Application” Architect (held for ~7 years)

– EDS US Civilian Government Chief Healthcare Architect

– Standards

• Chair, OMG Healthcare Domain Task Force

• Co-Chair, HL7 Service-oriented Architecture SIG

• Past Chair, HL7 Process Improvement Committee



The Premise:The Premise:

Healthcare IT is about improving health Healthcare IT is about improving health outcomesoutcomes

The Premise:The Premise:

Healthcare IT is about improving health Healthcare IT is about improving health outcomesoutcomes



The Premise Contradicted (Today’s View)The Premise Contradicted (Today’s View)

• Healthcare as a market sector has viewed IT investment as an expense and not as an investment

• Most IT investment to date has been administratively or financially focused

• The bulk of Healthcare IT in use address departmental or niche needs

• Integration of data within departments is common

• Integration of data within care institutions is not uncommon

• Integration of data within enterprises is uncommon

• Integration of data across enterprises is unheard of



The Promise (A Vision)The Promise (A Vision)

• The value of Health IT is measured in terms of business outcomes and not cost expenditures

– Direct ties of IT to improved beneficiary health

– Reduction of preventable medical errors

– Improved adherence to clinical protocols

• IT accountability through core healthcare business lines

– IT investment owned by business stakeholders

• Tangible benefits to constituents and health enterprise

– Improved health outcomes

– Improved data quality

– Increased satisfaction by beneficiaries and system users

– Higher satisfaction by users

– Improved public health capabilities



“Enterprise Architecture 101”“Enterprise Architecture 101”

• The practice of aligning IT with business objectives

– Identifying unplanned redundancy in work processes and systems

– Rationalizing systems and planning investment wisely

– Establishing target environment and a viable migration path

• Addresses all facets of IT and the business:

– Core business capabilities and business lines

– Identification of business functions

– Identification of IT needed to support the business

• Multiple Views of IT:

– Information content

– Systems (computational) view

– Technology (infrastructure) view

– Process (engineering) view



So, what’s this got to do with services?So, what’s this got to do with services?

• If services are the answer, what was the question?

• Let’s consider a case study…

• But first, a disclaimer…

The information that follows is derived from either public information or personal experience. This information is a good-faith representation, and every effort has been made to assure its accuracy and currency. Nonetheless, these slides do not necessarily reflect the official position of the Veterans Health Administration or the U.S. Government.



A little about the [US] Veterans Health Administration* A little about the [US] Veterans Health Administration*

• Business View– 158 hospitals/medical

centers

– 854 outpatient clinics

– 132 long-term care facilities

– 42 rehabilitation facilities

– Affiliated with 107 of 125 medical schools in the US

• Healthcare Statistics (2003)– 7.2M beneficiaries enrolled

– 4.8M treated

– 49.8M outpatient visits

• Operational View– 180k VHA employees

– 13k physicians, 49k nurses

– 85k health professionals trained annually

– USD $29.1B Budget for 2004

• Technical View– VistA (EHR) for over 20 years

– Software portfolio exceeds 140 applications

– Reengineering effort is based upon a services architecture

*statistics taken from May 2004 Fact Sheet, U.S. Dept of Veterans Affairs



VA’s Current EnvironmentVA’s Current Environment

• VistA, the VHA EHR, is in use ubiquituously across the VA enterprise (and also outside the US)

• All clinical systems are integrated (Clinician desktop, pharmacy, laboratory, radiology, etc)

• Data is available from any VA point-of-care

• Beneficiaries can self-enter family history and self-care progress notes

• VA CPOE numbers exceed 90%

• VistA is cited by the Institute of Medicine as the world’s leading EHR



…And they’re re-engineering the whole thing…And they’re re-engineering the whole thing

• Why? The premise. That’s why.

• Every VistA system instance is different

• Data quality is inconsistent site-to-site

• Not all data is represented formally using clinical terminologies

• Business rules are implemented inconsistently in different parts of the application suite

• [System] Quality of service differs site-to-site

• High maintenance costs (in both dollars and time)

• ~50% of their beneficiaries receive care outside of VA



Some of their business objectives…Some of their business objectives…

• Improve the ability to care for veterans

• Improve quality of care from improved data quality, consistency

• Improve access to information where and when it is needed

• Allow for better management of chronic disease conditions

• Increase efficiencies allow for improved access to care (e.g., “do more with less”)

• Improve consistency of the practice of healthcare via clinical guideline conformance



The VA Approach…The VA Approach…

• Migrate current applications into a service-oriented architecture

• Re-platform the application into current technologies

• Minimize vendor lock-in risk through use of open standards

• Standardize on an information model and terminologies for consistent semantics

• Recognize that healthcare is a community and solving it institutionally only solves it 50%



And finally, SOAAnd finally, SOA

• VA selected a service-oriented architecture for several reasons:

– Consistency in business rules enforcement

– Ability to flexibly deploy and scale

– Ability to achieve geographic independence from system deployments (dynamic discovery)

– Promoted authoritative sources of data

– Promote/improve reuse

– Minimize/reduced redundancy



Organizational EHR Maturity Organizational EHR Maturity

Generation I Generation II Generation III

Department systems

Facility-centric systems view

Inconsistent deployment

Person-centric systems view

Health outcomes based

Consistent semantics

Inter-Enterprise integration

Population health support

Continuous process improvement

Numbers of EHRs/ Utilization

Time

Most organizations are in the early phases of EHR implementation and the market will evolve significantly over time

Enterprise or organizational deployment

Limited integration across facilities

Inconsistent business practices

Inconsistent data quality



Why SOA for healthcare?Why SOA for healthcare?

• Service-oriented architecture is not a new concept

– founded in the 70’s

– Can be traced back to “subprocedure calls”

– Promotes resource-sharing

– Minimizes redundancy



Enterprise Architecture comes FirstEnterprise Architecture comes First

• Consider the common business challenges of large organizations or cross-organizations:

– What is the “source of truth” for people’s identity

– If there are multiple, what happens when they conflict?

– In how many locations are your business rules implemented/enforced

– What confidence is there that the enforcement is consistent?



Adapting to ChangeAdapting to Change

• How easily can your organization respond to a new collaboration (such as with a private entity or state)?

• How responsive are you to new policies or mandates?

• For what duration will your technology be deployed?

• How many technology changes will occur in that time?

• How will you manage integration with new systems?

• What if those new systems are in new technologies?



Top 3 Misconceptions about SOATop 3 Misconceptions about SOA

• SOA ≠ Web Services

– SOA can be done in many technologies. WS is just the current marketplace-buzz

• SOA does not address semantics

– Not necessarily. Good SOA solutions consider and do use data semantics

• We must choose between SOA and messaging

– Not at all. Many SOA implementations use messaging in their implementation. They are complementary and not competing



SOA vs. MessagingSOA vs. Messaging



Why Migrate towards SOA? Part IWhy Migrate towards SOA? Part I

• Promotes Re-Use and Consistency

– Allows functions to be “pulled out” of many systems

– Business rules are implemented in one place

– Since everyone needing a function uses the same service, consistency is assured

– The service becomes the authoritative source of the data. (The data source itself is ‘hidden’ within the service)



Why Migrate towards SOA? Part IIWhy Migrate towards SOA? Part II

• Deployment Flexibility

– Services may be deployed in many topologies

• Centralized model

• Hub-and-spoke

• Federated

• Peer to Peer

– Service users are ignorant of topology

– Promotes



Why Migrate towards SOA? Part IIIWhy Migrate towards SOA? Part III

• Dynamic Nature

– Services can discover other services at runtime

– Services can come online in real time

– Services do not necessarily have single point-of-failure (e.g., Services can fail over in real time)

– Services may be deployed side-by-side using different technologies (e.g., support heterogeneity)

– One Service instance may support multiple technologies (through facades/platform bindings)



Take-Away MessagesTake-Away Messages

• SOA is not the silver bullet

• SOA is not “radically different”

• SOA ≠ web services

• The root of a good technology decision must be a business driver

• A migration toward SOA is an architectural decision (and not a technology one)

• SOA standards are important



ReferencesReferences

• HSSP Website:

• http://hssp.wikispaces.com

• VA Website:

• http://www.va.gov



Thank you!Thank you!

Ken Rubin, EDS

+1 703 845 3277 desk

+1 301 335 0534 mobile

[email protected]

Documents

12/31/2013 11:20 AM Service-oriented Architecture What Does it mean to Healthcare Enterprises? May 2006 Ken Rubin EDS Co-Chair, OMG Healthcare Domain Task