Upload
stanley-walton
View
214
Download
0
Embed Size (px)
Citation preview
04/20/23 05:00
The Healthcare Services Specification ProjectAn Overview
The Healthcare Services Specification ProjectAn Overview
May 2006HL7 NZ SOA-Web Services SeminarMay 2006HL7 NZ SOA-Web Services Seminar
Ken RubinEDS
Co-Chair, OMG Healthcare Domain Task Force
Co-Chair, HL7 Services-oriented Architecture [email protected]
Ken RubinEDS
Co-Chair, OMG Healthcare Domain Task Force
Co-Chair, HL7 Services-oriented Architecture [email protected]
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 2
OverviewOverview
• Background / Rationale behind HSSP
• HSSP Objectives
• The Impetus for Collaboration
• OMG, HL7, and Operational Concerns
• Project Artifacts
• Dialog: The Value of Participating
• Current Status/Update
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 3
““How do you know that the [web-] How do you know that the [web-] services you’re building are not just services you’re building are not just the next generation of stovepipes?”the next generation of stovepipes?”
Janet Martino, LTC, USAF (Retired) to a panel of Healthcare IT Janet Martino, LTC, USAF (Retired) to a panel of Healthcare IT LeadersLeaders
““How do you know that the [web-] How do you know that the [web-] services you’re building are not just services you’re building are not just the next generation of stovepipes?”the next generation of stovepipes?”
Janet Martino, LTC, USAF (Retired) to a panel of Healthcare IT Janet Martino, LTC, USAF (Retired) to a panel of Healthcare IT LeadersLeaders
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 4
Why HSSP Was Created Why HSSP Was Created
• Several large provider organizations were each facing challenges in integrating current and emerging systems
– Veterans Health Administration
– Kaiser-Permanente
– SerAPI Project (Finland)
• There were a number of shared beliefs among the founding partners…
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 5
In each case…In each case…
• There was active integration and development work
• There was a shared belief that messaging alone was not the optimal solution
• A services-oriented architecture was the target environment
• There was strong commitment to standards
• There was recognition standard services would further interoperability with partners and products
• It was recognized that developing “stovepipe” services would not address business challenges
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 6
So, what is HSSP?So, what is HSSP?
• The “Healthcare Services Specification Project”
• Effort to create practical healthcare IT service specifications that address both behavior and information semantics
• A joint sponsored activity by HL7 and OMG
• Current focus activities
– Define a “Roadmap” for Services in Healthcare
– Entity Identification Service (EIS)
– Retreive, Locate, and Update Service (RLUS)
– Common Terminology Service (CTS)
– Decision Support Service (DSS)
– Migration guidance for Web Services in HL7 (SOA4HL7)
– Produce a methodology
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 7
Why “services” and not “messages”?*Why “services” and not “messages”?*
• Accepted industry best practice
– A common practice in healthcare but not yet healthcare IT
– Commonplace usage across “IT” outside of healthcare
– Many key products use them but do not expose interfaces
• Services define behavior explicitly and data transport implicitly
– Ensures functional consistency across applications
– Furthers authoritative sources of data
– Minimizes duplication across applications, reuse
• Services do not preclude the use of messages
– Services rely upon underlying transport protocols
– Messages can be used as payloads for service calls
– Messaging infrastructure may be used as underlying transport
*slide adapted from a Veterans Health Administration Presentation, used with permission
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 8
So, what about web services?So, what about web services?
• Web services alone (e.g., SOAP/WSDL, etc) do not solve the problem:
– What behaviours do we expect of an MPI?
– What behaviours are not expected or should remain unspecified?
– What confidence do we have that two MPIs can interoperate in an SOA intra- or inter-organization?
– What about information semantics?
– How will business exceptions be managed across instances?
• These issues are not addressed via selection of SOAP/WSDL as a platform
• These issues are not entirely addressed via Web Services as an ITS
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 9
Significant Healthcare Standards Development Organizations (SDOs)Significant Healthcare Standards Development Organizations (SDOs)
• HL7
• X.12
• NCPDP
• ASTM
• OMG
• DICOM
• SNOMED
• ICD
• LOINC
• IHE
• CEN TC 251
• ISO TC 215
“Functional” StandardsStructured Doc Standards
Terminology StandardsMessaging Standards
Services StandardsStandards Profiling
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 10
HSSP Builds Upon Existing WorkHSSP Builds Upon Existing Work
Ab
ilit
y to
Int
erop
erat
e
High
Low
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 11
Overview of Key HSSP ArtefactsOverview of Key HSSP Artefacts
• Service Development Framework (SDF)
– Methodology describing the services specification process
– Integrates life cycle across HL7 and OMG with callouts to existing processes (such as ballots)
– Version 1.0 Baselined in January 2006 (HL7 Phoenix)
• Service Functional Model (SFM)
– Describes in business terms the behaviour of the service
– Identifies relevant information content (e.g., RIM-derived artefacts, terminologies, etc.)
– Technology independent
– Includes conformance profiles
• RFPs
• Submissions
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 12
Current HSSP Priority Areas Current HSSP Priority Areas
Area Scope and Rationale for PriorityTerminology Services To develop a comprehensive terminology specification
(versioning, maintenance, query, etc.) built upon the current CTS specification.
Selected based upon past precedence, ongoing work interest, and ability to validate the emerging methodology.
Entity Identification To manage and maintain identities within and across domains, localities, or products.
Anticipated to be critical path dependency for other services; foundational work was available from HL7 and OMG.
Record Location and Retrieval
To discover, retrieve, and update records in distributed environments.
Seen as core foundational service to support EHR and healthcare delivery with interest from many national and regional programmes. Location & Retrieval merged upon recognition that location was effective retrieval of metadata.
Decision Support To assess data (such as patient data) and returns specific conclusions as the output.
Seen as a way to significantly reduce effort required and to promote wider adoption of CDSS implementations. Selected based upon strong business need and interests and additional volunteer community.
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 13
How the priorities were determined… How the priorities were determined…
• Based on an open selection process
• Brainstorming gave way to successive refinement and downselect
• Priorities determined by business need and resources
• Initial list included Terminology, Entity ID, Record Location, Record Retrieval
• Record Location and Retrieval activities subsequently merged
• Decision Support added later based upon community interest and resources
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 14
HL7, OMG, and the CollaborationHL7, OMG, and the CollaborationHL7, OMG, and the CollaborationHL7, OMG, and the Collaboration
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 15
What is HL7? What is HL7?
* Slide content courtesy of HL7, used with permission
Health Level Seven (HL7) is an ANSI accredited standards organization (ASO), working in areas of:
• Electronic Data Exchange • Healthcare Messaging
• Arden Syntax• Visual / Context Integration (CCOW)• Clinical Document Architecture (CDA)• Electronic Health Record System (EHRS)
Functional Model• Service-oriented Architecture
Members include providers, vendors and consultants, government & others. There are also now 30+ international affiliates.
ISO’s Open Systems Interconnect (OSI) model:Application Level” – level 7
ISO’s Open Systems Interconnect (OSI) model:Application Level” – level 7
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 16
What is OMG?* What is OMG?*
• The Object Management Group--a 15-year-old not-for-profit Computer Industry Standards Consortium
• Home of UML, the Industry’s Modeling Standard and the Model Driven Architecture (MDA)
• Open Membership and Adoption Process
– One-member, One-vote
• Specifications Available Free on our Website
• Vendors using OMG specifications may or may not be OMG members
• Over 500 members including Companies, Government Agencies, Universities
* Slide content courtesy of OMG, used with permission
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 17
Collaboration Rationale – Initial Thoughts…Collaboration Rationale – Initial Thoughts…
• HL7 has a world-class functional community
• …but HL7’s strength is not service architecture
• HSSP project needed to leverage talent of a strong architectural community
• OMG has history and demonstrated leadership in service definition and SOA
• OMG provided the ability to interact with multiple vertical domains (pharma, manufacturing, etc.)
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 18
The Result… The Result…
• HL7 brings…
– Healthcare semantic interoperability expertise and credibility
– 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
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 19
The Opportunity Created... The Opportunity Created...
• HSSP is open to any type of participant:
– National, Federal, State, Local Governments
– Payers, Providers, Consultants
– Individual stakeholders
• The process facilitates each party participating to their maximum advantage
– Discussions are “community of interest” focused
• Healthcare discussions in healthcare venue
• Technical discussions in technical venues
• Processes and results are open and available
– All proceedings are published on web and listserv
– Consistent multinational/multicultural participation
• “Guiding Principles” ensure we don’t lose sight of our objectives
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 20
Project Operational ConcernsProject Operational ConcernsProject Operational ConcernsProject Operational Concerns
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 21
The ApproachThe Approach
• HL7 is leading in service selection, functional elaboration, and conformance criteria
• OMG is leading the technical specification
• Both organizations jointly participating in all activities
• Work products are “owned” by only one organization but used collaboratively (e.g., any product is “hosted” by HL7 or OMG)
• “Operate as one project” is a core principle
• Actively seeking vendor participation
• Eclipse has committed to providing open source implementations
• IHE discussions are underway to profile and demonstrate viability of the implemented solutions
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 22
Project OrganisationProject Organisation
• One overarching project with five subproject efforts
• Overall project
– Meets at HL7 and OMG meetings
– Status teleconferences biweekly
– Owns responsibility for planning, marketing, etc.
• “Infrastructure” Subgroup
– Developed and maintains methodology
• Subprojects
– Determine their own deadlines, meeting schedules, etc.
– May be hosted by other committees
– Leverage project infrastructure and methodology
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 23
Timeline of Key EventsTimeline of Key Events
1996: First OMG Healthcare Service Spec Adopted (PIDS?)
2003: HL7 ServicesBOF formed
2004 September: HL7, OMG Collaboration MOU
2005 January: Joint Project Chartered
2005 April: Project Kickoff
2006 March: Issue Ballot for Functional Specs
2006 Q4: Technical Specs RFP (planned)
2005 September: Methodology and MetaSpecs Baselined (planned)
2005 October: Interoperability Services Workshop & Conference
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 24
2006 HSSP Project Schedule (major milestones)2006 HSSP Project Schedule (major milestones)
Jan: Charter HL7 SOA SIG
HL7UK Information Day
Jul: Issue 4 ballots (3 + 1)
Feb: Announce intention to ballot RLUS
Aug: Ballot review
Mar: Issue RLUS Ballot Sep: HL7 Boca Raton (Reconciliation);
RLUS DSTU Adopted!
OMG Anaheim (Issue RFPs)
Apr: OMG Meeting St. Louis
(RLUS RFP prep)
Oct: Intent to ballot DSS, EIS, CTS2
May: HL7 San Antonio
(RLUS ballot reconciliation)
Nov: HL7 Educational Summit Issue DSS, CTS2 Ballots
Jun: Announce intention to ballot
(3 committee, 1 membership)
Dec: OMG Washington
(Review Initial RFP Submissions)
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 25
HSSP Project DifferentiatorsHSSP Project Differentiators
• 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
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 26
HSSP In the “Community”HSSP In the “Community”
• HSSP is actively seeking to collaborate with other groups
• HSSP specs have a section citing existing work and its relevance
• Working project relationships with:
– HL7 Clinical Decision Support Technical Committee
– HL7 Vocabulary Committee
– Object Management Group Service-oriented Architecture SIG
– Eclipse Open Healthcare Framework Initiative
• Emerging relationships with:
– Integrating the Healthcare Enterprise (IHE)
– Medical Banking Initiative
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 27
Where should I engage?Where should I engage?
Interest Area (including representative communities-of-interest)
Venue
Setting functional priorities; selecting priority services
(Consumers, Providers, Vendors, Integrators)
HL7
Defining behaviour; service capabilities
(Consumers, Providers, Vendors)
HL7
Defining functional conformance/compliance criteria
(Consumers, Regulatory)
HL7
Technical specification, interface specification, evaluation criteria
(Consumers, Regulatory, Integrators)
OMG
Technical conformance/compliance criteria
(Consumers, Regulatory, Integrators)
OMG
Architectural considerations; service interdependencies, SOA
(Integrators, Vendors, Implementers)
OMG
Product development; technical standard creation; API definition
(Vendors, Implementors)
OMG
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 28
Dialogue: The Value of ParticipatingDialogue: The Value of ParticipatingDialogue: The Value of ParticipatingDialogue: The Value of Participating
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 29
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
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 30
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
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 31
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
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 32
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
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 33
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
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 34
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
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 35
The Bottom Line…The Bottom Line…The Bottom Line…The Bottom Line…
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 36
Why participate in Standards? Why participate in Standards?
• This is happening—the only way to influence the outcome is to engage
• 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
• Significant networking opportunities
• Establish/maintain market presence as thought-leader
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 37
Why HSSP? Why HSSP?
• Relentless focus on added business value for healthcare and project participants
– focused on and driven by business-need
– not an “academic exercise” striving for perfection
– “Standards must be used to be useful”
– Emphasis on practical, achievable, & marketplace-relevant
• Without these standards, we’re building “service stovepipes”
• Aggressive timelines encourage progress
• Assembled community of top industry talent
• Project structure promotes targeted participation
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 38
ReferencesReferences
• HSSP Wiki
• http://hssp.wikispaces.com
• HL7 Website:
• http://www.hl7.org
• OMG Website:
• http://www.omg.org
© 2006 HSSP Project, http://hssp.wikispaces.com
Reuse with attribution permitted Page 39
Thank you!Thank you!
Ken Rubin, EDS
+1 703 845 3277 desk
+1 301 335 0534 mobile