Service Functional Models (SFMs) and their relationship to the Electonic Health Record System Functional Model (EHR-S FM)

Transcription

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

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

4 Open service specifications in HL7 and HSSP Asset Purpose Functional Spec-DSTU Entity Identification Service (EIS) Retrieve Locate Update Service (RLUS) Decision Support Service (DSS) Common Terminology Service (CTS II) [Healthcare] Access Control Service (PASS Access Control) Human Svcs Directory (HSD) [Healthcare] Audit Service (PASS Audit) To manage identities and identifying traits (e.g., MPI) To manage location and retrieval of healthcare content To analyze patient data and assess against knowledge rules. Defines behavior for managing/maintaining terminologies Manages security policy as pertaining to access to health information To find providers & services in allocated areas, e.g., referrals. Security-oriented service to manage audit record Technical Spec Functional Spec-Norm Implementation Availability Complete Complete Complete Commercially Available Complete Complete Expected 9/2010 Complete Complete Expected 9/2010 Complete Expected 12/2010 Expected 5/2011 Commercially Available In development In development Complete In process TBD TBD N/A In process Complete TBD In process TBD TBD TBD page 4 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 Page 5

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

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

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

9 Detailed functional model example [HL7 Decision Support Service Functional Model] Get Knowledge Module Evaluation Result Description Precondition Inputs Outputs Post-conditions Business exceptions Evaluates the data provided by the client using one or more knowledge modules and returns the result(s) of the evaluation The specified knowledge module(s) exist The client is providing the data required by the knowledge module. The required data are identified using the Get Knowledge Module Data Requirements operation specified above Time zone, One or more knowledge modules for the evaluation, Data required by each knowledge module Evaluation results in the format specified by the semantic signifier None Knowledge module does not exist, Data were not provided in the correct format, unexpected error during the evaluation Aspects left to RFP submitters Relationship to levels of conformance Supported by all functional profiles Page 9

10 Use 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 Service Patient Cross Reference Profile Version: 1.0 Date: 10/22/2007 Description:.. Entity Cross-Reference Version Link Entity - Unlink Entity - List Linked Entities HL7 RIM V2.14 Patient - HL7 RIM - V Model: Set of traits taken from Patient Billing Account RMIM (FIAB_DM000000UV01). (EIS SFM included sample model) Page 10

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

12 EHR-S functional model 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 Page 12

13 Example: EHR-S functions supported by RLUS DC Manage summary lists DC Manage problem list DC Manage medication list DC Manage allergy and adverse reaction list DC Summarize health record DC Manage clinical documents and notes DC Capture external clinical documents DC Capture patientoriginated data DC Manage consents and authorizations DC Manage patient advanced directives DC Pharmacy communication DC Communication with medical devices S.2.2 Report generation S Health record output S.3.2 Information access for supplemental use S 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 Page 13

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

15 Takk fyrir / Kiitos 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 Page 15

16 Additional material Page 16

17 Understanding HSSP Artifacts, Roles, Attributes SFM Owned / Produced by HL7 Community RFP Submission Implementation 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 Page 17

18 SFM vs Technical Specification SFM Technical Specification Service scope Defined From SFM Business case Defined N/A Process / interaction Functions Information Infrastructure / Deployment Conformance Storyboards, mappings of capabilities to storyboards Technology neutral capabilities or responsibilities, behavior description in business terms Reference or define relevant content (data+metadata) for inputs and outputs. Assumptions, what is expected to be there, requirements for mandatory supported platforms Mandatory features, conformance of functional model to business need, identification of functional profiles, semantic profiles Interaction details as needed Interfaces and Operations, both technology independent and technology specific based on SFM capabilities. Behavior specification Operation payloads based on SFM capability inputs/outputs. Platform-specific technical infrastructure (interfacing technology, communication), generic runtime infrastructure, implications to deployment topology Conformance assertion to RFP requirements, establish platform specific technical conformance criteria for implementations Page 18