The model used for client-server communication is object-based. Clients send messages to these objects in order to retrieve data from the patient record database. From the perspective of the client, these objects are local; the client is unaware that the actual object implementation is running across the network, possibly on a different machine.
The server objects retain no state. These objects only provide an abstract interface to the patient record database. Each method call is independent, and there is no prescribed ordering to the calling sequence. The server objects encapsulate the access to the patient record database. The goal is to maintain the same interface, independent of changes in databases, systems, or networks.
Because the server objects are stateless, all access controls are enforced by each method. A different model would use the concept of sessions between the client and server objects. This can be accomplished by having the server objects retain some state, such as the user id if the requester. Each method then checks the state for the proper access being granted. This technique would require that one method be called before any others. This method would establish the access privileges based on the role of the requester. (This could be done by the object's constructor) Further method calls would assume that the access has been granted.
By using the idea of a session between client and server object, we have two choices for server objects to maintain the session. One choice is to have one server object, which maintain lists of sessions in its state data. The other choice is to have the server object dedicated to one session only. The first option would require that the server object implementation run continuously, accepting requests and establishing sessions. In the second option, the lifetime of the server object is limited to the session lifetime.
The Common Object Request Broker Architecture (CORBA) provides a means to specify the interface for a server object independent of the server's implementation. The advantages include allowing the client programs to be independent of changes in the server, and a consistent means of interfacing to servers is provided. We have used a CORBA compliant product in the development of the health care demonstration.
Client programs (such as the CGIBIN scripts for HTTP) do not communicate directly with the patient record database. The interface to the database is specified in CORBA IDL (interface definition language). A server program implements the operations specified in the IDL for the database server.
The objects developed for the server provide a wrapper to the underlying patient record database. The IDL language used is presented in Appendix B. There are two levels of wrappers provided in the demonstration project. The first level provides a basic interface to each of the database tables. This interface is named the patient_record_server_type. This interface provides methods to retrieve a piece of the patient record, as implemented by the underlying database. Each method provides controls on the access to the information based on the role of the requester.
Methods GetIdRecordList, GetAdministrativeList, GetEncounterList, GetEncounterNotesList, GetDiagnosticList, and GetAnnotationList perform query-by-example. An input parameter, of the same type as the objects returned in the list, contains the criteria for performing the query on the patient record database. For example, for method GetIdRecordList, to search on last name of "Smith," the criteria's record must have last_name set to "Smith."
Table 1 provides a description of the methods provided by the patient record server object.
The higher-level interfaces provided are patient_role_server_type
and doctor_role_server_type. These interfaces provide the methods
unique to their respective roles. For example, the patient role
server provides a method GetPatientRecord that retrieves the entire
patient record for a given patient id. Both the patient and doctor
servers rely on the lower-level patient record server interface
to implement the operations. Table 2 gives the description of
the patient server, and Table 3 gives the description for the
doctor server.
| GetAccessInfo | Returns access control information for a user name if access is verified for given name and password |
| GetIdInfo | Returns a patient ID record for a specific patient ID |
| GetIdRecordList | Returns a list of patient ID records |
| GetAdministrativeList | Returns a list of administrative records |
| GetEncounterList | Returns a list of encounter records |
| GetEncounterNot | Returns a list of encounter notes |
| GetDiagnosticList | Returns a list of diagnostic records |
| GetAnnotationList | Returns a list of annotations |
| GetPatientRecord | Returns the entire patient record for a given patient ID; the requester's role must be patient |
| GetIdRecords | Returns a list of ID records for all patients |
| GetPatientRecord | Returns the entire patient record for a given patient ID |