Healthcare Services Specification Project
(HSSP): SOA standards in Healthcare
October 2007
Alan Honey
Enterprise Architect
(Kaiser Permanente)
Co-chair HL7 SOA SIG
7/13/2017 9:07 PM
Agenda
HSSP Overview
• Background
• What is HSSP?
• Deliverables and Status
• Roadmap and Reference Architecture
• Methodology
• Technical Specification - RFP Process and submissions
• Value Proposition and Getting Engaged
• Questions / Discussion: (Open)
Page 2
Audience Assumptions
• Familiarity with SOA concepts and the basic value
proposition of SOA
– Business agility
– Cost and efficiency (especially integration)
– Simpler (at least it should be)
• Familiar with messaging standards (HL7, X.12 etc.)
– HL7 V2.x: well established in US but has well publicized
weaknesses
– HL7 V3 (separates model from implementation, which is in all
known cases based on XML) but heavy infrastructure and
difficult to implement
Page 3
Refresher: Web Services v Services v SOA
Web Services is technology (a platform in OMG-speak)
•
•
•
Classic web services stack: XML, SOAP, WSDL, UDDI
Usually HTTP based, but may use MQ (JMS, AMQP) or SMTP
Can support SOA, but also can support messaging or document
paradigms
Services
•
•
Well defined Functional Components, cohesive collections of
business or infrastructure functionality, exposed through well-defined
interfaces
Separation of interface from implementation, service clients depend
on the interface contract only, not internals of the implementation.
Page 4
Refresher: Web Services v Services v SOA
Service Oriented Architecture
• Overall cohesive framework and approach for defining and using
Services, with a focus on business perspective.
• Architecture focus: e.g. loose coupling, separation of concerns
• Focus on model driven solution delivery
• Common, standards-based infrastructure for distributed computing,
providing the “…ilities” (availability, reliability, scalability, performance)
• Uses declarative policies / rules to drive decisions in processing
• Complements Business Process automation, separation of Process
from Service
• SOA does NOT actually require Web Services, however web services
is the technology that is being used to deliver it today by almost every
organization doing SOA and this will continue for the foreseeable
future.
Page 5
Evolution of SOA/Services in HL7
Web Services as Transport (Phase 1)
– HL7 WS Profile
Web Services as Enabling Technology (Phase 2)
– SOA 4 HL7
– Provides some degree of durability
Standard Services (Phase 3) – In Progress
– HSSP Service Specifications
– Services Interoperability Paradigm
SOA (Phase 4) - Future
– Compliant with Reference Architecture
•
•
•
•
Metamodel
Implementation Guides
Profile Registry
Template / Static Model Registry
Page 6
Healthcare Service Specifications
• Take good principles and practices learned from
standardizing messaging and apply to Services, OR…
• Tie good SOA practices and patterns to the rich models of
HL7, CEN, OpenEHR
• Create true Interoperability specifications, not just
Integration specifications
• Provide architectural building blocks
• Helping to make SOA a reality for healthcare
organizations that mainly buy vendor software, and
providing direction for those that build.
Page 7
Agenda
HSSP Overview
• Background
• What is HSSP?
• Deliverables and Status
• Roadmap and Reference Architecture
• Methodology
• Technical Specification - RFP Process and submissions
• Value Proposition and Getting Engaged
• Questions / Discussion
Page 8
What is HSSP?
• The Healthcare Services Specification Project (HSSP) is a
joint venture between Health Level 7 (HL7) and The Object
Management Group (OMG).
• HSSP relies on HL7’s national and international domain
expertise and world-class information models to provide
Functional requirements and specifications
• OMG brings the technology industry to the table by issuing
a Request for Proposal (RFP). Submitting organizations
create the Technical Specification
• HSSP is young – it has been around for around 2 years or
so, and is growing
Page 9
What is HSSP?
• An effort to create common service interface specifications for
Healthcare IT
• Its objectives are:
– To create useful, usable healthcare standard services that address
functions, semantics and technologies
– To provide a framework for tying the specifications together into a
coherent overall Service Oriented Architecture
– To complement existing work and leverage existing standards where
possible
– To focus on practical needs and not perfection
– To capitalize on industry talent through open community participation
• Participation (past and current) from many organizations, including:
VA, DoD, NCI, HL7 Finland/SerAPI, HL7 Australia, Ocean
Informatics, Kaiser Permanente, CSW (UK), Intel, IBM, Oracle,
Software Partners, Northrop Grumman, Initiate Systems, many
others
Page 10
The HSSP Process
Service Functional
Model
OMG
HL7 DSTU
ANSI Standard
RFP
Responders
OMG RFP
OMG HDTF
HL7 SOA SIG
HL7
Technical
Specification
Page 11
Agenda
HSSP Overview
• Background
• What is HSSP
• Deliverables and Status
• Roadmap and Reference Architecture
• Methodology
• Technical Specification - RFP Process and submissions
• Value Proposition and Getting Engaged
• Questions / Discussion: (Open)
Page 12
What has HSSP delivered to date?
• Functional Specifications - HL7 DSTUs:
– Decision Support Service (DSS) receives patient data as the input and returns
patient-specific conclusions as the output
– Retrieve, Location, and Update Service (RLUS) provides a set of interfaces
for accessing and managing health information
– 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
– Initial Submissions received for RLUS and EIS and LOIs from four
organizations for DSS
• A Service Specification Framework (methodology) for developing the
service specifications
• An informative HL7 ballot document on Messaging-to-SOA Transition
Methodology (SOA4HL7)
Page 13
Current Service Specifications
Page 14
Other Current HSSP Activities
• Reference Architecture
- Taxonomies
- Business Rules
- Choreographies
- Service Meta-model
- Implementation guide
• Profiles
• Methodologies
• Template Registry
• Evangelizing SOA within
the Healthcare community
• Technical Specifications
(EIS, RLUS, DSS)
Page 15
Agenda
HSSP Overview
• Background
• What is HSSP
• Deliverables and Status
• Roadmap and Reference Architecture
• Methodology
• Technical Specification - RFP Process and submissions
• Value Proposition and Getting Engaged
• Questions / Discussion: (Open)
Page 16
Roadmap and Reference Architecture
Roadmap: High level summary of HSSP Services work and
direction – v1.0 complete and published on HSSP Wiki.
Reference Architecture: Detailed framework relating
services wihin an overall Service Oriented Architecture
(work in progress). Includes:
–
–
–
–
–
–
SOA Principles
SOA Reference Model
Service Taxonomy
Service Portfolio
Governance
Methodologies
Also, other important components are:
– Profile and Template / Static Model Registries
– Tooling Support
Page 17
Services Taxonomy (example)
HSSP Service Taxonomy
Layer
Infrastructure
Business
Information
Infrastructure Information:
(e.g. RLUS Update Security
Key Service)
Business Information:
(e.g. RLUS Retrieve CCD Service)
Functional
Infrastructure Functional: (e.g.
Choreography Engine, Logging)
Business Functional:
(e.g. Lab Order Management Service)
Focus
SOA
Business
Functional
Infrastructure
Functional
Business
Information
Infrastrucutre
Information
Business
Process
Page 18
Service Portfolio (example)
Page 19
Services
Metamodel
Page 20
Service Profiles
• Service definition defines consistent overall functionality
based on business requirements
• Profiles provide means to specialize and test
conformance (for function and information)
Business
Drivers
Functional
Profile
Realizes
Business
Service
Service Instance
(e.g. EIS)
Semantic
Profile
Realizes
Service Instance
(e.g. EIS)
Semantic Signifiers
Page 21
Principles and Policies:
The foundation of SOA Governance
Business Principles /
Objectives
SOA
Principles
Governance
HSSP
IT Principles
Methodology
and Standards
Policies
Conformance?
IT Architecture (SOA,
Service Interfaces)
Service Instances
Page 22
Service Design - The Semantic Spectrum
Information
Function
• Why does this matter?
•Affect the way that your governance model will work
•Affect the way you will structure your services
•Affect how you will (or won’t) maintain architectural integrity
•Development and Design
•Reusability
•Contracts
•QoS
•Not necessarily good or bad …. Just different
Page 23
Spectrum of Semantics (Function and Information)
Operation Signature
Potential Interface
Notes
Ack:Do(message message)
MessageHandler
Behavior is enclosed in the message and is not expressed in the
operation
2 HTTP GET, PUT
REST style
Information is explicit in the object through early binding,
while the functionality is fixed
3
Stuff: Retrieve (stuffTraits traits)
RLUS (without a
profile)
Functionally simplistic, but bound to variable Information.
Business semantics are not explicit
4
Order:Retrieve (orderTraits traits)
RLUS with an Order
Management Profile
Functionally simplistic, but reasonably mapped to business
semantics because of the constrained information semantics
and a manageable DAM
5 LabOrder:Retrieve(labOrderTraits
traits)
RLUS with a
LabOrderManagement
Profile
As above with more tightly constrained information semantics,
as well as a more constrained DAM
6
Ack:CreateLabOrder(order order)
Order:LabOrderNotification()
Lab Order
Management Service
A constrained and functionally complete DAM, neatly mapped
to both information and functional semanitcs
7
Ack:ChangeAge(person person,
age age)
Demographic Service
Functional semantics are reasonably explicit, information
supports functionality implicitly. Classic OOD
8 Ack:ChangeKenAge(age age)
Demographic Service
Functional semantics are very explicit, information supports
functionality implicitly. Classic OOP without any design or
reuse. Inappropriate functional granularity.
9
Demographic Service
Functional semantics encompass informational semantics. Zero
reusability. Silly.
1
Ack:ChangeKenAgeTo25()
Page 24
Agenda
HSSP Overview
• Background
• What is HSSP
• Deliverables and Status
• Roadmap and Reference Architecture
• Methodology
• Technical Specification - RFP Process and submissions
• Value Proposition and Getting Engaged
• Questions / Discussion: (Open)
Page 25
HSSP Methodology Work
SSF
– HSSP Process for producing Service Specifications. Covers both
Functional (HL7) and Technical (OMG) processes
SOA4HL7
– Interim methodology (Balloted HL7 Informative document) for
producing Service definitions in advance of Standards being
availabe
Dynamic Model
– Ongoing work with other HL7 committees (InM, MnM, ITS SIG) on
new approaches to dynamic modeling
Interoperability Paradigms
– Part of the Dynamic Model work to consider similarities and
differences between Services, Messaging and Document based
methodologies and looking for commonality where possible.
Page 26
Towards an HL7 Design Methodology
Services
Orchestration, Choreography,
and Interaction Patterns
Contents: Domain
& Document Models
Interoperability Paradigm
Trading Partner
Agreements: Binding
Services and Content
Models
Made by HL7, IHE, Realms, Projects
Messaging: Binding the Services
and Contents to a transportation
Platform (HL7 Wrappers & ATS)
Page 27
Agenda
HSSP Overview
• Background
• What is HSSP?
• Deliverables and Status
• Roadmap and Reference Architecture
• Methodology
• Technical Specification - RFP Process and submissions
• Value Proposition and Getting Engaged
• Questions / Discussion: (Open)
Page 28
Technical Specifications and RFPs
• Coordinated by OMG Healthcare Domain Task Force
(DTF)
• HL7 SFM used as basis for Request for Proposal (RFP)
– Request for specification of a platform-independent model (PIM)
and at least one platform-specific model (PSM) (e.g. SOAP/XML)
conforming to SFM requirements
• Letters of intent to specify and implement within 12 mo. 
initial specifications  single revised specification based
on merged efforts
• Approval by Healthcare DTF  Architectural Board 
Technology Committee  Board of Directors
• Specification not adopted unless at least one
implementation available commercially
Page 29
OMG Technology Adoption Process
• Any interested vendor with OMG membership may submit
• No submissions pass on initial submission
• Vendors choose to partner to form joint submissions 95% of the
time
• All OMG standards are reviewed by OMG Architecture Board
• The speed of the adoption is driven by marketplace pressure, not
the process
• The standards committee may either accept or reject
submissions – nothing more
• The approach assures business relevance and promotes rapid
timelines and quality
• The OMG Standard is published when software is available
Page 30
Feedback loop to HL7
• DSTU is ideally suited to this process
– Allows two years for “practical experience”
– OMG Technology adoptions are typically 18
months
• Throughout the process we will collect ‘lessons
learned’
• Outcomes of the technology adoption will be
incorporated and balloted into the SFM
Page 31
Current RFP Progress
EIS
– Submission Team: Intel, Software Partners, Ocean Informatics, Initiate, NG,
Satyam (also Oracle, Care Data).
– Initial submission discussed in Jacksonville in September. Working on
revised submission, including profiles for V3, V2 and OpenEHR.
RLUS
– Submission Team: Intel, Software Partners, Ocean Informatics, NG,
Satyam (also Oracle).
– Initial submission discussed in Jacksonville in September. Working on
revised submission, including profiles for V3, V2 and OpenEHR
DSS
– Submission Team (forming): Software Partners, Religent, 88Solutions (also
EDS, CDC, MHS)
– Work just starting on technical specification.
– Discussions with IHE progressing
Page 32
Agenda
HSSP Overview
• Background
• What is HSSP
• Deliverables and Status
• Roadmap and Reference Architecture
• Methodology
• Technical Specification - RFP Process and submissions
• Value Proposition and Getting Engaged
• Questions / Discussion: (Open)
Page 33
Value for Kaiser Permanente
• Integration is very expensive, mainly COTS vendor
packages (HL7 for clinical, also X.12, DICOM, others)
mainly batch or messaging, and changes slow and
difficult
• Turned to SOA to address this problem, however no
standard service interfaces, and each vendors services
very variable, semantically and technically. Good
lessons learned from messaging standards not being
applied to Services
• Part of initial HSSP kick-off and have been promoting
the development of Service standards ever since.
Return is long term but perceived to be very significant
• Apply pressure on software vendors to produce
standard interfaces
Page 34
More value …
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 35
Why participate?
• This effort is focused on and driven by business-need
– It is not an “academic exercise” striving for perfection
– For standards to be useful they must be used
– Focused on the practical and achievable
– Based upon business value and ROI
• Being run like a “project” and not a committee
• Recognize participation as an investment and not an expense
• 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
• Establish market presence and mindshare as industry leader
• This is happening—the only way to influence the outcome is to
engage
Page 36
How do I Participate?
• Determine areas of interest and priorities
– Involvement in current specification work?
– New Profiles for existing services (any time) ?
– Propose New Service needs (any time) ?
– Reference Architecture?
• Allocate resources to actively engage in the project
– Engage knowledgeable resources in the areas they are working already
in day job
– Involve the staff that can best address your business needs
– Organizations that commit resources garner more influence and more
mindshare
– Your business interests are being represented by your attendees
Page 37
2008 HSSP Schedule (planned, major milestones)
Jan:
SFM Ballots (CRFQ, Security)
Jul:
Publish Reference Architecture v1?
HL7 San Antonio (Jan 13-18)
Feb:
Mar:
Aug:
OMG Washington (Mar 10-14)
Sep:
EIS, RLUS RFP Final submissions
DSS RFP Initial Submission
HL7 Vancouver (Sep 14-19)
OMG Orlando (Sep 22-26)
Apr:
SOA in Healthcare conference
(Chicago) Organized by HSSP
Oct:
May:
HL7 Phoenix (May 4-9)
(possible CTS II, Provider/Services
Directory SFM Ballots)
Nov:
Jun:
OMG Ontario (CA) (Jun 23-27)
Dec:
OMG Santa Clara (Dec 8-12)
EIS, RLUS RFP Finalization?
Page 38
References
• HL7 Website:
• http://www.hl7.org
• OMG Website:
• http://www.omg.org
• Services Project Homepage
• http://www.healthinterop.org
QUESTIONS ?
Page 39