G06F17/30557—Details of integrating or interfacing systems involving at least one database management system

G06F17/3056—Details of integrating or interfacing systems involving at least one database management system between a Database Management System and a front-end application

Abstract

Embodiments disclosed herein provide an implementation defined segments (IDS) subsystem which allows new data segments to be added to an identity hub after deployment. A set of metadata tables are utilized to describe IDS, each of which is a data structure encapsulating a single row from a master data record residing in the identity hub. Once a segment (an object) is described, the identity hub can use the information to define persistent storage for the object in the database for any relational database management system, create internal structures to hold the data and process business rules and demographic comparisons against the data object, describe the data object to remote clients, and allow the clients to query the identity hub at runtime about what data objects exist, what fields and data types they contain, and additionally how they might be displayed or formatted on various clients.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001]

This application claims priority from U.S. Provisional Application No. 60/845,073, filed Sep. 15, 2006, entitled “METHOD AND SYSTEM FOR IMPLEMENTATION DEFINED SEGMENTS USING META-DATA,” which is fully incorporated by reference herein.

TECHNICAL FIELD

[0002]

This disclosure relates generally to relational database systems and more particularly to data structures and processing in relational database systems. Even more particularly, embodiments disclosed herein relate to a system and method of creating implementation defined segments at runtime based on metadata.

BACKGROUND

[0003]

For a software system to support the data needs of two or more vertical industries, it usually must make compromises in what data is available, or provide a large superset (e.g. the ability to encompass the data needs of all the industries it is desired to support) with many unused data items in order to satisfy the greatest common denominator. For instance, those demographic data items that may be important in a medical record registration application, may not have any use to a hotels central reservation system.

[0004]

One way to support multiple vertical markets with the same application or software system (product) is to have a very generic data storage capability which does not have anything specific to a given industry, application or format. The problem with this approach is that the data items which are specific to an industry or application may be those that are most valuable to the customer. Some industries have Electronic Data Interchange Standards that can be used, but they do not fit every application and rarely have wide acceptance.

[0005]

Another solution to the above problem is to create a large, all encompassing data model which tries to anticipate every conceivable contingency. This is cumbersome to install, and requires that the users wade through unused scaffolding if their particular business does not require the extra fields. And despite best efforts, they may still have requirements which are not included in the model.

SUMMARY OF THE DISCLOSURE

[0006]

Embodiments disclosed herein provide systems and methods that can eliminate or reduce the disadvantages of previously developed solutions to supporting multiple vertical industries with the same software system. More particularly, embodiments disclosed herein provide a way to describe data objects that will be used by the Initiate Identity Hub™ Software, and to store that description inside the Identity Hub database in a set of metadata tables known generically as the data dictionary. Initiate™ and Initiate Identity Hub™ are trademarks of Initiate Systems, Inc. Once a data object has been described, the Identity Hub can use the information to:

[0007]

1. Define persistent storage for the object in the database for any relational database management system (RDBMS) type supported by the Identity Hub software;

[0008]

2. Create internal structures to hold the data and process business rules and demographic comparisons against the data object;

[0009]

3. Create the on-the-wire protocol definition that describes the data object to remote clients using APIs such as the Initiate Identity Hub APIs. The communication software (e.g., contained in the Identity Hub) can transmit and receive these data objects without prior, hard coded knowledge; and

[0010]

4. Provide a mechanism in the APIs to query the Identity Hub at runtime about what data objects exist, what fields and data types they contain, and additionally how they might be displayed or formatted on various clients.

[0011]

Embodiments disclosed herein may be implemented entirely in software or may be implemented at least partially in hardware.

[0012]

By adopting embodiments disclosed here to generate Implementation Defined Segments (IDS), software implementers (e.g., partners, customers, or Initiate services employees) can create custom attribute segments on an installation by installation basis. The users of the Initiate Identity Hub software can benefit from having access to the data that is vital to their industry or application specific data needs. Each customer does not have to conform to some pre-defined, limiting data model. Moreover, there is no need to create custom application code for sites that want to take advantage of this feature. The IDS data segments will behave substantially exactly like hard-coded, pre-defined segments. The legacy pre-defined segments in use in older implementations can use the IDS technology under the covers, and over time the pre-defined segments can be deprecated, and replaced with a pure IDS implementation.

[0013]

Other features, advantages, and objects of the disclosure will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014]

A more complete understanding of the present invention and the advantages thereof may be acquired by referring to the following description, taken in conjunction with the accompanying drawings in which like reference numbers indicate like features and wherein:

[0015]

FIG. 1 depicts a simplified schematic representation of one embodiment of a computer network which includes a client computer and a server computer;

FIG. 8 shows a screenshot of one embodiment of an Add Segment component of Identity Hub Manager of FIG. 4 through which Implementation Defined Segments can be added;

[0023]

FIG. 9 shows a screenshot of one embodiment of an Add Field component of Identity Hub Manager of FIG. 4 through which field(s) can be added to a segment; and

[0024]

FIG. 10 depicts a schematic representation of one embodiment of an exemplary method of accessing data segments in a computer network.

[0025]

Skilled artisans appreciate that elements in the figures are illustrated for simplicity and clarity and are not necessarily drawn to scale.

DETAILED DESCRIPTION

[0026]

Preferred embodiments of the present invention and the various features and advantageous details thereof are explained more fully with reference to the examples illustrated in the accompanying drawings where like numerals are used to refer to like and corresponding parts or elements. Descriptions of known computer languages, data structures, programming techniques, operating systems, network protocols, and the like are omitted so as not to unnecessarily obscure the invention in detail. Skilled artisans should understand, however, that the detailed description and the specific examples, while disclosing preferred embodiments of the invention, are given by way of illustration only and not by way of limitation. Various substitutions, modifications, additions or rearrangements within the scope of the underlying inventive concept(s) will become apparent to those skilled in the art after reading this disclosure.

Each of client computers 12 and 16 is an example of a data processing system. ROM 122 and 162, RAM 124 and 164, HD 126 and 166, and database 18 include media that can be read by CPU 120 or 160. Therefore, each of these types of memories includes a data processing system readable medium. Within this disclosure, the term “data processing system readable medium” is used interchangeably with the term “computer-readable storage medium.” These memories may be internal or external to computers 12 and 16.

[0029]

Embodiments described herein may be implemented in suitable software code that may reside within ROM 122 or 162, RAM 124 or 164, or HD 126 or 166. In addition to those types of memories, some instructions implementing embodiments disclosed herein may be contained on a data storage device with a different data processing system readable storage medium, such as a floppy diskette. FIG. 2 illustrates a combination of software code elements 204, 206, and 208 that are embodied within a data processing system readable medium 202, on HD 166. Alternatively, the instructions may be stored as software code elements on a DASD array, magnetic tape, floppy diskette, optical storage device, or other appropriate data processing system readable medium or storage device.

[0030]

In an illustrative embodiment, the computer-executable instructions may be lines of compiled C++, Java, or other language code. Other computer architectures may be used. For example, some functions of client computer 12 may be incorporated into server computer 16, and vice versa. Further, other client computers (not shown) or other server computers (not shown) similar to client computer 12 and server computer 16, respectively, may also be connected to network 14.

[0031]

Communications between client computer 12 and server computer 16 can be accomplished using electronic, optical, radio frequency, or other signals. When a user is at client computer 12, client computer 12 may convert the signals to a human understandable form when sending a communication to the user and may convert input from a human to appropriate electronic, optical, radio frequency, or other signals to be used by client computer 12 or server computer 16.

[0032]

