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

Difference between revisions of "Product RLUS SFM"

From HL7Wiki
Jump to navigation Jump to search
(New page: ==Product Brief - Retrieve, Locate, Update Service Functional Model (RLUS SFM) == :back to Main_Page :back to Product List ===Product Name=== Retrieve, Locate, Update...)
 
Line 12: Line 12:
 
===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===

Revision as of 20:00, 17 July 2009

Product Brief - Retrieve, Locate, Update Service Functional Model (RLUS SFM)

back to Main_Page
back to Product List

Product Name

Retrieve, Locate, Update Service Functional Model (RLUS SFM)

Topics

Standard Category

Application Functional Specifications - Services (SOA)

Integration Paradigm

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

Releases

Summary

The Retrieve, Locate, Update Service Functional Model (RLUS 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 capable of querying information and returning data and metadata between systems. Although fairly abstract in nature, RLUS is actually very simple to understand—it provides a generic query and retrieval mechanism that can be used for a multitude of information content via a standard access mechanism, promoting consistency within a heterogeneous environment.

Description

For example, an organization may have a benefits/ enrollment system, an Electronic Health Record System, and a Personal Health Record System all within the organization. Intregrating information from among these systems can be complex. RLUS could be used to further this integration by building an RLUS-compatable interface into each of the above systems, and making a distributed RLUS call to retrieve pertinent information for a specific patient. The RLUS specification standardizes how disparate information types are managed and aggregated into a single result. Further, since RLUS provides a mechanism for new, richly structured information content to be supported, integration based upon RLUS allows for new systems to come online and integrate into the organization’s infrastructure. RLUS specifies a collection of behaviors needed to manage this inquiry, query, and retrieveal of content. The “location” function allows for the return of candidate information, indicating the availability of matching records without actually returning their instances (for example, does the system have any positive zzzz lab results for patient X). Other interface behaviors specify how the targeted information can be retrieved or updated. The RLUS SFM is among the first healthcare standards targeted to support a service-oriented architecture (SOA), and is at the basis for an unprecendented collaboration with the Object Management Group (OMG), whom has adopted a technical specification complementing this SFM.

Business Case (Intended Use, Customers)

Benefits

What is the benefit to using RLUS?

Integration of new software packages in a heterogeneous environment creates an exponential integration problem. Each new system-to-system interface creates tremendous integration burden in terms of creating messages, mapping data fields, and potentially transforming data for use. Interface engines have a role to play here, but do not directly support complex queries among participating systems. RLUS allows for these complexities to reside within the systems that hold the data, shielding requestors from unnecessary detail. RLUS simplifies the ask-answer pattern, providing both rigor and clarity while supporting rigorous information content.

Implementations/ Case Studies (Actual Users)

Resources

Work Groups

Education

Certification Available
  • none

Presentations

Relationship to/ Dependencies on, other standards

Links to current projects in development