Abstract:
A method for detecting privacy violations of patient personal healthcare information (PHI) can include receiving audit logs from all systems within a healthcare facility. These audit logs are generated any time PHI is accessed. The Healthcare Privacy Violation Detection System (HPV-DS) compares these generate audit logs to prior access history of the employee or authorized user that generated the audit log. If any field in the generated audit log is different from the authorized user&#39;s prior access history, the risk of a privacy violation is assessed and a risk score is assigned. For audit logs that differ from past access history enough, an alert turned on and the audit log is flagged for administrators to review.

Description:
RELATED APPLICATIONS 
       [0001]    This application is a non-provisional of U.S. provisional application No. 61/664,517, filed on Jun. 26, 2012, entitled “Healthcare Privacy Violation Detection and Investigation System and Method,” and U.S. provisional application No. 61/664,570, filed on Jun. 26, 2012, entitled “Healthcare Privacy Violation Detection and Investigation System and Method”, which are incorporated by reference herein in their entireties. 
     
    
     FIELD OF THE INVENTION 
       [0002]    The invention relates to data processing of healthcare management and patient record management, more specifically auditing an employee&#39;s or an authorized user&#39;s access to personal healthcare information, and more particularly information security policy for privacy investigation, breach reporting, and detection system and method. 
       BACKGROUND 
       [0003]    Healthcare facilities maintain massive databases containing a plethora of patient electronic medical records (EMR) and personal healthcare information (PHI). With a multitude of privileged information, the risk of inappropriate access is high. Health Insurance Portability and Accountability Act (HIPAA) and Health Information Technology for Economic and Clinical Health (HITECH) require healthcare entities to do monthly audits on their authorized users to check for any abuse of access to PHI or EMR data. To assist enforcement of these requirements, “audit logs” are generated in healthcare facilities that identify and track authorized user activity, such as who viewed, edited, printed, etc., a patient&#39;s EMR or PHI and whether that was done with a valid reason and authorized access. An automated and intelligent system that identifies abnormal usage based on prior behavior pattern recognition greatly reduces the work of administrators, e.g., Privacy and Compliance officers, who manually go through these audit reports to identify improper access. 
         [0004]    Several systems are directed to detect certain anomalies, or abnormal activities, in data streams. Rule-based detection methods are common, as are prior usage comparison, but both are mostly directed towards finding oddities in distributed computer networks. 
       SUMMARY 
       [0005]    The Healthcare Privacy Violation Detection System (HPV-DS) serves as a central point for investigative and auditing capability for HIPAA and HITECH or other compliance requirements on storing and accessing patient PHI, enabling healthcare providers to quickly and accurately monitor breaches within their systems. HPV-DS relies on past trends of authorized users in a healthcare facility to determine if an access was appropriate. Any outlier is reported, and all access that fit within normal activity are stored, but are not reported, so only the necessary occurrences are pointed out to authorities for review. The healthcare privacy violation detection system (HPV-DS) uses a healthcare facility&#39;s audit logs and non-healthcare audit logs to detect and report an authorized user&#39;s abnormal and potentially unauthorized access to a patient&#39;s personal health information (PHI). 
         [0006]    This system collects healthcare audit logs, which are generated for every action within a healthcare facility, from various systems and departments throughout the healthcare facility. Once received, the data can be compressed and encrypted if it is desired to send the data to the Cloud through the internet. Alternatively, the data could be held at an on a premises server. When the Cloud receives the data, it is decrypted, uncompressed, parsed, and normalized. The data is normalized to ensure HPV-DS encounters uniform data, the data is not duplicated, and to discard parameters that are unnecessary. 
         [0007]    Past access patterns and parameters are used to create a baseline for each authorized user. When an audit log contains a new authorized user (without baseline information), HPV-DS creates an authorized user&#39;s baseline through a learning mode. Whenever HPV-DS encounters a new authorized user, an alert is sent to the administrator (Privacy and Compliance officer), and the authorized user&#39;s baseline is built for a predetermined amount of time. During that time, the authorized user&#39;s PHI access is considered normal; at the end of this period, or when the administrator identifies the new authorized user&#39;s patterns as normal, the HPV-DS turns to active mode for that authorized user and alerts are only triggered for pattern outliers. 
         [0008]    Using a pattern analyzer with an anomaly detection engine, HPV-DS compares an authorized user&#39;s access data in the healthcare audit logs to the authorized user&#39;s baseline access parameters. When an audit log shows a parameter different from the baseline, a predetermined risk score for the parameter is applied to that action. The healthcare facility can assign a sliding scale of risk scores to parameters. If there are multiple parameters in the audit log that differ, a higher risk score is calculated and assigned. If a threshold score is exceeded, an alert is sent to the administrator and a ticket entry is created for detailed review. If most parameters are aligned with the baseline, a lower risk score is assigned, no alert is sent, and the record is added as more baseline data for that authorized user. HPV-DS also incorporates audit logs from non-healthcare sources that include personal authorized user information, such as addresses of the authorized user&#39;s family, family member names, work colleagues, etc. These audit logs are used to create an authorized user profile, which is incorporated to the baseline and is compared to the healthcare audit logs for alerting of any high risk access to PHI. While going through the pattern analyzer, the data can be simultaneously stored. All audit log data is kept in a database table once it has been parsed and normalized for future access to audit log information upon request. 
         [0009]    While going through the pattern analyzer and being stored, the parsed and normalized data is checked by a patient alert rule base. This rule base is used to detect access to high profile patient&#39;s PHI or patients who are privacy conscious. If these particular patients are identified in the current audit log data, an alert is sent and a ticket entry is created for future detailed review. If these patients are not identified, then no alert is issued and no record is created. 
         [0010]    A method for detecting privacy violations of patient personal healthcare information (PHI) access can include at least one processor for performing the steps of generating an audit log for an access to PHI by an authorized user; comparing at least one parameter of the audit log to a corresponding baseline parameter of the access to PHI by the authorized user that is considered normal; assigning a risk score to the parameter of the audit log when the parameter of the audit log differs from the corresponding baseline parameter; and adding together all of the risk scores to determine a cumulative risk score. 
         [0011]    The method can also include weighting the cumulative risk score according to a percentage of matching parameters, and/or weighting the risk score for each parameter based on a different risk of privacy violation for a particular parameter, and/or adding audit log parameters generated by the unknown authorized user to the new set of baseline parameters for the unknown authorized user for a predefined time frame, and/or a learning engine routine including creating and storing a new set of baseline parameters for an unknown authorized user when the audit log is generated by an unknown authorized user. 
         [0012]    A method for detecting privacy violations of patient personal healthcare information (PHI) access can include at least one processor for performing the steps of generating an audit log for an access to PHI by an authorized user; communicating with at least one system to collect the audit log; normalizing and parsing the audit log into a predefined and uniform data format; discarding parameters considered to be irrelevant to a risk of privacy violation; comparing at least one parameter of the audit log to a corresponding baseline parameter range of an access to PHI by an authorized user that is considered normal and non-healthcare authorized user information; adding a weighted risk score assigned to the corresponding baseline parameter range to a cumulative risk score for the access to PHI by the authorized user if the parameter of the audit log differs from the corresponding baseline parameter range; creating an alert and flagging the audit log when the cumulative risk score exceeds an acceptable threshold; storing the normalized and parsed audit log in a storage database; comparing the audit log to a set of patient rules; and creating the alert and flagging the audit log when at least one audit log parameter matches a corresponding parameter of the set of patient rules. 
         [0013]    A method for detecting privacy violations of patient personal healthcare information (PHI) access can include at least one processor for performing the steps of generating an audit log when an access to PHI by an authorized user occurs; normalizing and parsing the audit log into a predefined and uniform data format; discarding parameters considered to be irrelevant to a risk of privacy violation; comparing at least one parameter of the audit log to a corresponding baseline parameter range of the authorized user and non-healthcare authorized user information; adding a weighted risk score assigned to the baseline parameter range to a cumulative risk score for the access to PHI by the authorized user, if the parameter of the audit log differs from the corresponding baseline parameter range for the authorized user; creating an alert and flagging the audit log when the cumulative risk score exceeds an acceptable threshold; storing the normalized and parsed audit log in a storage database; creating the alert and flagging the audit log when at least one audit log parameter matches a corresponding parameter of a set of patient rules; adding the audit log to the baseline parameter range for the authorized user when the cumulative risk score is under the acceptable threshold; and creating an alert when an unknown authorized user generated the audit log and storing the audit log as the baseline parameter range for the unknown authorized user. 
         [0014]    Other applications of the present invention will become apparent to those skilled in the art when the following description of the best mode contemplated for practicing the invention is read in conjunction with the accompanying drawings. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0015]    The description herein makes reference to the accompanying drawings wherein like reference numerals refer to like parts throughout the several views, and wherein: 
           [0016]      FIG. 1  is a simplified logical flow diagram of a patient through a healthcare facility; 
           [0017]      FIG. 2  is a simplified logical flow diagram overview of the healthcare privacy violation detection system (HPV-DS); 
           [0018]      FIG. 3  is a simplified logical flow diagram of a learning engine; 
           [0019]      FIG. 4  is a simplified logical flow diagram of a pattern analyzer; and 
           [0020]      FIG. 5  is a simplified logical flow diagram of a patient rules engine. 
       
    
    
     DETAILED DESCRIPTION 
       [0021]    Referring now to  FIG. 1 , a simplified logical flow diagram of a patient passing through a healthcare facility. Every authorized user action illustrated in boxes or steps  12 - 20 , such as entering, altering, creating, etc., at the healthcare facility related to a patient&#39;s personal healthcare information (PHI) and/or a patient&#39;s electronic medical records (EMR) generates an audit log illustrated in boxes or steps  22 A- 22 E. These audit logs enable the healthcare&#39;s enforcement authority, e.g., Privacy and Compliance officers, to identify and track an authorized user&#39;s activities, such as who viewed, edits, or printed a patient&#39;s PHI or EMR. Authorized users of the system include healthcare employees, contractors, and any other individual allowed to access PHI and EMR. The actions illustrated in boxes or steps  12 - 20  occur throughout an authorized user&#39;s day-to-day work while caring for patients. For example, when a patient enters a hospital in step  10  to receive treatment, an audit log is generated in steps  22 A- 22 E when the patient is admitted and their data is entered in step  12 , when the patient is referred to a department in step  14 , when the patient&#39;s PHI is entered in a department in step  16 , when the patient receives tests in step  18 , when a doctor view the patient&#39;s tests in step  20 , etc. 
         [0022]      FIG. 2  shows an overview of the healthcare privacy violation detection system (HPV-DS). The audit logs of steps  22 A- 22 E are generated throughout the entire healthcare facility and may be generated on various different healthcare software systems in steps  24 A- 24 E in different departments, e.g., surgery, gynecology, hematology, pathology, and so on. 
         [0023]    The audit log collector illustrated in step  26  can receives audit logs generated by all healthcare authorized users from all healthcare systems in steps  24 A- 24 E. Certain implementations of this system as described herein can function while communicating over the internet in step  28  and with the use of a private cloud in step  30 , or in the form a single physical/virtual server which may host all of the functional components, or a combination of both to provide privacy monitoring and reporting software platform that works across diverse healthcare software systems in steps  24 A- 24 E. Once received by the audit log collector in step  26 , which has the flexibility of being implemented as a virtual web/cloud or physical collector, the data can be compressed and encrypted if it is desired to be sent through the internet in step  28  to the private cloud in step  30 . Alternatively, instead of steps  28  and  30 , the audit log data could go directly to a server that is located on the healthcare facility&#39;s premises, if a non-cloud implementation is chosen. This is a major technical advantage of this entire system—it can completely reside on a customer&#39;s premise, or it can reside in multiple parts that can be geographically separate and still function as a highly redundant system. The portability of this system from a highly distributed to centralized computing platform is a major advantage for flexibility of deployment in large or small setups. The audit log collector of step  26  is continuously gathering audit logs once the audit logs are generated. This allows auditing to occur in real time as opposed to a batch process 
         [0024]    Alerts can be generated through the patient rules engine of step  36  and the anomaly detection engine of step  38 . If it is determined that an alert is required in step  44 , the notification engine of step  46  sets off the alert. If no alert is required in step  44 , then no further action is taken in step  48 . Authorities may be alerted via phone, email, pager, short message service (sms), text messages, etc, about privacy breaches as they happen. These alerts may also be sent to any individual desired. This system also has the ability, due to its central data storing capability, to provide access to patients and for patients to run privacy reports on themselves. 
         [0025]    Once the private cloud of step  30  receives the audit log data, it is decrypted and uncompressed before it is accepted by the parser in step  32 . Each data source of steps  24 A- 24 E has its predefined configuration, stating the data type and the amount of data that is to be “normalized,” and the rest to be discarded as “noise” or waste. For example, if the audit log data sent to the parser in step  32  has fields A, B, C, D, E, F, and G, and if the parser configuration is set to only select fields B, C, D, and G, then only those fields will be “normalized” in a uniform data format. The remaining fields, A, E, and F, are discarded as unwanted data. In another implementation, a system that is partially residing on a customer&#39;s premises that collects in step  26  the audit logs, may also include a parser in step  32  on premises, and “normalize” the data before sending it over the internet in step  28 . 
         [0026]    After the data is parsed in step  32 , it is stored in step  34 , sent through a patient rules engine in step  36 , and sent to an anomaly detection engine in step  38 , which, for purposes of explaining, breaks down into two parts, a learning engine in step  40  and a pattern analyzer in step  42 . These analyses are concurrent. 
         [0027]    The stored data in step  34  may be used to create ad hoc reports by an administrator, e.g. Privacy and Compliance officers, on request. An example of such ad hoc reports can be a report requesting authorized user activity for a certain time period, a report showing an authorized user&#39;s views of a single patient&#39;s or multiple patients&#39; PHI or EMR. These reports can also be run across multiple systems (e.g.  24 A through  24 E) concurrently, whose audit logs are collected in step  26  and parsed in step  32  audit log data. 
         [0028]      FIG. 3  illustrates an example of the learning engine in step  40 . The learning engine of step  40  is a part of the anomaly detection engine in step  38 . After the audit logs are “normalized,” the data is stored in the anomaly detection engine in step  38  to maintain patterns and parameters for all possible unique authorized users who access systems at the healthcare facility known as a “baseline.” Authorized user&#39;s activity baselines are stored in the anomaly detection engine in step  38 . A baseline is considered the normal level of activity by a specific authorized user. The patterns to be considered for creating a baseline may consist of previously configured criteria such as last logon time, location used from, normal patients viewed, systems the authorized user normally accesses, typical times of day authorized user uses a system, time spend on a system, patient records typically viewed, department authorized user works in, etc. many more such parameters may be added to the pattern list to suit the reporting needs of the facility. When a new or unknown authorized user is encountered in step  50 , the activity patterns for that authorized user are used to create or add to the baseline for that authorized user in step  52 . Encountering an unknown authorized user also creates an alert in step  54  and flags the data in step  56 . Audit log data with activities of that new authorized user are used to build a new baseline for that authorized user in step  52 , based on a pre-designated time frame. For that time frame, the data is assumed, or is verified, to be normal patient record access and system usage behavior by that authorized user. After that time frame, the authorized user is considered known, and any access or behavior by that authorized user that is different from what was recorded during the designated time frame is identified and reported through an alert in step  54  and flagging the audit log in step  56 . In another embodiment, encountering an unknown authorized user in step  50  will create and/or add to their baseline in step  52 , create an alert in step  54  and flag in step  56 , but the authorized user will only cease to be unknown until the baseline is identified as normal by an administrator. Once identified as normal, alerts in step  54  and flags in step  56  are only generated if audit log data for that authorized user is different from the baseline for that authorized user. 
         [0029]    When an audit log is flagged, it is set aside as a ticket entry, informing an administrator that it is necessary to review that particular audit log activity. Whenever an alert is generated in step  54 , the audit log is flagged in step  56 . This does not have to be the case always; alerting in step  54  and flagging in step  56  can be customized by an administrator of the healthcare facility, such as creating alerts in step  54  only when a pattern exceeds a predetermined threshold in step  66 , and flagging in step  56  an audit log, creating a ticket entry for administrator review, only when a new authorized user is encountered in step  50 . 
         [0030]    Authorized user baseline data may also contain non-healthcare system information, such as Windows Active Directory or other Lightweight Directory Access Protocol stores that have identity stores that can store authorized user and domain based authentication information in an enterprise setting. Internet protocol address and Domain Name Service information of the host terminal and similar information is also received and added to the baseline analyzer to create an authorized user&#39;s profile. The work location, work shift schedule, personal or family addresses, family member names, work colleagues, and other related information of an authorized user from the Enterprise Resource Planning system, human resource system, and other similar information stores send this data to this system to create a baseline in step  52 . Any time there is a change in one of the baseline patterns for an authorized user, it is considered an outlier and administrators are alerted in step  54  and the audit log is flagged in step  56 . 
         [0031]    If the authorized user is known, the data will be sent directly to the pattern analyzer in step  42 . The pattern analyzer in step  42  maintains a baseline for each unique authorized user that accesses systems at a healthcare facility. 
         [0032]      FIG. 4  illustrates the pattern analyzer of step  42 . The normalized data is also compared to the baseline for the authorized user that generated the audit log in step  58 . Each parameter of the audit log data is checked against existing usage parameter patterns, the baseline, for that authorized user for a match in step  60 . Parameter matches are scored and these risk scores are added together in step  64 . The cumulative score of matching parameters is compared to a risk threshold in step  66 . If most parameters match in step  60 , the score will be low because there are few outliers. If the score does not exceed the risk threshold in step  66 , the record is added to the baseline for that authorized user in step  62 . This allows the baseline of each authorized user to be up-to-date on any changes in an authorized user&#39;s schedule. If all parameters match in step  60 , the risk score is zero. If fewer parameters match in step  60 , then risk level is considered high and a higher score is assigned. With a high score that is in excess of the risk threshold in step  66 , an alert will be sent to administrators in step  54  and the audit log will be flagged for further review in step  56 . 
         [0033]    In an alternative embodiment, each parameter can have a weighted risk score, so parameter outliers that may be a higher cause for concern exceed the threshold and are immediately reported in step  54 . 
         [0034]      FIG. 5  illustrates the patient rules engine of step  36 . The normalized data is also checked for against a set of patient rules to see if there are any matches in step  68 . Patient rules are made up of a list of patients, such as VIP&#39;s, privacy conscious, movie stars, football players, etc., so an alert in step  54  may be generated when the listed patient&#39;s PHI is accessed. This list of patient-specific rules may be updated by administrators. If the data matches a patient rule in step  68 , an alert is created in step  54  and the audit log is flagged in step  56 . If no match is found in patient rule match of step  68 , then no action is taken in step  58 . 
         [0035]    In an alternative embodiment, the patient rules engine of step  36  will only find a patient rule match in step  68  if that patient is in the healthcare facility. 
         [0036]    The processes, methods, or algorithms disclosed herein can be deliverable to/implemented by a processing device, controller, or computer, which can include any existing programmable electronic control unit or dedicated electronic control unit. Similarly, the processes, methods, or algorithms can be stored as data and instructions executable by a controller or computer in many forms including, but not limited to, information permanently stored on non-writable storage media such as ROM devices and information alterably stored on writeable storage media such as floppy disks, magnetic tapes, CDs, RAM devices, and other magnetic and optical media. The processes, methods, or algorithms can also be implemented in a software executable object. Alternatively, the processes, methods, or algorithms can be embodied in whole or in part using suitable hardware components, such as Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), state machines, controllers or other hardware components or devices, or a combination of hardware, software and firmware components. 
         [0037]    While the invention has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the invention is not to be limited to the disclosed embodiments but, on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims, which scope is to be accorded the broadest interpretation so as to encompass all such modifications and equivalent structures as is permitted under the law.