FIG. 3 depicts a simplified schematic representation of one embodiment of Initiate Identity Hub 300. In some embodiments, Hub 300 resides on a server computer (e.g., server computer 16). As an example, Hub 300 can be seen as a customer data integration hub that is built to operate in a network environment (e.g., Service-Oriented Architecture (SOA) environment) and can support any business application that uses Web Services, providing a layer of business services for accessing and manipulating the customer data. Components of Hub 300 may include Services 310, Engine 320, Manager 330, and Database 340. Services 310 contains software code including computer-executable instructions implementing Web services, interfaces (e.g., PDS, Java, C++ application programming interfaces (API), etc.), and inbound/outbound brokers (e.g., inbound and message managers, etc.) for handling incoming/outgoing requests/responses (e.g., connection requests, authentication, authorization, etc.). In some embodiments, components of Engine 320 may include shared objects, identity rules engine, comparison engine, and algorithms. Engine 320 is built to perform core functions of Hub 300 including strategic customer data integration, identification and recognition operations that generate results that are consumable by external systems as part of an SOA. Functionality of Engine 320 may be managed via Manager 330, some of which will be described in further detail below.

[0033]

Embodiments of Hub 300 provide accurate, scalable, and deployable solutions for customer-centric master data management as Hub 300 enables business entities to create complete, real-time views of data from various data sources 350 and applications 360 to more effectively manage, control, analyze and integrate customer, patient or constituent information and relationships while protecting data privacy. In particular, Hub 300 has the ability to handle hundreds of millions of records in sub-second response times with unique proprietary matching and linking technology that identifies and resolves information routinely, even when there is duplicate, fragmented or incomplete data. Within this context, Manager 330, embodied in a software application, enables administrators and implementers (i.e., system administrators, application administrators, database administrators, software developers, software engineers, system architect, and those responsible for implementing Initiate™ software applications) to easily manage Hub 300 software environment via a user interface. In this example, Manager 330 is installed on a server and accessible via an Intranet. In some embodiments, Manager 330 can be installed and run directly on a workstation.

[0034]

FIG. 4 shows a screenshot of one embodiment of exemplary user interface 430 of Manager 330. In this example, user interface 430 has top menu area 402, side menu area 406, and workspace 404. In some embodiments, side menu area 406 displays selectable icons with links to a plurality of functions, including Security for setting and maintaining user security, Applications for managing Initiate™ applications, Composite Views for creating composite views (which can be used by other applications such as the Initiate™ Enterprise Viewer application), Data Dictionary for viewing and editing data dictionary tables, Reporter Database for scheduling and running the reporting database extraction process, and Libraries for viewing and editing libraries and library functions (e.g., standardization, derived data, bucketing, and comparison). Embodiments described below are directed to Implementation Defined Segments that can be created through Data Dictionary for use by other components/applications such as Security.

[0035]

FIGS. 5A-5C show screenshots of one embodiment of a Security component of Identity Hub Manager 330 in which segment attributes are used to set up Group Permissions. In an enterprise environment, a user can be assigned to and thus affiliated with one or more groups that best fit their individual job requirements. For example, a manager in a company may need to look at member records and understand what records are involved in certain tasks, but not actually work the tasks. In that case, a group can be created with group permissions for member searches, member retrieves, and task searches. A group of users responsible for working the tasks would need additional permissions that would enable them to edit records, tasks, and attributes. FIG. 5A shows a screenshot of an exemplary Group Permissions window having a plurality of tabs including Composite Views, Interactions, Sources Member Attributes, and Segment Attributes. Each of the tabs enables an administrator/implementer to specifically define a particular type of permissions for each user group. For example, through the Composite Views tab, the administrator/implementer can select/unselect different types of views allowed for each group; through the Interactions tab, the administrator/implementer can define what actions that members of a group can perform; through the Sources tab, the administrator/implementer can restrict group member access to a specific data source or sources (e.g., hospitals; see FIG. 5A); through the Member Attributes tab, the administrator/implementer can identity what attributes (e.g., Address, Birth Date, etc.) a particular group can see (see FIG. 5B); and through the Segment Attributes (e.g., mpi_appdata, etc.; see FIG. 5C), the administrator/implementer can identify what data segments (e.g., member segments such as mpi_memname, mpi_memaddr, mpi_memdate, etc.) a particular group can use (see FIG. 6).

[0036]

Data segments or simply segments coincide with data schema of Hub 300 to define behavior of Engine 320 and member information. In some embodiments, a set of pre-defined (“fixed”) segments are created and packaged with Hub 300 prior to deployment. In some embodiments, implementers can add member-attribute implementation defined (“custom”) segments through Manager 330 upon/after deployment. Within this disclosure, each segment is a data structure which encapsulates a single row from the coinciding database table. In embodiments disclosed herein, segments are used as data storage structures for data that may be read from a database (e.g., database 350), or sent in from a client application (e.g., application 360). When Engine 320 operates on data, it passes around a set of these segment objects (i.e., they are Shared Objects).

[0037]

FIG. 6 shows a screenshot of one embodiment of exemplary Data Dictionary 600 of Manager 330. In this example, Data Dictionary 600 has a plurality of tabs including Segments 602 for viewing and editing segments. Segments can be added by selecting Add Segment icon or button 604. Unlike pre-defined segments (e.g., MemName, MemAddr, Memldent, etc.) which are created and then shipped to customers as part of Hub 300, implementation defined segments (IDS) are created at the time Hub 300 is implemented—by an implementer or an administrator—and therefore are not associated with a generated class. In some embodiments, when a segment is added an associated Data Definition Language (DDL) statement is also added. In some embodiments, each time an IDS is changed, an associated DDL statement is generated. Examples of DDL statements generated by Manager 330 are provided below.

[0038]

In some embodiments, there are three types of segments: dictionary segments, member segments, and audit segments. Audit segments enable reporting and tracking. Member segments define individual entities (i.e., members and members associated with an entity), member attributes, and task workflow. In some embodiments, only member attribute segments can be defined at the time of implementation. Dictionary segments contain type definition and lookup values. These values define customer specific data, engine behavior, and other segment types. Dictionary segments can be divided into five sections.

b. Segment Definitions—enable the definition of internal (internal to Hub 300) and customer-specific (i.e., implementation defined) segments that are maintained by Hub 300;

[0041]

c. Source Definitions—enable the definition of source systems recognized by Hub 300 and the interactions therebetween;

[0042]

d. Use Segments—provide Hub 300 specific configuration that defines behavior of Engine 320, which includes comparison, derived data, and standardization strategies, as well as linkage rules and other behavior rules; and

In the past, a segment was defined by what was referred to as a package. Packages were hard-coded C language structures that defined the data fields, what data type those fields were, and how the system should treat those fields. Packages proved to be a very powerful way to describe data in a manner that the rest of the Initiate Identity Hub™ software could use to operate on the data. However, because these packages were hard-coded C language structures, if a new segment definition is needed, a code change had to be made in the Initiate Identity Hub™ engine, a database table that matched the change had to be made, and any API changes needed for others to be able to access the new segment also had to be made.

[0046]

Embodiments of an Implementation Defined Segments subsystem disclosed herein represent an innovative way to support new segments without having to ship and support new code at each customer site that has unique data requirements. Instead of the package mechanism described above, a set of database tables, also referred to as metadata tables, would be read at system start-up to define the shape of the package data structures. If an implementer or administrator needs to change a segment, or add a new one, the implementer/administrator could just add the proper data to the database, and on the next restart of Engine 320, Hub 300 would behave exactly as if the segment information had been hard-coded in the packages.

[0047]

