9/5/2015 4:24 AM Healthcare Services Specification Project An Overview of HSSP January 2006 Ken Rubin EDS Co-Chair, OMG Healthcare Domain Task Force Co-Chair, HL7 Services-oriented Architecture SIG Ken Rubin EDS Co-Chair, OMG Healthcare Domain Task Force Co-Chair, HL7 Services-oriented Architecture SIG

Page 2 Organization of Today’s Program Present background and rationale behind HSSP Discuss and differentiate –“messages” from “services”; discussion about behavior –“HSSP Services” from “web services” OMG, HL7, and the Collaboration Project Operational Concerns Project Artifacts Dialog: The Value of Participating

Page 3 Organisation of Today’s Programme Present background and rationale behind HSSP Discuss and differentiate –“messages” from “services”; discussion about behaviour –“HSSP Services” from “web services” OMG, HL7, and the Collaboration Project Operational Concerns Project Artefacts Dialogue: The Value of Participating Yes! The American is capable of communicating in English ;-) Okay, enough humour…

Page 4 Project context: Why was HSSP created? Several large provider organizations were each facing challenges in integrating current and emerging systems –US Veterans Health Administration –Kaiser-Permanente –SerAPI Project Finland There were a number of shared beliefs among the founding partners…

Page 5 Project context: Why was HSSP created? (2) 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 –It was recognized that developing “stovepipe” services would not address business challenges –There was strong commitment to standards –There was recognition standard services would further interoperability with partners and products

Page 6 So, what is HSSP? An project to create common “service interface specification” standards that are tractable within healthcare IT A joint initiative co-sponsored by 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 the best industry talent through open community participation and maximizing each community for its strengths

Page 7 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

Page 8 Current HSSP Priority Areas AreaScope and Rationale for Priority Terminology ServicesTo 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 IdentificationTo 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 SupportTo 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.

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

Page 10 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

Page 11 OMG, HL7, and the Collaboration

Page 12 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.)

Page 13 Risks/Concerns with the OMG Prior negative history with HL7 Not a significant number of mainstream healthcare vendors were members Prior CORBAmed (health domain) work was largely irrelevant in the healthcare marketplace Drastically different membership and intellectual property models ( compared to HL7 ) Potential for added complexity by involving additional organizational dependency

Page 14 Attractions about the OMG Free availability of their standards promotes adoption Standards adoption mandates (commercially) available implementations – no shelfware standards Proven success at getting competing vendors to work together productively Rapid adoption model: 18 months from concept to standard with supporting implementations is common Business driven standards. Vendors write the standard so the results are implementable. Not academic. Ultimately only submitters influence the standard and the community owns issuance and acceptance of submissions Methodology embraces multi-platform standards specifications

Page 15 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 16 The Opportunity Ability to leverage talent from two distinctly different communities The whole could be greater than the sum of the parts –Allows the healthcare community to lead functionally –Allows the architectural/technology community to lead technically –Integrated process to produce more usable, business-relevant, timely products Process could promote usable, non-shelfware standards Promoted availability of commercial implementations/marketplace relevance Furthered multi-platform support/solutions

Page 17 The 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

Page 18 Project Operational Concerns

Page 19 Project 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

Page 20 Timeline 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

Page HSSP Project Schedule (major milestones) Jan: Charter HL7 SOA SIG HL7UK Information Day Jul: HL7 Educational Summit Issue 4 ballots (2 + 2) Feb: Announce intention to ballot Aug: Ballot review Mar: Issue ballots for EIS, RLUS Out of Cycle meeting (tentative) Sep: HL7 Boca Raton (Reconciliation); EIS, RLUS DSTU’s Adopted! OMG Anaheim (Issue RFPs) Apr: OMG Meeting St. Louis (RFP prep) Oct: Intent to ballot DSS May: HL7 San Antonio (ballot reconciliation) Nov: Issue DSS, CTS2 Ballots Jun: Announce intention to ballot (2 committee, 2 membership) OMG Boston (Issue Draft RFPs) Dec: OMG Washington (Review Initial RFP Submissions)

Page 22 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

Page 23 Project Artefacts

Page 24 HSSP Builds Upon Existing Work Ability to Interoperate High Low

Page 25 Overview 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

Page 26 The SFM and Leveraged HL7 Content The SFM: –identifies relevant semantics (including HL7 RIM-derived content, terminologies, constraints, etc) Note: HSSP does not expect to be adding RIM content. When shortcomings exist, the work will be directed to the appropriate existing HL7 Committees. –includes a section to cite existing external work and explain its relevance –has a traceability matrix to the EHR Functional Model and Standard –expressed behaviours are intended to be explicit representations considering HL7 Application Roles, Interactions, etc. –conformance profiles are one mechanism of addressing localization concerns and implementation variations

Page 27 Dialogue: The Value of Participating

Page 28 Why Participate in 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 –Acknowledgement that 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

Page 29 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

Page 30 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

Page 31 References HL7 Website: OMG Website: Services Project Homepage

Page 32 Thank you! Ken Rubin EDS desk mobile

Page 33 Supplemental Slides

Page 34 For Product Consumers and Users… The Impacts and Rationale of HSSP Specifications ImpactsRationale 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 offeringsConsumer demand will create increased marketplace competition Facilitates integrationUnity in purpose and consistency in interface eases integration burden Time to marketAvailability 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 Product Vendor … The Impacts and Rationale of HSSP Specifications ImpactsRationale 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 3 rd 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 36 Regulatory/Policy/Legislative … The Impacts and Rationale of HSSP Specifications ImpactsRationale 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 37 Research … The Impacts and Rationale of HSSP Specifications ImpactsRationale 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 38 Implementer/Integrator … The Impacts and Rationale of HSSP Specifications ImpactsRationale 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 39 SDOs … The Impacts and Rationale of HSSP Specifications ImpactsRationale Useable standardsEmphasis 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