Wednesday, September 18, 2013

IHE-ATNA and HL7-FHIR.SecurityEvent -- recording a Disclosure

An Accounting of Disclosures is a report that a Patient has the right to get. This report includes all the touches of their data that are outside some set of rules. In the USA these rules are defined in HIPAA, and mostly exclude just about everything. But, an Accounting of Disclosures is still a Right. I have covered the fact that an Accounting of Disclosures is only informed by IHE-ATNA audit log, mainly because few of the events that the rules say need to be recorded are mediated by Healthcare IT technology.

I am working on a FHIR application that one could use to record that a Disclosure has happened. This is defined in ASTM-2147, generally we need to know:
  • Who did the disclosure, 
  • What patient was involved (multiple patients, would be done as multiple audit entries), 
  • what data was involved (multiple identifiable data would be multiple audit entries), and 
  • why was the disclosure done. 
There is some other information that some circumstances would call for:
  • Who is the custodian of the data (the official organization responsible), and
  • Who authorized the release (if not the patient, or policy)
This brings up the question of how do I put this information into an IHE-ATNA Audit Log message. Well, the IHE-XUA profile put a minimal pattern of this IHE-ATNA event for recording that a Disclosure happened. I will expand on it a bit here, and likely in a new Change Proposal. The HL7 PASS Audit service also defined this Disclosure event. So, much of what I am doing is just bringing things together.

Some Standards work still needed:

It appears that some new codes need to be created. It isn't very clear what is the best organization to do this, but I always like going back to the core standards organization simply to keep everything nicely together. So I would tend to go back to DICOM.

First, we need an EventTypeCode that indicates that this event was a confirmed "Disclosure", as distinct from Export" events that are need to be looked at to see if they are part of normal treatment workflows.
It is not clear if the rest of this is the right values. specifically the identity of the  custodian and the authorizing agent. I pulled values from the role vocabulary in ASTM-1986. I couldn't find these in ISO-21298. I don't have easy access to the roles in SNOMED.

There also appears to be other work that I have uncovered that needs clarifications in IHE-ATNA, DICOM, and now FHIR.

ATNA - Accounting of a Disclosures audit message:

Field Name
Opt
Value Constraints
Event
AuditMessage/
EventIdentification
EventID
M
EV(110106, DCM, “Export”)
EventActionCode
M
“R” (Read)  for Export
EventDateTime
M
not specialized
PurposeOfUse
M
why was the data disclosed
EventTypeCode
M
EV(“Disclosure”, “HIPAA”, “Privacy Disclosure”)
ActiveParticipant - Releasing Agent (1)
ActiveParticipant - Custodian (0..1)
ActiveParticipant - Authorizing Agent (0..1)
ActiveParticipant - Receiving Agent (1)
Audit Source (1)
ParticipantObject – Patient(1)
ParticipantObject – Data (Document) released(1)

Releasing Agent
AuditMessage/
ActiveParticipant
UserID
M
Identity of the human that initiated the Disclosure.
AlternativeUserID
U
not specialized
UserName
U
not specialized
UserIsRequestor
M
“true”
RoleIDCode
M
EV(110153, DCM, “Source”)
NetworkAccessPointTypeCode
M
“1” for machine (DNS) name, “2” for IP address
NetworkAccessPointID
M
The machine name or IP address, as available
Custodian 
(if known)
AuditMessage/
ActiveParticipant
UserID
U
not specialized
AlternativeUserID
U
not specialized
UserName
U
not specialized
UserIsRequestor
M
“false”
RoleIDCode
M
EV("Health Records", ASTM1986, "Health Information Management")
NetworkAccessPointTypeCode
NA
not specialized
NetworkAccessPointID
NA
not specialized
Authorizing Agent
(if known)
AuditMessage/
ActiveParticipant
UserID
U
not specialized
AlternativeUserID
U
not specialized
UserName
U
not specialized
UserIsRequestor
M
“false”
RoleIDCode
M
EV("Patient Advocate", ASTM1986, "Patient Advocate")
NetworkAccessPointTypeCode
NA
not specialized
NetworkAccessPointID
NA
not specialized
Receiving Agent
AuditMessage/
ActiveParticipant
UserID
U
not specialized
AlternativeUserID
U
not specialized
UserName
U
not specialized
UserIsRequestor
M
“false”
RoleIDCode
M
EV(110152, DCM, “Destination”)
NetworkAccessPointTypeCode
M
“1” for machine (DNS) name, “2” for IP address
NetworkAccessPointID
M
The machine name or IP address, as available
Audit Source
AuditMessage/
AuditSourceIdentification
AuditSourceID
U
not specialized.
AuditEnterpriseSiteID
U
not specialized
AuditSourceTypeCode
U
not specialized
Patient    
(AuditMessage/
ParticipantObjectIdentification)
ParticipantObjectTypeCode
M
“1” (Person)
ParticipantObjectTypeCodeRole
M
“1” (Patient)
ParticipantObjectDataLifeCycle
U
not specialized
ParticipantObjectIDTypeCode
M
EV(2, RFC-3881, “Patient Number”)
ParticipantObjectSensitivity
U
not specialized
ParticipantObjectID
M
The patient ID in HL7 CX format.
ParticipantObjectName
U
not specialized
ParticipantObjectQuery
U
not specialized
ParticipantObjectDetail
U
not specialized
Data (Document) Released
(AuditMessage/
ParticipantObjectIdentification)
ParticipantObjectTypeCode
M
“2” (System)
ParticipantObjectTypeCodeRole
M
“3” (report)
ParticipantObjectDataLifeCycle
U
not specialized
ParticipantObjectIDTypeCode
M
EV(9, RFC-3881 , “Report Number”)
ParticipantObjectSensitivity
U
not specialized
ParticipantObjectID
M
The value of <ihe:DocumentUniqueId/>
ParticipantObjectName
U
not specialized
ParticipantObjectQuery
U
not specialized
ParticipantObjectDetail
U
not specialized











