Healthcare SOA Standards and Service Functional Models: A Relationship Analysis

1. Service Functional Models (SFMs) and their relationship to the Electonic Health Record System Functional Model (EHR-S FM) EFMI STC interoperability workshop, Reykjavik, June 2010 Dr. Juha Mykkänen University of Eastern Finland, HIS R&D Unit, researcher HL7 Finland, vice chair Includes material of HL7 International SOA WG, Healthcare Services Specification Project (HSSP) and HL7 Services-Aware Interoperability Framework which is gratefully acknowledged

2. Overview • SOA service standards for healthcare? • Service Functional Model (SFM) Specifications • Structure of SFMs • Relationship of EHR System Functional Model and SFMs • Concluding remarks

3. Why develop healthcare SOA standards? • Healthcare organizations are being driven to interoperate • “Messaging” is not the ideal approach for every interoperability challenge • SOA has demonstrated viability and benefits for many organizations and in many vertical-markets • especially for complex and changing domains • Open service specifications already exist in many countries and organizations for healthcare • Healthcare Services Specification Project has been defining SOA service standards since 2005 • joint effort between HL7 and OMG • Services are now one of the supported interoperability paradigms in HL7 SAIF (Services-Aware Interoperability Framework) • in addition to HL7 messages and CDA documents

4. Open service specifications in HL7 and HSSP page 4

5. Service Functional Model Characteristics • The SFM is a specification of the functionality of a Service • expressed in business terms • It does not specify any technology or platform and is implementation-independent • In general is not used to define new semantic content (especially HL7 content), but may reference existing or new semantics being defined elsewhere • It should cite and leverage existent work (i.e. specifications, not specific implementations) • “Business capabilities” and “Profiles” sections provide the core “normative” Service description • The remainder provides supporting context, rationale and explanation • A key specification for defining open SOA service standards • Is followed by technical specifications in the process

6. Place of SFM within the overall HSSP Process HL7 HL7 defines the requirements and functional specification. Technical Specification defined by vendors through the OMG RFP process. Service Functional Model OMG HL7 DSTU OMG HDTF OMG RFP ANSI Standard RFP Responders Technical Specification

7. Structure of a SFM specification [SFM boilerplate] 1 Executive Summary 1.1 Service Overview 1.2 Scope 1.3 Assumptions and Dependencies 1.4 Implementation Considerations 2 Business Context 2.1 The reason why the service is necessary 2.2 Storyboards / business process descriptions 3 Detailed Functional Model for each Interface 4 Profiles 4.1 Functional profiles 4.2 Semantic profiles 5 System Interaction Details [Optional] 6 Recommendations for Technical Specification • Appendices

8. Detailed Functional Model for each Interface • This section is the main normative content of the SFM • Each individual piece of functionality to be provided by the Service is described in some detail in terms of business capabilities, structured within interfaces • Each business capability describes a specific action the service must perform (in the technical specification, each will result in one or more “operations”). Examples: “Find a Person”, “Locate a Medical Record”, “Create an Order”, “Book an Appointment” • The grouping into interfaces is not critical, since this may be reorganized in the technical specification, but provides a logical, cohesive mechanism for grouping capabilities, e.g. service administration, service metadata management, update, query

9. Detailedfunctionalmodelexample[HL7 DecisionSupport Service FunctionalModel] 5.3.1 Get Knowledge Module Evaluation Result

10. Use of Profiles - Example Conformance Profile - Name - Version - Date - etc Entity Identification Service Patient Cross Reference Profile Version: 1.0 Date: 10/22/2007 Description: ………….. Entity Cross-Reference Version 1.0 - Link Entity - Unlink Entity - List Linked Entities Functional Profile - Name - Version - Capability 1 - Capability 2 - Capability N…. 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) Semantic Profile - Information Model ID - Version - Source - etc

11. SFM Appendices • Appendix A Relevant standards • existing standards or work that can be leveraged or referenced, which are documented in • Appendix B Glossary • contains a glossary of terms specific to the SFM • Appendix C HL7 EHR-S Functional Model traceability • an assessment of how the Service maps to the EHR Functional Model • Any additional relevant details may be added in further appendices, e.g. in the Entity Identification SFM there was a discussion on relevant existing IHE profiles

12. EHR-S functionalmodel and SFMs • EHR system functional model provides shared language for the description of EHR system functionality • many functional requirements from EHR-S FM can be defined as services or their operations, or supported by infrastructure service operations • traceability of service specifications to requirements! • examples • Clinical Decision Support Service (DSS) supports many Clinical Decision Support functions specified in Section C.2 of the EHR-S functional model • Record Location and Update Service (RLUS) can be used to implement tens of direct care, supportive or information infrastructure functions of the EHR-S

13. Example: EHR-S functions supportedby RLUS • DC.1.1.3 Manage summary lists • DC.1.1.3.1 Manage problem list • DC.1.1.3.2 Manage medication list • DC.1.1.3.3 Manage allergy and adverse reaction list • DC.1.1.5 Summarize health record • DC.1.1.6 Manage clinical documents and notes • DC.1.1.7 Capture external clinical documents • DC.1.1.8 Capture patient-originated data • DC.1.5.1 Manage consents and authorizations • DC.1.5.2 Manage patient advanced directives • DC.3.2.2 Pharmacy communication • DC.3.2.5 Communication with medical devices • S.2.2 Report generation • S.2.2.1 Health record output • S.3.2 Information access for supplemental use • S.3.3.4 Support of service requests and claims • I.2 Health record information and management • I.2.1 Data Retention and Availability • I.2.4 Extraction of health record information • I.3.1 Distributed registry access

14. Conclusions • SOA approach emphasizes interoperability and flexibility • service-oriented enterprise architecture used increasingly in healthcare organizations and networks • SOA service standards emerging also in healthcare • Service Functional Models are an important tool to realize services-based interoperability paradigm • in analysis and blueprint phases, basis for conceptual design • especially important are service role specifications, behaviors and static information models • EHR system functional model standard promotes traceability to requirements from service specifications

15. Takk fyrir / Kiitos • http://www.uku.fi/solea • http://www.hl7.com • http://hssp.wikispaces.com • http://www.hl7.fi • juha.mykkanen@uef.fi This work is related to the SOLEA project, funded by the National Agency of Technology and Innovation TEKES, Konecranes, OP-keskus OSK, Commit; Oy, CSC Tieteen tietotekniikan keskus, Datawell, Fujitsu Services, Hospital district of Helsinki and Uusimaa, Intersystems, Logica Suomi, Mawell, RAY - Finland’s Slot Machine Association, Medbit / Hospital diestrict of Varsinais-Suomi, Metso, Hospital district of Northern Savo, Hospital district of Satakunta. ”Blindur er bóklaus maður” ”Blind is a man without a book” -Icelandic proverb

16. Additionalmaterial

17. Understanding HSSP Artifacts, Roles, Attributes Implementation SFM RFP Submission Owned / Produced by HL7 Community Produced / owned by OMG community Produced by OMG Member “Submitters” Owned by organizations and vendors Defines what a service does but not how Translates SFM into technical requirements Defines the service’s technical spec Builds the service that lives behind the interface Independent of technical platform ID’s supported technical platforms Defines interfaces, platform bindings, and conformance profiles Complies with a “conformance profile” Audience is tech leads, EAs, tech spec developers Audience is community with implementation interest Audience is project team architect, lead developers, etc. Audience are consumers of the system or service

18. SFM vs Technical Specification