📊 Diagram: Health Insurance Portability and Accountability Act (HIPAA) Case-Study

🔗 Link to Original Paper/Article

View Full Main Source

📝 Short Description

This diagram illustrates the data flow between the components/functionalities of the HIPAA application from the study. The diagram is based on the code from the study, in which the nodes show different functionalities and labels show decorators that the functions had. This application contains only the functionality of viewing index records.The diagram also shows the added components for privacy policies and consents implemented in the app, which was one of the main focus of the paper.

🔤 Abbreviations

• None

📖 Extensive Description (if possible)

The left side of the diagram shows the user entering its credentials (email, username, and password) into the Flask App. From here on there are 2 possible flows of data, which depend on the user being already registered or not. In both flows the credentials flow to the Login Flask or Register Flask nodes. Afterwards in the login case the credentials flow to the Check Credentials node where they are checked and consequentially to the SQLite DB node. In the case of the registration flow the credentials flow to the After Register Hook and finally to the SQLite DB. From this node the user_consents and index_records flow to the Current User node (which represents the user currently using the app). From this point on there are some information flows. The first one send the user_consents data to the Policy node which forwards it to the View Consents Template where the user its able to see its current consent settings. In the second one user_consents flow to the Remove Consents node, which then forwards the actualize_consents to the Save To DB node. The third one is again the forwarding of the user_consents to the Add Consents node, which forwards the new_consents to the Save To DB node. Lastly there is the flow of index_records to the View Index Record node, which then forwards this to the View Index Template node so that the user can see the records. This last flow is the only functionality, outside of the consent policies, which is implemented in the source code of the paper.

🏷️ Label description

• 🗂️ Data Labels:

  • DataType:

    • ConsentSettings: List of consented actions/purposes of the user
    • IndexRecords: List of index records from a patient
    • NewConsentSettings: List of updated actions/purposes of the user after adding a new consent

  • Credentials:

    • Email: Email of the user
    • Password: Password of the user
    • Username: User name of the user

• 🏷️ Node Labels:

  • Decorator:

    • Secure: Decorator that defines that given node (or function in the code) as secure
    • UserRegistered: Decorator that defines that for the given node (or function in the code) the user has to be registered
    • LoginRequired: Decorator that defines that for the given node (or function in the code) the user has to be logged in

  • ConsentedPurposes

    • ViewRecords: The purpose of viewing the records is consented

⚠️ Constraints

• Sensitive data from the user such as ConsentSettings (old or new) and IndexRecords can not flow to an insecure node:

  1. secure: data DataType.ConsentSettings,DataType.NewConsentSettings,DataType.IndexRecords neverFlows vertex !Decorator.Secure

• Index records data neverflows to a node which does not have the purpose/settings of ViewRecords allowed:

  2. purposes: data DataType.IndexRecords neverFlows vertex !ConsentedPurposes.ViewRecords

🚨 Violations

• None