FHIR SecurityEvent - Disclosure 

That is the complex and complete definition using the IHE-ATNA table. We now have a RESTful implementation of this in HL7 FHIR. So what does one of these look like in FHIR. The advantage, or disadvantage, of FHIR  is that it does allow you to cheat. Given that it has left constraints to profiles, such as IHE, it leaves almost everything optional. It further provides mechanisms for simple text to be used where  coded values are defined. Thus I can make a very simple FHIR message, that really doesn't carry the same meaning, but does get across the educational purpose. Note that I am still working on this, so will update this as I get it corrected.

<SecurityEvent xmlns="http://hl7.org/fhir">
  <event>
    <type>
      <coding>
        <system value="http://nema.org/dicom/dcid"/>
        <code value="110106"/>
        <display value="Export"/>
      </coding>
    </type>
    <subtype>
        <coding>
            <system value="HIPAA"/>
            <code value="Disclosure"/>
            <display value="HIPAA disclosure"/>
        </coding>
    </subtype>
    <action value="R"/>
    <dateTime value="2013-09-17T14:24:00-06:00"/>
    <outcome value="0"/>
  </event>
  <participant>
    <!-- Source Participant, the Releasing Agent -->
    <role>
      <coding>
        <system value="http://nema.org/dicom/dcid"/>
        <code value="110153"/>
        <display value="The sender of the data"/>
      </coding>
    </role>
    <userId value="INSERT_USERNAME"/>
    <requestor value="true"/>
  </participant>
  <participant>
    <!-- Destination Participant, the Receiving Agent -->
    <role>
      <coding>
        <system value="http://nema.org/dicom/dcid"/>
        <code value="110152"/>
        <display value="The destination of the data"/>
      </coding>
    </role>
    <userId value="INSERT_RECIPIENT"/>
    <requestor value="false"/>
  </participant>
  <source>
    <!-- Source of Audit event -->
    <identifier value="Johns Accounting of Disclosures Application"/>
  </source>
  <object>
    <!-- ParticipantObject - Patient -->
    <identifier value="INSERT_PATIENT_NAME"/>
    <name value="INSERT_PATIENT_NAME"/>
    <type value="2"/>
    <lifecycle value="6"/>
  </object> 

  <object>
    <!-- ParticipantObject - what was disclosed -->
    <lifecycle value="11"/>
    <type value="4"/>
    <identifier value="INSERT_DESCRIPTION_OF_DATA"/>
    <name value="INSERT_DESCRIPTION_OF_DATA"/>
  </object>
</SecurityEvent>

Conclusion

This is just how to record that a Disclosure has happened. I have yet to work out how a report can be made. I suspect this should be somewhat easy, especially with FHIR. I can just query on the SecurityEvent with the patient that I want to report on, looking for Export / Disclosure events. Then I just extract out the specific fields. More complex will be to handle someone being more complete with their Disclosure auditing.

The playing with this has uncovered a bunch of little things. It appears that I have uncovered there needs to be clarifications in IHE-ATNA, DICOM, and now FHIR.

No comments:

Post a Comment