<H3>Special Instructions</H3><p> <p>This test is based on a use case involving a series of login and patient record events. The secure node should check with the Project Manager to find the assigned Audit Record Repositories. Then, the secure node should run through the test and make sure all of the events are logged. During the evaluation, the Connectathon monitor will ask the Secure Node to repeat the steps and will examine the logs in the Audit Record Repository in real time.</p> </p><H3>Description</H3><p>This test shows that the Secure Node manages different accounts for different users and can disable accounts when one of the users is no longer employed by the institution. It shows this management by examining audit logs. The log should reference the user accounts specifed below (use those accounts) and the system that is being tested. Indicating in the log that "someone" logged in "to some system" is not acceptable for this test.</p><p>Paul Erker and William Retired are cousins working at the Large Hospital System (LHS). They have login IDs of <strong>erkerp</strong> and <strong>retiredw</strong>. William Retired will retire during the Connectathon week. During the first part of the test, he has access rights; after retirement, those rights are revoked. Please follow these steps for this test.</p><ol> <li>Each Secure Node should create and activate accounts for <strong>erkerp</strong> and <strong>retiredw</strong> for operation on Monday morning or in advance of the Connectathon. This does not require an audit message.</li> <li>On the Secure Node, login as retiredw. This should generate an audit log. The Secure Node should allow William to have access to some data that would generate an audit log. This will be specific to the actor and profiles supported. At least one audit record should be generated <strong>Two audit messages verified by monitor.</strong> </li> <li>On the Secure Node, disable the <strong>retiredw account</strong>. No audit record is required.</li> <li>On the Secure Node, try to login (and fail) as <strong>retiredw</strong>. This should fail and generate an audit record <strong>verified by monitor.</strong> </li> <li>On the Secure Node, login (successfully) as <strong>erkerp</strong>. This should generate an audit record (<strong>verified by the monitor</strong>).</li> </ol><H3>Evaluation</H3><p>Connectathon monitor will observe the Secure Node performing the tasks listed as they occur in real time. The monitor will then examine the Audit Record Repository to see if the proper audit messages are received. It is probably best to examine the Audit Record Repository after each event.</p><p>Monitor is looking for these audit events in this order</p><ol> <li>Successful login for retiredw </li> <li>Access to PHI/patient record for retiredw</li> <li>Login failure for retiredw</li> <li>Successful login for erkerp</li> </ol><p>Login failures should be clearly identified as failures. All events should clearly indicate the user and system that generated the event. Events that include access to PHI should clearly indicate the patient.</p> 