Healthcare Services Specification Project The Business Case and Importance of Services

1
Healthcare Services Specification Project
The Business Case and Importance of Services
January 2007

• HL7 Service-Oriented Architecture SIG
• OMG Healthcare Domain Task Force

2
Background

• This presentation represents the collective input
  and thinking from the collective participants
  involved in the Healthcare Services Specification
  Project.
• Contributions to this content have come from
• The Object Management Group (OMG) community
• The Health Level Seven (HL7) community
• The Integrating the Healthcare Enterprise (IHE)
  community
• The Eclipse Open Healthcare Framework community
• This presentation is intended to describe the
  purpose, role, and importance of
  industry-standard service interface specifications

3
Why common services and not just messages?

• A common practice in healthcare, just not yet in
  healthcare IT
• Many key products use them but do not expose
  interfaces
• Ensures functional consistency across
  applications
• Accepted industry best practice
• Furthers authoritative sources of data
• Minimizes duplication across applications, reuse
• Messages can be either payloads in or
  infrastructure beneath services
• Service-oriented architecture is just automation
  of common services

slide adapted from a Veterans Health
Administration Presentation, used with permission
4
What is the Healthcare Service Specification
Project?

• An effort to create common service interface
  specifications tractable within Health IT
• A joint standards development project involving
  Health Level 7 (HL7) and the Object Management
  Group (OMG)
• Its objectives are
• 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

5
What are threads of active work?

• SOA Functional Standards
• Scheduling Service, Order Entry/Management,
  Anonymization, Terminology Maintenance/Navigation,
  Workflow, etc, .)
• Technical Specifications for balloted Functional
  Standards
• Entity Identification, Record Location/Update/Retr
  ieval, Clinical Decision Support, Service
  Ontology Development
• Implementation Guidance White Papers
• Service Registries, HL7 V2/V3 migration
  strategies, deploying SOA into Provider
  Organizations, etc.
• Methodology
• Service Specification Framework
• SOA4HL7 Messaging-to-SOA Transition Methodology

6
2007 HSSP Project Schedule (planned, major
milestones)
7
Where would these specifications be used

• Inter-Enterprise (such as NHIN, RHIOs, LHINs)
• By functionally specifying behavior, roles
  between applications and products are clarified,
  and the technologies supporting them can be
  profiled and sharpened
• Intra-Enterprise
• Standardization on functionality allows for
  better integration of off-the-shelf and custom
  development environments, and promotes more of a
  plug and play environment
• Intra-Product
• Facilitates 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

8
The Approach

• HL7 to lead in service selection, functional
  elaboration, and conformance criteria
• OMG to lead in technical specification
• Both organizations jointly participate in all
  activities
• Work products will be owned by only one
  organization but used collaboratively
• Operate as one project as a principle
• Actively seek vendor participation
• Engage IHE community

9
The Value of Collaboration

• HL7 brings
• Healthcare semantic interoperability expertise
• Rich, extensive international community
  perspective
• Diverse membership base
• OMG brings
• distributed systems architecture and modeling
  excellence
• Effective, efficient, rapid process
• Premise that standards must be implemented
• Resulting in
• Services will be identified by the community
  needing them
• Improved methodology resultant from functional
  and architectural merging of the two groups
• Facilitation of multi-platform implementation and
  broader implementation community

10
Context of HSSP Specifications
Interoperability
Platform Bindings
Model-based
Platform-independent
component
Specifications
Model Fragment
Computationally-
Independent Specification
Reference Information Model
HL7 Application Roles
Data Types and Terminology Bindings
Middleware Frameworks
Standard Terminologies and Vocabularies
Messaging Specifications (HL7, others)
HL7 Community and Open Participation
Physical/Software Infrastructure
11
Two Dimensions of Interoperability

• 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
• What can HSSP provide to get us to the goal?

Ideal Target
HSSP Reference Arch
Semantics
HL7 Messaging
HSSP RLUS (Profiled)
HSSP EIS
OWL-S
Web Services
UDDI v3
CORBA
Java RMI
HSSP RLUS
Behavioral
From the RM-ODP Informational Viewpoint
12
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 MedicAlert mission to protect and save
  lives requires a repository of comprehensive
  medical information that comes from multiple
  sources for our members. Our SOA-based
  infrastructure demands the rich and flexible
  capabilities that are provided by these standard
  interoperable services., David Harrington, CTO,
  MedicAlert Foundation
• 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

