1. 6/7/2014 1:02 AM Healthcare Service Specification Project (HSSP): Producing Service Functional Models (SFMs) October 2007

2. Page 2 © 2007 HSSP Project, http://hssp.wikispaces.com 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).

3. Page 3 © 2007 HSSP Project, http://hssp.wikispaces.com 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.

4. Page 4 © 2007 HSSP Project, http://hssp.wikispaces.com 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

5. Page 5 © 2007 HSSP Project, http://hssp.wikispaces.com 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

6. Page 6 © 2007 HSSP Project, http://hssp.wikispaces.com 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

7. Page 7 © 2007 HSSP Project, http://hssp.wikispaces.com 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.

8. Page 8 © 2007 HSSP Project, http://hssp.wikispaces.com 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.

9. Page 9 © 2007 HSSP Project, http://hssp.wikispaces.com 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.

10. Page 10 © 2007 HSSP Project, http://hssp.wikispaces.com 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

11. Page 11 © 2007 HSSP Project, http://hssp.wikispaces.com 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.

12. Page 12 © 2007 HSSP Project, http://hssp.wikispaces.com 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

13. Page 13 © 2007 HSSP Project, http://hssp.wikispaces.com 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

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

15. Page 15 © 2007 HSSP Project, http://hssp.wikispaces.com 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.

16. Page 16 © 2007 HSSP Project, http://hssp.wikispaces.com 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 1.0 - Link Entity - Unlink Entity - List Linked Entities 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)

17. Page 17 © 2007 HSSP Project, http://hssp.wikispaces.com 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)

18. Page 18 © 2007 HSSP Project, http://hssp.wikispaces.com 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

19. Page 19 © 2007 HSSP Project, http://hssp.wikispaces.com Reuse with attribution permitted References Project wiki: http://hssp.healthinterop.orghttp://hssp.healthinterop.org Object Management Group: http://www.omg.orghttp://www.omg.org Health Level Seven: http://www.hl7.orghttp://www.hl7.org