MIRC PHI Access Logging

From MircWiki
Revision as of 19:44, 8 March 2013 by Johnperry (talk | contribs) (Protected "MIRC PHI Access Logging" ([edit=sysop] (indefinite) [move=sysop] (indefinite)))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

This article describes how the PHI Access Log works in the RSNA MIRC implementation. It is intended for anyone who authors documents containing PHI and for administrators of sites with such documents.

The Advanced Author Tool provides a section called PHI. This section can contain one or more study blocks, each containing fields itentifying:

  • a study identifier (typically the DICOM StudyInstanceUID)
  • a patient identifier (typically the DICOM PatientID)
  • a patient name (typically the DICOM PatientName)

When a MIRCdocument is displayed or exported, the server checks the document to see if it contains a PHI section. If it does, the server makes an entry in an access log. The entry contains:

  • the date and time of the access to the document
  • the username of the requestor
  • the IP address of the requestor
  • the path identifying the MIRCdocument on the server
  • the query parameters included in the request
  • the contents of the three fields for each study block

The HIPAA privacy regulations require the mantenance of a log tracking access to PHI. The PHI section allows the author to specify what information is to be logged. This section is not intended for any other purpose. There may be PHI in many other sections of the document. The purpose of the PHI section is only to trigger the logging action and to provide the contents of the log entry.

1 Responsibilities of the Author

When creating a document containing PHI, the author is responsible for adding a study block for each study whose PHI is included in the document.

Since the regulations require that the person accessing PHI be identified, it is important that documents containing PHI not be made public.

2 Responsibilities of the Administrator

If the DICOM Service template or TCE Service template is configured to capture PHI from DICOM transmissions, the phi element must be included in the template. The GxxxxExxxx element can be used to populate the fields automatically. See DICOM Elements for details. See also the article on the MIRCdocument Schema for information on the structure of the phi element.

The contents of the access log are available to the administrator through the URL path /mirc/phi.

If a public document containing PHI is accessed by an unauthenticated user, the access log entry contains the value [User NOT authenticated] for the username. Seeing this in the log indicates a security problem that must be corrected by changing the read permission for the document to make it private or restricted (e.g., non-public).

3 Important Note

Removing or modifying the phi element in a MIRCdocument does not completely de-identify the document. At the risk of over-emphasizing the obvious, the existence of the phi element only indicates that PHI is present elsewhere in the document. Removing the element or modifying it is actually a violation of the regulations since it would then either indicate that the document contained no PHI or that it contained different PHI from what is actually present.