Method of and system for dynamically controlling access to data records6763344Abstract A system for controlling access to records stored in a database queries the database to obtain an initial result set of records. The method then applies access rules to the records of the initial result set to obtain a final result set of records. Then, the method provides access to records of the final result set according to an access profile for the user requesting the records. Claims What is claimed is: Description FIELD OF THE INVENTION
TABLE I
Type of Data Protect_Cd Access
Diagnosis H Read
Diagnosis K Read/Write
Diagnosis L Read/Write
Procedure H Read
. . . . . . . . .
The user profile contains columns for type of data, protection code (Protect_Cd), and access level. In the medical record embodiment of the present invention, the data types include diagnosis records and treatment records. The each protection code corresponds to an access level. Thus, in Table I, the user can read, but not modify, a diagnosis record with a protection code of H. The user can read and modify a diagnosis record with a protection code of K. It should be recognized that there can be other protection codes that deny read access to certain records, or selectively hide or suppress data in certain records. After the user has logged on to record access system 11, the user can request records. For example, a user can request the diagnosis records for a particular patient. Upon receipt of a request, the record access component constructs a query to database 13. Database 13 returns an initial result set of the type illustrated in the following Table II.
TABLE II
Patient Diag_Cd Facil. Type Date Protect_Cd
P00001 300 0001 A 1996-01-01 X
P00001 100 0002 C 1997-05-01 X
P00001 200 0002 D 1998-05-01 X
P00001 350 0003 F 1999-01-01 X
P00001 490 0002 E 1999-08-15 X
The initial result set of Table II includes diagnosis records for patient P00001. Each diagnosis record includes a diagnosis code (Diag_Cd), which is a number corresponding to a diagnosis, a facility identifier (Facil.), a type, and the date of the diagnosis. Each diagnosis record also contains a protection code (Protect_Cd), which defines the level of access for the record. In the preferred embodiment of the present invention, a security policy table is defined in the system that contains one entry for each type of data record. The security policy table associates a unique base protection code with each data type. The security policy table indicates the default access for all users to each type of data. In Table II, each record has a base protection code of X. In the preferred embodiment, the system has predefined data types. An example of a predefined data type is Diagnosis. However, the system administrator may determine that additional, special, data types are required. The system administrator may create new data types, such as HIV Diagnosis or STD Diagnosis, via a graphical user interface. As new data types are created, new protection codes are created off the base, giving the administrator the ability to uniquely protect these new data types. After database 13 has returned the initial result set, record access component 19 calls dynamic tagging component 21. Dynamic tagging component queries a rule set of the type illustrated in the following Table III for rules pertaining to data of the initial result set.
TABLE III
Type Rule Protect_Cd
Diag. (diag_cd = '100') or facil. = '0001' K
Diag. (facil. in ('0003', '0004') H
Diag. (type = 'D') M
. . . . . . . . .
As shown Table III, the rules set includes a set of rules written as structured query language (SQL) statements. Each rule of Table III is associated with a protection code (Protect_Cd). Dynamic tagging component 21 uses the rules set to construct an in-memory SQL statement that applies the rules set against the initial result set. A system administrator can thus easily define access rules using SQL syntax. The dynamic tagging component uses the results of the application of the rules set to dynamically recalculate the protection code for each record of the initial result set to form a final result set as illustrated in the following Table IV.
TABLE IV
Patient Diag_Cd Facil. Type Date Protect_Cd
P00001 300 0001 A 1996-01-01 K
P00001 100 0002 C 1997-05-01 K
P00001 200 0002 D 1998-05-01 M
P00001 350 0003 F 1999-01-01 H
P00001 490 0002 E 1999-08-15 X
The tagging is done by building an SQL "with" construct that contains the determining values from each row and "where" construct(s) that contain the customer rules that pertain to the data type. The "cast" construct is used to tag each record which indicates which "where" construct was satisfied. At the end of this query, each record is appropriately classified, either remaining in the base protection code X, or in a new protection code (e.g. H, K, or M). The final result set is passed back through a security component of record access component 19 that uses the requesting user's access profile (Table I) to determine the user's access level (i.e., None, Read, Read/Write, Read/Write/Delete) to the records of the final result set. In the example of Table IV, only records with protections code (Protect_Cd) H, K, and L will be returned to the user, and only the K and L records may be updated by the user. The operation of the method and system of the present invention is summarized with respect to the flowchart of FIG. 3. A user logs on to the record access system at block 31. The record access system obtains the access profile for the user and waits for a record request at block 33. When the record access component receives a record request, the record access component queries the database, at block 35. The database returns an initial result set, at block 37, and the record access component calls the dynamic tagging component, at block 39. The dynamic tagging component constructs an in-memory SQL query to apply the rules of the rules set against the record of the initial result set and tags the records of the initial result set to form a final result set, at block 41. The record access component applies the user's access profile to the final result set and provides the results to the user, at block 43. From the foregoing, it may be seen that the present invention overcomes the shortcomings of the prior art. Access rules are defined by SQL statements in the rules set. The system administrator can add or modify access rules easily without having to recompile the system, as in the prior art method of imbedding logic rules in the data store application. All records are added to the database with the same base protection code. Final protection codes are applied to the records of the initial result set. Thus, the data migration issue of the prior art is solved by deferring the tagging of data until the records are actually retrieved from the data store. The method and system of the present invention have been illustrated and described with respect to a presently preferred embodiment. Those skilled in the art, given the benefit of this disclosure, will recognize alternative embodiments. Accordingly, the foregoing disclosure is intended for purposes of illustration rather than limitation.
|
Same subclass Same class Consider this |
||||||||||