11/18/2015 7:51 pm hl7 service-oriented architecture sig omg healthcare domain task force open...

26
01/28/22 22:42 HL7 Service-Oriented Architecture SIG OMG Healthcare Domain Task Force Open Health Tools Healthcare Services Specification Project The Business Case for Healthcare SOA Standards January 2012

Upload: anthony-dennis

Post on 05-Jan-2016

214 views

Category:

Documents


0 download

TRANSCRIPT

04/20/23 18:16

HL7 Service-Oriented Architecture SIG

OMG Healthcare Domain Task Force

Open Health Tools

Healthcare Services Specification Project

The Business Case for Healthcare SOA Standards

January 2012January 2012

Page 2

AcknowledgementsContributions to this content have come

from:Health Level Seven (HL7)

http://www.hl7.org

Object Management Group (OMG) http://www.omg.org

With additional contributions from:Integrating the Healthcare Enterprise (IHE)

http://www.ihe.net

Open Health Toolshttp://www.openhealthtools.org

Page 3

page 3

What is the Healthcare Service Specification What is the Healthcare Service Specification Project? Project? A joint standards development activity occurring in multiple

organizations, including Health Level 7 (HL7), the Object Management Group (OMG), IHE, Open Health Tools, and others

An effort to create common “service interface specifications” tractable within Health IT

Its objectives are:To create useful, usable

healthcare standards that address business functions, semantics and technologies

To complement existing work and leverage existingstandards

To focus on practical needs and not perfection

To capitalize on industry talent through open community participation

PolicyBusiness

Drivers

InformationModels

Service Funct.Model

RFP

Profiles

TechnicalSpecifications

Implementations

Requirements

Government, Professional Societies,…

Healthcare Organizations

HL7, openEHR, CEN, …

HL7 Domain Committees, CEN, Standards Bodies (SDOs)

OMG Healthcare Domain Task Force

IHE, SDOs, Healthcare Orgs

IHE

OMG, RFP Submitters

Interop Testing

Vendors, OHT, Healthcare Orgs

Page 4

What type of products do you produce? SOA Functional Standards [Service

Functional Models]Define the scope, purpose, and information content of

industry standard healthcare services Technical Specifications for balloted

Functional StandardsBind functional specifications into specific technologies,

transport protocols; technical conformance criteria Implementation Guidance & White

PapersNon-normative guidance to help consumers apply and

use HSSP specifications within their organizations. Not standards.

Page 5

2012 Key Milestones

Jan: HL7 Meeting (San Antonio) Jul:

Feb: Aug:

Mar: OMG Meeting (Washington) Sep: HL7 Meeting (Baltimore) > Ballot: Medication Stmt Profile Ballot anticipated> Ballot: Common Terminology Svcs 2 Normative Edition

OMG Meeting (Jacksonville)> Anticipated adoption: Services Directory (ServD) > RFP for Clinical Info Model Profile for UML to be issued

April: Interconnected Health Conf (Chicago)> Conference Proceedings can be found here

Oct:

May: HL7 Meeting (Vancouver)> Finalize Retrieve, Locate, Update Service Normative Spec

Nov:

Jun: OMG Meeting (Boston/Cambridge) > Revised submission of Services Directory (ServD)> “Information Day” on Healthcare Services

HL7 Italy “Open Days” (Rome, IT) HL7 Singapore SOA “Town Hall”

Dec: OMG Meeting (SFO/Burlingame)> Ballot: Medication Stmt Profile Ballot anticipated

Page 6

Core Project Principles

Leverage each community to its strengthOrganizations jointly participate in all

activitiesWork products will be “owned” by only one

organization but used collaboratively“Operate as one project” as a principleActively seek vendor participationRecognize that participation is an

investment

Page 7

HL7

OMG

The HSSP Process

HL7 DSTU

Service Functional Model

RequirementsOMG RFP

Technical Specification

Lessons Learned

ANSI Standard

Page 8

SFM

Understanding HSSP Artifacts, Roles, Attributes

Owned / Produced by

HL7 Community

RFP Submission Implementation

Defines what a service does but not how

Independent of technical platform

Audience is tech leads, EAs,

tech spec developers

Produced / owned by OMG

community

Translates SFM into technical requirements

ID’s supported technical

platforms

Audience is community with implementation

interest

Produced by OMG Member “Submitters”

Defines the service’s

technical spec

Defines interfaces, platform bindings, and conformance

