This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Product DSS SFM"

From HL7Wiki
Jump to navigation Jump to search
 
Line 1: Line 1:
==Product Brief - Decision Support Service Functional Model (DSS SFM)==
+
=Product Brief - Decision Support Service Functional Model (DSS SFM)=
 
+
__TOC__
 
:back to [[Main_Page]]
 
:back to [[Main_Page]]
 
:back to [[Product_List|Product List]]
 
:back to [[Product_List|Product List]]
 
===Product Name===
 
===Product Name===
 
Decision Support Service Functional Model (DSS SFM)
 
Decision Support Service Functional Model (DSS SFM)
 
+
<!--
 
===Topics===
 
===Topics===
 
+
-->
 
===Standard Category===
 
===Standard Category===
 
Application Functional Specifications - Services (SOA)
 
Application Functional Specifications - Services (SOA)
 
===Integration Paradigm===
 
===Integration Paradigm===
 
Services
 
Services
====How does this relate to the OMG Technical Specification and to the Healthcare Services Specification Project?====
 
For EIS, HL7 has partnered with OMG to produce technical specifications supporting Service Functional Models within OMG’s technology adoption process. To the healthcare industry, this provides value via OMG’s rigorous architectural approach, review process,
 
and distributed systems expertise. For OMG, this relationship brings deep healthcare experience via HL7’s extensive international participation and vertical industry expertise. The Healthcare Services Specification Project (HSSP) is a moniker for the collaboration between groups collaborating on service standards, of which HL7 and OMG are participants.
 
====How does this relate to the HL7 Services-Aware Enterprise Architecture Framework?====
 
