Healthcare Services Specification Project The Business Case and Importance of Services

1
Healthcare Services Specification Project
The Business Case and Importance of Services
October 2005

• HL7 Services Specification Project Workgroup
• 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.
• Represented were members from
• Object Management Group (OMG)
• Health Level Seven (HL7)
• Integrating the Healthcare Enterprise (IHE)
• 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
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

6
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

7
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

8
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
9

• HSSP Stakeholder Benefits and Impacts

10
For Product Consumers and UsersThe Impacts and
Rationale of HSSP Specifications
Impacts Rationale
Promotes deployment ease and flexibility Specifications will support multiple topologies
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
11
Product Vendor The Impacts and Rationale of
HSSP Specifications
Impacts Rationale
Market opportunity ability to grow business / Grow the pie Standardization of interfaces eases cost-of-entry to markets
Conformance adds legitimacy to product offering Consumers view conformance as a confidence metric
Reduced time and cost to market Use of 3rd party components Simplify / reuse of design Ability to reuse design ideas, incorporate off-the-shelf components into value-add offerings
Participation provides the ability to influence the standard You can shape the standard to be supportive of your product architecture
12
Regulatory/Policy/Legislative The Impacts and
Rationale of HSSP Specifications
Impacts Rationale
Establishing objective assessment criteria Measurement criteria for regulatory compliance Inclusion of rigorous conformance assertions benefits compliance and verification
Allows for technology change within the regulation Concurrent support of multiple technologies allows for technology evolution
Offering an easy/easier solution that is complete and actionable / ease the path to adoption How do we Pick the winning horse? Opportunity cost of using the wrong standard has big implications HSSP integrates function/ behavior, data, and protocol promoting an integrated solution set
Solution that complements existing standards HSSP is using HL7 semantics, OMG processes, IHE testing, and established technology protocols
13
Research The Impacts and Rationale of HSSP
Specifications
Impacts Rationale
Promotes accessibility to raw information Strong emphasis on semantically rigorous data and query/retrieval
Enabler for collaborative studies, e.g. de-identification, retrieval, etc. Leveraged use of identity service enables de-identification
Enlarges cell and sample sizes based on interoperability
Facilitates responsiveness to bio-surveillance requirements Standard interfaces accommodate dynamic and emerging strategies and tools
Enables construction of higher-order service stacks with less investment Composable nature of services promotes construction
14
Implementer/Integrator The Impacts and
Rationale of HSSP Specifications
Impacts Rationale
Reduced integration time and cost resulting from the use of standard tooling Use of standard in off-the-shelf tools facilitates their use
Risk mitigation (skill portability/ training advantage, vendor independence, substitutability) By training staff in the standard, skills are portable across tools
Creates a value offering opportunity based on the ability to deliver using these service standards Allows staff and solutions to build upon the use of the standard and not technologies
Improved ability to deliver and support interfaces that have been implemented Using services speeds project design phases and promotes reuse
15
SDOs The Impacts and Rationale of HSSP
Specifications
Impacts Rationale
Useable standards Emphasis on practicality
Market-focused standards based on commercial implementations Shortens time required to develop specifications and encourages collaboration
Promotes harmonization, cooperation, cohesion among standards communities Integration of function, data, and technology promotes leveraged reuse
More members/involvement more revenue better specs Practical, market-focus and iterative timeline promotes participation and results
16
Reference Examples

• Mass Clinical Data Exchange (CDX)
• RHIO
• Merger/acquisition
• Public health / disease reporting

17
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

18
Project Timeline and Roadmap
1996 First OMG Healthcare Service Spec Adopted
(PIDS?)
2003 HL7 ServicesBOF formed
2005 September HL7, OMG Collaboration MOU
2005 January Joint Project Chartered
2005 April Project Kickoff
2005 September Methodology and MetaSpecs
Baselined (planned)
2005 October Interoperability Services Workshop
Conference
2006 January Functional Specs Ballot (planned)
2006 Q4 Technical Specs RFP (planned)
19
How is this project different?

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

20
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

21
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

22
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

23
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

24
References

• HL7 Website
• http//www.hl7.org
• OMG Website
• http//www.omg.org
• Services Project Homepage
• http//groups.yahoo.com/group/ServicesSpec