We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byChristian Leason
Modified over 2 years ago
6/7/2014 1:02 AM Healthcare Service Specification Project (HSSP): Producing Service Functional Models (SFMs) October 2007
Page 2 © 2007 HSSP Project, Reuse with attribution permitted Purpose This deck provides overview guidance to project teams that are producing Service Functional Models (SFMs). For full details, see the Service Specification Framework (SSF). Sections 3 and 4 of the SSF Document set out the process in detail. This is based on SFM Boilerplate v2-1 and SSF v1-4 For a high level overview of the complete end-to-end process, see Service Specification Framework (SSF) - Overview for New Projects Project teams are also encouraged to read through one of the existing HSSP SFMs (e.g. EIS or RLUS) to get a general feel for what an SFM is (note these were based on earlier versions of the SFM Template).
Page 3 © 2007 HSSP Project, Reuse with attribution permitted OMG HL7 Place of SFM within the overall HSSP Process HL7 DSTU Service Functional Model OMG RFP RFP Responders Technical Specification ANSI Standard OMG HDTF HL7 defines the requirements and functional specification. Technical Specification defined by vendors through the OMG RFP process.
Page 4 © 2007 HSSP Project, Reuse with attribution permitted SFM Understanding HSSP Artifacts, Roles, Attributes Owned / Produced by HL7 Community RFP Submission Implementation Defines what a service does but not how Independent of technical platform Audience is tech leads, EAs, tech spec developers Produced / owned by OMG community Translates SFM into technical requirements IDs supported technical platforms Audience is community with implementation interest Produced by OMG Member Submitters Defines the services technical spec Defines interfaces, platform bindings, and conformance profiles Audience is project team architect, lead developers, etc. Owned by organizations and vendors Builds the service that lives behind the interface Complies with a conformance profile Audience are consumers of the system or service
Page 5 © 2007 HSSP Project, Reuse with attribution permitted SFM vs Technical Specification SFMTechnical Specification Service scopeDefined From SFM Business caseDefined N/A Process / interaction Storyboards, mappings of capabilities to storyboards Interaction details as needed FunctionsTechnology neutral capabilities or responsibilities, behavior description in business terms Interfaces and Operations, both technology independent and technology specific based on SFM capabilities. Behavior specification InformationReference or define relevant content (data+metadata) for inputs and outputs. Operation payloads based on SFM capability inputs/outputs. Infrastructure / Deployment Assumptions, what is expected to be there, requirements for mandatory supported platforms Platform-specific technical infrastructure (interfacing technology, communication), generic runtime infrastructure, implications to deployment topology ConformanceMandatory features, conformance of functional model to business need, identification of functional profiles Conformance assertion to RFP requirements, establish platform specific technical conformance criteria for implementations
Page 6 © 2007 HSSP Project, Reuse with attribution permitted Service Functional Model Characteristics The SFM is an technology and implementation- independent specification of the functionality of a Service expressed in business terms –It does not specify any technology or platform –In general should not be 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) –Sections 5 (Business capabilities) and 6 (Profiles) alone provide the core normative Service description –The remainder provides supporting context, rationale and explanation There is not a fixed order in which the sections should be completed, but this deck gives a suggested ordering
Page 7 © 2007 HSSP Project, Reuse with attribution permitted SFM Sections 1 and 2.1 Sections 1 and 2 can effectively be treated as the executive summary. Section 1 is boilerplate context and Section 2 in an Executive Summary that describes the objectives and need for the Service and provides a summary of the detailed content following in the subsequent section. Service Overview (Section 2.1) consists of the Description and Purpose (2.1.1) and Scope (2.1.2) –The SFM Template suggests some questions that could be answered to give direction, but this is a free form section to describe in simple business terms what the Service is meant to do and what the business problem or need is.
Page 8 © 2007 HSSP Project, Reuse with attribution permitted SFM Sections 2.2 and 2.3 Section 2.2 Reason why the service is necessary –This expands a little more on this theme by describing the value of having the service as a standard for potential stakeholders. This is more like a business case. Project Context (Section 2.3) is a simple statement of how the Service fits in within the overall HSSP Roadmap, i.e. its relationship, if any to other Services.
Page 9 © 2007 HSSP Project, Reuse with attribution permitted SFM Sections 2.4 and 2.5 Sections 2.4 and 2.5 would usually be completed in parallel with or after the detailed sections have been written, since they are aimed at giving the reader of the specification a high level introduction before diving into the detail. Service Structure (Section 2.4) provides an overview of the components of the services, i.e. the main interfaces and profiles. Implementation Considerations (Section 2.5) identifies and outlines any issues or implications for implementation of the Service that are foreseen at the time of producing the functional specification.
Page 10 © 2007 HSSP Project, Reuse with attribution permitted SFM Sections 3 and 4 Section 3 is used to describe Business Storyboards, in a similar fashion to v3 messaging Storyboards. –These provide a textual description of a sequence- of-events of some importance to the authors of the SFM. –These are NOT meant to be exhaustive, merely sufficient to ensure that the interfaces and capabilities of the Service can be defined and have business relevance Any assumptions or dependencies are identified in Section 4. This also helps to provide further context for those later specifying the technical specification
Page 11 © 2007 HSSP Project, Reuse with attribution permitted SFM Section 5 Section 5 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 12 © 2007 HSSP Project, Reuse with attribution permitted SFM Section 5 cont. For each action/capability, the following information needs to be defined: –A business-friendly name (e.g., Find a Person vs. FindPerson) –A high-level functional description of the expected behavior –Business Pre-conditions (identifies business conditions that must be in place before the capability can be carried out) –Inputs (information items that needs to be supplied by the client) –Outputs (information that is returned by the service) –Business Post-conditions (identifies business state after the action is completed) –Business Exception conditions if any known –Enumeration of aspects to be left to the technical specification –Relationship to levels of conformance (or other patterns) –Any other descriptive notes or comments
Page 13 © 2007 HSSP Project, Reuse with attribution permitted The Composition of HSSP Profiles Semantic Space/ Universe Formalism (Structure) Semantic Signifiers (profile-relevant semantic structures) Usage Context (interoperability paradigm) Functional Subset List (enumerate Supported Functions) Version Submitter Name Metadata
6/7/2014 1:02 AM Semantic Space/ Universe Formalism (Structure) Semantic Signifiers (profile-relevant semantic structures) Usage Context (interoperability paradigm) Functional Subset List (enumerate Supported Functions) Version Submitter Name Metadata
Page 15 © 2007 HSSP Project, Reuse with attribution permitted SFM Section 6 Section 6 defines functional, semantic and conformance profiles, which are instrumental for conformance –Profiles provide a mechanism to enable definition of generic, reusable service interfaces that can be used in many different scenarios using different information constructs. –Functional profiles identify named groupings of functionality (i.e. simple coherent subsets of the defined set of actions, e.g. a Locate profile in RLUS) –Semantic profiles identify the different information structures that may be supported by the service (e.g. specific HL7 V3 information models such as a V3 RIM Patient profile or an OpenEHR Archetype) –Conformance profiles are simply a named combination of a functional profile with a semantic profile, which provides a reference point for implementers to indicate what they are conforming to.
Page 16 © 2007 HSSP Project, Reuse with attribution permitted Composition 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 17 © 2007 HSSP Project, Reuse with attribution permitted SFM Sections 7 and 8 Section 7 is an optional section that allows for the storyboards from section 3 to be described in more detail and in systems terms (e.g. activity or sequence diagrams depicting the intended systems interactions) Section 8 defines and summarizes issues to be taken into consideration in the technical specification. This is an opportunity to identify considerations for those developing the technical specification (e.g. specific technology standards that need to be used)
Page 18 © 2007 HSSP Project, Reuse with attribution permitted SFM Appendices A search should also be made of existing standards or work that can be leveraged or referenced, which are then documented in Appendix A Appendix B contains a glossary of terms specific to the SFM When producing sections 2 or 3, an assessment should be made of how the Service maps to the EHR Functional Model (Appendix C) Appendix D is boilerplate text outlining the approach to binding to Information Models 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 19 © 2007 HSSP Project, Reuse with attribution permitted References Project wiki: Object Management Group: Health Level Seven:
4/12/2015 7:43 AM HL7 Interoperability Paradigms September 2007 WGM, Atlanta, GA John Koisch, OCTL Consulting Alan Honey, Kaiser Permanente Grahame Grieve,
1/28/ :02 PM Healthcare Services Specification Project (HSSP) HL7 Services Oriented Architecture SIG Entity Identification Service (EIS) RFP Discussion.
10/9/ :26 AM Healthcare Services Specification Project Decision Support Service (DSS) Overview and Outstanding Issues Kensaku Kawamoto M.D.-Ph.D.
Health eDecisions Use Case 2: CDS Guidance Service Strawman of Core Concepts Use Case 2 1.
1 ECCF Training 2.0 Introduction ECCF Training Working Group January 2011.
FRED Interlinked Registries DRAFT roadmap for consideration.
Initial slides for Layered Service Architecture From existing materials: Practical Guide to SOA in Healthcare Part II IHE SOA Whitepaper.
Copyright © 2006 Data Access Technologies, Inc. Open Source eGovernment Reference Architecture Approach to Semantic Interoperability Cory Casanave, President.
HL7 V2 Implementation Guide Authoring Tool Proposal Robert Snelick National Institute of Standards and Technology October 6 th 2010 Contact:
Page 1 Copyright © 2010 Data Access Technologies, Inc. Model Driven Solutions May 2009 Cory Casanave Architecture of Services SOA for E-Government Conference.
Component-Based Software Engineering Main issues: assemble systems out of (reusable) components compatibility of components.
1. Introduction OASIS Reference Model for Service Oriented Architecture 2. ECF 4.0 Architecture 2.1 Core vs. Profiles 2.2 Major Design Elements 2.3.
Proposed update of Technical Guidance for INSPIRE Download services based on SOS Matthes Rieke, Dr. Albert Remke (m.rieke, 52°North.
1 ECCF Training Computationally Independent Model (CIM) ECCF Training Working Group March 2011.
Presented to: By: Date: Federal Aviation Administration Registry/Repository in a SOA Environment SOA Brown Bag #5 SWIM Team March 9, 2011.
1/23/2014 9:52 AM SOA4HL7: Defining Services based on HL7 Messaging Artifacts Alan Honey, Kaiser Permanente Enterprise Architect (Based on material initially.
Catalogue, synthesise Templates, forms, data sets used in real, diverse health settings Formal representation of clinical business object REQUIREMENTS.
Flex Your APEX Implementing Oracle E-Business Suite Descriptive Flexfields in Application Express Shane Bentz InterVarsity Christian Fellowship/USA.
11/25/2015 5:06 PM HSSP Service Development Framework (SDF) Overview May 2006 Ken Rubin EDS Co-Chair, OMG Healthcare Domain Task Force Co-Chair, HL7 Services-oriented.
Electronic Submission of Medical Documentation (esMD) Use Case & Functional Requirements Overview PPA Use Case Diagram Review Dec 14, :00 PM – 3:00.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Standards Analysis Summary vMR – Pros Designed for computability Compact Wire Format Aligned with HeD Efforts – Cons Limited Vendor Adoption thus far Represents.
1 CIS224 Software Projects: Software Engineering and Research Methods Lecture 11 Brief introduction to the UML Specification (Based on UML Superstructure.
1 Service Oriented Architecture Reference Model An informal SOA Ontology.
2/11/2014 9:17 AM Healthcare Services Specification Project The Business Case for Healthcare SOA Standards HL7 Service-Oriented Architecture SIG OMG Healthcare.
What IHE Delivers Care Services Discovery IHE IT Infrastructure Planning Committee Carl Leitner – IntraHealth International.
September, 2005What IHE Delivers 1 Karen Witting IBM Cross-Community: Peer- to-Peer sharing of healthcare information.
EHR-S Conformance Considerations Lynne S. Rosenthal National Institute of Standards and Technology August 2004.
Data Segmentation for Privacy November 16 th, 2011.
Construction process lasts until coding and testing is completed consists of design and implementation reasons for this phase –analysis model is not sufficiently.
Dec UtilityAMI OpenHAN TF Requirements Working Group Specification Briefing January 2008.
Introduction to Product Family Engineering. 11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 2 Product Family Engineering Overview Project Engineering.
2/11/2014 8:44 AM The CDA Release 3 Specification Stack September 2009 HL7 Services-Aware Enterprise Architecture Framework (SAEAF)
1 ECCF Training Computationally Independent Model (CIM) ECCF Training Working Group January 2011.
1 DoDAF V2.0 Community Update Overview 12 August 2010 MR. MICHAEL WAYSON Architecture and Infrastructure Directorate Office of the DoD Deputy Chief Information.
RCRIM September 2007 Working Group Meeting Clinical Research Filtered Query Service Tuesday, September 18, 2007 (Q4) Sheraton Hotel Atlanta, GA.
Public Health Reporting Initiative Stage 3 Sprint: Implementation Guide Development Phone: x
IHE Workshop – June 2006What IHE Delivers 1 Cynthia A. Levy Cedara Software IHE Technical Committee Import Reconciliation Workflow Profile.
National Institute of Standards and Technology Technology Administration U.S. Department of Commerce 1 Patient Care Medical Devices Test Effort Integrating.
UML - Development Process 1 Software Development Process Using UML (2)
CS 4850: Senior Project Fall 2014 Object-Oriented Design.
Cross Domain Patient Identity Management Eric Heflin Dir of Standards and Interoperability/Medicity.
6/4/2016 8:05 PM Healthcare Services Specification Project Decision Support Service (DSS) Overview and Areas of Active Discussion HL7 Clinical Decision.
> > > Solution Architecture Blueprint and Review Preparation Template IN-PROCESS.
Slide 1 Testing Workflow Purpose l Purpose Verify the result from implementation by testing each build Plan the tests in each iteration Integration tests.
Daniel Amyot, University of Ottawa Based on slides by Gunter Mussbacher (2009) and Stéphane Somé (2008) with material from these standards: IEEE ,
© 2017 SlidePlayer.com Inc. All rights reserved.