Must be implemented by a User Manager. When Noah Client has a need for a user, e.g. a module connects to Noah Client, Noah Client will start the preferred User Manager if it is not running. Noah Client will call the User Manager's implementation of the Login interface. If returning true, a valid User ID will be returned in UserID and Noah Client will set this UserID as the logged in User. The User Manager should not call SetCurrentUserID as Noah Client sets the User ID and the User manager will received a UserChanged event. This may be a little surprising, but it is consistent with the rule that the initiator of an action that causes an event does not receive the event but all other applications will receive the event.
A module connects to Noah Client and no user is logged in.
The module connect call is blocked until a user is logged in.
Noah Client will start a User Manager because of the module that connects, the module is the initiator of the action.
Noah Client calls the login function and a user ID is retuned as a result of the call. This is not an action with respect to Noah Client.
Noah Client sets the user as the logged in user .
A User Changed event is fired to the User manager
The modules connect call returns.
bool GetPatientIDsByInfo(object PatientInfo, out int PatientID);
// NOT USED
bool SetPatientIDByInfo(int  PatientIDs, out int PatientID)
Given a number of patient ids, the PatientManager verifies the ids and displays the GUI that gives the user the option to select a patient or patients, if more than one. If only one patient id is given, the id is verified and the function returns immediately without showing the GUI. If PatientIDs is null, the patient GUI is shown, and the user can select a patient. If a valid patient is returned, the function returns true and the patient is set to active in Noah Client. This is the same scenario as calling Login, described above. The patient manger should not call SetCurrentPatientID as the patient manager will received a PatientChanged event.