FIG. 7 depicts a schematic representation of one embodiment of metadata tables for defining Implementation Defined Segments. Two tables, mpi_seghead 702 and mpi_segxfld 704, are used to describe a segment for use by Engine 320. Mpi_seghead 702 contains the unique name of the segment (i.e., one row exists for each segment definition). This is joined to mpi_segxfld 704 which defines the individual fields contained in each segment in mpi_seghead 702. Mpi_segattr 706 does not define the shape or structure of the data. Rather, Mpi_segattr 706 defines the role in which a particular data segment will be used. For example, an implementer could define a segment called “phone” which would have a row in mpi_seghead 702, then one or more rows in mpi_segxfld 704 describing the fields which make up a “phone” segment. As an example, mpi_segxfld 704 might contain fields for the international calling code, the area code, prefix, and the local number itself. Once this “phone” segment is defined, several roles for this shaped segment can be defined by making rows in mpi_segattr 706 for HOMEPHONE, WORKPHONE, or MOBILEPHN. This would allow the implementer to logically separate the generic phone data segment into logical rows for specific processing. Detailed definitions of these metadata tables are provided in Tables 1-3 below. Examples are provided in Tables 4-5 below.

[0000]

TABLE 1

mpi_seghead Details

Expanded name

Segment Definition Header

Initiate ™

This dictionary table provides the bridge between the

software use

logical names for storage segments, and the physical

tables in which they are stored.

mpi_seghead Attribute Descriptions

Attribute

Description

caudrecno

Creation of this particular record, from mpi_audhead

maudrecno

Last time the record value was modified, from

mpi_audhead

recstat

Record status - ‘A’ctive, ‘I’nactive, ‘D’eleted, ‘S’hadow

segrecno

Unique segment identifier - surrogate key for segcode

segcode

Segment code definition - primary key

segname

Physical table name for data segment storage

objcode

Internal Initiate ™ software usage

hasattr

(Y/N) Contains member attribute data

engineonly

(Y/N) Engine configuration items only

segverno

Used for dictionary segment versioning to support

multiple servers

[0000]

TABLE 2

mpi_segxfld Details

Expanded name

Segment-to-Field Association

Initiate ™

This dictionary table provides the engine with

software use

information on the fields that are available in each

segment.

Cross reference

This table cross-references mpi_seghead through

segcode.

mpi_segxfld Attribute Descriptions

Attribute

Description

caudrecno

Creation of this particular record, from mpi_audhead

maudrecno

Last time the record value was modified, from

mpi_audhead

recstat

Record status - ‘A’ctive, ‘I’nactive, ‘D’eleted, ‘S’hadow

segcode

Segment code, from mpi_seghead

fldseqno

Field sequence number

fldname

Field name

fldtype

Initiate standard datatype (char, varchar, date, time,

datetime, integer, smallint)

fldlength

Field length - 0 for all types except char/varchar

ispkey

Flag whether field is primary key

isrequired

Flag whether field is required

isvirtual

Flag whether field is virtual (non database)

[0000]

TABLE 3

mpi_segattr Details

Expanded name

Segment Attribute Definitions

Initiate ™ software

This dictionary table describes the named

use

attributes that Initiate Identity Hub ™ software

stores using the primary Initiate ™ data types.

mpi_segattr Attribute Descriptions

Attribute

Description

caudrecno

Creation of this particular record, from mpi_audhead

maudrecno

Last time the record value was modified, from

mpi_audhead

recstat

Record status - ‘A’ctive, ‘I’nactive, ‘D’eleted, ‘S’hadow

attrrecno

Attribute record number - Surrogate key for attrcode

memtypeno

Member type

segcode

Storage segment code from mpi_seghead (specifies

physical table)

attrcode

Attribute code - primary key for this table

attrname

Attribute name

attrlabel

Attribute label, can be used for reports or interactive

screen displays

attrdesc

Longer text description of the attribute

edtcode

Enumerated data type, if applicable, from mpi_edthead

isvirtual

Flag indicating if this segment is physical or virtual

adtrole

Abstract Data Type Role - unused at this time

nsactive

Number of allowable active-status instances for an

attribute type (applies at a memrecno-atterecno-

asaidxno level).*

nsexists

The maximum number of a member's attrcodes instances

(applies at a memrecno-atterecno-asaidxno level). The

system trims off any instances greater than this number.*

msfilter

Status filter for records

*Special Values

nsactive:

0

Determines the number of active values to maintain for this

member. 0 or 1 retains one active value of an attribute

type; the MCA attribute is the active attribute and all previous

values become inactive. 2 maintains two active values, and so on.

nsexists:

0

0 = no restriction on the number of attribute values stored for

member; do not trim off any historical attribute values.

>0

Any number above 0 tells the system to trim (delete) any

historical attribute values above that number. For instance,

if nsexists is set to 3, there are 3 values for the HOMEADDR

attribute. If a member is updated to add a 4th, then

the oldest value is deleted.

[0000]

TABLE 4

mpi_seghead

caudrecno

maudrecno

recstat

segrecno

segcode

segname

objcode

hasattr

engineonly

segverno

1

1

A

1

SYSKEY

mpi_syskey

dic

N

N

0

1

1

A

2

SYSPROP

mpi_sysprop

dic

N

Y

0

1

1

A

3

APPHEAD

mpi_apphead

dic

N

N

0

1

1

A

4

APPPROP

mpi_appprop

dic

N

N

0

1

1

A

5

APPDATA

mpi_appdata

dic

N

N

0

1

1

A

6

SEQGEN

mpi_seqgen

dic

N

Y

0

1

1

A

7

STRHEAD

mpi_strhead

dic

N

N

0

1

1

A

8

STRXSTR

mpi_strxstr

dic

N

N

0

1

1

A

9

STRANON

mpi_stranon

dic

N

N

0

1

1

A

10

STREQUI

mpi_strequi

dic

N

N

0

1

1

A

11

STRFREQ

mpi_strfreq

dic

N

N

0

1

1

A

12

STRWORD

mpi_strword

dic

N

N

0

1

1

A

13

STREDIT

mpi_stredit

dic

N

N

0

1

1

A

14

STRNBKT

mpi_strnbkt

dic

N

N

0

1

1

A

15

STRSBKT

mpi_strsbkt

dic

N

N

0

1

1

A

16

WGTHEAD

mpi_wgthead

dic

N

N

0

1

1

A

17

WGTXWGT

mpi_wgtxwgt

dic

N

N

0

1

1

A

18

WGT1DIM

mpi_wgt1dim

dic

N

N

0

1

1

A

19

WGT2DIM

mpi_wgt2dim

dic

N

N

0

1

1

A

20

WGT3DIM

mpi_wgt3dim

dic

N

N

0

1

1

A

21

WGT4DIM

mpi_wgt4dim

dic

N

N

0

1

1

A

22

WGTNVAL

mpi_wgtnval

dic

N

N

0

1

1

A

23

WGTSVAL

mpi_wgtsval

dic

N

N

0

1

1

A

24

EDTHEAD

mpi_edthead

dic

N

N

0

1

1

A

25

EDTELEM

mpi_edtelem

dic

N

N

0

1

1

A

26

LIBHEAD

mpi_libhead

dic

N

N

0

1

1

A

27

STDFUNC

mpi_stdfunc

dic

N

N

0

1

1

A

28

DVDFUNC

mpi_dvdfunc

dic

N

N

0

1

1

A

29

BKTFUNC

mpi_bktfunc

dic

N

N

0

1

1

A

30

CMPFUNC

mpi_cmpfunc

dic

N

N

0

1

1

A

31

EXCFUNC

mpi_excfunc

dic

N

N

0

1

1

A

32

DVDHEAD

mpi_dvdhead

dic

N

N

0

1

1

A

33

DVDXSTD

mpi_dvdxstd

dic

N

N

0

1

1

A

34

DVDXCMP

mpi_dvdxcmp

dic

N

N

0

1

1

A

35

DVDXQRY

mpi_dvdxqry

dic

N

N

0

1

1

A

36

DVDXBKT

mpi_dvdxbkt

dic

N

N

0

1

1

A

37

DVDYBKT

mpi_dvdybkt

dic

N

N

0

1

1

A

38

CMPHEAD

mpi_cmphead

dic

N

N

0

1

1

A

39

CMPSPEC

mpi_cmpspec

dic

N

N

0

1

1

A

40

EXCHEAD