13
HSSP Moving in Internet Time (Globally)
2005 January Joint Project Chartered
2005 April Project Kickoff
2005 October Interoperability Services Workshop
Conference
2006 January HL7 Charters SOA Special Interest
Group
2006 May EIS, RLUS, and DSS Ballots Issued
2006 Summer HSSP Education held in Australia,
Finland, Norway, US
2006 September EIS, RLUS, and DSS Pass HL7
Ballot
2006 December EIS, RLUS RFPs Issued
2007 Q1 Functional work begins for 07
14
What has the HSSP delivered?

• HL7 DSTUs
• A Decision Support Service (DSS) receives patient
  data as the input and returns patient-specific
  conclusions as the output
• The Retrieve, Location, and Update Service (RLUS)
  provides a set of interfaces for accessing and
  managing health information
• The Entity Identification Service (EIS) for
  identification of patient, providers and other
  entities participating in the care
• OMG-issued technical Requests for Proposal (RFPs)
  finalized or drafted for all DSTUs
• A Service Development Framework (methodology) for
  developing the service specifications
• An informative HL7 ballot document on the SOA4HL7
  Messaging-to-SOA Transition Methodology

15
How is this project different?

• Active participation from three continents and
  15 organizations
• Significant cross-cutting community involvement
• Providers Payers (Blue Cross/Blue Shield, DoD
  Military Health System, Intermountain Health,
  Kaiser-Permanente, Mayo Clinic, Veterans Health
  Administration)
• Vendors Integrators (Accenture, CSW Group, EDS,
  IBM, Northrop-Grumman, PatientKeeper, Universata)
• Value-added Providers (MedicAlert, Ocean
  Informatics, Eclipse Foundation, etc.)
• Governments (Veterans Health Administration, DoD
  Military Health System (MHS), Canada Health
  Infoway, NeHTA Australia, SerAPI (Finland))
• Managing differences between SDOs in terms of
  membership, intellectual property, and cost
  models

16
Approach is producing a Comprehensive Solution

• HSSP SOA
• Conformance Profiles
• Semantic Functional
• Model Pedigree
• Profile and Template Registries
• Conformance Testing (Governance)
• Functional Models for Core and Business services
• Methodology for HL7 to Service Mapping
• Support for Federation, Forwarding, and
  Orchestration
• Ontology for Service Description and Discovery

• Services
• Interaction Payload
• Interaction Contracts
• Interactions
• Compositions

• HL7
• Story Boards
• Application Roles
• Payloads
• CIMs and LIMs
• Control Act and Transmission Wrappers
• HMD

17
Why should I participate? One

• This effort is focused on and driven by
  business-need
• It is not an academic exercise striving for
  perfection
• Acknowledgement that for standards to be useful
  they must be used
• Focused on the practical and achievable
• Short timelines
• Based upon business value and ROI
• Leveraging talent from two standards communities
• Up-front commitment ensures community engagement
  
• Being run like a project and not a committee
• Recognize participation as an investment and not
  an expense

18
Why should I participate? Two

• This is happeningthe only way to influence the
  outcome is to engage
• Significant networking opportunitiesyou will
  gain access to the best and brightest in the
  industry and the world
• Prime opportunity to directly engage with
  complementing stakeholder groups
  (provider-to-vendor, vendor-to-payer, SDO-to-SDO,
  etc)
• Benefit from lessons learned from others
• Reduce design burden
• Establish market presence and mindshare as
  industry leader

19
How do I Participate?

• Join appropriate standards organizations
• HL7 for functional work
• OMG for technical specification work
• Join both
• Allocate resources to actively engage in the
  project
• Engage existing, knowledgeable resources in the
  areas they are working already.
• Subgroups form based on industry need and
  priority
• Teleconferences are weekly meetings
  approximately bimonthly

20
Who should I involve?

• Involve the staff that can best address your
  business needs
• The benefits you receive will depend upon your
  investment
• Organizations that commit resources garner more
  influence and more mindshare
• Your business interests are being represented by
  your attendees

21
References

• HL7 Website
• http//www.hl7.org
• OMG Website
• http//www.omg.org
• Services Project Homepage
• http//hssp.wikispaces.com/

22

• Supplemental Slides HSSP Stakeholder Benefits
  and Impacts

23
For Product Consumers and UsersThe Impacts and
Rationale of HSSP Specifications
24
Product Vendor The Impacts and Rationale of
HSSP Specifications
25
Regulatory/Policy/Legislative The Impacts and
Rationale of HSSP Specifications
26
Research The Impacts and Rationale of HSSP
Specifications
27
Implementer/Integrator The Impacts and
Rationale of HSSP Specifications
28
SDOs The Impacts and Rationale of HSSP
Specifications