In 2008, HL7 embarked upon developing its [http://wiki.hl7.org/index.php?title=Architecture_Board#SAEAF Services-Aware Enterprise Architecture Framework] (SAEAF). SAEAF will be aligning the broad range of HL7 specifications—including services, messages, and document standards—to a consistent approach across the whole of HL7’s offerings. SAEAF also specifies usage constraints for deployed HL7 standards. Several HSSP services predate SAEAF. Over time, we expect all HL7 Service Functional Models to come into alignment with SAEAF.
 
====Don’t industry standard services (such as the Decision Support Service, Entity Identification Service) limit vendor competition?====
 
Not necessarily. While industry standards specify how a consumer interacts with the service, these specifications have expressly left how these functions are supported out-of-scope. In other words, there is no predetermined knowledge modeling formalism, system design platform, or approach that is advocated in the standard. Vendors are able to compete based upon quality-of-service and the benefits of their specific implementation. Further, the specification includes mandatory and supplemental requirements (“nice-to-haves”), which can further stratify marketplace offerings.
 
 
===Type===
 
===Type===
 
+
DSTU
 
===Releases===
 
===Releases===
 
* DSTU: HL7 Version 3: Decision Support Service (DSS), Release 1. This DSTU has been extended an additional 24 months upon the approval of the TSC as indicated in [http://hl7projects.hl7.nscee.edu/tracker/index.php?func=detail&aid=996&group_id=52&atid=313 TSC Tracker item #996].  Ends April 2011
 
* DSTU: HL7 Version 3: Decision Support Service (DSS), Release 1. This DSTU has been extended an additional 24 months upon the approval of the TSC as indicated in [http://hl7projects.hl7.nscee.edu/tracker/index.php?func=detail&aid=996&group_id=52&atid=313 TSC Tracker item #996].  Ends April 2011
  
 
===Summary===
 
===Summary===
The Decision Support Service Functional Model (DSS SFM) Draft Standard for Trial Use (DSTU) is a draft functional standard defining the functions, responsibilities, inputs, outputs, and expected behavior of a system component for evaluating patient data to reach patient-specific conclusions. A DSS, for example, can evaluate a patient’s health summary as encoded in a Continuity of Care Document (CCD) and provide structured recommendations regarding the patient’s health maintenance and chronic disease management needs. The DSS SFM is among the first healthcare standards targeted to support a service-oriented architecture (SOA), and is at the basis for an unprecedented collaboration with the Object Management Group (OMG), which has adopted a technical specification complementing this SFM.
+
The Decision Support Service Functional Model (DSS SFM) Draft Standard for Trial Use (DSTU) is a draft functional standard defining the functions, responsibilities, inputs, outputs, and expected behavior of a system component for evaluating patient data to reach patient-specific conclusions. A DSS, for example, can evaluate a patient’s health summary as encoded in a Continuity of Care Document (CCD) and provide structured recommendations regarding the patient’s health maintenance and chronic disease management needs. The DSS SFM is among the first healthcare standards specifically designed to support a service-oriented architecture (SOA), and establishes a basis for an unprecedented collaboration with the Object Management Group (OMG), which has adopted a technical specification complementing this SFM.  
  
 
===Description===
 
===Description===
 +
*How does this relate to the OMG Technical Specification and to the Healthcare Services Specification Project?
 +
**For EIS, HL7 has partnered with OMG to produce technical specifications supporting Service Functional Models within OMG’s technology adoption process. To the healthcare industry, this provides value via OMG’s rigorous architectural approach, review process, and distributed systems expertise. For OMG, this relationship brings deep healthcare experience via HL7’s extensive international participation and vertical industry expertise. The Healthcare Services Specification Project (HSSP) is a moniker for the collaboration between groups collaborating on service standards, of which HL7 and OMG are participants.
 +
*How does this relate to the HL7 Services-Aware Enterprise Architecture Framework?
 +
**In 2008, HL7 embarked upon developing its [http://wiki.hl7.org/index.php?title=Architecture_Board#SAEAF Services-Aware Enterprise Architecture Framework] (SAEAF). SAEAF will be aligning the broad range of HL7 specifications—including services, messages, and document standards—to a consistent approach across the whole of HL7’s offerings. SAEAF also specifies usage constraints for deployed HL7 standards. Several HSSP services predate SAEAF. Over time, we expect all HL7 Service Functional Models to come into alignment with SAEAF.
 +
*Don’t industry standard services (such as the Decision Support Service, Entity Identification Service) limit vendor competition?
 +
**Not necessarily. While industry standards specify how a consumer interacts with the service, these specifications have expressly left how these functions are supported out-of-scope. In other words, there is no predetermined knowledge modeling formalism, system design platform, or approach that is advocated in the standard. Vendors are able to compete based upon quality-of-service and the benefits of their specific implementation. Further, the specification includes mandatory and supplemental requirements (“nice-to-haves”), which can further stratify marketplace offerings.
  
 +
===Business Case (Intended Use, Customers)===
 +
*Vendor: Decision Support systems;
 +
*Healthcare providers seeking Decision Support Systems
  
===Business Case (Intended Use, Customers)===
+
===Benefits===
====Why produce an industry standard Decision Support Service?====
 
 
Quite simply, the Decision Support Service defines the collective set of behaviors that one would expect a clinical decision support engine to perform. This functionality is required of most healthcare organizations and allows for the data collected in electronic health records and other clinical information systems to provide enhanced value for patients, clinicians, healthcare providers, and payors. The challenge is that the lack of a standard makes the use of decision support services more costly and difficult. Without clearly defined expectations of how Decision Support Services should interface with health information systems, variants abound and interoperability suffers.
 
Quite simply, the Decision Support Service defines the collective set of behaviors that one would expect a clinical decision support engine to perform. This functionality is required of most healthcare organizations and allows for the data collected in electronic health records and other clinical information systems to provide enhanced value for patients, clinicians, healthcare providers, and payors. The challenge is that the lack of a standard makes the use of decision support services more costly and difficult. Without clearly defined expectations of how Decision Support Services should interface with health information systems, variants abound and interoperability suffers.
  
===Benefits===
 
*
 
*
 
 
===Implementations/ Case Studies (Actual Users)===
 
===Implementations/ Case Studies (Actual Users)===
*
+
*This document is the Service Functional Model (SFM) for the Decision Support Service, which is specified under the Service Development Framework process under the auspices of the Healthcare Services Specification Project (HSSP). 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.
*
+
 
 
===Resources===
 
===Resources===
  
Line 46: Line 44:
 
====Education====
 
====Education====
 
* See more at http://www.hl7.org/implement/training.cfm
 
* See more at http://www.hl7.org/implement/training.cfm
 +
<!--
 
=====Certification Available=====
 
=====Certification Available=====
 
*none
 
*none
Line 54: Line 53:
 
*
 
*
 
====Links to current projects in development====
 
====Links to current projects in development====
*
+
*-->

Latest revision as of 19:00, 11 November 2009

Product Brief - Decision Support Service Functional Model (DSS SFM)

back to Main_Page
back to Product List

Product Name

Decision Support Service Functional Model (DSS SFM)

Standard Category

Application Functional Specifications - Services (SOA)

Integration Paradigm

Services

Type

DSTU

Releases

  • DSTU: HL7 Version 3: Decision Support Service (DSS), Release 1. This DSTU has been extended an additional 24 months upon the approval of the TSC as indicated in TSC Tracker item #996. Ends April 2011

Summary

The Decision Support Service Functional Model (DSS SFM) Draft Standard for Trial Use (DSTU) is a draft functional standard defining the functions, responsibilities, inputs, outputs, and expected behavior of a system component for evaluating patient data to reach patient-specific conclusions. A DSS, for example, can evaluate a patient’s health summary as encoded in a Continuity of Care Document (CCD) and provide structured recommendations regarding the patient’s health maintenance and chronic disease management needs. The DSS SFM is among the first healthcare standards specifically designed to support a service-oriented architecture (SOA), and establishes a basis for an unprecedented collaboration with the Object Management Group (OMG), which has adopted a technical specification complementing this SFM.

Description

  • How does this relate to the OMG Technical Specification and to the Healthcare Services Specification Project?
    • For EIS, HL7 has partnered with OMG to produce technical specifications supporting Service Functional Models within OMG’s technology adoption process. To the healthcare industry, this provides value via OMG’s rigorous architectural approach, review process, and distributed systems expertise. For OMG, this relationship brings deep healthcare experience via HL7’s extensive international participation and vertical industry expertise. The Healthcare Services Specification Project (HSSP) is a moniker for the collaboration between groups collaborating on service standards, of which HL7 and OMG are participants.
  • How does this relate to the HL7 Services-Aware Enterprise Architecture Framework?
    • In 2008, HL7 embarked upon developing its Services-Aware Enterprise Architecture Framework (SAEAF). SAEAF will be aligning the broad range of HL7 specifications—including services, messages, and document standards—to a consistent approach across the whole of HL7’s offerings. SAEAF also specifies usage constraints for deployed HL7 standards. Several HSSP services predate SAEAF. Over time, we expect all HL7 Service Functional Models to come into alignment with SAEAF.
  • Don’t industry standard services (such as the Decision Support Service, Entity Identification Service) limit vendor competition?
    • Not necessarily. While industry standards specify how a consumer interacts with the service, these specifications have expressly left how these functions are supported out-of-scope. In other words, there is no predetermined knowledge modeling formalism, system design platform, or approach that is advocated in the standard. Vendors are able to compete based upon quality-of-service and the benefits of their specific implementation. Further, the specification includes mandatory and supplemental requirements (“nice-to-haves”), which can further stratify marketplace offerings.

Business Case (Intended Use, Customers)

  • Vendor: Decision Support systems;
  • Healthcare providers seeking Decision Support Systems

Benefits

Quite simply, the Decision Support Service defines the collective set of behaviors that one would expect a clinical decision support engine to perform. This functionality is required of most healthcare organizations and allows for the data collected in electronic health records and other clinical information systems to provide enhanced value for patients, clinicians, healthcare providers, and payors. The challenge is that the lack of a standard makes the use of decision support services more costly and difficult. Without clearly defined expectations of how Decision Support Services should interface with health information systems, variants abound and interoperability suffers.

Implementations/ Case Studies (Actual Users)

  • This document is the Service Functional Model (SFM) for the Decision Support Service, which is specified under the Service Development Framework process under the auspices of the Healthcare Services Specification Project (HSSP). 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.

Resources

Work Groups

Education