mpi_exchead

dic

N

N

0

1

1

A

41

EXCSPEC

mpi_excspec

dic

N

N

0

1

1

A

42

EVTTYPE

mpi_evttype

dic

N

N

0

1

1

A

43

ENTTYPE

mpi_enttype

dic

N

N

0

1

1

A

44

MEMTYPE

mpi_memtype

dic

N

N

0

1

1

A

45

MEMSTAT

mpi_memstat

dic

N

N

0

1

1

A

46

EIATYPE

mpi_eiatype

dic

N

N

0

1

1

A

47

EIASTAT

mpi_eiastat

dic

N

N

0

1

1

A

48

TSKTYPE

mpi_tsktype

dic

N

N

0

1

1

A

49

TSKSTAT

mpi_tskstat

dic

N

N

0

1

1

A

50

IXNHEAD

mpi_ixnhead

dic

N

Y

0

1

1

A

51

SEGHEAD

mpi_seghead

dic

N

Y

0

1

1

A

52

SEGATTR

mpi_segattr

dic

N

N

0

1

1

A

53

SEGXFLD

mpi_segxfld

dic

N

N

0

1

1

A

54

SRCHEAD

mpi_srchead

dic

N

N

0

1

1

A

65

SRCATTR

mpi_srcattr

dic

N

N

0

1

1

A

66

SRCXENT

mpi_srcxent

dic

N

N

0

1

1

A

55

SRCXSRC

mpi_srcxsrc

dic

N

N

0

1

1

A

56

CVWHEAD

mpi_cvwhead

dic

N

N

0

1

1

A

57

CVWXSEG

mpi_cvwxseg

dic

N

N

0

1

1

A

58

GRPHEAD

mpi_grphead

dic

N

N

0

1

1

A

59

GRPXIXN

mpi_grpxixn

dic

N

N

0

1

1

A

60

GRPXCVW

mpi_grpxcvw

dic

N

N

0

1

1

A

61

GRPXSEG

mpi_grpxseg

dic

N

N

0

1

1

A

62

USRHEAD

mpi_usrhead

dic

N

N

0

1

1

A

63

USRXGRP

mpi_usrxgrp

dic

N

N

0

1

1

A

64

USRPROP

mpi_usrprop

dic

N

N

0

1

1

A

101

MEMHEAD

mpi_memhead

mem

N

N

0

1

1

A

102

MEMBKTD

mpi_membktd

mem

N

Y

0

1

1

A

103

MEMCMPD

mpi_memcmpd

mem

N

Y

0

1

1

A

104

MEMQRYD

mpi_memqryd

mem

N

Y

0

1

1

A

111

MEMIQUE

mpi_memique

mem

N

Y

0

1

1

A

112

MEMOQUE

mpi_memoque

mem

N

Y

0

1

1

A

113

MEMNOTE

mpi_memnote

mem

N

N

0

1

1

A

114

MEMXEIA

mpi_memxeia

mem

N

N

0

1

1

A

115

MEMXTSK

mpi_memxtsk

mem

N

N

0

1

1

A

116

MEMLINK

mpi_memlink

mem

N

N

0

1

1

A

117

MEMRULE

mpi_memrule

mem

N

N

0

1

1

A

121

ENTIQUE

mpi_entique

mem

N

Y

0

1

1

A

122

ENTOQUE

mpi_entoque

mem

N

Y

0

1

1

A

123

ENTNOTE

mpi_entnote

mem

N

N

0

1

1

A

124

ENTXEIA

mpi_entxeia

mem

N

N

0

1

1

A

125

ENTXTSK

mpi_entxtsk

mem

N

N

0

1

1

A

126

ENTLINK

mpi_entlink

mem

N

N

0

1

1

A

127

ENTRULE

mpi_entrule

mem

N

N

0

1

1

A

131

MEMATTR

mpi_memattr

mem

Y

N

0

1

1

A

132

MEMENUM

mpi_memenum

mem

Y

N

0

1

1

A

133

MEMNAME

mpi_memname

mem

Y

N

0

1

1

A

134

MEMADDR

mpi_memaddr

mem

Y

N

0

1

1

A

135

MEMPHONE

mpi_memphon

mem

Y

N

0

1

1

A

137

MEMIDENT

mpi_memident

mem

Y

N

0

1

1

A

138

MEMDATE

mpi_memdate

mem

Y

N

0

1

1

A

139

MEMTEXT

mpi_memtext

mem

Y

N

0

1

1

A

140

MEMOREF

mpi_memoref

mem

Y

N

0

1

1

A

141

MEMAPPT

mpi_memappt

mem

Y

N

0

1

1

A

142

MEMELIG

mpi_memelig

mem

Y

N

0

1

1

A

143

MEMDRUG

mpi_memdrug

mem

Y

N

0

1

1

A

144

MEMCONT

mpi_memcont

mem

Y

N

0

1

1

A

145

MEMEXTA

mpi_memexta

mem

Y

N

0

1

1

A

146

MEMEXTB

mpi_memextb

mem

Y

N

0

1

1

A

147

MEMEXTC

mpi_memextc

mem

Y

N

0

1

1

A

148

MEMEXTD

mpi_memextd

mem

Y

N

0

1

1

A

149

MEMEXTE

mpi_memexte

mem

Y

N

0

1

1

A

201

AUDHEAD

mpi_audhead

aud

N

Y

0

1

1

A

202

AUDATTR

mpi_audattr

aud

N

Y

0

1

1

A

203

AUDXMEM

mpi_audxmem

aud

N

Y

0

[0000]

TABLE 5

mpi_segxfld

fld-

isre-

caudrecno

maudrecno

recstat

segcode

fldseqno

fldname

fldlabel

fldtype

length

ispkey

quired

isvirtual

1

1

A

MEMATTR

1

attrval

attrVal

CHAR

128

N

Y

N

1

1

A

MEMENUM

1

elemrecno

elemRecno

UDWORD

0

N

Y

N

1

1

A

MEMENUM

2

elemval

elemVal

CHAR

40

N

Y

Y

1

1

A

MEMNAME

1

onmlast

onmLast

CHAR

75

N

N

N

1

1

A

MEMNAME

2

onmfirst

onmFirst

CHAR

30

N

N

N

1

1

A

MEMNAME

3

onmmiddle

onmMiddle

CHAR

30

N

N

N

1

1

A

MEMNAME

4

onmprefix

onmPrefix

CHAR

10

N

N

N

1

1

A

MEMNAME

5

onmsuffix

onmSuffix

CHAR

10

N

N

N

1

1

A

MEMNAME

6

onmdegree

onmDegree

CHAR

10

N

N

N

1

1

A

MEMNAME

7

onmtitle

onmTitle

CHAR

20

N

N

N

1

1

A

MEMADDR

1

stline1

stLine1

CHAR

75

N

N

N

1

1

A

MEMADDR

2

stline2

stLine2

CHAR

75

N

N

N

1

1

A

MEMADDR

3

stline3

stLine3

CHAR

75

N

N

N

1

1

A

MEMADDR

4

stline4

stLine4

CHAR

75

N

N

N

1

1

A

MEMADDR

5

city

city

CHAR

30

N

N

N

1

1

A

MEMADDR

6

state

state

CHAR

15

N

N

N

1

1

A

MEMADDR

7

zipcode

zipCode

CHAR

10

N

N

N

1

1

A

MEMADDR

8

country

country

CHAR

3

N

N

N

1

1

A

MEMADDR

9

geotext1

geoText1

CHAR

40

N

N

N

1

1

A

MEMADDR

10

geocode1

geoCode1

CHAR

8

N

N

N

1

1

A

MEMADDR

11

geocode2

geoCode2

CHAR

8

N

N

N

1

1

A

MEMPHONE

1

phicc

phIcc

CHAR

3

N

N

N

1

1

A

MEMPHONE

2

pharea