profiles

Audience is project team

architect, lead developers, etc.

Owned by organizations and vendors

Builds the service that lives behind

the interface

Conforms with a “service profile”

Audience are consumers of the

system or service

Page 9

page 9

Asset InventoryAsset InventoryAsset Purpose Functional

SpecificationTechnical

SpecificationImplementation

Availability

Entity Cross-Reference Service (IXS)

To manage and correlate identities and identifying traits (e.g., MPI)

Complete Complete Commercially Available

Retrieve Locate Update Service (RLUS)

To manage location and retrieval of healthcare content

Complete Complete In Development

Decision Support Service (DSS)

To analyze patient data / assess knowledge rules.

Complete Complete Open Source

Common Terminology Service (CTS II)

Defines behavior for managing/maintaining terminologies

Complete Complete Open Source

PASS [Healthcare] Access Control Service

Manages security policy as pertaining to access to health information

Trial Use Standard

Complete(Beta)

Commercially Available

PASS [Healthcare] Audit Service

Security-oriented service to manage audit record

Trial Use Standard

Complete(Beta)

Commercially Available

Healthcare and Community Services Provider Directory (HCSPD)

To find providers & services in allocated areas, e.g., referrals.

Complete September 2012 Under Development

hDATA Record Format Specification

A hierarchical format with metadata tagging for organizing / representing [clinical] data

Complete N/A Open Source & Commercial

hDATA RESTful Transport Specification

REST binding for data retrieval using SOA (RLUS for REST)

Complete Expected 9/2011

Open Source

Page 10

Context of HSSP Specifications

Page 11

page 11

Interoperability RealizedInteroperability Realized

Context ConstraintsRequirements

En

terp

ris e

Info

rmati

o nC

om

pu

tati

on

a lEn

gin

eeri

ng

Page 12

How are HSSP services expressed?

Semantic Space/Universe

Formalism (Structure)

Semantic Signifiers(profile-relevant

semantic structures)

Usage Context(interoperability

paradigm)

FunctionalSubset List

(enumerate Supported Functions)

Ve

rsio

nS

ub

mitt

er

Na

me

Metadata Metadata

Page 13

The Benefits of HSSP Standards…

Define industry standard behaviors for healthcare-oriented service functions

Eliminate “different flavors” of web services from occurring in different organizations

Rapid-pace stds development: ~18-24 months

Methodology embracing cross-group standards development

Page 14

Where would these specifications be used

Inter-Enterprise (such as NHIN, RHIOs, HIE’s) By functionally specifying behavior, roles between

applications and products are clarified, and the technologies supporting them can be profiled and sharpened

Intra-EnterpriseStandardization on functionality allows for better integration

of off-the-shelf and custom development environments, and promotes more of a “plug and play” environment

Intra-ProductFacilitates vendors ability to integrate third-party value-add

components and speed design phase with higher confidence Custom-Implementation

Affords organizations wishing to custom-develop the opportunity to later integrate off-the-shelf

Page 15

HL7 ’s Services-Aware Interoperabilty Framework identifies architectural perspectives and levels describing and affecting interoperability

Conceptually HSSP activities are aligned with SAIF.

Includes SOA-based behavioral framework and conformance framework for HL7 standards (including HL7 v2 and v3 messages, CDA documents and services)

Utilizes SOA and Model-Driven Architecture principles for explicit expression of policy, governance and traceability

HSSP and the HL7 SAIF

Page 16

The Value of HSSP …

Value Rationale

Promotes deployment ease and flexibility

Specifications will support multiple topologies and technologies

Consistency at the interface level assures asset protection

Standard interfaces means that conformant components are substitutable

Multiple vendor product use/ interoperability

Using compliant products means side-by-side interoperation of multiple product offerings

Increased buyer/product offerings Consumer demand will create increased marketplace competition

Facilitates integration Unity in purpose and consistency in interface eases integration burden

Time to market Availability of an industry-accepted component interface eases product development burden

Requirements definition – influence vendors in a direct way

Participation by provider and payer community is direct expression of business need

Lower cost = wider deployment = higher quality service

Page 17

Why participate in standards at all? This is happening, with or without

you. We’d rather it be with you…

Unparalleled Networking. Standards work

provides access to the industry’s best and brightest Benefit from “lessons learned” from

others. Someone else may have already solved your biggest problem.

Industry Leadership. Standards work provides

