Transcript Corporate Presentation Tutorial

Healthcare Services Specification Project
The Business Case and Importance of Services
January 2007
HL7 Service-Oriented Architecture SIG
OMG Healthcare Domain Task Force
7/20/2015 11:26 PM
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
Page 2
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
Page 3
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
Page 4
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/Retrieval,
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
Page 5
2007 HSSP Project Schedule (planned, major milestones)
Jan:
Baseline Functional Areas for
2007 cycle
Jul:
Educ. Summit Boston (Jul 10-12)
Issue 2007 SFM Ballots
HL7 San Diego (Jan 7-12)
Feb:
Mar:
OMG San Diego (Mar 26-30)
Aug:
Ballot review
Sep:
HL7 Atlanta (Sep 16-21)
EIS, RLUS “intent to submit” due
Issue DSS RFP
Apr:
May:
OMG Jacksonville (Sep 24-28)
EIS, RLUS Tech. Submissions Due
Oct:
HL7 Cologne
Nov:
HSSP Information Day
Jun:
Announce intention to ballot 2007
SFMs
HL7 Educational Summit
IHE Infrastructure Planning WG
Dec:
OMG Burlingame (Dec 10-14)
Page 6
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
Page 7
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
Page 8
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
Page 9
High
Ability to Interoperate
Context of HSSP Specifications
Low
Page 10
Two Dimensions of Interoperability
Ideal Target
Semantics
HSSP Reference Arch
HL7 Messaging
HSSP RLUS (Profiled)
HSSP EIS
OWL-S
Web Services
• 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
UDDI v3
Java RMI
CORBA
HSSP RLUS
Behavioral
From the RM-ODP Informational Viewpoint
• What can HSSP
provide to get us to the
goal?
Page 11
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 opensource implementations making availability abundant.”, Richard Mark Soley,
Ph.D., Chairman and CEO, OMG
Page 12
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
Page 13
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
Page 14
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
Page 15
Approach is producing a Comprehensive Solution
• Services
– Interaction Payload
• HSSP SOA
– Conformance Profiles
– Interaction Contracts
• Semantic + Functional
– Interactions
• Model Pedigree
– [Compositions]
• HL7
– Story Boards
– Application Roles
– Payloads
– CIMs and LIMs
– Control Act and
Transmission Wrappers
– HMD
– 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
Page 16
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
Page 17
Why should I participate? [Two]
• This is happening—the only way to influence the outcome is
to engage
• Significant “networking” opportunities—you 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
Page 18
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
Page 19
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
Page 20
References
• HL7 Website:
• http://www.hl7.org
• OMG Website:
• http://www.omg.org
• Services Project Homepage
• http://hssp.wikispaces.com/
Page 21
Supplemental Slides:
HSSP Stakeholder Benefits and Impacts
Page 22
For Product Consumers and Users…
The 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
Page 23
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
Ability to reuse design ideas, incorporate off-theshelf components into value-add offerings
• Use of 3rd party components
• Simplify / reuse of design
Participation provides the ability
to influence the standard
You can shape the standard to be supportive of
your product architecture
Page 24
Regulatory/Policy/Legislative …
The Impacts and Rationale of HSSP Specifications
Impacts
Rationale
Establishing objective assessment
criteria:
Inclusion of rigorous conformance assertions
benefits compliance and verification
Measurement criteria for
regulatory compliance
Allows for technology change within the
regulation
Concurrent support of multiple technologies
allows for technology evolution
Offering an easy/easier solution that is
HSSP integrates function/ behavior, data,
complete and actionable / ease the path and protocol promoting an integrated solution
to adoption:
set
How do we “Pick the winning
horse”?
“Opportunity cost” of using the
wrong standard has big
implications
Solution that complements existing
standards
HSSP is using HL7 semantics, OMG
processes, IHE testing, and established
technology protocols
Page 25
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 deidentification
Enlarges cell and sample sizes
based on interoperability
Facilitates responsiveness to biosurveillance 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
Page 26
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
Page 27
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
Page 28