phArea

CHAR

5

N

N

N

1

1

A

MEMPHONE

3

phnumber

phNumber

CHAR

20

N

Y

N

1

1

A

MEMPHONE

4

phextn

phExtn

CHAR

6

N

N

N

1

1

A

MEMPHONE

5

phcmnt

phCmnt

CHAR

20

N

N

N

1

1

A

MEMIDENT

1

idsrcrecno

idSrcRecno

UDWORD

0

N

Y

N

1

1

A

MEMIDENT

2

idissuer

idIssuer

CHAR

12

N

Y

Y

1

1

A

MEMIDENT

3

idnumber

idNumber

CHAR

40

N

Y

N

1

1

A

MEMIDENT

4

idexpdate

idExpDate

DTTM

0

N

N

N

1

1

A

MEMDATE

1

dateval

dateVal

CHAR

19

N

Y

N

1

1

A

MEMTEXT

1

textval

textVal

CHAR

32767

N

Y

N

1

1

A

MEMOREF

1

objrecno

objRecno

UDWORD

0

N

Y

N

1

1

A

MEMAPPT

1

apsrcrecno

apSrcRecno

UDWORD

0

N

Y

N

1

1

A

MEMAPPT

2

apissuer

apIssuer

CHAR

12

N

Y

Y

1

1

A

MEMAPPT

3

apnumber

apNumber

CHAR

40

N

Y

N

1

1

A

MEMAPPT

4

apstime

apStime

DTTM

0

N

Y

N

1

1

A

MEMAPPT

5

resid

resId

CHAR

20

N

N

N

1

1

A

MEMAPPT

6

resloc

resLoc

CHAR

20

N

N

N

1

1

A

MEMAPPT

7

resdept

resDept

CHAR

20

N

N

N

1

1

A

MEMELIG

1

onmlast

onmLast

CHAR

75

N

N

N

1

1

A

MEMELIG

2

onmfirst

onmFirst

CHAR

30

N

N

N

1

1

A

MEMELIG

3

onmmiddle

onmMiddle

CHAR

30

N

N

N

1

1

A

MEMELIG

4

onmprefix

onmPrefix

CHAR

10

N

N

N

1

1

A

MEMELIG

5

onmsuffix

onmSuffix

CHAR

10

N

N

N

1

1

A

MEMELIG

6

onmdegree

onmDegree

CHAR

10

N

N

N

1

1

A

MEMELIG

7

stline1

stLine1

CHAR

75

N

N

N

1

1

A

MEMELIG

8

stline2

stLine2

CHAR

75

N

N

N

1

1

A

MEMELIG

9

city

city

CHAR

30

N

N

N

1

1

A

MEMELIG

10

state

state

CHAR

15

N

N

N

1

1

A

MEMELIG

11

zipcode

zipCode

CHAR

15

N

N

N

1

1

A

MEMELIG

12

country

country

CHAR

3

N

N

N

1

1

A

MEMELIG

13

geotext1

geoText1

CHAR

40

N

N

N

1

1

A

MEMELIG

14

geocode1

geoCode1

CHAR

8

N

N

N

1

1

A

MEMELIG

15

geocode2

geoCode2

CHAR

8

N

N

N

1

1

A

MEMELIG

16

phicc

phIcc

CHAR

3

N

N

N

1

1

A

MEMELIG

17

pharea

phArea

CHAR

5

N

N

N

1

1

A

MEMELIG

18

phnumber

phNumber

CHAR

13

N

N

N

1

1

A

MEMELIG

19

phextn

phExtn

CHAR

6

N

N

N

1

1

A

MEMELIG

20

phcmnt

phCmnt

CHAR

20

N

N

N

1

1

A

MEMELIG

21

dob

dob

DTTM

0

N

N

N

1

1

A

MEMELIG

22

ssn

ssn

CHAR

9

N

N

N

1

1

A

MEMELIG

23

sex

sex

CHAR

1

N

N

N

1

1

A

MEMELIG

24

percode

perCode

CHAR

3

N

N

N

1

1

A

MEMELIG

25

insgroup

insGroup

CHAR

20

N

N

N

1

1

A

MEMELIG

26

insplan

insPlan

CHAR

20

N

N

N

1

1

A

MEMELIG

27

eligdate

eligDate

DTTM

0

N

N

N

1

1

A

MEMELIG

28

termdate

termDate

DTTM

0

N

N

N

1

1

A

MEMDRUG

1

onmlast

onmLast

CHAR

75

N

N

N

1

1

A

MEMDRUG

2

onmfirst

onmFirst

CHAR

30

N

N

N

1

1

A

MEMDRUG

3

onmmiddle

onmMiddle

CHAR

30

N

N

N

1

1

A

MEMDRUG

4

dob

dob

DTTM

0

N

N

N

1

1

A

MEMDRUG

5

ssn

ssn

CHAR

9

N

N

N

1

1

A

MEMDRUG

6

sex

sex

CHAR

1

N

N

N

1

1

A

MEMDRUG

7

percode

perCode

CHAR

3

N

N

N

1

1

A

MEMDRUG

8

rxnumber

rxNumber

CHAR

7

N

N

N

1

1

A

MEMDRUG

9

refillnumber

refillNumber

UWORD

0

N

N

N

1

1

A

MEMDRUG

10

totalrefills

totalRefills

UWORD

0

N

N

N

1

1

A

MEMDRUG

11

pharmacyid

pharmacyId

CHAR

17

N

N

N

1

1

A

MEMDRUG

12

datefilled

dateFilled

DTTM

0

N

N

N

1

1

A

MEMDRUG

13

drugcode

drugCode

CHAR

21

N

N

N

1

1

A

MEMDRUG

14

quantity

quantity

UDWORD

0

N

N

N

1

1

A

MEMDRUG

15

dayssupply

daysSupply

UWORD

0

N

N

N

1

1

A

MEMDRUG

16

prescriberid

prescriberId

CHAR

17

N

N

N

1

1

A

MEMCONT

1

ctrname

ctrName

CHAR

60

N

N

N

1

1

A

MEMCONT

2

ctrid

ctrId

CHAR

12

N

N

N

1

1

A

MEMCONT

3

ctrmasname

ctrMasName

CHAR

60

N

N

N

1

1

A

MEMCONT

4

ctrmasid

ctrMasId

CHAR

12

N

N

N

1

1

A

MEMCONT

5

ctrlob

ctrLob

CHAR

12

N

N

N

1

1

A

MEMCONT

6

ctrcenter

ctrCenter

CHAR

10

N

N

N

1

1

A

MEMCONT

7

ctrnetwork

ctrNetwork

CHAR

12

N

N

N

1

1

A

MEMCONT

8

ctrdeal

ctrDeal

CHAR

6

N

N

N

1

1

A

MEMCONT

9

ctrcisid

ctrCisId

CHAR

9

N

N

N

1

1

A

MEMCONT

10

ctrseqnum

ctrSeqNum

CHAR

3

N

N

N

1

1

A

MEMCONT

11

ctrparcd

ctrParCd

CHAR

9

N

N

N

1

1

A

MEMCONT

12

ctrmarket

ctrMarket

CHAR

12

N

N

N

1

1

A

MEMCONT

13

ctreffdate

ctrEffDate

DTTM

0

N

N

N

1

1

A

MEMCONT

14

ctrenddate

ctrEndDate

DTTM

0

N

N

N

1

1

A

MEMEXTA

1

subidnum

subIdnum

CHAR

60

N

N

N

1

1

A

MEMEXTA

2

hpmemidnum

hpMemIdnum

CHAR

30

N

N

N

1

1

A

MEMEXTA

3

hpsubidnum

hpSubIdnum

CHAR

30

N

N

N

1

1

A

MEMEXTA

4

hppolidnum

hpPolIdnum

CHAR

30

N

N

N

1

1

A

MEMEXTA

5

