healthcare services specification project the business case for healthcare soa standards
Post on 12-Jan-2016
31 Views
Preview:
DESCRIPTION
TRANSCRIPT
04/21/23 04:06
Healthcare Services Specification Project The Business Case for Healthcare SOA Standards
Healthcare Services Specification Project The Business Case for Healthcare SOA Standards
HL7 Service-Oriented Architecture SIG
OMG Healthcare Domain Task Force
Open Health Tools
HL7 Service-Oriented Architecture SIG
OMG Healthcare Domain Task Force
Open Health Tools
March 2008March 2008
Page 2
AcknowledgementsAcknowledgements
• Contributions 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
What is the Healthcare Service Specification Project? What is the Healthcare Service Specification Project?
• A joint standards development activity occurring in multiple organizations, including Health Level 7 (HL7), the Object Management Group (OMG), Open Health Tools, IHE, 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 existing standards
– To focus on practical needs and not perfection
– To capitalize on industry talent through open community participation
04/21/23 04:06
PolicyBusiness
Drivers
InformationModels
Service Functional
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 5
HSSP is part of the bigger health IT landscape…HSSP is part of the bigger health IT landscape…
HSSP
HL7 Domain Committees
OMG
HITSP
National Programs (e.g. ONC, NEHTA)
CEN
OpenEHR
OHT
IHE
Methodology (SSF),DSTU Feedback,
Consultative support
SFMs, Info Models,
Requirements,Service Profiles
Policy
Service Profiles
Methodology,HL7/SOA Harmonization
SOA Interoperability Specifications
Use Cases,Requirements
TechnicalSpecifications,RFP process
Use Cases,Candidate Standards
Info Models,Semantic Profiles
SOA Interop Specs
RFPRequirements
Integration Profiles,Conformance Testing,
Interoperability Validation
TechnicalSpecifications
Open SourceRef Implementations,
Tools
SOA Interoperability Specifications,
Use Profiles
Page 6
What type of products do you produce? What type of products do you produce?
• SOA Functional Standards [Service Functional Models]
– CTS II - Terminology Maintenance/Navigation
– CRFQ – Clinical Research Filtered Query
– PASS – Privacy, Access, and Security Services
– HSD – Human Services Directories
• Technical Specifications for balloted Functional Standards
– EIS - Entity Identification Service (such as MPI)
– RLUS - Retrieve/Locate/Update Service
– DSS - Decision Support Service
• Implementation Guidance & White Papers
– Practitioners Guide to SOA in Health Care
– Implementation Guides
Page 7
2008 HSSP Project Schedule (planned, major milestones)2008 HSSP Project Schedule (planned, major milestones)
Jan: SFM Ballots (CRFQ, Security)
HL7 San Antonio (Jan 13-18)
Jul: Publish SOA Practitioners Guide
Feb: Aug:
Mar: OMG Washington (Mar 10-14) Sep: HL7 Vancouver (Sep 14-19)
OMG Orlando (Sep 22-26)
CTS II SFM Ballot (HL7)
HSD SFM Ballot (HL7)
Apr: SOA in Healthcare Workshop (Chicago) Organized by HSSP
Oct:
May: HL7 Phoenix (May 4-9) Nov:
Jun: OMG Ontario (CA) (Jun 23-27)EIS, RLUS RFP Final submissions DSS RFP Initial Submission
Dec: OMG Santa Clara (Dec 8-12)
Issue CTS II RFP
Issue HSD RFP
Page 8
Where would these specifications be usedWhere 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-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 9
Core Project PrinciplesCore Project Principles
• Leverage each community to its strength
• 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
• Recognize that participation is an investment
Page 10
OMG
HL7
The HSSP ProcessThe HSSP Process
HL7 DSTU
Service Functional Model
OMG RFP
Technical Specification
ANSI Standard
Page 11
SFM
Understanding HSSP Artifacts, Roles, AttributesUnderstanding 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
Complies with a “conformance
profile”
Audience are consumers of the
system or service
Page 12
How are HSSP services expressed? 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
Why “services”?*Why “services”?*
• 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, provides reuse
• Messages can be either payloads in or infrastructure beneath services
• Service-oriented architecture provides the framework for automation of common services
*slide adapted from a Veterans Health Administration Presentation, used with permission
Page 14
Context of HSSP SpecificationsContext of HSSP Specifications
Ab
ilit
y to
Int
erop
erat
e
High
Low
Page 15
Two Dimensions of InteroperabilityTwo Dimensions of Interoperability
Sem
antics
Behavioral
UDDI v3
Web Services
Java RMI
HSSP RLUS (Profiled)
OWL-S
CORBA
Ideal Target
HSSP Reference Arch
HSSP EIS
• 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?
From the RM-ODP Informational Viewpoint
HSSP RLUS
HL7 Messaging
Page 16
SOA ≠ Web ServicesSOA ≠ 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 17
The Value of HSSP …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 18
How is this project “different”? 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, 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 19
Why should I participate in HSSP? Why should I participate in HSSP?
• This effort is focused on and driven by business-need
– It is not an “academic exercise” striving for perfection
– Standards must be used to be useful
– Focused on the practical and achievable
– Short timelines
– Based upon business value and ROI
• Leveraging talent from multiple communities
• Being run like a “project” and not a committee
• We recognize that participation is an investment and not an expense
Page 20
Why participate in standards at all? 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 21
How do I Participate?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 work
– OMG for technical specification work
• 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 22
Who should I involve?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 23
ReferencesReferences
All HSSP artifacts and work in process are open. Visit us at:
• http://hssp.healthinterop.org
Page 24
Supplemental Slides: Supplemental Slides: HSSP Stakeholder Benefits and ImpactsHSSP Stakeholder Benefits and ImpactsSupplemental Slides: Supplemental Slides: HSSP Stakeholder Benefits and ImpactsHSSP Stakeholder Benefits and Impacts
Page 25
What Participants are Saying… 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
Page 26
For Product Consumers and Users…The Impacts and Rationale of HSSP SpecificationsFor 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 27
Product Vendor …The Impacts and Rationale of HSSP SpecificationsProduct 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
Page 28
Regulatory/Policy/Legislative …The Impacts and Rationale of HSSP SpecificationsRegulatory/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
Page 29
Research …The Impacts and Rationale of HSSP SpecificationsResearch …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
Page 30
Implementer/Integrator …The Impacts and Rationale of HSSP SpecificationsImplementer/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 31
SDOs …The Impacts and Rationale of HSSP SpecificationsSDOs …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 32
Composition of Profiles - ExampleComposition of Profiles - Example
Conformance Profile- Name- Version- Date- etc
Functional Profile- Name- Version- Capability 1- Capability 2- Capability N….
Semantic Profile- Information Model ID- Version- Source- etc
Entity Identification ServicePatient Cross Reference ProfileVersion: 1.0Date: 10/22/2007Description: …………..
Entity Cross-ReferenceVersion 1.0- Link Entity- Unlink Entity- List Linked Entities
HL7 RIM V2.14 Patient- HL7 RIM- V2.14- Model: Set of traits taken from
Patient Billing Account RMIM (FIAB_DM000000UV01).
(EIS SFM included sample model)
top related