Monday, November 30, 2009

ATNA and Accounting of Disclosures

The ATNA audit log enables an Accounting of Disclosures but is NOT the Accounting of Disclosures. It doesn't contain all the events or details, and should not.

I must be very clear that ATNA audit logging is designed and intended for “Security Surveillance” only. It is intended to be used by the security office to detect anomalies that need further investigation. It does not even purport to contain all the information for this further investigation. Further investigation often involves inspection of other things for corroborating evidence such as from non-security audit logs, video camera recordings, door-lock logs, security-guard logs, interviews, etc. In this spirit the ATNA audit log is a best-effort log, meaning that it will record the best most fullest information that it has. This means that if a user-identity is available then it needs to be in the audit log, but if it isn’t (and presumably access control had good reason to allow the event) then none is recorded.

As implied above, the ATNA audit log it-self is expected to be somewhat redundant. This is why the Document Consumer and the Registry are expected to record an audit log event, even though the audit log event is expected to have the same data. This is done so that one can see the anomaly where the Registry is being queried without the appropriate Document Consumer query. But also because it is possible that the Document Consumer can record things like the user identity better than the Registry can. (I use Document Consumer and Registry as examples, Insert any actors and the story reads the same).

The design of ATNA was deliberate to exclude descriptive values, favoring unique identifiers and codes. This was done in full understanding that the security office would have the ability and reasonable cause to get access to the tools for de-referencing the unique identifiers. This means that a patient is not recorded with their fullname, but rather their PID; and the security office uses the same PIX/PDQ or other method as any other application to resolve names into PID or PID into names as necessary. The advantage of this is that the security office knows of the current list of cross-referenced identifiers for a more complete view. This unique identifier lookup of course must be authorized by the access control system and audited by the audit logging system, and thus there is someone watching the watchers. This same thing is done for Document Unique IDs, where a XDS style query on the document unique id can retrieve the metadata, and if necessary the document can be pulled as well. This should also be the system used to retrieve the user identity description, organization identity, etc.

I recognize the ‘federated user ID’ issue that was uncovered in the NHIN. That is that there was no guarantee that the security office would have access to all of the federated user Identity Providers to do this reverse lookup. I would be interested in how the OASIS or Liberty-Alliance folks would resolve that one. Seems this is a common problem not unique to Healthcare. The solution seems to be a business relationship issue more than a technical one. Worse case, I would have the details from a SAML assertion logged somewhere else, rather than include descriptive information in the Security Audit Log. Another potential is to use the local identification used. This local identification can then be tracked into detailed logs of database subsystems, etc.

The ATNA audit log can be used to inform an “Accounting of Disclosures”, but the ATNA audit log must not be viewed as the “Accounting of Disclosures”. First, it contains many events that are not necessary for an Accounting of Disclosures. One important and often overlooked aspect is that it should contain the sub-system change history. Change management of hardware and software is often very important for detecting intrusions, although it is rarely related to any patient disclosure. Second the ATNA audit log is a combined list of all security audit events including all patients and all user events.

Thus we should not look for how the ATNA audit log contains all of the attributes of an Accounting of Disclosures but rather how it can be used to inform an Accounting of Disclosures. In fact there is likely other sources of information that will need to be brought into the reporting workflow to produce a complete Accounting of Disclosures. Indeed the best that one can expect an infrastructure system, such as XCA Responding Gateway, that is recording ATNA audit events to do is provide a list of events that need further investigation.

Given all the above, you should see why the “Plain text Name of the User”, “Plain text Name of the Organization”, “Purpose of Use”, or other attributes necessary in an Accounting of Disclosures are not a part of the ATNA audit log. But the events found in the ATNA audit log would be used to investigate if the event does represent a disclosure, and additional resources would be used to derive these Accounting of Disclosure attributes.

1 comment:

  1. I would add...

    I strongly recommend against repurposing or overloading any RFC 3881 data. That would thwart interoperability and archival validity and violate standards at least in spirit.

    RFC 3881 ActiveParticpant.UserName is an optional text field that is meant to capture the external user entity identifier. It's use is not standardized, so you cannot depend on it being valued or used consistently among implementations.

    RFC 3881 ParticipantObjectIdentification.ParticpantObjectName is an optional text field that is meant to capture the external identifier, e.g., patient name. It's use is not standardized, so you cannot depend on it being valued or used consistently among implementations.

    You can use the optional ParticipantObjectIdentification.ParticipantObjectDetail item to record well nigh anything in an audit record. However, the type-and-value pairs are not standardized, so you cannot depend on them being valued or used consistently among implementations.

    It is possible to profile RFC 3881 (IHE ATNA, HITSP T15) to make optional data be non-optional. This requires a side-agreement for all parties to value the data consistently. Gaining widespread consent to the agreement is an open question.

    You can extend the RFC 3881 schema per W3C rules. I recommend against this, as the extender needs to arrange for the extension schema to be owned and maintained long-term. Gaining widespread consent to use the extension is an open question.

    ReplyDelete