1. 9/4/2015 3:10 AM The Healthcare Services Specification Project An Overview June 2006 - Europacs 2006 preconference workshop Most of the slides by Ken Rubin, EDS ken.rubin@eds.com Presented by Jari Porrasmaa, jari.porrasmaa@uku.fi University of Kuopio, HIS R&D, SerAPI project The Association of Finnish Local and Regional Authorities, National eHealth project Co-Chair, HL7 Services-oriented Architecture SIG HL7 Finland TC member, MUG Finland vice member of the board Most of the slides by Ken Rubin, EDS ken.rubin@eds.com Presented by Jari Porrasmaa, jari.porrasmaa@uku.fi University of Kuopio, HIS R&D, SerAPI project The Association of Finnish Local and Regional Authorities, National eHealth project Co-Chair, HL7 Services-oriented Architecture SIG HL7 Finland TC member, MUG Finland vice member of the board

2. Page 2 © 2006 HSSP Project, http://hssp.wikispaces.com Reuse with attribution permitted Overview Background / Rationale behind HSSP HSSP Objectives Project deliverables OMG, HL7 and collaboration Current Status/Update - timelines Very briefly - how Finland is addressing continuity of care, regional and national implementations

3. Page 3 © 2006 HSSP Project, http://hssp.wikispaces.com Reuse with attribution permitted 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…

4. Page 4 © 2006 HSSP Project, http://hssp.wikispaces.com Reuse with attribution permitted 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

5. Page 5 © 2006 HSSP Project, http://hssp.wikispaces.com Reuse with attribution permitted 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 –4 service specifications (EIS, RLUS, CTS, DSS) –Guidance for Service Oriented Architectures and HL7 V3 messaging (SOA4HL7) –Produce a methodology

6. Page 6 © 2006 HSSP Project, http://hssp.wikispaces.com Reuse with attribution permitted Why “services” and not just “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

7. Page 7 © 2006 HSSP Project, http://hssp.wikispaces.com Reuse with attribution permitted 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

8. Page 8 © 2006 HSSP Project, http://hssp.wikispaces.com Reuse with attribution permitted Current HSSP Priority Areas AreaScope and Rationale for Priority Terminology Services CTS II 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 EIS 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 Update RLUS 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. Decision Support CDSS 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.

9. Page 9 © 2006 HSSP Project, http://hssp.wikispaces.com Reuse with attribution permitted SOA4HL7 Project under HL7 SOA SIG, close collaboration with InM committee, chartered in May 2006 WGM Purpose to maximize SOA benefits in a HL7 V3 oriented approach Work Products / Deliverables –Architecture Requirements and SOA Framework –Methodology - extensions to the HSSP SDF methodology for creating "interim" service definitions and implementations using HL7 V3 content –V3 Infrastructure Mapping - Define a mapping of current V3 artifacts to the SOA framework. Discuss & refine approach in September, some form of a ballot document January or May 2007

10. Page 10 © 2006 HSSP Project, http://hssp.wikispaces.com Reuse with attribution permitted HL7, OMG, and the Collaboration

11. Page 11 © 2006 HSSP Project, http://hssp.wikispaces.com Reuse with attribution permitted 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

12. Page 12 © 2006 HSSP Project, http://hssp.wikispaces.com Reuse with attribution permitted 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) XMI, CWM, BPM/BMI, Corba,... 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

13. Page 13 © 2006 HSSP Project, http://hssp.wikispaces.com Reuse with attribution permitted Collaboration and responsibilities 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

14. Page 14 © 2006 HSSP Project, http://hssp.wikispaces.com Reuse with attribution permitted 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

15. Page 15 © 2006 HSSP Project, http://hssp.wikispaces.com Reuse with attribution permitted 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)

16. Page 16 © 2006 HSSP Project, http://hssp.wikispaces.com Reuse with attribution permitted 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

17. Page 17 © 2006 HSSP Project, http://hssp.wikispaces.com Reuse with attribution permitted 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

18. Improving continuity of care in Finland, Clinical Document Architecture - CDA Regional information systems (early 2000) and the national eHealth program (2003-2007) both build upon the HL7 CDA standard CDA is a standard for expressing clinical documents CDA R1 (2000) –structured header, general document structures, very limited structure in clinical data content CDA R2 (2005) –header + document structure similar to R1, clinical statement pattern for structuring clinical content

19. Regional Information System Main purpose - all relevant information is available at point of care –seamless care chains –avoid reduntant tests etc. Reference database has metadata about encounters and episodes CDA R1 documents are generated dynamically upon requests Privacy: patient consent required - Specialized care- - Social care Regional information system Patient Primary care Private sector, etc... - - - reference database Different enterprise application Care provider (picture from the implementation guide for regional ISs v1.1.2, HL7 Finland)

20. Regional Information System - functionality and technology external systems Care provider, EPR + CISs + web access to regional system 1. 1.the references, CDA headers (+HL7FI local header), batch or online 2.access to references, decide what docs are relevant (user+patient context) 3.fetch relevant CDA docs (patient consent required) 4.the regional system fetches the documents from other organisations/systems 5.CDA document (XML) is rendered in the browser through an XSLT style sheet communication secured, 2-way ssl authentication 2. 3. 4. 5. communication secured, 1-way ssl auth., (2-way for some use cases) Context mgmt (almost CCOW)

21. Requirements on structuring clinical data (DSS, benchmarking, quality, statistics, etc) –Core data set defined by various domain experts, expressed using the CDA R2 entries (clinical statements) Implementation guidelines for various document types: –overall narrative EPR, laboratory results, diagnosis list, medication list, eForms,... Change approach - not only dynamic extraction, but CDA R2 is the legal and persistent patient record format Building a national CDA archival service (repository) EPR vendors currently adding nationally agreed structures to their products and building CDA R2 interfaces (A very narrow view into the national program, it has many other development areas as well) National eHealth program - CDA R2

22. HL7 V3 messaging in Finland Documents don't solve everything, V3 messaging is coming in new areas: –death notification to national person registry –regional scheduling services ePrescription - mix of CDA and V3? National CDA archive - V3 medical records or IHE XDS? Some other topics also under discussion Preferred transport profile is web services

23. Page 23 © 2006 HSSP Project, http://hssp.wikispaces.com Reuse with attribution permitted Summary HSSP is a collaboration between HL7 and OMG aiming in creating standardized service specifications for healthcare Active work in: –Record location and update (RLUS) –Entity identification (EIS) –Common terminology services II (CTS II) –Clinical decision support service (CDSS) –Service oriented architectures and V3 messaging (SOA4HL7) Finland is deploying CDA and some V3 messages nationally, some services also deployed and next development phase will include more services

24. Page 24 © 2006 HSSP Project, http://hssp.wikispaces.com Reuse with attribution permitted References HSSP Wiki http://hssp.wikispaces.com HL7 Website: http://www.hl7.org OMG Website: http://www.omg.org