a platform for you to establish market presence. Risk avoidance. Increasingly, standards

compliance is mandatory. Make them work for you and not against you.

Page 18

Why should I participate in HSSP?

This effort is focused on and driven by business-needIt is not an “academic exercise” striving for

perfectionStandards must be used to be useful Focused on the practical and achievableShort timelines Based upon business value and ROI

Leveraging talent from multiple communitiesBeing run like a “project” and not a

committee

We recognize that participation is an investment and not an expense

Page 19

How do I Participate? Participation is open to everyone. You don’t need to

be a member (though we encourage you to do so) Join appropriate standards organizations

HL7 for functional workOMG for technical specification work

Allocate resources to actively engage in the projectEngage existing, knowledgeable resources in the

areas they are working already.Subgroups form based on industry need and priorityTeleconferences are weekly; meetings

approximately bimonthly

Page 20

How is this project “different”? Active participation from three continents and 15+

organizationsSignificant cross-cutting community involvement

Providers & Payers (Blue Cross/Blue Shield, DoD Military Health System, Duke University, Kaiser-Permanente, Mayo Clinic, Veterans Health Administration)

Vendors, Integrators, Value-added Providers (Booz-Allen Hamilton, CSW Group, EDS, IBM, Initiate Systems, Intel, Northrop-Grumman, Ocean Informatics, Software Partners, 88Solutions)

Governments (Canada Health Infoway, DoD Military Health System (MHS), National Cancer Institute, NeHTA (Australia), SerAPI (Finland), Veterans Health Administration, Victoria Health (Australia))

Managing differences between SDOs in terms of membership, intellectual property, and cost models

Page 21

Who should I involve?

Involve the staff that can best address your business needs:You will get out what you put in. Senior

staff will drive more value and ROI to you than a junior associate.

Organizations that commit resources garner more influence and more mindshare

Your business interests are being represented by your attendees

Page 22

ReferencesAll HSSP artifacts and work in process are

open. Visit us at: http://hssp.healthinterop.org

Page 23

Supplemental Slides: Supplemental Slides: HSSP Stakeholder Benefits and HSSP Stakeholder Benefits and ImpactsImpacts

Supplemental Slides: Supplemental Slides: HSSP Stakeholder Benefits and HSSP Stakeholder Benefits and ImpactsImpacts

Page 24

SOA ≠ Web Services

SOA Web Services

Is a technology platform? No Yes

Is a transport protocol? No Yes

Primary ownership is business-line owned?

Yes No

Affects workflow and business processes? Yes No

Is an enabler for business and IT transformation?

Yes Yes

Is an industry standard? No Yes

Page 25

Why “services”?*A common practice in healthcare, just not yet in

healthcare ITMany key products use them but do not expose interfaces Ensures functional consistency across applicationsAccepted industry best practice Furthers authoritative sources of dataMinimizes duplication across applications, provides reuseMessages can be either payloads in or infrastructure

beneath servicesService-oriented architecture provides the framework for

automation of common services

*slide adapted from a Veterans Health Administration Presentation, used with permission

Page 26

What Participants are Saying… “Kaiser Permanente I.T. is currently transitioning to an SOA-based

approach to business and systems integration. Availability of industry standard services will bring many benefits towards this goal in terms of speed of implementation, flexibility and reduced cost. I am very pleased that both HL7 and OMG are committed to this timely effort.”, Alan Honey, Enterprise Architect (Principal), Kaiser-Permanente

“The creation of a health Informatics infrastructure based upon a service-based architecture grounded in comparable data has the potential to improve healthcare delivery and greatly enhance patient safety.”, Peter L. Elkin, MD, FACP, Professor of Medicine, Mayo Clinic College of Medicine

“The Eclipse Foundation is pleased to support an open source project dedicated to building frameworks, components, and exemplary tools to make it easy and cost-effective to build and deploy healthcare software solutions. This Eclipse Open Healthcare Framework project will leverage the Eclipse Platform developed by IBM, Intel, Wind River, Actuate, Borland, BEA, Computer Associates and others.” Mike Milinkovich, Executive Director, Eclipse Foundation

“The time is now and the place is here in this joint OMG/HL7 project. Never before has the industry been closer to cogent, clear healthcare IT data model and service standards that can provide true interoperability in a short timeframe, with open-source implementations making availability abundant.”, Richard Mark Soley, Ph.D., Chairman and CEO, OMG