memexpdate

memExpDate

DTTM

0

N

N

N

1

1

A

MEMEXTA

6

empname

empName

CHAR

35

N

N

N

1

1

A

MEMEXTA

7

onmlast

onmLast

CHAR

75

N

N

N

1

1

A

MEMEXTA

8

onmfirst

onmFirst

CHAR

30

N

N

N

1

1

A

MEMEXTA

9

onmmiddle

onmMiddle

CHAR

30

N

N

N

1

1

A

MEMEXTA

10

onmprefix

onmPrefix

CHAR

10

N

N

N

1

1

A

MEMEXTA

11

onmsuffix

onmSuffix

CHAR

10

N

N

N

1

1

A

MEMEXTA

12

dob

dob

DTTM

0

N

N

N

1

1

A

MEMEXTA

13

sex

sex

CHAR

1

N

N

N

1

1

A

MEMEXTA

14

ssn

ssn

CHAR

9

N

N

N

1

1

A

MEMEXTA

15

stline1

stLine1

CHAR

60

N

N

N

1

1

A

MEMEXTA

16

stline2

stLine2

CHAR

60

N

N

N

1

1

A

MEMEXTA

17

city

city

CHAR

30

N

N

N

1

1

A

MEMEXTA

18

state

state

CHAR

2

N

N

N

1

1

A

MEMEXTA

19

zipcode

zipCode

CHAR

15

N

N

N

1

1

A

MEMEXTA

20

country

country

CHAR

3

N

N

N

1

1

A

MEMEXTA

21

comtype1

comType1

CHAR

2

N

N

N

1

1

A

MEMEXTA

22

comdata1

comData1

CHAR

80

N

N

N

1

1

A

MEMEXTA

23

comtype2

comType2

CHAR

2

N

N

N

1

1

A

MEMEXTA

24

comdata2

comData2

CHAR

80

N

N

N

1

1

A

MEMEXTA

25

comtype3

comType3

CHAR

2

N

N

N

1

1

A

MEMEXTA

26

comdata3

comData3

CHAR

80

N

N

N

1

1

A

MEMEXTB

1

txnid

txnID

UDWORD

0

N

Y

N

1

1

A

MEMEXTB

2

propcode

propCode

CHAR

8

N

Y

N

1

1

A

MEMEXTB

3

doa

doa

DTTM

0

N

Y

N

1

1

A

MEMEXTB

4

cctype

ccType

CHAR

2

N

Y

N

1

1

A

MEMEXTB

5

ccexpdate

ccExpDate

CHAR

8

N

Y

N

1

1

A

MEMEXTB

6

ccnumber

ccNumber

CHAR

40

N

Y

N

1

1

A

MEMEXTC

1

acctnumber

acctNumber

CHAR

20

N

N

N

1

1

A

MEMEXTC

2

encdate

encDate

DTTM

0

N

N

N

1

1

A

MEMEXTC

3

disdate

disDate

DTTM

0

N

N

N

1

1

A

MEMEXTC

4

pattype

patType

CHAR

20

N

N

N

1

1

A

MEMEXTC

5

svctype

svcType

CHAR

20

N

N

N

1

1

A

MEMEXTC

6

svcloc

svcLoc

CHAR

20

N

N

N

1

1

A

MEMEXTC

7

phys1

phys1

CHAR

20

N

N

N

1

1

A

MEMEXTC

8

phys2

phys2

CHAR

20

N

N

N

1

1

A

MEMEXTC

9

plan1

plan1

CHAR

20

N

N

N

1

1

A

MEMEXTC

10

plan2

plan2

CHAR

20

N

N

N

1

1

A

MEMEXTC

11

user1

user1

CHAR

20

N

N

N

1

1

A

MEMEXTC

12

user2

user2

CHAR

20

N

N

N

1

1

A

MEMEXTD

1

secidnum

secIdnum

CHAR

18

N

N

N

1

1

A

MEMEXTD

2

onmlast

onmLast

CHAR

18

N

N

N

1

1

A

MEMEXTD

3

onmfirst

onmFirst

CHAR

18

N

N

N

1

1

A

MEMEXTD

4

onmmiddle

onmMiddle

CHAR

18

N

N

N

1

1

A

MEMEXTD

5

onmsuffix

onmSuffix

CHAR

4

N

N

N

1

1

A

MEMEXTD

6

ssn

ssn

CHAR

11

N

N

N

1

1

A

MEMEXTD

7

sex

sex

CHAR

1

N

N

N

1

1

A

MEMEXTD

8

dob

dob

DTTM

0

N

N

N

1

1

A

MEMEXTD

9

stline1

stLine1

CHAR

30

N

N

N

1

1

A

MEMEXTD

10

stline2

stLine2

CHAR

30

N

N

N

1

1

A

MEMEXTD

11

city

city

CHAR

17

N

N

N

1

1

A

MEMEXTD

12

state

state

CHAR

2

N

N

N

1

1

A

MEMEXTD

13

zipcode

zipCode

CHAR

10

N

N

N

1

1

A

MEMEXTD

14

phone

phone

CHAR

12

N

N

N

1

1

A

MEMEXTD

15

expind

expInd

CHAR

1

N

N

N

1

1

A

MEMEXTD

16

expdate

expDate

DTTM

0

N

N

N

1

1

A

MEMEXTD

17

moddate

modDate

DTTM

0

N

N

N

1

1

A

MEMEXTE

1

accnum

accNum

CHAR

20

N

Y

N

1

1

A

MEMEXTE

2

studate

stuDate

DTTM

0

N

N

N

1

1

A

MEMEXTE

3

studyId

studyId

CHAR

64

N

N

N

1

1

A

MEMEXTE

4

refphys

refPhys

CHAR

40

N

N

N

1

1

A

MEMEXTE

5

studesc

stuDesc

CHAR

64

N

N

N

1

1

A

MEMEXTE

6

stumod

stuMod

CHAR

60

N

N

N

1

1

A

MEMEXTE

7

frmcnt

frmCnt

UDWORD

0

N

N

N

1

1

A

MEMEXTE

8

pacsid

pacsId

CHAR

180

N

N

N

[0000]

TABLE 6

mpi_segattr

caudrecno

maudrecno

recstat

attrrecno

memtypeno

segcode

attrcode

attrname

attrlabel

attrdesc

edtcode

isvirtual

adtrole

nsactive

nsexists

msfilter

1

1

A

11

1

MEMATTR

SEX

Sex

Sex

Sex

SEX

N

0

1

0

A

1

1

A

12

1

MEMATTR

RACE

Race

Race

Race

RACE

N

0

1

0

A

1

1

A

13

1

MEMATTR

MARSTAT

Marital

Marital

Marital

NULL

N

0

1

0

A

Status

Status

Status

1

1

A

14

1

MEMATTR

RELIGION

Religion

Religion

Religion

NULL

N

0

1

0

A

1

1

A

15

1

MEMATTR

LANGUAGE

Language

Language

Language

NULL

N

0

1

0

A

1

1

A

16

1

MEMATTR

FACILIY

Facility

Facility

Facility

NULL

N

0

1

0

A

1

1

A

17

1

MEMATTR

OPERID

Registrar

Registrar

Registrar

NULL

N

0

1

0

A

1

1

A

18

1

MEMATTR

LOCATN

Location

Location

Location

NULL

N

0

1

0

A

1

1

A

19

1

MEMNAME

LGLNAME

Legal

Legal

Legal

NULL

N

0

1

0

A

Name

Name

Name

1

1

A

20

1

MEMADDR

HOMEADDR

Home

Home

Home

NULL

N

0

1

0

A

Address

Address

Address

1

1

A

21

1

MEMPHONE

HOMEPHON

Home

Home

Home

NULL

N

0

1

0

A

Telephone

Telephone

Telephone

1

1

A

22

1

MEMPHONE

WORKPHON

