Difference between revisions of "Product RLUS SFM"
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | =Product Brief - Retrieve, Locate, Update Service Functional Model (RLUS 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=== | ||
Retrieve, Locate, Update Service Functional Model (RLUS SFM) | Retrieve, Locate, Update Service Functional Model (RLUS SFM) | ||
| − | + | <!-- | |
===Topics=== | ===Topics=== | ||
| − | + | --> | |
===Standard Category=== | ===Standard Category=== | ||
Application Functional Specifications - Services (SOA) | Application Functional Specifications - Services (SOA) | ||
===Integration Paradigm=== | ===Integration Paradigm=== | ||
Services | Services | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
===Type=== | ===Type=== | ||
| − | + | DSTU | |
===Releases=== | ===Releases=== | ||
| − | * | + | *HL7 V3 RLUS, R1 December 2006 |
===Summary=== | ===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 | + | 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. |
| − | standard access mechanism, promoting consistency | ||
| − | within a heterogeneous environment. | ||
===Description=== | ===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. | 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. | 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. | ||
| Line 36: | Line 30: | ||
===Business Case (Intended Use, Customers)=== | ===Business Case (Intended Use, Customers)=== | ||
| − | * | + | *Vendors: Health Care IT, |
| + | *Providers: Hospitals and Health Networks, | ||
| + | *Integrators/consultants | ||
===Benefits=== | ===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: | |
| − | + | #RLUS interfaces could be a fundamental component of any distributed health record system. | |
| − | + | #RLUS interfaces may be included as a functional set of service interfaces for their healthcare applications. | |
| + | #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. | ||
| + | <!-- | ||
===Implementations/ Case Studies (Actual Users)=== | ===Implementations/ Case Studies (Actual Users)=== | ||
* | * | ||
| − | * | + | *--> |
===Resources=== | ===Resources=== | ||
| Line 51: | Line 50: | ||
*[http://www.hl7.org/Special/committees/soa/index.cfm Services Oriented Architecture (SOA)] | *[http://www.hl7.org/Special/committees/soa/index.cfm Services Oriented Architecture (SOA)] | ||
====Education==== | ====Education==== | ||
| − | * See more at http:// | + | * See more at http://www.hl7.org/implement/training.cfm |
| + | <!-- | ||
=====Certification Available===== | =====Certification Available===== | ||
*none | *none | ||
| + | |||
====Presentations==== | ====Presentations==== | ||
| − | * | + | *--> |
====Relationship to/ Dependencies on, other standards==== | ====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==== | ====Links to current projects in development==== | ||
| − | * | + | *[http://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm?action=edit&ProjectNumber=268 Project Insight # 268], Infrastructure: Resource Location and Updating Service Functional Model |
Latest revision as of 20:29, 11 November 2009
Product Brief - Retrieve, Locate, Update Service Functional Model (RLUS SFM)
Contents
- 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:
- RLUS interfaces could be a fundamental component of any distributed health record system.
- RLUS interfaces may be included as a functional set of service interfaces for their healthcare applications.
- 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
- See more at http://www.hl7.org/implement/training.cfm
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
- Project Insight # 268, Infrastructure: Resource Location and Updating Service Functional Model
