If the access check is successful, the query on the database is performed. Before data is returned, any data items that are not accessible to the requester are eliminated from the data. This control allows pieces of the database tables to be accessed, while other pieces are suppressed. The server method uses a table-driven approach to remove any data not accessible because of the requester's role.
In the case of a patient requesting the entire patient record, the patient role server performs another form of verification. The request to the patient record server is made using the patient id as the criteria. The actual value of the id is retrieved from the verification database when the user-name/password check is made. The id value passed by the requester is not trusted, and is therefore not used.
The UK policy was incorporated into the POSIX demonstration project.
At this point in the development of the demo, the UK policy has
been somewhat simplified by eliminating the labeling and limiting
the number of roles. We have defined seven roles for the health
care demonstration. Table 4 gives the roles and the accessible
data for each. In order to change the roles, or change the access
for a role, all that is needed is to change a table that the server
methods use to control access. The operation of the methods is
to replace any inaccessible data with blank strings before returning
the data.
| Patient | All information for the patient |
| Doctor | All information |
| Voluntary Caring Agency | Name, address, clinical data |
| Researcher | Age, sex, clinical data |
| Epidemiologist | Age, sex, clinical data |
| Environmental Health Officer | Name, ID, address |
| Organization Staff | Name and ID |
Every requester, on entry to the "Patient Record Health Care Demonstration Project," must first be identified and take on a role. This is accomplished by requiring the requester to specify a name, password, and to select a role for the entire session. The information provided is verified before access to any patient records is allowed. If the information provided is found to be in error, the requester may correct and resubmit the information.
Once a requester is verified, the ID type associated with the specific requester is provided to all of the access requests initiated along with the requester's name, encoded requester's password, and role.