Work

Work

Work

NULL

N

0

0

0

A

Telephone

Telephone

Telephone

1

1

A

23

1

MEMIDENT

SSN

Social

Social

Social

NULL

N

0

1

0

A

Security

Security

Security

1

1

A

24

1

MEMIDENT

PTENTRID

Enterprise

Enterprise

Enterprise

NULL

N

0

1

0

A

ID

ID

ID

1

1

A

25

1

MEMIDENT

PTCHRTID

Chart

Chart

Chart

NULL

N

0

0

0

A

ID

ID

ID

1

1

A

26

1

MEMIDENT

MRN

Medical

Medical

Medical

NULL

N

0

0

0

A

Record

Record

Record

Number

Number

Number

1

1

A

27

1

MEMDATE

BIRTHDT

Birth

Birth

Birth

NULL

N

0

1

0

A

Date

Date

Date

1

1

A

28

1

MEMDATE

DEATHDT

Death

Death

Death

NULL

N

0

0

0

A

Date

Date

Date

1

1

A

29

1

MEMNAME

PCPNAME

Primary

Primary

Primary

NULL

N

0

1

0

A

Care

Care

Care

Provider

Provider

Provider

1

1

A

30

1

MEMATTR

PCPLICID

Primary

Primary

Primary

NULL

N

0

1

0

A

Care

Care

Care

Provider

Provider

Provider

License

License

License

Id

Id

Id

1

1

A

31

1

MEMATTR

PCPPRAC

Primary

Primary

Primary

NULL

N

0

1

0

A

Care

Care

Care

Provider

Provider

Provider

Practice

Practice

Practice

Name

Name

Name

1

1

A

32

1

MEMPHONE

PCPPHN

Primary

Primary

Primary

NULL

N

0

1

0

A

Care

Care

Care

Provider

Provider

Provider

Phone

Phone

Phone

1

1

A

33

1

MEMATTR

PCPDEAID

Primary

Primary

Primary

NULL

N

0

1

0

A

Care

Care

Care

Provider

Provider

Provider

DEA Id

DEA Id

DEA Id

1

1

A

34

1

MEMATTR

PCPSPEC

Primary

Primary

Primary

NULL

N

0

1

0

A

Care

Care

Care

Provider

Provider

Provider

Specialty

Specialty

Specialty

1

1

A

41

1

MEMATTR

ENCACCT

Encounter

Encounter

Encounter

NULL

N

0

0

0

A

Acct

Acct

Acct

Number

Number

Number

1

1

A

42

1

MEMDATE

ENCADM

Encounter

Encounter

Encounter

NULL

N

0

0

0

A

Start Date

Start Date

Start Date

1

1

A

43

1

MEMDATE

ENCDIS

Encounter

Encounter

Encounter

NULL

N

0

0

0

A

End Date

End Date

End Date

1

1

A

44

1

MEMATTR

ENCPAID

Encounter

Encounter

Encounter

NULL

N

0

0

0

A

Paid

Paid

Paid

1

1

A

45

1

MEMATTR

ENCPTYPE

Encounter

Encounter

Encounter

NULL

N

0

0

0

A

Patient

Patient

Patient

Type

Type

Type

1

1

A

46

1

MEMATTR

ENCDIAG

Encounter

Encounter

Encounter

NULL

N

0

0

0

A

Diagnosis

Diagnosis

Diagnosis

1

1

A

51

1

MEMNAME

GTNAME

Guarantor

Guarantor

Guarantor

NULL

N

0

0

0

A

Name

Name

Name

1

1

A

52

1

MEMDATE

GTDOB

Guarantor

Guarantor

Guarantor

NULL

N

0

0

0

A

Birthdate

Birthdate

Birthdate

1

1

A

53

1

MEMADDR

GTHADDR

Guarantor

Guarantor

Guarantor

NULL

N

0

0

0

A

Home

Home

Home

Address

Address

Address

1

1

A

54

1

MEMATTR

GTINSNM

Guarantor

Guarantor

Guarantor

NULL

N

0

0

0

A

Ins Name

Ins Name

Ins Name

1

1

A

55

1

MEMATTR

GTINSPOL

Guarantor

Guarantor

Guarantor

NULL

N

0

0

0

A

Ins Policy

Ins Policy

Ins Policy

Number

Number

Number

1

1

A

56

1

MEMATTR

GTINSCOV

Guarantor

Guarantor

Guarantor

NULL

N

0

0

0

A

Ins

Ins

Ins

Coverage

Coverage

Coverage

1

1

A

57

1

MEMATTR

GTEMPNM

Guarantor

Guarantor

Guarantor

NULL

N

0

0

0

A

Employer

Employer

Employer

Name

Name

Name

1

1

A

58

1

MEMATTR

GTOCC

Guarantor

Guarantor

Guarantor

NULL

N

0

0

0

A

Occupation

Occupation

Occupation

1

1

A

59

1

MEMIDENT

GTSSN

Guarantor

Guarantor

Guarantor

NULL

N

0

0

0

A

SSN

SSN

SSN

1

1

A

60

1

MEMAPPT

APPT

APPT

APPT

APPT

NULL

N

0

0

0

A

1

1

A

61

1

MEMEXTC

ENCNTR

Encounter

Encounter

Encounter

NULL

N

0

0

0

A

Information

Information

Information

[0048]

Part of the IDS metadata defines how the data should be stored and persisted in a database. The mpi_seghead table gives the table name, and the segXfld table identifies the field name, the field data type, and field length (if needed). The tables defined above include flags which allow a user to define a segment that contains virtual fields, or virtual attributes. At a field level, the mpi_segxfld.isvirtual flag defines whether or not a data field should be stored. If it is marked as virtual, the Identity Hub engine will create space to store values, and will transport the values to and from any calling client application, but it will not save those values in the database. At an attribute level, the mpi_segattr.isvirtual flag says that the Identity Hub should not store the entire attribute. The IDS meta-data stores a generic data type that is not specific to any given relational database that the Identity Hub has been ported to. A mechanism in the Identity Hub engine translates from this generic data type to a RDBMS specific type through the use of a lookup file that is contained outside the database. A sample section of this file for the Oracle database is given below:

[0000]

[ORACLE]

integer =

number(10)

smallint =

number(5)

date =

date

time =

date

datetime =

date

varchar =

varchar2(%s)

char =

char(%s)

bigtext =

long

truncate =

truncate table %s

optimize =

analyze table %s delete statistics

optimize2 =

analyze table %s compute statistics for all indexes

loader =

sqlldr

tablist =

select table_name from user_tables

idxlist =

select index_name from user_indexes

[0049]

The IDS sub-system looks up the generic data type on the left from the mpi_segxfld table, and it is translated to the RDBMS specific type on the right. The reason this file is not stored in the database is that Engine 320 needs the RDBMS specific types prior to creating the segment metadata tables when the system is first installed. Hub 300 has utility programs that can create a database from the generic data types for any RDBMS that Hub 300 has been ported to. When defining a new segment, Manager 330 will export the generic DDL statement used to make the database specific table and indexes. An example is show below for a fictional customer segment that contains a customer name, phone number, a customer id number, and date that shows when the customer first started doing business:

[0000]

-- -------------------------------------------------

-- Generated via Initiate Identity Hub Manager

--

T|MEM|mpi_memcust|IDS Generated Table|

C|MEM|mpi_memcust|memrecno|integer|0|N|member record number|

C|MEM|mpi_memcust|memseqno|smallint|0|N|member record

sequence number|

C|MEM|mpi_memcust|caudrecno|integer|0|N|create audit record number|

C|MEM|mpi_memcust|maudrecno|integer|0|N|modify audit record

number|

C|MEM|mpi_memcust|recstat|char|1|N|record status: active,

inactive, deleted|

C|MEM|mpi_memcust|attrrecno|smallint|0|N|attribute record number|

