Special Instructions
PREREQUISITE TEST:
The ATNA Secure Node/Application should successfully complete the no-peer AuditEvent_Resource_Check test before this one. Passing that test ensures that you are sending compliant audit messages in this peer-to-peer test.
TRANSPORT FOR THE AUDIT RECORDS:
There are three variations of this peer-to-peer test:
- ATNA_Audit_Logging_FHIR-Feed (this test)
- ATNA_Audit_Logging_TLS-Syslog
- ATNA_Audit_Logging_UDP-Syslog
TEST PARTNERS:
This is a peer-to-peer test. A Secure Node or Secure Application must send audit messages to a vendor's Audit Record Repository; a tool is not a valid partner for this test.
Both test partners must support the ATX: FHIR Feed option.
Description
The purpose of this ATNA_Logging_FHIR-Feed test is for your ATNA Secure Node or Secure Application to send AuditEvent Resources to an Audit Record Repository.
The type of AuditEvent Resource depends on the nature of the Secure Node/Application.
The top priority for audit testing would be an event that involves
access to PHI that would result in an audit message that includes a
Patient ID. If the Secure Node or Secure Application does
not generate an audit message that includes a patient ID, we will accept
a different audit message.
Evaluation
Monitor Instructions:
The primary purpose of this test is to check interoperability
(exchange of audit messages) between the Secure Node/Application and the
Audit Record Repository. It is not necessary for you to use the
EVSClient tool to verify the content of the audit messages that are
exchanged in this test. That kind of verification is done in the AuditEvent_Resource_Check test.
Evidence provided by the ARR:
- Some ARRs have great user interfaces to enable the monitor to view the received audit message; the ARR will give guidance in Step 10 on how to find the audit message(s) exchanged in this test.
- Otherwise the ARR is asked to paste log evidence, database evidence, or a screen capture into Test Step 20 so that you don't have to hunt for logs with the ARR.
- Step 30 tells the participants in the test that a Monitor will not verify it without good evidence in step 10 or 20.
Evidence provided by the Secure Node or Application:
- The XML or JSON for the audit AuditEvent Resource sent by the SN or SA is found in Step 110.
To verify:
- The submission of an audit record is an HTTP POST by the
SecureNode/Application of a single AuditEvent Resource to the Audit
Record Repository.
- The AuditEvent applies to a
transaction/trigger that occurred during Connectathon week (i.e. the
SA/SN is not posting an 'old' audit record)
- Confirm that the AuditEvent sent by the SN and SA has been received and stored on the ARR.