Patient Data in the Audit Log

There are many different Audit Logs that we often think of. These audit logs should be designed and maintained independent as they have very different purposes.

1. Security Audit Logs -- contain log of security relevant events that have happened. These logs are used to prove that the security controls are working properly and to evaluate if the organizations security and privacy policies are being upheld. The use of these audit logs are limited to the privacy/security office. I outline in Accountability using ATNA Audit Controls how to get Privacy Audit Reports from a Security Audit Log.
2. Medical Records Audit Logs -- contain log of clinically relevant events that have happened. Are used to prove that a clinical event has happened. Examples include that a drug that was ordered was administered by a specific nurse at a specific time. These audit logs need to be visible to the clinical users and are used in clinical decision support and reporting.
3. Error/Event Audit Logs -- contain log of errors or events that have happened. Often these are debugging logs or diagnostic (software or hardware) logs that are used by service personnel during the installation, configuration, or servicing of the system/equipment

How much Patient Identifiable Data is allowed in Security Audit Logs?

There are a few factors in this question:

• Patient Identifiable Data is the binding of healthcare data with identifiers of the patient. In the USA this is referred to as Protected Health Information (PHI).
• Audit logs, especially security logs, generally need many identifiers. These identifiers will give accurate sorting, filtering, and reporting.
• The Audit Reporting system can always use lookup services (IHE PWP, PDQ, XDS, or other) to convert identifiers into displayable names, or to find aliases that should also be used in the searching.
• Audit logs, especially security logs, generally do NOT need healthcare data. They need to identify the data, which is done using unique identifiers assigned to the data where possible.

Thus the answer to the question is that audit logs should have as close to zero PHI in them as possible. This of course is the goal, with the possibility of good reason to break this goal. Usually these good reasons are because the identifiers are not yet available, or not available in the code-path that is recording the audit event.

Therefore the audit logs should include the user ID, but not the display name of the user. They should include the patient ID, but not the patient's name. They should include the lab order number, but not the lab values.

Here is an abstract description of an ATNA audit event, one event:

• User ID (e.g. 212008131, NOT the user's personal name: "John Moehrke")
• Patient ID (e.g. pa123456, NOT the patient's personal name)
• Data ID (DICOM SOP Instance, CDA Document OID, XDS UUID)
• Description of what (Viewed, Created, Updated, Printed, Exported, etc)
• Success/Failure of the operation

The point is that the reporting tools have the ability to look these up, with appropriate access controls and audit logs too…

It is understood that some clinics are specialty clinics, like Betty Ford Clinic, and thus a patient being associated with that clinic is enough to suspect that the patient has that ailment. These specialty clinics need to be handled as special cases.

Where are Security Audit Logs stored?

Security Audit logs need to be protected from threats. These are a different class of threats and there is a very different set of mitigation.

A security audit log needs to be writable by any system that is creating authentic audit log events, clearly the record needs to show what system recorded the event. One risk this presents is that a malicious individual could simply create many audit events and thus overflow the audit server with useless messages, so the operational design needs to handle this.

The security audit log should be readable only by those authorized to read it. This will be a small sub-set of employees as the security audit log will contain sensitive health information (PHI), but will also contain sensitive employee information.

There are many different filtering, reporting, and alerting requirements on the audit log system.

This is why the ATNA profile utilizes syslog standards to record the audit events on a specialized system. These specialized systems are used often outside of healthcare, and there is a very large industry built around them (IBM tivioli, CA unicenter, etc). The Healthcare industry should utilize these network standards and focus our attention on continuing to develop clinical capability. There is no reason for the healthcare industry to reinvent this wheel.

See Also

• IHE - Privacy and Security Profiles - Audit Trail and Node Authentication
• Accountability using ATNA Audit Controls 
• ATNA and Accounting of Disclosures
• ATNA audit log recording of Query transactions
• How granular does an EHR Security Audit Log need to be?
• Document Submission: Audit requirements under error conditions
• ATNA + SYSLOG is good enough
• NIST SP800-92 Guide to Computer Security Log Management

Around and Around we go

I have spent the last three days in DC at a face-to-face meeting with the S&I Framework - Data Segmentation for Privacy (DS4P). We have gotten nothing accomplished. No matter what direction the agenda tries to approach this, we end up discussing the 'yes but' rat-holes.

The Project has 5 parts. These 5 parts are well defined, and we could focus on any one of them and make progress.

1. How do you PUSH clinical documents from one organization to another while carrying enough information that the receiving organization can protect them
2. How do we PULL clinical documents from one organization to another while protecting the the information 
3. How do we manage consents in an HIE that chooses to have central management and HIE-wide consents. 
4. What would centrally managed consent look like. Documenting the CDA consent-directive, and how it can be used for specific use-cases.
5. What are the rules that one would use to determine the 'tagging' of data that you are about to send.

Privacy Rules
The biggest problem is of course that the rules one would need to apply for (5) and the rules one would need to encode in (4) are not well defined, even in the paper world. If they could be defined in the paper world this would be a much quicker problem to solve. Because of this lack of clarity even in the paper world, it is hard to discuss how to move this from paper to electronic. I would like to offload much of this work until the ONC e-Consent project is further along. This project should help give us some clarity on the rules, hopefully starting with some reasonable stepping stones.

Communicating Segmentation 
Items 1-3 are available today, but not well understood. This is especially true if one focuses on Document exchange where the control necessary is applied to the whole document. It is true that CDA does have some ability to drive controls at the section level, and there are some hacks available for the entry level. This CDA mechanism is really not well understood, and I struggle to find any real-world use of it. Further this mechanism is under revision with the CDA R3 project, revision that could really do a better job if given some reasonable input. Thus, I would like to see the S&I Framework project focus the fine-grained controls within CDA on documenting the need and use-cases for these fine-grained controls.

The point I would like to emphasize is that the transport can do one level, totally independent of the more fine-grained controls that could be applied within a CDA document. The industry would gain greatly simply through the documentation of the kind of controls that the transport can offer. This would be very useful to moving forward.

Conclusion
We can document some solutions that are available today but not well understood or documented. I am perfectly fine with explaining that they are not perfect solutions. I am simply not willing to let perfection get in the way of good. I want to move the Healthcare industry along using stepping stones.

The French Health Information Systems Interoperability Framework -- Now available in English

I first pointed at the French National EHR based on IHE XDS back in June. The good news today is that there is now an English translation of their documents. The important part about this is not just that they used XDS, and did a fine job of explaining XDS better than IHE ever have. The important part is that because this is an operational environment, they document those things that are beyond the scope of IHE. This means document content, vocabularies, security model, privacy model, etc.

The documents now available in English are:

• Introduction to the HIS-IF
• Common Rules and Templates for CDA Content Modules
• Service Layer for Document  Sharing
• Synchronous Transport Layer

To get access to these, Please go to this article on the release of these documents

Meaningful Transmission into Oblivion

Today I heard that the Meaningful Use Stage 2 criteria require only that PHI can be Transmitted, never Received. I was shocked and didn't believe it was so. I asked around and indeed we couldn’t find any case where the Meaningful Use Stage 2 criteria ever requires a certified product be capable of receiving PHI that was transmitted by another.

This kind of one-sided conversation is typical of government work, but that surely can’t be the intention. Surely ONC didn’t mean that they want everyone to be able to Send health information while at the same time no-one is required to be able receive it. But clearly that is all that the ONC rule calls for. “transmit to 3rd party”, and “transmit summary of care record”. One could include “download” by the patient. Never includes receive or upload…


Oblivion is a dark place, where all Health data probably  already exists. Why send more of it there?

This is so absurd that I had described the receiving side when I covered the Meaningful Use Transports. Indeed all discussions of Health Information Exchange always speak of how one receives the documents. It is the reception of the documents (pushed or pulled) that ultimately provide the benefit of a HIE. The original author or custodian doesn’t get any benefit from their participation in the Exchange. So, it could be that ONC simply figures that reception is obviously needed and thus will happen naturally.

Hope springs eternal, is an unreliable way to get change.

Some of the use-cases such as immunizations, surveillance, or reportable cases are indeed one-way. There is no need for these to have receive sides.

Receiving externally sourced documents does have struggles that are unique and difficult. The Meaningful Use stage 1 included criteria to Display documents, I guess one could assume this is enhanced at MU2 without need for clarity? I think it needs to be made clear. Specifically CDA documents by definition only require that the narrative part be displayed. There is no CDA criteria that I am aware of that requires that any of the structured and coded part be used in any display or even used in anyway at all. Just that the narrative block can be displayed.

Typically the Reception side is done through some human mediation. This is done to allow for quality controls to check that the content is intact, that the patient is identified and matched, that there is proper coding or manipulation of coding, that there is appropriate permissions applied, that there is appropriate routing to appropriate people, etc. So, typically there is not much that one can do purely in technology. This is especially true with the Direct Project, when the sender didn't utilize the XDM.zip content packaging with the defined XD* Metadata. But even when metadata is perfect, codes are aligned perfectly, and there is clear need and permissions; the automated flow directly into the Legal Medical Record will be carefully controlled by Medical Records oversight. I think that the legal Medical Records domain is not considered enough.

Patient Provided data is important yet a difficult topic due to plenty records of intentional abuse (drug seeking behavour) or unintended (forgetting some critical factor). Patient provided 'upload' is even harder as it also has to deal with issues of potential falsification. I have had these discussions with some as well, people really wanting Digital Signatures. I think Digital Signatures will eventually happen, but they are not a panacea and there are other ways for a provider to check on the accuracy of another provider's authored content. Such as, ask the other provider for confirmation. For truly patient authored content, the kind of thing the doctor first asks you in the exam room: "What is the problem?"; this is always considered suspicious until the doctor confirms with his own observations... (I would say taken with a grain of salt, but we all know salt is bad for the health).


Conclusion
Thus at best the Reception side should be expected to be a human mediated queue (inbox). There will be cases where it is more automated, especially with Query/Retrieve exchanges. But that is a different topic.

Updates
Note that the NPRM does require the capability to incorporate the summary of care record and to reconcile clinical information [§170.314(b)(1) Incorporate summary of care record] and [§ 170.314(b)(4) Clinical information reconciliation]. But I would stress that in order to incorporate one must first catch it.


Note2 that the NPRM [§170.314(b)(1)] does say what should be done after one catches a 'summary of care record'. And it is right in line with my concern above. But it still doesn't say what precedes the 'incorporation' functionality, nor what one would do with anything that might come in on the defined 'Transports'.

§ 170.314(b)(1)(1) Transitions of care – in corporate summary care record . Upon receipt of a summary care record formatted according to the standard adopte d at § 170.205(a)(3), electronically incorporate, at a minimum, the following data elements: Patient name; gender; race; ethnicity; preferred language; date of birth; smoking status; vital sign s; medications; medicati on allergies; problems; procedures; laboratory tests and va lues/results; the referring or  transitioning provider’s name and contact information; hospital admission and  discharge dates and locations; discharge instructions; reason(s) for hospita lization; care plan, including goals and instructions; names of  providers of care during hospitalizations; and names and contact information of any additional known care team members beyond th e referring or transitioning  provider and the receiving provider. 

FW: NIST - Safeguarding Health Information: Building Assurance through HIPAA Security

This just crossed my desk. Wish I could be there. Please let me know how it goes.

NIST, HHS and OCR Sponsored Event: 
“Safeguarding Health Information: Building Assurance through HIPAA Security”

The National Institute of Standards and Technology (NIST) and the Department of Health and Human Services (HHS), Office for Civil Rights (OCR) are co-hosting the 5th annual conference Safeguarding Health Information: Building Assurance through HIPAA Security on June 6 & 7, 2012 at the Ronald Reagan Building and International Trade Center in Washington, D.C.  

Visit NIST website for details and registration.

The conference will explore the current health information technology security landscape and the Health Insurance Portability and Accountability Act (HIPAA) Security Rule. This event will highlight the present state of health information security, and practical strategies, tips and techniques for implementing the HIPAA Security Rule. The Security Rule sets federal standards to protect the confidentiality, integrity and availability of electronic protected health information by requiring HIPAA covered entities and their business associates to implement and maintain administrative, physical and technical safeguards.

The conference will offer important keynote addresses and plenary sessions as well as breakout sessions following two learning tracks around specific areas of security management and technical assurance. Presentations will cover a variety of current topics including updates on HHS health information privacy and security initiatives, OCR's enforcement of health information privacy and security activities, integrating security safeguards into health IT, safeguards to secure mobile devices, removing sensitive data from the Internet, and more.

Visit NIST website for details and registration.

---