| Oracle® Healthcare Master Person Index Relationship Management User's Guide Release 4.0 E71323-02 |
|
|
PDF · Mobi · ePub |
| Oracle® Healthcare Master Person Index Relationship Management User's Guide Release 4.0 E71323-02 |
|
|
PDF · Mobi · ePub |
Oracle Healthcare Master Person Index (OHMPI) is used for identity resolution and creates single views of various healthcare domains, such as Patients, Individual Providers, Investigators, Payers, Organizational Providers, and so on. Within the same domain and between these domains data is highly connected and related and the volume of relationship association can be high. The association views are complicated based on many different types of relationship association.
OHMPI Relationship Management (RM) is created for managing the complex relationships as addressed above between providers and patients, among providers, and among patients based on dynamic property changes in today's healthcare setting. It also allows you to apply relationship inferring rules for advanced relationship computation and discovery. OHMPI RM is built upon metadata-driven and open architecture for offering flexible relationship data modeling and customization. OHMPI RM is based on standard open architecture for providing pluggable and extensible capability.
OHMPI relationship data model is based on the standard entity-relationship (ER) data model which uses the mathematical relation construct to express relationships between entities. The OHMPI RM relationship is an explicit linkage between two master entities within a single master domain or across master domains if master entities relates. In other word, the relationships that the OHMPI RM manages are based on a single trusted view of data. The master entities are such as Patients, Individual Providers, Organizational Providers, Payers, Investigators, and so on. The OHMPI RM relationship is represented as a tuple of source, target, and relation in Figure 1-1.
The OHMPI RM is typed model. The relationship type is a type of association that can be present between two master entity types or with a single master entity type. The master entity is also known as MPI domain. It is the template for relationship which defines built-in system default relationship attributes and customer-defined relationship attributes. In process perspective there is no difference between system default relationship attributes and customer-defined attributes. The relationship types are such as Patient-of, PCP-of, Admitting-Physician-of, Emergency-Contact and more. The relationship types are divided into different categories, such as Provider and Patient relationship category, Family relationship category, and so on.
By definition, relationship implies relationship instance of a specific relationship type.
Any names for relationship type, entity type, attribute, ruleset, and task:
Non-case sensitive
Start with alphabets
Mix with any letters, digits, and underscore
Avoid one-character names
Any names of relationship types can be mixed with hyphen
Any resources naming and query parameters of the RM REST APIs:
Non-case sensitive
Any Ids:
Mix with any letters and digits
Non-case sensitive
The direction of a relationship can be either bidirectional or unidirectional. A bidirectional relationship has both an owning side and an inverse side. A unidirectional relationship has only an owning side. The owning side of a relationship determines how the RM runtime makes creations to the relationship or query relationships in the database. In a unidirectional relationship, only owning side can create or navigate relationships. In other words, the navigation or creation can be done only from the source side. In a bidirectional relationship, both sides of source and target can create or navigate relationships.
The following are the types of multiplicities:
One-to-one: One source entity instance is related to one single instance of another target entity.
One-to-many: One source entity instance can be related to multiple instances of the other target entities.
Many-to-one: Multiple instances of a source entity can be related to one single instance of the other target entities.
Many-to-many: Multiple source entity instances can be related to multiple instances of the other targets.
The validity of relationship is the state of being a valid relationship. The validity can either be:
Resolved: If the relationship is valid
OR
Potential: If the validity of the relationship is not decided yet
The potential relationship is created when the relationship management performs probabilistic match on the domain MPI database for the inbound messages and could not find any assumed match. The domain MPI application responses back with a list of potential duplicates. The human review process or intelligent business workflow is required to determine any match or no match from the potential duplicates. Without the determination of match or no match, the relationship management creates the relationship with the Potential state using the potential duplicate. This relationship is named as potential relationship. The potential relationship is not actual resolved relationship. The determination of resolving the potential state is made through the post process such as the human review process or intelligent business workflow. The Resolved relationship is the actual relationship. There shall not be any ambiguity of potential entities.
For more information, see Chapter 4, "Relationship Management Databases".
The relationship rule is used for defining the business logic and process for discovering relationships. It is definitive, pluggable, and standard-based.
For more information, see Chapter 5, "Relationship Discovery and Relationship Rules".
The relationship policy is used for defining the business logic and process for processing relationships. There are two types of relationship policies: relationship update policy and relationship event policy. The relationship update policy defines the business logic and process on how to update the existing relationships. The relationship event policy defines the business logic and process on how to react with the events from the external applications. Both are definitive, pluggable, and standard-based.
For more information, see Chapter 6, "Relationship Update and Event Policies".
This section addresses the relationship management process and architecture. The relationship management application contains the design time and run time modules. The relationship management design-time is a NetBeans IDE plug-in. To create a relationship management project, the relationship management wizard takes your input, such as application server, the application name, the application location, date format, maximum file size, maximum rows fetched, and so on.
Figure 1-2 illustrates the architecture diagram of the relationship management design-time.
Figure 1-2 Relationship Management Design Time
The relationship management design time NetBeans wizard is used to:
Create the relationship management project
Generate the relationship management service application
Configure the relationship management service application
Build the relationship management service application
Generate the relationship management database scripts
Generate the relationship management data manager application
Configure the relationship management data manager application
Build the relationship management data manager application
Generate the relationship management MPI agent application
Configure the relationship management MPI agent application
Build the relationship management MPI agent application
Each OHMPI application requires its own dedicated relationship management MPI agent application. The wizard will generate the different MPI agent application for different MPI domain. Once you build all the relationship management applications, you deploy the relationship management service application and the relationship management data manager applications in the same Oracle WebLogic environment or the distributed environment. And deploy the relationship management MPI agent application to the Oracle WebLogic environment where the OHMPI application runs with the outbound event notification properly configured.
Figure 1-3 illustrates the architecture diagram of the relationship management runtime.
Figure 1-3 Relationship Management Runtime
The relationship management runtime provides the core services of the relationship managements. The services are exposed as a set of REST APIs. The metadata resources REST APIs provide the capability of managing the relationship types and entity types. The service resources REST APIs provide the capability of managing the instances of relationships and entities. The integration resources REST APIs are used for integrating with the OHMPI application underlying. The management resources REST APIs provides the capability of managing the MPI domains, rulesets, and tasks. The statistics resources REST APIs provide the capability of retrieving the statistical information about the relationship management applications.
For more information on the relationship management REST APIs, see Oracle Healthcare Master Person Index Relationship Management REST APIs Reference Guide.
The relationship management MPI agent application is used to integrate with the OHMPI applications asynchronously to react with various MPI outbound events through the standard JMS topic. For more information, see Section 6.2, "Relationship Event Policies".
The relationship management data manager application is the web-based relationship management data stewardship. It allows you to create or update the metadata on the fly. For more information, see Oracle Healthcare Master Person Index Relationship Management Data Manager User's Guide.
The OHMPI MIDM application can be integrated with the relationship management data manager directly. With the proper configuration, you can search relationships based on the result of the entity search from the OHMPI MIDM. For more information, see Chapter 3, "Integrating with Master Person Index Applications".
The relationship management application consists of several different components. Each component can be deployed individually or optionally in a distributed fashion. The relationship management application can run without associating with any MPI domain application in a generic relationship management standalone fashion. The relationship management application also can integrate tightly with the MPI domain applications. The integration is done through the comprehensive relationship management REST APIs and the relationship management API agent. The major deployable components consist of:
The relationship management service provides the core services of all the relationship managements. The services are exposed as the standard REST APIs. The relationship management service is packaged as a war application and deployed to the Oracle WebLogic server.
For more information on the RM REST APIs, see Oracle Healthcare Master Person Index Relationship Management REST APIs Reference Guide.
The relationship management data manager is a web-based data management console which provides the customers an ability to manage the relationship types, entity types, domains, rulesets, and tasks. It also allows the customers to search entities and relationships from any supported internet browsers.
For more information, see Oracle Healthcare Master Person Index Relationship Management Data Manager User's Guide.
The relationship management MPI agent is used for integrating with OHMPI applications asynchronously through OHMPI outbound JMS-based notifications. Each OHMPI application is required to deploy one-dedicated RM MPI agent which runs in the same domain where the OHMPI executes.
For more information on integrating with OHMPI outbound events, see Section 6.2, "Relationship Event Policies".
One instance of the relationship management service is able to interact with multiple OHMPI applications. For more information, see Oracle Healthcare Master Person Index guides.
The following are the deployment strategies:
The standalone deployment strategy is generic deployment manner.
Deploy the relationship management database schema to the Oracle Database.
Deploy the relationship management service to the Oracle WebLogic server.
Deploy the relationship management data manager to the Oracle WebLogic server.
Figure 1-4 Relationship Management Deployment in Standalone Mode
The integration deployment strategy is integration deployment manner. The relationship management is integrated with the OHMPI application(s) through MIDM and relationship management integration REST APIs.
Deploy the integrated OHMPI MPI application(s).
Deploy the relationship management database schema to the Oracle Database.
Deploy the relationship management service to the Oracle WebLogic server.
Deploy the relationship management data manager to the Oracle WebLogic server.
Figure 1-5 Relationship Management Integration Deployment
The MPI agent deployment strategy is asynchronous integration deployment manner. The relationship management is integrated with the OHMPI application(s) through the MPI agent(s).
Deploy the integrated OHMPI MPI application(s).
Deploy the relationship management database schema to the Oracle Database.
Deploy the relationship management service to the Oracle WebLogic server.
Deploy the relationship management data manager to the Oracle WebLogic server.
Deploy the relationship management MPI agent to the Oracle WebLogic server.
Figure 1-6 Relationship Management MPI Agent Deployment
|
 Copyright © 2016, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