C|MEM|mpi_memcust|asaidxno|smallint|0|N|attribute

sparse array index number|

C|MEM|mpi_memcust|custname|varchar|40|Y|SEGXFLD generated|

C|MEM|mpi_memcust|custid|integer|0|N|SEGXFLD generated|

C|MEM|mpi_memcust|custphone|varchar|20|Y|SEGXFLD generated|

C|MEM|mpi_memcust|custsince|datetime|0|Y|SEGXFLD generated|

I|MEM|mpi_memcust|mpi_memcust|U|memrecno,memseqno||

[0050]

The generated DDL statement above contains not only the fields defined by the user, but also the fields used to join this data table to the rest of the data model of Hub 300 and to provide for attribute-level auditing. The additional scaffolding is generated automatically and may change as future versions of Hub 300 may need to change the data model. As discussed above, these Data Definition Language (DDL) statements are sent to the file system instead of the database, so that they can be used to create the empty tables before the database is fully populated.

[0051]

In some embodiments, every segment used by Hub 300 could be built by the IDS technology disclosed herein. In some embodiments, the scope of the IDS capability of Manager 330 is limited to a sub-section of the data model called Member Attributes. Member Attributes are data segments that contain the demographic data used for comparison by Hub 300. They are the most likely point in the data model for a customer to want to customize or add additional capability. However, as one skilled in the art can appreciate, the scope of the IDS capability may be extended to include all but a small kernel of segments that will need to remain pre-defined so that the system may bootstrap itself at startup.

[0052]

In some embodiments, Manager 330 is programmed to enable an implementer or an administrator to define Implementation Defined Segments and the attributes that use these segments. As an example, FIGS. 8-9 show screenshots of the dialogs where the MEMCUST example segment was defined. Specifically, FIG. 8 shows a screenshot of one embodiment of an Add Segment component of Manager 330. The first dialog as shown in FIG. 8 defines the MEMCUST example segment. The database independent DDL example shown above can be generated by selecting (clicking on) the Generate DDL button (icon). A field can be added, updated, or deleted by selecting an appropriate button or icon.

[0053]

FIG. 9 shows a screenshot of one embodiment of an Add Field component of Manager 330. This next dialog shows how the fourth field “custsince” was added to the MEMCUST example segment. Specifically, the implementer would click on Add Field button 802 at the first dialog and be presented with the next dialog as shown in FIG. 9. In this example, the implementer would specify the Field Name, Label, Data Type, and Length, and then click the Add button to complete the process of adding the new field “custsince” to the segment “MEMCUST”. The valid data types (e.g., char, varchar, integer, smallint, datetime, date, time) are shown in a drop-down combo box control.

[0054]

The IDS subsystem described above provides a way to programmatically access the IDS metadata and determine what data segments are available, and what data fields they are made up of. Hub 300 includes a set of programming APIs (Application Programming Interfaces) as libraries that can be called from the C++ or Java programming language. These same APIs are used on pre-built applications so they can adapt to new data segments in the same manner that a custom built client application would. In some embodiments, the APIs have metadata classes that allow a programmer to find out at run-time how many segments are defined in the system, and for each of those segments, what fields and data types are they made up of. Additional classes allow the creation of an Implementation Defined Segment, and access to the data in each of the fields in either its native data type or as a generic string representation. When writing data to Hub 300, the programmer most often knows the shape of the attribute (what fields exist and their data type). In some cases, the incoming data may be in string format. and the API can convert it to the proper underlying data type for the caller. The dictionary store contains the metadata required to figure out what attribute is linked to a particular segment and the API will ensure that the proper amount of storage to hold that segment is allocated. By interrogating the metadata tables, knowledge of the shape of a particular segment can be obtained, as well as the number of segments defined (e.g., for an embodiment of Engine 320).

[0055]

FIG. 10 depicts a schematic representation of one embodiment of an exemplary method of accessing data segments in computer network 100 where client 12 and server 16 reside. There are various ways to access a segment and its field(s), including direct access and indirect access through client interactions. Within this disclosure, an interaction refers to a request from client 12 to Hub 300 (e.g., residing on server 16) and the result of that request from Hub 300 back to client 12. Via TCP/IP connects and through Initiate™ APIs, user actions are associated with specific interactions. Segments are the logical representation of a table of its contents within Database 340.

[0056]

When a user initiates an action (e.g., a retrieve), a specific interaction (e.g., MEMGET) sends the retrieve criteria to Hub 300. The returned data includes segments (e.g., MEMHEAD, MEMATTR, MEMNAME, MEMADDR, MEMPHONE, MEMTYPE, and/or MEMIDENT) containing the requested member data from the applicable tables (e.g., mpi_memhead, mpi_memattr, mpi_memname, mpi_memaddr, mpi_memphone, mpi_memtype, and/or mpi_memident). Depending upon the interaction, the specific criteria, and the information stored in Database 340 about a member, multiple segments may be returned. This process is illustrated in FIG. 10.

[0057]

Although the present invention has been described in detail herein with reference to the illustrative embodiments, it should be understood that the description is by way of example only and is not to be construed in a limiting sense. It is to be further understood, therefore, that numerous changes in the details of the embodiments of this invention and additional embodiments of this invention will be apparent to, and may be made by, persons of ordinary skill in the art having reference to this description. It is contemplated that all such changes and additional embodiments are within the scope of the invention as detailed in the following claims.

Claims (20)

1. A system, comprising:

a processor;

one or more computer readable media accessible by said processor and storing computer instructions executable by said processor; and

an identity hub installed on said one or more computer readable media;

wherein said identity hub comprises an identity engine capable of matching and integrating identity data from a plurality of sources into master data records;

wherein functionality of said identity engine is accessible by an identity hub manager;

wherein each IDS is a data structure which encapsulates a single row from one of said master data records; and

wherein each IDS has one or more editable fields and an associated Data Definition Language (DDL) statement.

2. The system of claim 1, wherein said identity hub manager resides on a server computer and is accessible by a client computer.

3. The system of claim 1, wherein said identity hub manager is installed and run directly on a workstation.

4. The system of claim 1, wherein said IDS coincide with data schema of said identity hub to define behavior of said identity engine and member information.

5. The system of claim 1, wherein said identity hub includes a set of pre-defined segments which are created prior to said deployment.

6. The system of claim 1, wherein said DDL statement is generated by said identity hub manager.

7. The system of claim 1, wherein said IDS are member segments defining individual entities, member attributes, and task workflow.

8. The system of claim 1, wherein said identity hub includes a set of metadata tables which are read at system start-up to define shape of data structures used by said identity engine.

9. The system of claim 1, wherein said set of metadata tables include a first metadata table, a second metadata table, and a third metadata table, wherein each row of said first metadata table defines a unique name of a segment, wherein said second metadata table defines individual fields contained in each segment defined in said first metadata table, and wherein said third metadata table defines one or more roles of a particular segment.

10. A computer readable medium embodying a set of metadata tables defining shape of data structures to be used in an identity hub residing on a server computer;

wherein said set of metadata tables are deployable to a client computer;

wherein said set of metadata tables include a first metadata table, a second metadata table, and a third metadata table;

wherein each row of said first metadata table defines a unique name of a segment;

wherein said second metadata table defines individual fields contained in each segment defined in said first metadata table; and

wherein said third metadata table defines one or more roles of a particular segment.

11. The computer readable medium of claim 10, wherein said set of metadata tables are read at system start-up of said client computer.

12. The computer readable medium of claim 11, wherein one or more implementation defined segments (IDS) are added to said identity hub by utilizing said set of metadata tables to describe said one or more IDS.

13. The computer readable medium of claim 12, wherein each IDS is a data structure which encapsulates a single row from a master data record residing in said identity hub.

14. The computer readable medium of claim 12, wherein each IDS has one or more editable fields and an associated Data Definition Language (DDL) statement.