Difference between revisions of "SFM"
| Line 45: | Line 45: | ||
Notes to Readers | Notes to Readers | ||
| − | + | <font color=blue>This document is the Service Functional Model for the Common Terminology Services 2 specification, which is specified under the Service Development Framework process under the auspices of the Healthcare Services Specification Project (HSSP). Further context is given in the overview section below, but one key point to note is that the SFM provides a Service '''Interface''' specification, NOT the specification of a Service implementation. This is a critical distinction in terms of Service Oriented Architecture. There could be many different ways of implementing all or part of the functionality to support the behavior described in this specification.</font> | |
Revision as of 19:52, 18 March 2008
| Project Leads | Russell Hamm rhamm@apelon.com (Apelon, Inc.)
Craig Stancl stancl.craig@mayo.edu (Mayo Clinic/Foundation) |
| Editors | John Carter John.X.Carter@ge.com(GE Healthcare)
Sundak Ganesan dsq3@CDC.GOV(CDC) Russell Hamm rhamm@apelon.com (Apelon, Inc.) Senthil Nachimuthu snachimuthu@mmm.com(3M Health Information Systems Division) Craig Stancl stancl.craig@mayo.edu (Mayo Clinic/Foundation) |
| Contributors | Harold Solbrig hsolbrig@apelon.com
(Apelon, Inc.) James Buntrock buntrock.james@mayo.edu(Mayo Clinic/Foundation) |
Preface
Notes to Readers
This document is the Service Functional Model for the Common Terminology Services 2 specification, which is specified under the Service Development Framework process under the auspices of the Healthcare Services Specification Project (HSSP). Further context is given in the overview section below, but one key point to note is that the SFM provides a Service Interface specification, NOT the specification of a Service implementation. This is a critical distinction in terms of Service Oriented Architecture. There could be many different ways of implementing all or part of the functionality to support the behavior described in this specification.
NOTE: For the purposes of this specification, the terms vocabulary and terminology are interchangeable.
Changes from Previous Release
This is the first public release of this document.
Acknowledgements
This document is the result of the collaboration of many individuals and organizations. The terminology and standards community - all involved in the numerous meetings and teleconferences are to be thanked for their contributions and support. In addition to the listed authors, the following individuals are acknowledged for their contributions and support during the development of this specification.
- The HL7 Vocabulary Technical Committee
- Dr. Christopher Chute (Mayo Clinic/Foundation)
- John Koisch (OCTL Consulting)
- Harold Solbrig (Apelon, Inc.)
- Ken Rubin (EDS)
Note that sections of this document in <blue> indicate text that is consistent across HSSP specifications
Overview
Introduction and Scope
The Service Specification Development Framework Methodology is the methodology followed to define HSSP specifications. The methodology sets out an overall process, and also defines the responsibilities of the Service Functional Model (SFM). Section 2 sets out the business context for this particular specification, but firstly it is important to understand the overall context within which this specification is written, i.e. its purpose from a methodology standpoint.
HL7-OMG Healthcare Services Specification Project (HSSP)
The Healthcare Services Specification Project (HSSP) [http://hssp.wikispaces.com] is a joint endeavor between Health Level Seven (HL7) [http://www.hl7.org] and the Object Management Group (OMG) [http://www.omg.org]. The HSSP was chartered at the January 2005 HL7 meeting under the Electronic Health Records Technical Committee, and the project was subsequently validated by the Board of Directors of both organizations.
The HSSP has several objectives. These objectives include the following:
- To stimulate the adoption and use of standardized “plug-and-play” services by healthcare software product vendors
- To facilitate the development of a set of implementable interface standards supporting
