leveraging a reference architecture and standards to promote interoperability

03-23-05April 2008

Leveraging a Reference Architecture and Leveraging a Reference Architecture and Standards to Promote Interoperability Standards to Promote Interoperability

Ken Rubin ([email protected])

Chief Healthcare Architect, EDS Federal Health Portfolio

Chair, OMG Healthcare Domain Task Force

© 2008, All Rights Reserved, Reuse with Attribution Permitted page 2

SOA, Healthcare, and Reference Architectures April 2008

Learning ObjectivesLearning Objectives

• Understand healthcare and its unique challenges as a market sector

• Define context and dimensions of Interoperability

• Come to a shared understanding of Architecture and its role

• Provide an overview of Standards pertinent to health interoperability

• Tying the above together. How do standards, architecture, and SOA help promote interoperability



A little personal background… A little personal background…

• ~18 years of IT experience• ~10 years Enterprise Architecture and Health Informatics experience• Roles:

– Chief Healthcare Architect for EDS’ Federal Healthcare Portfolio– Veterans Health Administration Enterprise “Application” Architect (held for ~7 years)– Standards

• 10 years of standards participation and involvement• Chair of the OMG Healthcare Domain Task Force• Co-Chair of HL7 Service-oriented Architecture Committee• Enterprise Architect for Open Health Tools• Past Chair, HL7 Process Improvement Committee



DisclaimersDisclaimers

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, currency, and vendor/product neutrality.

Nonetheless, these slides do not necessarily reflect the official position of the Veterans Health Administration, the U.S. Government, EDS, or any organizational affiliation.

03-23-05April 2008

An Introduction to Health Care An Introduction to Health Care



The Healthcare “Vertical”: A Global ContextThe Healthcare “Vertical”: A Global Context

• In almost every culture, healthcare is being viewed as “broken”

• Demand ubiquitously is outpacing supply

• To date, Information Technology investments in healthcare have been limited

• Countries with the means to do so are investing in IT

