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

Product RLUS SFM

From HL7Wiki
Jump to navigation Jump to search

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)

Standard Category

Application Functional Specifications - Services (SOA)

Integration Paradigm

Services

Type

DSTU

Releases

  • HL7 V3 RLUS, R1 December 2006

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

The Retrieve, Location, and Updating Service (RLUS) provides a set of interfaces through which information systems can access and manage information. RLUS allows health data to be located, accessed and updated regardless of underlying data structures, security concerns, or delivery mechanisms.

RLUS explicitly occupies the service space within an information processing environment. It is independent of, but compatible with, underlying structures, including local security implementations, data models, or delivery mechanisms. By separating and exposing those aspects of resources that facilitate inter-organization work flows in a service layer, this specification abstracts the problem of interoperability away from underlying systems. It is this abstraction and reconfiguration that allows interoperability and system durability independent of burdensome technology integration.

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)

  • Vendors: Health Care IT,
  • Providers: Hospitals and Health Networks,
  • Integrators/consultants

Benefits

Within a mobile society, the value of healthcare information systems will ultimately be derived from their ability to locate, process, and supply healthcare resources found in other systems and different formats. RLUS takes the healthcare marketplace volatility as a given, and provides a primary interaction mechanism between systems, remaining independent but complementary to underlying technologies. RLUS gives vendors several opportunities:

  1. RLUS interfaces could be a fundamental component of any distributed health record system.
  2. RLUS interfaces may be included as a functional set of service interfaces for their healthcare applications.
  3. Vendors can add value to the customer’s solution with the addition of one or more RLUS-conformant services. This increases the scope of each customer’s reach, and in turn allows additional value to be available to other clinical practices.

RLUS provides architects and designers with an effective mechanism to specify, scope, and implement the portions of a healthcare enterprise architecture committed to interoperability. Whether this interoperability is between departments, systems, or organizations, RLUS embodies a flexible, responsive methodology that shortens design time and reduces product iterations.

Resources

Work Groups

Education

Relationship to/ Dependencies on, other standards

  • Standards such as the Common Terminology Service (CTS), the emerging CTS II specification, and work in progress such as the Entity Identification Service all form foundational elements that will benefit RLUS. Other HL7 standards relevant include HL7 CDA, EHR, RIM, the IHE XDS Cross Enterprise Document Exchange, and the W3C's URI.

Links to current projects in development