Difference between revisions of "MIRC PHI Access Logging"
m (Protected "MIRC PHI Access Logging" ([edit=sysop] (indefinite) [move=sysop] (indefinite))) |
|||
(3 intermediate revisions by the same user not shown) | |||
Line 2: | Line 2: | ||
The Advanced Author Tool provides a section called <b>PHI</b>. This section can contain one or more <b>study</b> blocks, each containing fields itentifying: | The Advanced Author Tool provides a section called <b>PHI</b>. This section can contain one or more <b>study</b> 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 <b>PHI</b> section. If it does, the server makes an entry in an access log. The entry contains: | When a MIRCdocument is displayed or exported, the server checks the document to see if it contains a <b>PHI</b> 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 <b>study</b> block | |
− | The HIPAA privacy regulations require the mantenance of a log tracking access to PHI. The <b>PHI</b> section allows the author to specify what information is to be logged. This section is <b>not</b> intended for any other purpose. There may PHI in many other sections of the document. The purpose of the <b>PHI</b> section is only to trigger the logging action and to provide the contents of the log entry. | + | The HIPAA privacy regulations require the mantenance of a log tracking access to PHI. The <b>PHI</b> section allows the author to specify what information is to be logged. This section is <b>not</b> intended for any other purpose. There may be PHI in many other sections of the document. The purpose of the <b>PHI</b> section is only to trigger the logging action and to provide the contents of the log entry. |
==Responsibilities of the Author== | ==Responsibilities of the Author== | ||
Line 22: | Line 22: | ||
== Responsibilities of the Administrator == | == Responsibilities of the Administrator == | ||
− | If the DICOM Service template or TCE Service template is configured to capture PHI from DICOM transmissions, the <b> | + | If the DICOM Service template or TCE Service template is configured to capture PHI from DICOM transmissions, the <b>phi</b> element must be included in the template. The <b>GxxxxExxxx</b> element can be used to populate the fields automatically. See [[The_MIRCdocument_Schema#DICOM_Elements |DICOM Elements]] for details. See also the article on the [[The_MIRCdocument_Schema#phi | MIRCdocument Schema]] for information on the structure of the <b>phi</b> element. |
The contents of the access log are available to the administrator through the URL path <b><tt>/mirc/phi</tt></b>. | The contents of the access log are available to the administrator through the URL path <b><tt>/mirc/phi</tt></b>. |
Latest revision as of 19:44, 8 March 2013
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.