TSC Product List SFM

Product Briefs - Services Functional Models

back to 2009_TSC_Product_Visibility

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.

Product Brief - Entity Identification Service Functional Model (EIS SFM)

Summary

The Entity Identification Service Functional Model (EIS 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 managing identities, such as would be used in a Master Patient Index (MPI). Not limited to use for Patients, the EIS SFM can be equally applied to manage identities for staff, providers, facilities, or any other “entities” needing identity management. The EIS 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) whom has adopted a technical specification complementing this SFM.

Description

Why produce an industry standard Identification Service?

Quite simply, the Entity Identification Service defines the collective set of behaviors that one would expect system components such as an MPI to perform. This functionality is required of most healthcare organizations and supported by many vendors and product. The challenge is that each one does things a bit differently, and making them work together becomes exponentially complex. Without clearly defined expectations of what falls within the responsibility of the Identification Service, variants abound and interoperability suffers.

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

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.

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.

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

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.

Business Case

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.

Resources

Presentations

back to 2009_TSC_Product_Visibility