– Australia (NeHTA: http://www.nehta.gov.au )

– Canada (Infoway: http://www.infoway-inforoute.ca/ )

– United Kingdom (NPfIT: http://www.connectingforhealth.nhs.uk/ )

– United States (NHII, RHIOs, … http://www.os.dhhs.gov/healthit/ )

– Others….

• Unprecedented participation and collaboration internationally



Vertical Market Sector Objectives for HealthcareVertical Market Sector Objectives for Healthcare

• Clinical

– Improve information quality

– Improve information availability at point-of-care

– Reduce preventable medical errors

– Support adherence to clinical protocols

• Administrative

– Improve resource management and utilization

– Improve information management, security, privacy

• Financial

– Improve fiscal life cycle; revenue cycle management



Healthcare’s ChallengesHealthcare’s Challenges

• Funding is sparse everywhere

• IT is competing with direct patient care for $$$

• There are few incentives and many risks for organizations to share information

• Information content is very diverse and complex, and is not consistently represented by practitioners

• The volumes of data are enormous

• The institutional culture is still very much paper-based

• There is an inherent lack of infrastructure within and across care organizations

• Software products that are available are largely proprietary



The Premise …The Premise …

Healthcare IT is about improving Healthcare IT is about improving health outcomeshealth outcomes



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



A View into Health IT AdoptionA View into Health IT Adoption

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



The PrThe Proomise (A Vision)mise (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



Case Study: The [US] Veterans Health Case Study: The [US] Veterans Health Administration* Administration*

• Business View– Operates 1400+ sites of care

– 155 hospitals/medical centers

– 872 outpatient clinics

– 135 long-term care facilities

– 45 rehabilitation facilities

– Affiliated with 107 of 125 medical schools in the US

• Healthcare Statistics (2006)– 7.9M beneficiaries enrolled

– 74.5M people potentially eligible

– ~775K inpatient visits

– 5.5M patients treated

– 60M+ outpatient visits

• Operational View (2004)– 180k VHA employees

– 13k physicians, 49k nurses

– 90k health professionals trained annually

– USD$34.9B budget in 2007

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

– Software portfolio exceeds 140 applications

– Reengineering effort is based upon a services architecture

*statistics taken from 2007 VA Fact Sheet, U.S. Department of Veterans Affairs:

http://www1.va.gov/opa/fact/vafacts.asp



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 thingAnd 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%

This is the reason interoperability and standards are essential!

03-23-05April 2008

Interoperability and StandardsInteroperability and Standards



What is Interoperability?What is Interoperability?

• According to IEEE, interoperability is defined as:

– the ability of two or more systems or components to exchange information and to use the information that has been exchanged

• Why do we care?

– No organization exists in a vacuum

– Increasingly, business pressures are driving organizations to collaborate and interchange data with their peers

– Integration and dependencies between market sectors are increasingly important

– Our ability to integrate drives consumer value

– Consumers are increasingly empowered



The 20 Second Interoperability QuizThe 20 Second Interoperability Quiz

Are you interoperable…

• … if you and your business partners “speak” different languages

• … if gender = “01” means “male” in your business and “female” for your business partner?

• …if the primary context for information sharing is e-mail or fax?

• … if electronic data is exchanged via CD-ROM, or DVD-ROM?

• …if you use XML?

• …if you use Web Services?



The 20 Second Agility Quiz The 20 Second Agility Quiz

How well can your organization’s IT adapt to…

• … address the new business rules that resulted from a legislated policy?

• … deployment changes resulting from adding a data center?

• … integrating clinical information with a new business partner?

• … integrating with “the new <place clinical specialty here> system”

• … emerging public interest in personal health records?



Measuring InteroperabilityMeasuring Interoperability

• NeHTA (the Australian National e-Health Transition Authority) published an Interoperability Maturity Model

– It defines a rigorous method of assessing and measuring interoperability

– It is based on the maturity levels defined in the Carnegie-Mellon Capability Maturity Model (CMMI)

– It identifies dimensions of interoperability, namely:

• Organisational

• Informational

• Technical

– http://www.nehta.gov.au/index.php?option=com_docman&task=cat_view&gid=123&Itemid=139



Addressing the Two Dimensions of InteroperabilityAddressing the Two Dimensions of Interoperability

Sem

antics

Behavioral

UDDI v3

Web Services

Java RMI

OWL-S

CORBA

Ideal Target • Behaviorally, there are a lot of solutions

• Need to marry Semantic Interoperability with Behavior

• The touchstone business case is the notion of automated discovery, composition, and delivery

SNOMED-CT

ISO-11179



The beauty of standards… The beauty of standards…

• HL7 • X.12• NCPDP• ASTM• OMG• DICOM• IHTSDO/SNOMED• ICD• LOINC• IHE• CEN TC 251• ISO TC 215

“Functional” StandardsStructured Doc Standards

Terminology StandardsMessaging Standards

Services StandardsStandards Profiling



Scope of HL7 Activities and StandardsScope of HL7 Activities and Standards

• Messaging • RIM• CDA• CCOW• CTS• Vocab• Arden• Decision Support• Services• EHR

• Modeling and Methodology

• Vocabulary

• Architecture Review Board

• CCOW

• Clinical Decision Support

• Conformance

• Control Query

• Financial Management

• Medical Records

• Orders and Observations

• Patient Administration

• Patient Care

• Personnel Mgmt

• Regulated Clinical Research and Information Management

• Scheduling and Logistics

• Structured Documents

• Arden Syntax

• Attachments

• Clinical Guidelines

• Community-based Health

• Pediatrics

• Electronic Health Records

• Government Projects

• Image Management

• Java

• Lab Automation and Testing

• Medication

• Security and Accountability

• Templates

• XML

• Services

• Public Health and Emergency Response



11

returns_to

1..*1..*

1

1

1

1

11

11

0..*specifies_ability_in 0..*

11

11

1

can_accompany

1

1..*

1

1..*

1

0..*0..*

is_managed_by

0..*0..*

MessageMessagecontrolcontrol

ParticipationParticipation ActAct

HL7 RIMHL7 RIM

RoleRoleEntityEntity

StructuredStructuredDocumentsDocuments



Model-Driven Architecture Model-Driven Architecture

Fundamentally, MDA enables business-meaning to be realized in multiple technologies

MDA promotes separation of concerns

MDA facilitates service-oriented architecture

MDA provides an infrastructure to leverage commercially-available tooling

MDA allows for side-by-side technology deployments

* Separation of concerns based upon ISO RM-ODP Specification



What is the Healthcare Services What is the Healthcare Services Specification Project?Specification Project?

• Standards specifically to support healthcare SOA

• Community to establish “SOA service” definitions, demarcations, responsibilities, and behavoiur for core functions needed both within and across organizations

• A joint effort involving HL7, OMG, Open Health Tools (OHT), and IHE

HSSP

HL7 Domain Committees

OMG

HITSP

National Programs (e.g. ONC, NEHTA)

CEN

OpenEHR

OHT

IHE

Methodology (SSF),DSTU Feedback,

Consultative support

SFMs, Info Models,

Requirements,Service Profiles

Policy

Service Profiles

Methodology,HL7/SOA Harmonization

SOA Interoperability Specifications

Use Cases,Requirements

TechnicalSpecifications,RFP process

Use Cases,Candidate Standards

Info Models,Semantic Profiles

SOA Interop Specs

RFPRequirements

Integration Profiles,Conformance Testing,

Interoperability Validation

TechnicalSpecifications

Open SourceRef Implementations,

Tools

SOA Interoperability Specifications,

Use Profiles

HSSP’s Objectives:

• To create useful, usable healthcare standards that address functions, semantics and technologies

• To complement existing work and leverage existing standards

• To focus on practical needs and not perfection

• To capitalize on industry talent through open community participation



The HSSP Asset Inventory….The HSSP Asset Inventory….

• Healthcare Services Specification Framework– The methodology used to identify and specify services– “Boilerplate” documentation for the specification of future services

• The Healthcare Reference Enterprise Architecture (under construction)– Implementation guidance to organizations implementing healthcare services– HSSP “Roadmap” -- The priorities, dependencies, relationships, and architectural context for

healthcare services

• Service Functional Models [describe the scope, behavior, and functions of services]– Entity Identification Service SFM [HL7 Balloted Draft Standard for Trial Use (DSTU)] – Resource Location and Update Service SFM [HL7 Balloted DSTU]– Decision Support Service SFM [HL7 Balloted DSTU]– Clinical Research Filtered Query SFM [HL7 Balloted DSTU]– Common Terminology Service SFM [Ballot expected 3Q2008]

• OMG RFPs– Entity Identification Service RFP – Resource Location and Update Service RFP – Decision Support Service RFP

• “SOA4HL7” Implementation Guide [HL7 Balloted Informative Document]– Actionable guide for HL7-based SOA implementations– Leverages existing standards in the context of SOA implementation



So, what do we do about… So, what do we do about…

“Functional” StandardsStructured Doc Standards

Terminology StandardsMessaging Standards

Services StandardsStandards Profiling

• HL7

• X.12

• NCPDP

• ASTM

• OMG

• DICOM

• IHTSDO/SNOMED

• ICD

• LOINC

• IHE

• CEN TC 251

• ISO TC 215

03-23-05April 2008

ArchitectureArchitecture



Guiding Principles Guiding Principles

• Systems must add value to healthcare stakeholders (patients, caregivers, and organizations)

• Information Technology (IT) cannot “fix” business problems

• I.T. does not exist in a vacuum

• We cannot optimize the continuum of care without considering flow between practitioners, departments, and facilities

• A useful “tool” to understand large complex environments is to “separate concerns”*:

– Business (Enterprise) View

– Information View

– Systems View

– Technologies View

• The difference between system success and failure lies in the “small stuff” – details matter!

* *Separation of concerns based upon ISO RM-ODP Specification



““Types” of ArchitectureTypes” of Architecture

Enterprise Architecture

Systems Architecture

Reference Architectur

e

Primary purpose is for organizational transformation Yes No No

Intended to be extended and localized No No Yes

Is an authoritative source of guidance Yes Yes No

Is ideally expressed in UML Partly Yes Partly

Is appropriate for model-driven design No Yes No

Is intended to be directly realized/implemented Partly Yes No



Health IT, Enterprise Architecture, and Business Health IT, Enterprise Architecture, and Business ChangeChange

• What is architecture?

• What is Enterprise Architecture?

• Is Health Enterprise Architecture different? Why?

• Why do I care?

• Architecture forms the foundation for supporting and integrating IT and applications

• Enterprise Architecture is the discipline devoted to aligning IT investments with business needs

• Yes and no. The core concept is identical in healthcare as other industries. That said, the information and workflow complexities “change the game”

• Ultimately, systems will only fit within the fabric of a health organization if they are architected in. If not, we have standalone “one-offs” that impede workflow and adversely affect both patients and caregivers.



““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



The Context for Healthcare Architecture…The Context for Healthcare Architecture…

• …to serve as a catalyst positively influencing government health IT investments

• …to galvanize the private sector through Government-demonstrated leadership

• …to articulate and capture the “to be” and help organizations achieve it

• …to characterize how and where approved standards are used

• …to shape and frame interoperability intra- and inter-organizationally



How do we use architecture to drive change?How do we use architecture to drive change?

P2

P3

P4

P1

Current Environment •Integration is within a point-of-care (but nt across points-of-care)

•IT solutions are largely problem-specific or niche-based

•Limited ability to support beneficiary-directed care and PHR

•Inconsistent meanings and representations of data

•Financials/claims not directly driven from clinical process

Legacy Enablement and Modernization

Healthcare Informatics

Data Management

Security andInfrastructure Improvement

Healthcare Business

Transformation

Solution Integration and Software Development

Real

ize

valu

e from

exi

stin

g da

ta a

nd sof

twar

e in

vest

men

t

Drive so

lutions t

hat pro

mote health

and are cl

inically

viable

Improve operations through performance mgmt and info

assurance

Improve reliability, information assurance, and capacity

Driving to improve quality, care delivery, and organizational efficacy

Pro

mote

inte

ropera

bilit

y b

y levera

gin

g C

OTS, Sta

ndard

s,

and S

OA

Future Vision•Realize improved quality-of-care and cost-avoidance through HIT

•Improved service delivery resulting from world-class HIT partner

•Realize healthcare IT solutions that empower caregivers and beneficiaries

•Facilitates patient involvement directly in their care (PHR)

•Enables holistic view of health data, across enterprise and enterprises

Eliminate unplanned redundancies

Align Adapt Transform

“Wrapper” existing applications with SOA interface

Ability to budget, plan, execute SW development repeatably

Integrated security mgmt

Workflow improvement from HIT

Institute versioning of ontology and data



Realizing sustainable health systems….Realizing sustainable health systems….

P2

P3

P4

P1

Current Environment •Integration is within a point-of-care (but nt across points-of-care)

•IT solutions are largely problem-specific or niche-based

•Limited ability to support beneficiary-directed care and PHR

•Inconsistent meanings and representations of data

•Financials/claims not directly driven from clinical process

Legacy Enablement and Modernization

Healthcare Informatics

Data Management

Security andInfrastructure Improvement

Healthcare Business

Transformation

Solution Integration and Software Development

Real

ize

valu

e from

exi

stin

g da

ta a

nd sof

twar

e in

vest

men

t

Drive so

lutions t

hat pro

mote health

and are cl

inically

viable

Improve operations through performance mgmt and info

assurance

Improve reliability, information assurance, and capacity

Driving to improve quality, care delivery, and organizational efficacy

Pro

mote

inte

ropera

bilit

y b

y levera

gin

g C

OTS, Sta

ndard

s,

and S

OA

Future Vision•Realize improved quality-of-care and cost-avoidance through HIT

•Improved service delivery resulting from world-class HIT partner

•Realize healthcare IT solutions that empower caregivers and beneficiaries

•Facilitates patient involvement directly in their care (PHR)

•Enables holistic view of health data, across enterprise and enterprises

Deploy IT Governance

HIT-facilitated adherence to clinical protocol

Baseline core org. business functions

Identify target operational objectives

Establish EA program

Improved workflow

Increase asset utilization`

Eliminate unplanned redundancies

Improve organizational agility

Improved efficacy, quality, and care delivery

Align Adapt Transform

Target applications for legacy enablement identified

Remove point-to-point interfacing at transport layer (interface engines)

“Wrapper” existing applications with SOA interface

Refactor, re-architect, re-design legacy applications

Data cleansing, transformation, load of redesigned apps

Phased side-by-side deployment of wrappered and refactored

Improvement in resource competency-base

Improvement compliance with architectural oversight

Software development merges “agile” and CMMI practices

Promote community- experience sharing

Improved ROI measurement

Established culture of reuse and process improvement

Adaptive, agile, quality, repeatable delivery

SOA Governance established and managed

Ability to budget, plan, and execute SW development repeatably

Install access point controls

Reduced numberof incidents

Integrated security mgmt

Deploy enterprise management tools

Improved FISMA Reporting

Improved ‘scorecard’ grades

IT Asset Management

Enterprise Data Protections

Secure, redundant, high-availability infrastructure

Clinical-oriented usability engineering

Informatics involvement in requirements

Clinical data representationpromoting physician decision support

Informatician involvement in software life cycle

Enterprise adoption of controlled medical vocabulary

Workflow improvement resulting from HIT adoption

Evidence-based HIT

Enterprise-wide interoperable data available and used by caregivers

“Intelligent” EHR decision support

Identify preferred codesets

Prioritize which and how much data is to be computable

Establish authoritative data sources

Identify and license medical knowledge sources

Data mapping and trans-formation from legacy

Normalize structures for complex data representation

Institute versioning of ontology and data

Establish terminology services bureau supporting evolution

Predictive Decision Support from EHR

Determine basis for out-of-agency sharing

03-23-05April 2008

Bringing in Together…Bringing in Together…



Guiding Principles Guiding Principles

• Seek to simplify the problem by separating “concerns”*

– Business (Enterprise) View

– Information View

– Systems View

– Technologies View

• Leverage standards at interface points to minimize vendor proprietary risks

• The difference between system success and failure lies in the “small stuff” – details matter!

• “So, what does this have to do with MDA?”….* Separation of concerns based upon ISO RM-ODP Specification



Designing for Designing for InteroperabilityInteroperability

Ab

ilit

y to

Int

erop

erat

e

High

Low



An approach…. An approach….

• Consider IT within the fabric of the enterprise– How does it integrate with workflow?– IT success must be evidence-based

• Clarify IT responsibilities within your organization– Establish authoritative systems and data sources– Use standards “wherever systems touch”– Focus on information quality

• Take a 20+ year view– The health record must be durable– The technologies will not be

• You are not alone…– Healthcare is a community discipline– Organizations, systems, products, and technologies all play a role– There will be no single marketplace “winner”



Make IT a Business Enabler Make IT a Business Enabler

• Conduct Enterprise Architecture planning to understand the business

– What is the “state of affairs” today?– Where do we want to be tomorrow?

• Work with the stakeholder community to identify desired outcomes

– Focus early priorities on early returned investment– Identify and capture meaningful metrics– Validation should be “round trip” based upon observed impacts

• Reflect IT as a function of the business– How effectively are business needs being captured?– How are stakeholder interests being assured during system

implementation?– How are education, training, and process integration being addressed?



Five success measures of your architecture…Five success measures of your architecture…

5) Durable, with decreasing rate of change- Evolution, not revolution. If you get it right, changes become small and

incremental

4) Standards-based, with variances that are localized to minimize impact. - Build on existing work

- Depart only where you need to

- Any time two things touch, that touch-point should be a standard

3) Product-neutral- Organizations cannot afford to base their entire future on a dependency of any

one product

4) Clear- Make sure you architecture is understandable, concise, and accurate

- Use “separation of concerns” and “viewpoints”

- Make sure you architecture is suitable for its intent

5) Useful, as architectures that sit on shelves add no value.



Five Keys For Overall SuccessFive Keys For Overall Success

1) Leadership must come from the “business” community

2) Define success measures with meaningful business outcomes

3) Design your architecture to realize the impacts you hope to achieve

4) Recognize that while every organization is unique, their challenges aren’t

5) The future isn’t the hard part. Building it while you are “moving” is.



SOA in Health Care: SOA in Health Care: Realizing Quality of Care, Business Value, and Delivery on I.T.’s PromiseRealizing Quality of Care, Business Value, and Delivery on I.T.’s Promise

Chicago, IL April 15-17, 2008Chicago, IL April 15-17, 2008

http://http://www.omg.orgwww.omg.org/news/meetings/HC-WS//news/meetings/HC-WS/

• Three-day event featuring lessons-learned, best-practices, and experience sharing

• Event features an “Executive Summit” followed by business & technical tracks

• Representation from provider, payer, and public health communities

• Featured speakers and panelists include

– Jonathan White, M.D. Health IT Portfolio DirectorAHRQ

– Vish SankaranProgram Director, Federal Health Architecture, ONCHIT

– Ken LunnDirector of Data Stds and ProductsNational Programme for Health IT (UK)

– Marion Ball, Ed.D.Fellow, IBM ResearchProfessor Emerita, Johns Hopkins

– Steve FlamminiChief Technology OfficerPartners Health Care

– Dennis GiokasChief Technology OfficerCanada Health Infoway

– Don MonVice PresidentAHIMA

– Stanley Huff, M.D.Chief Medical Informatics OfficerInterMountain Health Care



Our Challenge…Our Challenge…

““It is cheaper and easier than ever to create It is cheaper and easier than ever to create badly designed applications and spaghetti badly designed applications and spaghetti

integration.”integration.”

Alan Honey, Enterprise Architect, Kaiser-Permanente



ReferencesReferences

• Health Interoperability Portal (Launching soon!)

– (educationally focused, this portal will contain information to help readers make informed decisions about health interoperability challenges and solutions)

• http://healthinterop.org

• HL7 Website:

• http://www.hl7.org

• HSSP “Wiki”

– (contains all active project work, including links to each subgroup, adopted standards, and is the foundation for the HSSP community)

• http://hssp.healthinterop.org

• OMG Website:

• http://www.omg.org



Thank you!Thank you!

Ken RubinChair, OMG Healthcare Domain Task Force

Healthcare Architect [email protected]

[email protected]