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

Product EIS SFM

From HL7Wiki
Revision as of 19:53, 17 July 2009 by Llaakso (talk | contribs) (New page: ==Product Brief - Entity Identification Service Functional Model (EIS SFM)== :back to Main_Page :back to Product List ===Product Name=== Entity Identification Service...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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

back to Main_Page
back to Product List

Product Name

Entity Identification Service Functional Model (EIS 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 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.

Business Case (Intended Use, Customers)

Benefits

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