Healthcare Policy Compliance: A Blockchain Smart Contract-Based Approach

Abstract

This paper addresses the critical challenge of ensuring healthcare policy compliance in the context of Electronic Health Records (EHRs). Despite stringent regulations like HIPAA, significant gaps in policy compliance often remain undetected until a data breach occurs. To bridge this gap, we propose a novel blockchain-powered, smart contract-based access control model. This model is specifically designed to enforce patient-provider agreements (PPAs) and other relevant policies, thereby ensuring both policy compliance and provenance. Our approach integrates components of informed consent into PPAs, employing blockchain smart contracts to automate and secure policy enforcement. The authorization module utilizes these contracts to make informed access decisions, recording all actions in a transparent, immutable blockchain ledger. This system not only ensures that policies are rigorously applied but also maintains a verifiable record of all actions taken, thus facilitating an easy audit and proving compliance. We implement this model in a private Ethereum blockchain setup, focusing on maintaining the integrity and lineage of policies and ensuring that audit trails are accurately and securely recorded. The Proof of Compliance (PoC) consensus mechanism enables decentralized, independent auditor nodes to verify compliance status based on the audit trails recorded. Experimental evaluation demonstrates the effectiveness of the proposed model in a simulated healthcare environment. The results show that our approach not only strengthens policy compliance and provenance but also enhances the transparency and accountability of the entire process. In summary, this paper presents a comprehensive, blockchain-based solution to a longstanding problem in healthcare data management, offering a robust framework for ensuring policy compliance and provenance through smart contracts and blockchain technology.

I Introduction

Electronic health records (EHRs) have emerged as a cornerstone in modernizing healthcare, offering numerous benefits that enhance efficiency and quality of care. These systems facilitate immediate and remote access to patient data, a critical feature that streamlines the medical care decision-making process. By transitioning from paper-based systems, EHRs significantly reduce errors commonly associated with manual record-kee**, thereby enhancing patient safety and care quality [1, 2, 3]. One of the key advantages of EHRs is their ability to promote interoperability across different healthcare platforms. This interconnectedness allows for the seamless sharing of patient data among various healthcare providers, leading to improved continuity of care and a more cohesive healthcare experience. Additionally, the shift to EHRs results in notable cost savings by eliminating the expenses related to paper records and optimizing resources [2].

Furthermore, EHR systems play a vital role in strengthening healthcare services. They enhance clinical cooperation and increase the accuracy of diagnostics. The constant availability of up-to-date patient medical records is crucial for maximizing treatment productivity and ensuring timely and accurate medical interventions [4, 5, 6]. The trend of storing patient information electronically on local databases or cloud servers underscores the healthcare industry’s commitment to making patient care more efficient and precise [7]. EHRs represent a significant leap forward in healthcare technology. They streamline administrative processes, improve care coordination, and contribute to better clinical outcomes. As healthcare organizations continue to adopt and refine EHR systems, they pave the way for a more efficient, accurate, and patient-centered approach to healthcare service delivery.

The transition to EHRs has marked a significant advancement in healthcare technology, improving the efficiency and quality of patient care. However, this digital transformation also brings forth complex information security and privacy challenges, which are critical to address for maintaining patient trust and compliance with regulatory standards. Data security and privacy violations are increasingly seen across the healthcare sector. Many of these can be attributed to this industry’s widespread use of smartphones, internet-connected devices, sensors, wearable devices, mobile-based health applications, and other IT-dependent services. Cybersecurity risks, potential breaches, and the need for stringent access controls raise significant questions. Additionally, interoperability issues, human factors such as user authentication, and the imperative of legal compliance further compound the challenges associated with implementing and maintaining EHR systems [8, 9].

Laws, policies, and regulations are pivotal in addressing EHR challenges and safeguarding healthcare data security and patient privacy. In various global regions, diverse privacy standards, including the General Data Protection Regulation (GDPR) in Europe, the Health Insurance Portability and Accountability Act (HIPAA) in the United States (US), and My Health Record (MHR) in Australia, have been established to protect patient privacy and personal data [10]. The HIPAA policy standards and guidelines help mitigate the risks associated with EHR and promote trust between patients and healthcare providers.HIPAA requires healthcare organizations to implement technical, administrative, and physical safeguards to secure EHRs [11]. These safeguards include access controls, encryption, authentication measures, and regular security assessments. By enforcing these safeguards, HIPAA helps prevent unauthorized access, data breaches, and identity theft. Furthermore, HIPAA mandates the implementation of privacy policies and procedures to govern the use and disclosure of patient information. It grants patients certain rights, such as the right to access and amend their medical records, and requires healthcare providers to obtain patient consent for certain uses and disclosures of their information.

HIPAA also establishes non-compliance penalties, incentivizing healthcare organizations to prioritize data security and privacy. These penalties can range from fines to criminal charges, depending on the violation severity. The violation can also lead to reputational damage, eroding trust from clients and the public. Organizations may face exclusion from federal programs, financial strain due to legal costs, and increased scrutiny. The violation of HIPPA can also lead to provider confusion, increased documentation time, alert fatigue, and potential patient safety issues [12]. According to the Office of Civil Rights Data study, since October 2009, massive security breaches may have affected more than half of the population in the USA. At least 173 million medical records were breached due to the policy non-compliance. The study showed that the hackers recruited healthcare insiders with access to valuable data ‘using online ads and social media.

According to the Information Security Media Group, 75% of US healthcare organizations reported at least one security breach affecting less than 500 individuals, and 21% reported an incident affecting more than 500 individuals. The Healthcare Information and Management Systems Society found that 68 percent of surveyed healthcare organizations in the US experienced a significant security incident. These incidents were reported to be caused by insider threats (53.7%) and external threats (63.6% of healthcare organizations). It is important to note that these reported incidents may not capture all security breaches, as some incidents go undetected or are underreported. Security breaches in healthcare can be costly, with cases of breaches in healthcare data costing hospitals between US$250000 to US$2.5M in settlement payments [13].

The landscape of health insurance, designed to safeguard individuals and families against the financial burdens of medical expenses, is now facing a growing challenge from those seeking to exploit vulnerabilities for personal gain due to non-compliance with health care policy. In 2022, 431 individuals were convicted of healthcare fraud, constituting 8.4 percent of all offenses related to theft, property destruction, and fraud. This marks a 1.4 percent rise in healthcare fraud offenders compared to the fiscal year 2018 [14]. The National Health Care Anti-Fraud Association (NHCAA) estimates that the monetary damages resulting from healthcare fraud reach tens of billions of dollars annually. A statistical analysis suggests it accounts for about 3 percent of healthcare expenditures. However, certain government and law enforcement agencies posit the losses to be as high as 10 percent of the annual health outlay, potentially exceeding 300 billion dollars [15]. Health insurance fraud has financial repercussions, leading to increased costs for insurers and potentially higher premiums for policyholders. It can compromise the quality of care by encouraging unnecessary medical procedures and overusing services. Providers involved in fraudulent activities may face reputational damage and legal consequences. Overall, health insurance fraud erodes public trust in the healthcare system and diverts resources from critical healthcare initiatives.

Figure 1: Number of Health care Insurance Fraud [14]

TABLE I: OCR HHS - Compliance Complain

Year	Complains	Compliance Reviews	Technical Assistance	Total Cases
2018	25089	438	7243	32770
2019	29853	338	9060	39251
2020	26530	566	5193	32289
2021	26420	573	4244	31237

Table I shows the number of compliance complaints received by the U.S. Department of Health and Human Services (HHS) Office for Civil Rights (OCR). The major reasons for the complaints are (i) impermissible uses and disclosures of PHI; (ii) lack of safeguards of PHI; (iii) lack of patient access to their PHI; (iv) lack of administrative safeguards of electronic PHI; and (v) use or disclosure of more than the minimum necessary PHI.

While advancements in security and privacy technology are essential for enhanced protection of patient data from such incidents, substantial evidence indicates that improper adoption, implementation, and enforcement of policies contribute significantly to unauthorized access—without a legitimate ”need to know”—to Electronic Health Record (EHR) data [16]. Whether intentional or unintentional, users are often granted access privileges they should not possess. Policies are frequently not adhered to accurately, and there are delays in checking or implementing access control rules. Instances have been observed where identical roles and privileges are assigned universally to all employees. Additionally, individual patient-level policies are often not rigorously enforced. Auditing and monitoring gaps are also prevalent, typically occurring only in response to serious complaints or legal mandates.

Sarkar et al. [17] present an alternative perspective on security and privacy breaches within the healthcare industry. They explore the existence of distinct professional subcultures within healthcare organizations. Through a qualitative study, the authors identify factors that inadvertently lead these subculture groups to violate information security policies. For instance, in cases where a doctor, positioned at the apex of the subculture hierarchy, seeks access to information beyond their authorized scope, lower-ranking employees within the subculture may not intervene to prevent it.

Figure 2: Policy Enforcement, Compliance, and Provenance .

While ensuring the enforcement of system security policies is crucial, it is equally vital to establish provenance to validate adherence to these policies. Figure 2 illustrates the interplay among enforcement, compliance, and provenance. Effective policy enforcement safeguards healthcare data against unauthorized access and misuse. When policies are adequately enforced, achieving policy compliance becomes possible, as compliance necessitates aligning all actions with the relevant policies. However, this compliance alone lacks quantifiable measurement or validation. To assess policy compliance accurately, maintaining the integrity of policy enforcement activities is indispensable. Enforcement integrity ensures that events are accurately recorded as they unfold. An independent auditor conducts a policy audit to verify the compliance status of the policy. Provenance, in turn, offers a chronological record of policy enforcement activities as they transpire.

Another important factor contributing to policy violations is insufficient enforcement mechanisms due to different sets of policy bodies. Healthcare is often subject to a complex web of regulations and guidelines established by different organizations at the national and international levels. This multiplicity of policy bodies can create challenges and potential conflicts for healthcare providers and professionals [18, 19]. Analysis of data from the United States Department of Health and Human Services, covering data breaches recorded from January 2015 to December 2020, revealed that a significant portion of the compromised data resulted from insufficient communication and training for healthcare professionals. Inadequate communication and training contribute to policy violations in healthcare by leaving staff unaware of existing policies or changes, leading to unintentional non-compliance. Insufficient training exacerbates challenges in understanding complex policies, increasing the risk of improper implementation. Additionally, communication gaps between departments, limited feedback mechanisms, and cultural barriers further hinder effective policy adherence among health professionals [20].

This paper proposes a smart contract-based policy enforcement architecture to accurately enforce deployed authorization, obligation/regulatory, operational policies, and patient-provider agreements (PPAs) during data access decision-making. The approach uses blockchain smart contracts to implement access control features and data security guidelines. Moreover, we propose a blockchain-based integrity storage system for EHRs, policies, access control model features, audit trails of deployed policies, and the integrity of subjects’, objects’, and environments’ attributes. Since blockchain keeps immutable records, it can keep track of transactions in real-time and identify any unauthorized changes. In addition, the consensus process in a blockchain network guarantees that smart contracts work as intended without user interference.

The proposed architecture enforces applicable policies and PPAs by kee** audit trails linked to enforced policies and enforcing access based on smart contracts. Since the blockchain network stores all user policies and event logs, it provides provenance services. For any transaction, smart contracts will automatically notify the appropriate users. Also, once smart contracts are fully deployed and functional, the conditions and mechanisms written into the code can’t be changed.

This paper is an extension of the earlier works [21, 22]. Our major contributions are as follows:

• Critical analysis of HIPAA security and privacy and organizational policies to integrate with the proposed framework to ensure policy compliance through proper policy enforcement, preserving policy lineage and enforcement activities as audit trails, and timely compliance checking through auditing the audit trails.

• Private or enterprise Ethereum blockchain-based provenance mechanism for storing enforcement activities as audit trails. It guarantees that any audit trail modification can be detected, which is one of the crucial requirements for ensuring and certifying policy compliance through independent audits.

• Proof of Compliance (PoC) consensus mechanism to verify the activities’ compliance status for the proposed private/enterprise blockchain-based audit trails. A set of distributed, decentralized, and independent auditor nodes performs the compliance checking for the given audit trails. They determine compliance and non-compliance status for every access that happens in the system.

• Implementation of the graphical user interfaces (GUI) for the proposed framework with patient-provider agreement (PPA) and informed consent. Through informed consent enforcement, patient privacy policies are integrated and enforced to ensure healthcare policy compliance.

The remainder of the paper is organized as follows: Section II contains some related works. Healthcare policy requirements are discussed in Section III. Section IV discusses the proposed approach overview or summary for policy enforcement, provenance, and compliance. In Section V, the necessary figures, components, and interactions using blockchain and smart contracts are shown for how informed consent can be added to the patient-provider agreement (PPA) and the contact-based enforcement mechanism. A private or enterprise blockchain-based policy provenance mechanism is discussed in Section VI for storing policy enforcement activities as audit trails. The integrity verification process for audit trails is also given. Section VII discusses the requirements and application of a blockchain consensus mechanism called Proof of Compliance (PoC) for the proposed framework to verify the compliance status as compliance and non-compliance for health workers. A sequence diagram for policy enforcement, provenance, and compliance mechanisms is given in Section VIII. Section IX contains the implementation conceptual designs. The paper is concluded with a brief discussion in Section X. Finally, Section XI discusses some future research directions to complete and extend the proposed compliance frameworks.

II Related Works

In the burgeoning landscape of electronic health records (EHR) management, various researchers have proposed innovative blockchain-based frameworks to tackle challenges such as secure storage, scalability, and interoperability.

Shahnaz et al [23] proposed a blockchain-based framework for EHR and provided secure storage of electronic records with granular access rules for users. It also addresses the scalability problem of blockchain by utilizing off-chain storage. This paper exclusively concentrates on ensuring secure information storage and does not delve into implementing information consent or other privacy standards mandated by the government.

Mayer et al [24] analyzed that Blockchain technology can provide secure and tamper-resistant storage of medical records, ensuring data integrity and authenticity, and also suggest that the blockchain directory model and the chain structure of blockchain can support the continuous growth of medical records. The blockchain should implement OpenEHR, HL7 FHIR, HIPAA, GDPR, IHE, ISO, SNOMED, DICOM, HIE, and PII standards to facilitate interoperability and ensure the uniformity of healthcare information for all stakeholders.

Wang et al [25] developed a combined attribute-based/identity-based encryption and signature blockchain mechanism to minimize the utilization of different cryptographic systems for different security requirements in the EHR. This system ensures the integrity and traceability of medical data. This work only focuses on the encryption of the signatures and identity of the patient and doesn’t focus on safeguarding other patient information like health history, insurance company details, etc.

Azaria et al [26] designed a blockchain prototype to handle the permission and data access management system called MedRec [4]. MedRec provides patients with a comprehensive and unalterable record of their medical information, facilitating easy retrieval from their healthcare providers and treatment locations. The framework supports interoperability, improves the data quality and the quantity of the medical records, and reduces the fragmentation and latency while accessing the medical records. Our system also manages permission and data access using blockchain, similar to the MedRec architecture. It ensures transparency in patient record access by seeking patient consent when sharing the records with team members.

Amin et al[22] introduced a blockchain-based contract-oriented access control model aimed at enforcing agreements between patients and providers (PPAs) and other healthcare policies to address issues in policy compliance that may result in unauthorized access [5]. Their proposed architecture utilizes blockchain to store policies, access control measures, audit trails, and the integrity of Electronic Health Records (EHRs) attributes. Integrating patient-provider agreements with the access control model enhances transparency and accountability. Our model extends this framework by incorporating policy compliance and an informed consent mechanism.

Albalwy et al.[27] introduced ConsentChain, a blockchain-based dynamic consent management architecture on the Ethereum platform, facilitating clinical genomic data exchange. This system utilizes smart contracts to model patient actions, data creators, and data requesters for granting or revoking data-sharing permissions. However, the focus of the work is primarily on genomic data sharing with specific stakeholders, such as clinicians and researchers, leaving out considerations for the distinct consent management requirements in clinical treatment scenarios. Recognizing the distinct requirements in clinical treatment processes, our proposal suggests a consent management framework to address complex permission assignments for diverse roles like treatment team members, insurance agents, external doctors, and pharmacists.

Tith et al. [28] propose an electronic consent management model using Hyperledger Fabric blockchain and purpose-based access control. Patient records, consents, and metadata are stored on the blockchain and shared among participating organizations, with a Chaincode managing the business logic for consent. While the initial model is designed for data sharing and donation, the authors highlight the limitations of the Hyperledger network in terms of restricted participation and limited public trust. To address this, we advocate for the adoption of the private Ethereum blockchain for its broader participant inclusion, enhanced transparency through a public consensus mechanism, and widespread use of smart contracts in various projects.

Haque et al. [29] introduced an architecture for a COVID vaccination passport (VacciFi) that adheres to GDPR by storing vaccination data in off-chain storage. They utilize a permissioned blockchain to enhance the ability of participating entities to monitor activities. This study offers valuable insights into the design requirements of our proposed system.

Piao et al. [30] suggested a data-sharing scheme for GDPR compliance based on blockchain. The goal is to encourage adherence to regulations and offer a platform for user-service provider interaction to ensure secure data sharing. This study primarily emphasizes user authentication and private data sharing, with less emphasis on provenance.

The existing study suggested the potential effectiveness of blockchain in storing compliance-related information for provenance; most of them primarily focus on regulatory policy compliance and do not address individual policies within patient consent and organizational access control policies. We are deploying the patient policy smart contract in the blockchain framework to uphold the integrity of the patient’s records.

III Healthcare Policy Compliance Requirements

Healthcare policies vary significantly across countries, influenced by political systems, economic conditions, cultural values, and historical developments. In India, the regulatory framework includes the Personal Data Protection Bill and the Information Technology Act. European countries adhere to the General Data Protection Regulation; Australia utilizes My Health Record (MHR); the USA follows HIPAA; and Canada abides by the Personal Information Protection and Electronic Documents Act (PIPEDA). The US government also follows certain federal laws in addition to international laws to maintain the integrity and confidentiality of the data. The Emergency Medical Treatment and Labor Act is a federal law enacted in 1986 that requires hospitals to provide emergency medical treatment to individuals regardless of their ability to pay or their insurance status. It prohibits patient dum**, which is the refusal of care or transfer of patients with unstable medical conditions.

Children’s Health Insurance Program (CHIP) is a joint federal and state program that provides health coverage to children in low-income families who do not qualify for Medicaid but cannot afford private insurance. In 2016, the 21st Century Cures Act was passed as a federal law aimed at expediting advancements in health research. It addresses both privacy concerns, and the law also prohibits the practice of information blocking, wherein organizations engage in activities hindering or preventing access to electronic health information. Additionally, the 21st Century Cures Act introduces provisions enabling the compassionate sharing of mental health and substance abuse treatment details with family members and caregivers. Violations of this prohibition can result in fines of up to 1 million dollars per instance.

Apart from international and federal policies, health care must even abide by state laws to address the privacy and security of medical records, like California Confidentiality of Medical Information Act (CMIA), Colorado Medical Records Privacy Act (CMRPA), Arizona Health Information Exchange (HIE), etc. The local and city governments also play a supportive role in healthcare through public health department rules, community health initiatives, etc., which overarch the regulatory framework established by federal and state laws. The HIPAA policy also allows the organization to set up its policy and rules to ensure data security. The Facility Access Control and Workstation Security rules of the physical safeguard security policy are established and managed by organizational laws. We are implementing HIPAA and HITECH policies within our framework to ensure data protection.

III-A HIPAA Overview

HIPAA, or the Health Insurance Portability and Accountability Act, is a U.S. federal law enacted in 1996 that establishes standards and safeguards for the protection of sensitive patient health information, known as Protected Health Information (PHI)[31]. Ensuring adherence to the policies outlined by the government in HIPAA is a crucial aspect when constructing any information security framework. This is particularly important because patients value the confidentiality of their healthcare records. Patients who do not trust the healthcare framework may withhold essential information from healthcare providers. The HIPAA policy is divided into four rules as shown in Fig. 3: (i) privacy rule, (ii) security rule, (iii) omnibus rule, and (iv) breach notification rule.

The HIPAA Privacy Rule outlines the standards for protecting individuals’ medical records and other personal health information, known as protected health information (PHI), held by covered entities and their business associates. The Privacy Rule sets forth rules and procedures that covered entities must follow to ensure the confidentiality and privacy of PHI. It establishes the rights of individuals over their health information, including the right to access their records, request corrections, and control the disclosure of their health information.

The HIPAA Security Rule is a set of regulations established under the Health Insurance Portability and Accountability Act (HIPAA) to protect electronic protected health information (ePHI). It outlines standards and safeguards for covered entities, such as healthcare providers and health plans, that must be followed to secure ePHI. The rule encompasses administrative, physical, and technical safeguards, requiring entities to implement policies, procedures, and technologies to safeguard electronic health information’s confidentiality, integrity, and availability.

The HIPAA Omnibus Rule introduced significant modifications to strengthen the HIPAA policy. It expanded liability by making business associates directly accountable for compliance with certain HIPAA provisions, particularly the Security Rule. The rule heightened breach notification requirements, specifying what constitutes a reportable breach and establishing notification procedures. Additionally, it incorporated amendments related to the Genetic Information Nondiscrimination Act (GINA), further safeguarding genetic information from misuse in health plans.

The HIPAA Breach Notification Rule mandates that covered entities and their business associates notify affected individuals, the U.S. Department of Health and Human Services (HHS), and, in certain cases, the media in case of a breach of protected health information (PHI). A breach is the unauthorized acquisition, access, use, or disclosure of PHI that compromises its security or privacy. Covered entities must conduct a risk assessment to determine the probability of compromise, and if the risk is low, breach notification requirements may be waived. Non-compliance with breach notification rules can result in financial penalties.

The US government also launched the HITECH Act (Health Information Technology for Economic and Clinical Health Act) which introduced several policies and provisions aimed at promoting the adoption and meaningful use of health information technology, particularly electronic health records (EHRs). HITECH made significant changes to HIPAA by amending its rules and strengthening its enforcement mechanisms. It introduced new requirements and increased penalties for non-compliance. HITECH expanded the liability of business associates by holding them directly accountable for compliance with certain HIPAA provisions. Business associates are now subject to many of the same rules and penalties as covered entities. HITECH also significantly increased the penalties for HIPAA violations, providing a tiered structure based on the level of negligence. The maximum annual penalty for a single violation increased substantially. HITECH also brought forth additional mandates regarding data breach notifications. According to the HITECH Breach Notification Rule, in the event of a data breach, HIPAA-covered entities are obligated to inform the individuals impacted by the breach. Furthermore, notification must be provided to both the Secretary of Health and Human Services and the media if the breach affects more than 500 individuals.

Figure 3: Types of HIPAA Rules.

III-B HIPAA Regulated Organizations

The regulations outlined in the HIPAA Rules pertain to both covered entities and business associates. Entities, organizations, and agencies falling within the scope of a covered entity as defined by HIPAA are obligated to adhere to the Rules. These regulations mandate safeguarding the privacy and security of health information while also granting individuals specific rights regarding their health data. In cases where a covered entity enlists the assistance of a business associate for healthcare-related activities, a formal contract or arrangement must be in place. Fig. 4 shows the HIPAA-regulated organizations.

for tree= grow=east, growth parent anchor=west, parent anchor=east, child anchor=west, edge path=[edge,-¿, ¿=latex] (!u.parent anchor) – +(10pt,0pt) —- (.child anchor) edge label; [HIPAA Regulated Organizations, basic, l sep=10mm, [Business Associates, xnode, l sep=10mm, [Lawyers  , tnode] [Financial Organizations  , tnode] [Cloud Service Providers  , tnode] [Software Providers  , tnode]] [Covered Entity, xnode, l sep=10mm, [Health Clearing House  , tnode] [Health Plans  , tnode] [Healthcare Providers  , tnode] ]]

Figure 4: HIPAA Regulated Organizations.

The HIPAA new regulation typically mandates that covered entities and their business associates establish contracts, termed a business associate agreement (BAA) to ensure proper protection of protected health information. These contracts also serve to define and restrict, as necessary, the acceptable uses and disclosures of protected health information by the business associate. According to the updated regulations, business associates are now directly accountable under HIPAA, and they face enforcement actions in the same manner as covered entities.

A formal agreement between a covered entity and a business associate must include an outline of the allowed and mandatory uses and disclosures of protected health information by the business associate, and stipulate that the business associate will not utilize or disclose the information beyond what is permitted by the contract or as mandated by law, and mandate the implementation of adequate safeguards by the business associate to prevent unauthorized use or disclosure, including adherence to the requirements of the HIPAA Security Rule concerning electronic protected health information, etc.

III-C HIPAA Rules Incorporation In Framework

The proposed framework incorporates the privacy and security rules of the HIPAA/HITECH policy to protect patient information, adheres to the rules of the regulated organization, and doesn’t implement the omnibus and breach notification rules as shown in Fig. 3. The framework adheres to the following privacy and security guidelines:

• The patient grants consent for the treatment team members to access their information. The patient also controls the extent of information shared with specific team members and the type of access, such as read, write, and update permissions. As a result, the privacy and HIPAA policies related to authorization and disclosure accounting comply.

• The framework enables patients to grant access rights to their emergency contacts, allowing them to access information. It also allows restricted access to specific information, ensuring compliance with the confidential communications policy.

• Due to frequent updates in HIPAA policies, it is crucial for those managing patient information to stay informed about these changes. The healthcare prototype manages workforce training and security following HIPAA policies by implementing an expiration date for HIPAA training. Authorities cannot access patient health records once their HIPAA training expires, and access is only reinstated after they undergo the required training renewal.

• Password authentication and information consent mechanisms are employed within the framework to enforce HIPAA policies related to access and audit control. Access to information is restricted to authorized entities, and the system generates regular audit logs, notifying relevant authorities.

• The workstation security physical safeguard security policy is enforced as the framework is a licensed application and will be installed on secured workstations. Restricting the application license to a select number of fully authenticated systems installed on workstations helps minimize the risk of data breaches.

The developed framework offers the benefit of enhancing transparency for patients by informing them about who is accessing their information. This instills confidence in patients, assuring them that their data is secure and aligns with most privacy and security policies outlined in HIPAA.

IV Proposed Approach Overview

To ensure healthcare policy compliance, it is essential to enforce the right set of policies through the right enforcement mechanism. It is also equally important to ensure provenance regarding applicable policy lineage and policy enforcement activities or audit trails. Finally, independent auditors must verify the audit trails to determine compliance and non-compliance status. If the right set of policies is enforced timely and all provenance is preserved, then the organizations or systems comply with the appropriate policies and best practices. The relationship between policy enforcement, provenance, and compliance is depicted in Fig. 2.

The main idea is to integrate components of informed consent into the patient-provider agreement. Then create and deploy smart contracts for informed consent components in the blockchain network. The authorization module calls the corresponding smart contract for an access request to enforce informed consent. The request specifies which subject wants to perform which operation on what objects under what constraints or conditions. Once the smart contract is called and the authorization module decides, the corresponding event information is recorded as logs in the blockchain network.

To accurately evaluate compliance, we must keep a comprehensive record of policy history and the exact execution of enforcement actions. This history includes all the policies used by the authorization system to make decisions. Ensuring the accuracy of recorded events is vital, as these reflect actual enforcement actions. The records provide a clear sequence of enforcement steps, safeguarding against unauthorized modifications of audit trails or inappropriate access to healthcare data. A private blockchain-based provenance system is proposed where all audit trails are stored. Section VI includes the detailed mechanism for maintaining provenance.

To ensure that systems adhere to set policies, a consensus mechanism called Proof of Compliance (PoC) is proposed. PoC involves a network of independent, decentralized, and independent auditor nodes. These nodes are responsible for auditing and verifying whether the system’s operations and access permissions comply with the required policies from available provenances. All these enforcement checks are recorded in an ’audit blockchain’, providing a transparent and reliable history of compliance. By using the Proof of Compliance mechanism, organizations can more effectively tackle and reduce compliance-related challenges. Section VII discusses all the required components for policy compliance activities.

The auto-triggering feature of smart contracts ensures that relevant event or activity data is captured and recorded reliably, without omitting any essential details. This data is then stored securely on the blockchain network, a platform known for its decentralized, immutable, and tamper-proof nature. Such a robust system guarantees that the original agreements made between patients and providers are upheld. It also ensures the integrity of event logs, maintaining them exactly as they were created and recorded, free from any unauthorized alterations

V Policy Enforcement

Policy enforcement refers to the implementation of rules, procedures, and safeguards to ensure compliance with the regulations and requirements outlined in HIPAA. This includes enforcing policies related to the security and privacy of protected health information (PHI). Enforcement mechanisms are essential for holding covered entities, business associates, and other entities accountable for safeguarding PHI and complying with the HIPAA rules.

V-A Patient-Provider Agreement (PPA)

The patient-provider agreement aims to determine who is responsible for what in treatment. The goal is to improve outcomes, lower risks, and educate patients better. A multi-center study [32] evaluated the utility of the PPA, how readily patients understood it, its ability to educate patients in an unbiased way about treatment, and the feasibility of incorporating a PPA in clinical practice. Both patients and doctors believe this PPA helped them decide on a course of treatment and was fair in laying out the treatment’s risks and benefits. Most patients reported the PPA to be ”somewhat helpful” or ”very helpful” in deciding on a course of treatment and ”easy to understand.” A PPA, also known as a contract, differs from organization to organization. Healthcare organizations adjust what they need from patients and what they expect from them to match those needs, treatments, and responsibilities. This is done based on the nature and needs of treatment and services. Also, the components and representation of the PPA depend on the hospital or clinic. Examples include general hospitals, emergency rooms, urgent care or walk-in clinics, dental care, cancer treatment, physiotherapy, etc.

The patient-provider agreement is depicted in Figure 5 with the necessary components. The Patient-Provider Agreement formally is composed of four tuples:

$$PPA=(PC,PrC,ROC,ICC)$$

satisfying the following requirements:

• $PC$ is a finite set of patient components containing the patient’s personal information, contact information, mailing information, pharmacy information, billing and insurance information, emergency contact, and others. The patient is responsible for providing and maintaining valid information for these components.

• $PrC$ is a finite set of provider components, including the treatment team, anonymous data sharing for research, prescription, and others. Treatment team members for a patient include doctors, nurses, support staff, lab technicians, and billing officers. During the treatment period for a patient, everything from treatment to insurance coverage and billing is considered.

• $ROC$ is a finite set of regulatory and other components. It has applicable security and privacy policies to comply with the local government, regulatory agencies (HIPAA, GDPR), federal government, and foreign government requirements if necessary.

• $ICC$ is a finite set of informed consent components. It indicates that the patient has given permission to access medical data.

Algorithm 1 shows the step-by-step instructions for creating a PPA with $PC$, $PrC$, $ROC$, and $ICC$. A patient-provider agreement is formed when a patient visits a hospital. The terms and conditions of the contract make it invalid after a certain period. There may be several contracts for a single patient. Several patient-provider agreements must be created and properly documented to deliver healthcare services. Managing many contracts involves various things, such as contract creation, development, testing, updating, etc. If the requests contain contracts, the authorization module must consider those with other required policies when making access decisions. From Figure 5, it is seen that the proposed model stores the integrity of a PPA on the blockchain network to ensure the detection of any modification, intentionally or unintentionally.

Figure 5: Patient Provider Agreement (PPA) and Informed Consent Management Framework [21].

Input : (i) $PC$, (ii) $PrC$, (iii) $ROC$, (iv) $ICC$, (v) $\mathbb{R}_{PPA}$, (vi) $\mathbb{BN}_{SC}$

1   /* $\mathbb{R}_{PPA}$: secured PPA repository, $BN_{SC}$: blockchain network smart contract */

Result : A formal $PPA$

2 Input Parameters Initialization $PPA_{i}\leftarrow\{PC_{i},PrC_{i},ROC_{i},ICC_{i}\}$ for patient identity $i$  (i) $PC\leftarrow\{\wp_{1},\wp_{2},\wp_{3},\wp_{4},\wp_{5},........\wp_{M}\}$  (ii) $PrC\leftarrow\{\delta_{1},\delta_{2},\delta_{3},\delta_{4},\delta_{5},........\delta_{N}\}$  (iii) $ROC\leftarrow\{\Re_{1},\Re_{2},\Re_{3},\Re_{4},\Re_{5},........\Re_{P}\}$  (iv) $ICC\leftarrow\{\ell_{1},\ell_{2},\ell_{3},\ell_{4},\ell_{5},........\ell_{R}\}$ PPA Components Integrity Calculation   /* $\mathbb{H}(\partial)$ calculates hash of $\partial$ */

3  (a) $\mathbb{H}_{PC}\leftarrow\{\wp_{1},\wp_{2},\wp_{3},\wp_{4},\wp_{5},........\wp_{M}\}$  (b) $\mathbb{H}_{PrC}\leftarrow\{\delta_{1},\delta_{2},\delta_{3},\delta_{4},\delta_{5},........\delta_{N}\}$  (c) $\mathbb{H}_{ROC}\leftarrow\{\Re_{1},\Re_{2},\Re_{3},\Re_{4},\Re_{5},........\Re_{P}\}$ (d) $\mathbb{H}_{ICC}\leftarrow\{\ell_{1},\ell_{2},\ell_{3},\ell_{4},\ell_{5},........\ell_{R}\}$  (e) $\mathbb{H}_{PPA_{i}}\leftarrow\mathbb{H}(\mathbb{H}_{PC},\mathbb{H}_{PrC},\mathbb{H}_{ROC},\mathbb{H}_{ICC})$ PPA Finalization if $PPA_{i}$ is complete then

4         /* complete: presence of $PC$, $PrC$, $ROC$, $ICC$ */

5       if $(\mathbb{R}_{PPA}+PPA_{i})$ contains no conflicts then

6             (i) do $\mathbb{R}_{PPA}\leftarrow(\mathbb{R}_{PPA}+PPA_{i})$ (ii) add $\mathbb{ID}_{PPA_{i}}$ to patient profile, $\mathbb{P}_{i}$ (iii) call $\mathbb{BN}_{SC}(\mathbb{ID}_{PPA_{i}},\mathbb{H}_{PPA_{i}})$   /* later PPA integrity verification */

7             Return: Success ($PPA_{i}$ added to $\mathbb{R}_{PPA}$)

8      else

9             Error: $(\mathbb{R}_{PPA}+PPA_{i})$ contains conflicts   /* $PPA_{i}$ revision required to add to $\mathbb{R}_{PPA}$ */

10            

11       end if

12      

13else

14       Error: $PPA_{i}$ cannot be created (incomplete PPA)

15 end if

Algorithm 1 Patient-Provider Agreement (PPA)

V-A1 Informed Consent Components

Before giving consent, patients need to know everything about the particular consent. Figure 6 shows the informed consent conceptual framework structure. The Informed Consent formally is composed of four tuples:

$$IC=(U,O,OP,CON)$$

satisfying the following requirements:

• $U$ is a finite set of authorized users denoted as $\{u_{1},u_{2},u_{3},.....\}$. The user can perform certain operations on healthcare resources when certain conditions are satisfied.

• $O$ is a finite set of protected objects otherwise known as protected healthcare resources. A finite set of protected objects $(O)$ denoted as $\{o_{1},o_{2},o_{3},.....\}$.

• $OP$ is a finite set of operations denoted by $\{op_{1},op_{2},op_{3},...\}$. Operations represent the system actions that authorized users can perform on the objects. Examples of operations are read, write, and update.

• $CON$ is a finite set of conditions. It indicates the conditions that must be satisfied by the user to perform operations on the protected objects. A finite set of conditions, $CON$, can be denoted as $\{con_{1},con_{2},con_{3},...\}$.

There are many users in the healthcare system. Each user plays a different role and responsibility in performing their job. Treatment team members for a patient include doctors, nurses, support staff, lab technicians, billing officers, the patient’s emergency contact person, and other hospital employees assigned by the authority. Some outsider members are insurance agents, pharmacists or pharmacy technicians, doctors or lab technicians from another hospital. As the treatment period for a patient, everything from treatment to insurance coverage and billing is considered. Informed consent users can be anyone from five groups of people: (i) treatment team member, (ii) emergency contract, (iii) external users, (iv) insurance company agent, and (v) pharmacy. External users are from different hospitals when a patient is transferred for better treatment if the situation demands it. Usually, external users have temporary access to admitted patients’ health records.

Figure 6: Informed Consent Components [21].

The term object refers to an electronic version of a patient’s medical history kept on file by the healthcare provider over time. It may include all the administrative and clinical information pertinent to the patient’s care under a specific provider, such as demographics, progress notes, issues, medications, vital signs, previous medical history, immunizations, laboratory information, and radiology reports. These objects must be protected from unauthorized users. The main purpose of informed consent permitting by patients to users to perform certain operations.

Those who are qualified to perform necessary operations in the healthcare sector carry out several operations. Some common operations are view/read, add/write, update/modify, delete, etc. In the view operation, users can only view or read healthcare records or resources if the request is valid and complies with all applicable policies. The state of the data is not changed in this operation, ensuring data integrity. However, it can compromise confidentiality and privacy if the access requested is granted without appropriate credentials. On the other hand, the write operation changes the state of the records or healthcare data. If proper policy enforcement is not ensured, it breaks the integrity of the data.

There might be various constraints or conditions under which certain consent can be enforced, rejected, revoked, and others. The conditions can be but are not limited to:

• Time Constraints: In time constraints, any user can access a patient’s healthcare data within a certain time. For example, the time condition for consent is regular office hours: 8 am-5 pm. In this case, the request is rejected if any subject wants to access the patient’s record beyond this time. The attempt is recorded as an audit trail event.

• Date Constraints: The date constraints limit the calendar date. No access request is granted beyond the intended date.

• Day Constraints: Day conditions can include work days (Monday-Friday), weekends (Saturday–Sunday), holidays, etc. Based on the day, the subject can access data. Suppose a regular doctor has a duty on workdays. On weekends, no access is given to that doctor.

• Location-based Constraints: The location-based condition allows users to access information from a certain location, like a hospital building, inside an emergency room for treating emergency patients, and others.

• IP-based Constraints: IP-based conditions limit healthcare users from accessing resources from certain IPs. Device IPs must be from the known list; otherwise, no access is granted.

• Access Frequency Dependent: A user can operate for a certain number in access-frequency-dependent conditions. Suppose an external doctor is given five times view permission. Once the doctor reads the patient’s specified records five times, the given consent is expired, and access is denied. There is no access without getting new consent.

The above mentions list is not fixed for the conditions, but we consider them for this study. There might be other conditions depending on the nature of the treatment, patient characteristics, provider business policy, nature, etc. With sophisticated technology, malicious attackers can spoof the conditions to fool the system into accessing healthcare data and other compromised credentials. Proper layered defense mechanisms must be deployed to ensure that conditions’ credentials are accurate, not fabricated or manipulated.

V-A2 Informed Consent Smart Contract Generation

Once a patient-provider agreement, or PPA, is created and stored in the repository, all informed consent components are deployed as smart contracts. The patient owns all the deployed contracts. The authorization module needs to access these smart contracts to make decisions with other components such as subject attributes, object attributes, operations attributes, environmental attributes, organizational policies, regulatory and other policies, and others required. Algorithm 2 shows the steps to develop and deploy smart contracts for informed consent components. The smart contract deployment unit, SCDU, collects all consent components from PPA and checks integrity to confirm that collected consents are not modified deliberately or inadvertently. In step 3 in Figure 5, PPA integrity as the hash from Algorithm 1 ($Hash_{PPA_{i}}$) is stored in the blockchain network along with PPA id.

To verify PPA integrity, SCDU calls the corresponding smart contract function to retrieve the PPA hash value stored in the network. Any modification of consent components voids consent. If there is no modification, then SCDU creates and deploys smart contract(s) to the blockchain network. Once the contracts are deployed, the contract addresses are added to the patient’s profile and hospital systems. The contract address is an identifier for a smart contract in the blockchain network.

Input : Informed Consent Component $ICC$.

Output : Smart contract contains informed consents elements $ICC$ from patient-provider agreement $PPA$.

1 Initialization Informed Consent $IC_{i}:=\{Sub,Op,Obj,Cond\}$ where $Sub,Op,Obj,Cond$ represent one or more individual attribute(s) and $i$ represents patient identity;Subject Attributes $Sub:=\{SubAttr_{1},SubAttr_{2},........SubAttr_{M}\}$ Operation Attributes $Op:=\{OpAttr_{1},OpAttr_{2},........OpAttr_{N}\}$ Object Attributes $Obj:=\{ObjAttr_{1},ObjAttr_{2},........ObjAttr_{P}\}$ Conditions $Cond:=\{CondAttr_{1},CondAttr_{2},........CondAttr_{R}\}$ Smart Contract Generation and Deployment if $IC_{i}$ is complete then

2         /* complete means presence of $Sub$, $Op$, $Obj$, and $Cond$ with patient consent */

3       $IC_{i}$ is added to smart contract

4else

5       Denied: smart contract for $IC_{i}$ can not be created and deployed   /* incomplete informed consent component */

6      

7 end if

Algorithm 2 Informed Consent Smart Contract

V-B Contract-Based Access Control

We propose an extended version of the Attribute-Based Access Control Model [33] to integrate the Patient-Provider Agreement (PPA) for authorizations with other applicable policies and attributes. The proposed model is called the Contract-based Access Control Model. Integrating PPA into the access control model improves transparency and accountability and facilitates compliance monitoring. Figure 7 contains proposed model components. The solid line with the arrow indicates request/command and the dotted line with the arrow means response/feedback. The dotted line with circles (purple colored) shows the request/command and response/feedback. Their interactions and descriptions are discussed in the following.

Figure 7: Contract-Based Access Control Model [22].

Subject (SB): A subject is a human user or non-person entity (NPE), such as a device that issues access requests to perform operations on objects. Subjects are assigned one or more attributes. A total $m$ number authorized subjects can be represented as $\{sb_{1},sb_{2},sb_{3},sb_{4},.....sb_{m}\}$.

Subject Attributes (SA): Subject attributes of a subject, such as a name, date of birth, home address, training record, and job function, may, individually or combined, comprise a unique identity that distinguishes that user from all others. A finite number, total $n$, of subject attributes defined as $\{sa_{1},sa_{2},sa_{3},sa_{4},.....sa_{n}\}$.

Object (OB): An object can be a resource or requested entity and anything upon which a subject may operate, including data, applications, services, devices, and networks. A finite number, total $p$, of objects to be protected can be written as $\{ob_{1},ob_{2},ob_{3},ob_{4},.....ob_{p}\}$.

Object Attributes (OA): An object’s attributes help to describe and identify it. Attributes include the object name, creator, creation time, and others. A $q$ number of object attributes can be expressed as $\{oa_{1},oa_{2},oa_{3},oa_{4},.....oa_{q}\}$.

Operation (OP): An operation is an action that can be requested by any subject for any object. Only a subject can be authorized to perform a requested operation on an object if the policy allows it. A finite, total $r$, of actions to be performed are denoted as $\{op_{1},op_{2},op_{3},op_{4},.....op_{r}\}$.

Environment Condition (EC): Environmental conditions are dynamic factors, independent of subject and object, that may be used as attributes at decision time. They may include location, time, day of the week, threat level, device ID, user IP address, temperature, etc. A finite, total $s$, of environmental conditions can be expressed as $\{ec_{1},ec_{2},ec_{3},ec_{4},.....ec_{s}\}$.

Policy Contract Administration Point (PCAP): It provides functionalities for creating, storing, managing, and testing policies, PPAs, and SB, OB, and EC attributes.

Attributes Repository (AR): It contains all SB, OB, and EC attributes. Before storing, PCAP ensures the authenticity and integrity of the attributes’ sources and values because the repository acts later as a standard to verify and compare the user’s provided attributes to make the authorization decisions.

Policy Contract Repository (PCR): The PCR contains digital policies (DPs) and metapolicies (MPs) of obligatory policies like organizational policies, regulatory agency policies, and access control policies. A policy is the representation of rules that makes it possible to determine if requested access should be allowed, given attributes of the SB, OB, and EC.

Patient-Provider Agreement Repository (PPAR): It contains all valid contracts made by patients and providers. The Policy Contract Decision Point or PCDP must execute PPAs related to an access request.

Policy Contract Decision Point (PCDP): It computes access decisions by evaluating the applicable policies from PCR, PPAs from PPAR, and attributes from AR.

Policy Contract Information Point (PCIP): The PCIP is the retrieval source of the attributes required for policy evaluation to make authorizations by PCDP.

Policy Contract Enforcement Point (PCEP): After making authorizations, the PCDP forwards decisions to PCEP. The PCEP can access protected resources and objects through a resource access point (RAP). Multiple RAP might exist, but every object is accessible only through a single RAP.

Policy Contract Audit Trails (PCAT): It contains the activities happening in the system and related to policy compliance. All activities other than policy compliance-related are not required for this proposed model. The actions can be reconstructed properly from PCAT to recreate the events performed by PCEP, PCDP, PCIP, PCAP, and SB.

VI Policy Provenance

While enforcing policy for system security is essential, it is equally important to maintain provenance to demonstrate policy compliance. However, by itself, policy compliance cannot be measured or validated. An independent auditor performs a policy audit to certify the policy’s compliance status using available provenance data. To measure policy compliance, it is essential to maintain the following:

• policy lineage

• integrity of policy enforcement activities

Policy lineage contains all policies where the authorization module makes authorization decisions based on these policies. Enforcement integrity means the events are recorded as they happened. Provenance provides a lineage of policy enforcement activities as they are executed. No one should be able to modify audit trails to cover activities or unwanted healthcare data access. This section contains the detailed mechanisms of provenance to ensure policy lineage and audit trail integrity.

VI-A Provenance via Blockchain

Figure 8 depicts the provenance services via the blockchain network. The blockchain network acts as a platform that has two major components: (i) smart contract and (ii) storage capacity. The smart contract provides integrity services for attributes, policies, and access control mechanisms. The blockchain network stores policy, the hash of policy, attributes, access control, health records, audit trails, and others.

Figure 8: Provenance via Blockchain.

VI-B Policy Enforcement Audit Trails

We propose a private blockchain-based audit trail-storing system. All policy enforcement activities are collected and stored on the private blockchain network as audit trails. The private Ethereum blockchain network is used to store audit trails. Fig. 9 shows the structure of policy enforcement audit trails. A private blockchain is a setup where a closed group of users determines the consensus mechanism and other properties like block structure, block size, and block contents. To ensure that audit trails are not intentionally modified, this proposed approach stores block ID and block hash (as integrity) on a public blockchain like Ethereum. Fig. 10 depicts the audit block structure for the audit blockchain. Each block contains a $M$ number of audit trails as transactions, where each log includes which subject performs what operation on which object under what conditions at what time.

An API, or Oracle, is used to interact with a blockchain network from another one. Since smart contracts cannot communicate directly from one blockchain network to another. API/Oracle is a trusted and blind entity that reads data from the source and transfers it to the destination without modifying or revealing data to other entities. The detailed mechanism of the API or Oracle is out of the scope of this paper. We will address the complete technical design and implementation in our future communication.

Figure 9: Policy Enforcement Audit Trails.

Figure 10: Audit Blockchain Block Structure.

Storing policy enforcement activities can be done using database management systems. However, we propose a private blockchain (Ethereum private or enterprise setup) instead of database systems. In Section VII, a consensus mechanism called Proof of Compliance (PoC) is proposed to verify the compliance status of enforcement activities. A set of dedicated blockchain nodes perform compliance-checking operations according to the consensus algorithm. Also, the existing smart contract framework can be used to perform various operations to provide services, such as all audit trails for a particular user or an object, and so on. To execute the PoC consensus mechanism, storing audit trails on a blockchain is required. It is very expensive to store data on public blockchain networks. Moreover, systems generate a large amount of data, and audit trails contain sensitive information regarding users’ actions. We avoid storing audit trails on the public blockchain.

VI-C Audit Trail Verification

Everyone should not access the audit trails since they contain sensitive information regarding users’ executed operations or health data access. Access to audit logs must be controlled and restricted to a certain group of users who have privileges according to the organization and other applicable policies. However, it is necessary to access or check a user’s activity data for various purposes. So, there must be a process to verify the integrity of a user’s audit trails from the audit blockchain without revealing other users’ activity data. We propose a zero-knowledge-based audit trail integrity verification process shown in Fig. 11. A user provides audit trails or activity data and gets modified or not-modified responses from the system. After getting a request from a user, the Integrity Verifier (IV) gets the block ID and integrity from the audit blockchain. Then IV queries the public blockchain to retrieve the block hash for the audit blockchain block ID. If audit block integrity and stored hashes on the public blockchain are matched, then IV returns are not modified or tampered with by the user. Otherwise, the activity data is tampered with in the audit blockchain. Moreover, all blocks in the audit blockchain are added through a consensus mechanism. A single-bit modification invalidates all the blocks in the tampered block. Which indicates any kind of modification. Here, the Integrity Verifier also acts as a blind and trusted entity, such as an API or Oracle. It does not reveal data to other entities and analyzes data for any interest. It also does not modify any data while processing users’ requests.

Figure 11: Audit Trails Integrity Verification

VII Policy Compliance

The healthcare industry is subject to varying degrees of regulatory oversight, and compliance with these regulations is essential for its operation and growth. The specific regulatory landscape can vary by country and region, adding complexity to this industry. Non-compliance or compliance failure causes various business and legal issues, like medical and business license suspension, employee termination, monetary fines, business restrictions within a particular jurisdiction, business reputation loss, patient or client dissatisfaction, etc. These non-compliance cases are mostly found or noted while conducting internal, external, or third-party audits and reviews. To help healthcare organizations detect early non-compliance issues, this section presents a consensus mechanism called Proof of Compliance ($PoC$). Some distributed, decentralized, and independent auditor nodes check the compliance status of any logical operations or accesses that have already been approved, granted, or executed in the system to get to PHI. The $PoC$ auditors work on audit trail provenance data that is securely stored and maintained on the audit blockchain. Section VI contains the detailed proposed mechanism of maintaining a private blockchain-based audit trail provenance system. The Proof of Compliance consensus mechanism helps organizations minimize compliance challenges. Organizations can consider $PoC$ outputs and take further actions to reduce non-compliance cases to avoid compliance issues and business losses.

VII-A Transaction Structure

Fig. 12 shows the conceptual transaction structure for the proposed consensus mechanism. An individual transaction represents an approved or granted health data access request. Initially, there are five elements in any transaction: (i) subject, (ii) operation, (iii) object, (iv) conditions, and (iv) timestamp. The system adds one more element, compliance status, to the initial transaction after performing a compliance status check.

Figure 12: Proof of Consensus (PoC) Consensus Transaction Structure.

Figure 13: Auditor Nodes Compliance Checking.

Subjects are users who can perform certain operations on healthcare resources when certain conditions are satisfied. They must be authorized to perform any operations. Unauthorized users should not access protected health information, which can cause security and privacy violations. Operations represent the system actions that authorized users can perform on the objects. Examples of operations are read, write, and update. Objects are protected healthcare information. Any operations based on this information must be according to the applicable policies. A timestamp is the block creation time. The time has been given in seconds since 1.1.1970. The proposed framework captures the time when an access happens. Conditions that must be satisfied by the user to perform operations on the protected objects. Based on the consensus mechanism, the auditor nodes determine the compliance status. Fig. 13 shows the compliance determination process. The status can be compliance, noncompliance, or not determined. Selected auditor nodes perform the compliance-checking operations.

VII-B Proof of Compliance Network Structure

Fig. 14 shows the blockchain structure for the proposed consensus mechanism. All users’ access requests are authorized and recorded as audit trails in provenance. Then the proof of compliance consensus mechanism performs compliance checking and adds compliance status as compliance or non-compliance. Finally, blocks are created and added to the blockchain network.

Figure 14: PoC Blockchain Network Structure.

VII-C Proof of Compliance (PoC) Participant Nodes

Multiple nodes participate in the network to perform different roles. In the following, they are discussed along with their corresponding activities in the network.

Client Node: This node submits all transactions to the network for confirmation, auditing, and commit. This node is also responsible for reading blocks from the network with the required credentials.

Order Node: It performs all transaction ordering services submitted by the client node. Transaction ordering can be done in various ways: first come, first serve, priority-based, transaction size, etc. Once transactions are ordered, it transfers them to the validator/endorser node for verification.

Validator/Endorser Node: Chaincodes, smart contracts, or business logic are executed by this node to validate the transactions.

Auditor Node: This node is responsible for checking the compliance requirements for regulations and other applicable bodies.

Committer Node: It writes the transactions verified by the validator/endorser and auditor nodes to the blockchain ledger. After writing the transactions to the ledger, no entity can modify the blocks or transactions.

VII-D Proof of Compliance (PoC) Consensus Mechanism

Algorithm 3 contains the step-by-step activities of the proof of compliance mechanism. There are four major groups of operations (i) signature verification and order, (ii) transaction validation, (iii) policy compliance verification, and (iv) ledger modification. In signature verification and order, the order nodes perform users’ signature verification for submitted transactions. After verification, only valid transactions are ordered for the next step. If a user submits a transaction using a private key but includes another user’s public key or ID, then the submitted transaction is invalid. The validator/endorser node executes chaincodes or smart contracts to verify the transaction output. Then, the auditor nodes perform transaction compliance status checking. After checking, a status, compliance or non-compliance, is added at the end of the transaction, as shown in Fig. 12. Other components in the submitted transaction should not be modified. Finally, after adding the compliance status to the transaction, it is permanently added to the blockchain ledger. Before adding, the responsible nodes must verify that the submitted transaction elements are the same.

The PoC reports do not support final regulatory compliance certification. However, it is possible if one or more multiple audit nodes are deployed and maintained in the consensus mechanism by the corresponding regulatory agency, government agency, or compliance authority. Also, it is important to satisfy certain requirements by the proposed framework. The regulatory authority authorities and corresponding responsible offices must provide those requirements. Currently, there is no proposal or requirements for compliance status checking.

Input :  (i) list of transactions $(Txns)$ and (ii) set of policy $Plcy$

Output :  (i) list of accepted/rejected transactions $(Txns)$ (ii) list of transactions that are policy compliance

1 Initialization $\mathbb{N}_{Order}$ order nodes $\mathbb{N}_{Validator}$ validator/endorser nodes $\mathbb{N}_{Audit}$ audit nodes $\mathbb{N}_{Committer}$ committer nodes Signature Verification and Order $Txn_{Valid}=[]$   /* accepted transaction list */

2 $Txn_{Invalid}=[]$   /* rejected transaction list */

3 for $i\leftarrow Txns_{Start}$ to $Txns_{End}$ by $1$ do

4       if $\zeta(PK_{i},Tnx_{i})==Signed_{Tnx_{i}}$ then

5             $Txn_{Valid}\leftarrow Txn_{Valid}+Txn_{i}$

6      else

7             $Txn_{Invalid}\leftarrow Txn_{Invalid}+Txn_{i}$

8       end if

9      

10 end for

11 Transaction Validation $Txn_{Accepted}=[]$   /* accepted transaction list */

12 $Txn_{Rejected}=[]$   /* rejected transaction list */

13 for $i\leftarrow{Txn_{Valid}}_{Start}$ to ${Txn_{Valid}}_{End}$ by $1$ do

14       if $\zeta(PK_{i},Tnx_{i})==Signed_{Tnx_{i}}$ then

15             $Txn_{Accepted}\leftarrow Txn_{Accepted}+{Txn_{Valid}}_{i}$

16      else

17             $Txn_{Rejected}\leftarrow Txn_{Rejected}+{Txn_{Valid}}_{i}$

18       end if

19      

20 end for

21 Policy Compliance Verification $Txn_{Compliance}=[]$   /* compliance transactions */

22 $Txn_{NonCompliance}=[]$   /* noncompliance transactions */

23 for $i\leftarrow{Txn_{Accepted}}_{Start}$ to ${Txn_{Accepted}}_{End}$ by $1$ do

24       if $\zeta(PK_{i},Tnx_{i})==Signed_{Tnx_{i}}$ then

25             $Txn_{Compliance}\leftarrow Txn_{Compliance}+{Txn_{Accepted}}_{i}$

26      else

27             $Txn_{NonCompliance}\leftarrow Txn_{NonCompliance}+{Txn_{Accepted}}_{i}$

28       end if

29      

30 end for

31 Ledger Modification $Txn_{Compliance}=[]$   /* compliance checked final transactions */

32 $Txn_{NonCompliance}=[]$   /* noncompliance transactions */

33 for $i\leftarrow{Txn_{Accepted}}_{Start}$ to ${Txn_{Accepted}}_{End}$ by $1$ do

34       if $\zeta(PK_{i},Tnx_{i})==Signed_{Tnx_{i}}$ then

35             $Txn_{Compliance}\leftarrow Txn_{Compliance}+{Txn_{Accepted}}_{i}$

36      else

37             $Txn_{NonCompliance}\leftarrow Txn_{NonCompliance}+{Txn_{Accepted}}_{i}$

38       end if

39      

40 end for

Algorithm 3 Proof of Compliance (PoC) Consensus

VII-E Healthcare Data Security and Privacy

The auditor nodes verify the compliance status of healthcare workers’ access activities. For this, they need to access the deployed and applicable policies with the corresponding audit trails. In this situation, the audit nodes do not access any protected health information directly or indirectly. However, activity logs can contain some sensitive information about health professionals as well as patients. For example, it is possible to learn about a patient’s ongoing treatment from the audit trails. If a specialist doctor accesses a patient’s health data, then it can be concluded that the doctor is treating the patient. In this proposed $PoC$ consensus mechanism, the auditor nodes act as secured, trusted, and blind entities. They don’t reveal data to other unauthorized users. They don’t analyze data to learn about providers and patients. They do not modify or tamper with data or $PoC$ decisions. They do not store data intentionally. They analyze data only to make compliance status decisions. The complete protocols for them to act as secured, trusted, and blind entities are not addressed in this paper currently. They are our future research directions.

VII-F Blockchain Data as Court Evidence

In June 2018, a landmark court judgment affirmed for the first time that electronic data stored on a blockchain could be considered valid electronic evidence. Subsequently, in a separate case in 2019, the court extended this recognition to not only the authenticity and integrity of electronic evidence stored on a blockchain but also to evidence generated by the blockchain itself [34]. The Blockchain Technology Act, House Bill 3575, passed by the House of Representatives on May 29, 2019, and enacted in January 2020, governs the utilization of blockchain technology in transactions and legal proceedings. The Act sets forth regulations, imposes limitations, and provides definitions for terms such as blockchain and electronic record. According to the Act, the use of a blockchain to create, store, or verify a smart contract, record, or signature does not undermine its legal effect or enforceability. Moreover, when the law mandates written records, electronic evidence recorded on a blockchain is deemed sufficient. Similarly, for situations requiring a signature, an electronically recorded signature on a blockchain or blockchain evidence confirming a person’s intent to provide a signature is considered satisfactory [35].

Hence, the implementation of our prototype, utilizing blockchain for smart contract storage, is following US law. The hospital can submit complaints about policy violations against offenders, supported by evidence from our blockchain framework.

VIII Achieving Provenance and Compliance

The data access control process for provenance and compliance is summarized in Figure 15, and the steps are as follows:

Step 1 and 10: The subject puts the request to PCEP in Step 1 with the required credentials and attributes. The subject receives the object in Step 10 if an access request is granted. Otherwise, the subject receives the access denial decision.

Step 2 and 7: PCEP forwards the subject access request in Step 2 with the credentials and attributes received from the subject to PCDP to make the decision. In Step 7, PCEP receives the access decision made by PCDP.

Step 3, 4, 5, and 6: In Step 3, PCDP requests PCIP to retrieve the attributes of the subject and object and environmental conditions related to the access request. PCDP also asks the policy repository to find the applicable policies. It also requests that the PPAR retrieve the PPAs between the patient and the provider for the access request. In Step 5, PCIP retrieves the attributes from the attribute repository. PCDP receives responses in Step 6.

Step 8 and 9: If access is granted, then PCEP gets the object in these steps.

Step 12: PCAP updates the attribute, policy, and patient-provider agreement repository.

Step 11 and 13: In Step 11, PCEP, PCDP, and PCIP record the activities as audit trails to PCAT. When PCAP updates repositories, its activities are recorded in Step 13.

Step 14: PCVP gets all required information from repositories to certify policy compliance.

Figure 15: Policy Enforcement, Provenance, and Compliance Sequence Diagram.

IX Implementation and Experimental Evaluation

To study the challenges in using blockchain smart contracts for policy compliance provenance as outlined above, we implement a proof-of-concept on the Ethereum blockchain. The proofs-of-concept have two parts: one implements traditional access control policies for a hypothetical healthcare provider and the other implements policies involved in the contract between a patient and the provider. We implement both policies as contracts per the algorithms shown in Section.

We chose the Ethereum blockchain protocol test network, Goerli, since it is the first blockchain platform with smart contract features. We use the Python-based Brownie blockchain development framework to build, deploy, test, and do other things with smart contracts. We use Solidity as a programming language for the proposed approach to writing smart contracts.

We send transactions through the Ethereum test network, Goerli, using the Metamask wallet. Goerli faucet ether is spent for smart contract deployment and transaction submission. In smart contracts, all communication occurs through function calls and event triggers, which the Ethereum protocol handles automatically.

IX-A Sample Policies

To make sure that the treatment team members have access to patients’ health, we include some sample policies. Other users must not access the data.

Policy 1 (P1): In an emergency, treatment team member doctors can read and write, and other members can read patients’ health records. Patient and emergency contact personnel must be notified about the emergency access.

Policy 2 (P2): In an emergency, emergency contact personnel can read patients’ health records. Patient and emergency contact personnel must be notified about the emergency contact personnel access.

Policy 3 (P3): Treatment team member doctors can read and write all medical data for the assigned patient.

Policy 4 (P4): Treatment team members, nurses, and support staff can only read particular health records for the assigned patient.

Policy 5 (P5): Lab technicians can read and write test results prescribed by doctors. They can not read or write any other results or healthcare records.

Policy 6 (P6): Assigned billing officers can read and write patient personal information and billing information. They can not read or write healthcare records.

Policy 7 (P7): Assigned insurance company employees can read only medical test names and doctor’s information. They can not read or write any medical records, including visit notes. Insurance coverage claim payment information must be shared with the patient.

Policy 8 (P8): A patient can read all his or her medical records, including visit notes, prescriptions, medical test results, and insurance claim information. But he/she can not write any medical records. He/she can write personal, billing, emergency contact, and check-in information.

Policy 9 (P9): Audit logs integrity must be protected once they are recorded to prevent log tampering. It means no one can alter the log data.

Policy 10 (P10): Healthcare Providers cannot access patients’ data if they do not have HIPAA/HITECH/GDPR training from 6/12 months.

IX-B Patient Treatment Team Members

Treatment team members for a patient include doctors, nurses, support staff, lab technicians, billing officers, insurance agents, and the patient’s emergency contact person. As the treatment period for a patient, we include everything from treatment to insurance coverage and billing. For this study, we consider one member from each category, like the doctor, nurse, and others. However, there might be multiple team members in each category. Table II shows the patient-treatment team members and their responsibilities during and after treatment. Team members are randomly selected if they are available. An emergency contact person is added by the patient and not randomly selected for the treatment team. Algorithm 4 shows the steps of treatment team creation for a patient.

TABLE II: Patient Treatment Team Member

SN	Treatment Team Member	Treatment Team Member Responsibilities
1	Doctor (DOC)	Viewing patient’s healthcare data
2	Nurse (NRS)	Creating new patient’s healthcare data
3	Support Staff (STF)	Correcting erroneous or appending patient’s healthcare data
4	Billing Officer (BLO)	Viewing patient’s healthcare data
5	Radiology Lab Tech (RLT)	Creating new patient’s healthcare data
6	Pathology Lab Tech (PLT)	Correcting erroneous or appending patient’s healthcare data
7	Emergency Contact (EMC)	Viewing patient’s healthcare data
8	Pharmacist (PHR)	Creating new patient’s healthcare data
9	Insurance Agent (INA)	Correcting erroneous or appending patient’s healthcare data

Input : (i) $DOC$, (ii) $NRS$, (iii) $STF$, (iv) $BLO$, (v) $RLT$, (vi) $PLT$, (vii) $EMC$, (viii) $PHR$, (ix) $INA$

1   /* $\mathbb{R}_{PTT}$: secured PTT repository, $BN_{SC}$: blockchain network smart contract */

Result : A formal treatment team

2 PTT Member Initialization $PTT_{i}\leftarrow\{DOC_{i},NRS_{i},STF_{i},BLO_{i},RLT_{i},PLT_{i},EMC_{i},PHR_{i},INA_{i}\}$ for patient identity $i$  (i) $DOC\leftarrow\{DOC_{1},DOC_{2},DOC_{3},.......,DOC_{D}\}$  (ii) $NRS\leftarrow\{NRS_{1},NRS_{2},NRS_{3},.......,NRS_{N}\}$  (iii) $STF\leftarrow\{STF_{1},STF_{2},STF_{3},.......,STF_{S}\}$  (iv) $BLO\leftarrow\{BLO_{1},BLO_{2},BLO_{3},.......,BLO_{B}\}$  (v) $RLT\leftarrow\{RLT_{1},RLT_{2},RLT_{3},.......,RLT_{R}\}$  (vi) $PLT\leftarrow\{PLT_{1},PLT_{2},PLT_{3},.......,PLT_{P}\}$  (vii) $EMC\leftarrow\{EMC_{1},EMC_{2},EMC_{3},.......,EMC_{E}\}$  (viii) $PHR\leftarrow\{PHR_{1},PHR_{2},PHR_{3},.......,PHR_{H}\}$  (ix) $INA\leftarrow\{INA_{1},INA_{2},INA_{3},.......,INA_{I}\}$ PTT Finalization if $PTT_{i}$ is complete then

3         /* complete: presence of all members */

4       if $(\mathbb{R}_{PTT}+PTT_{i})$ contains no conflicts then

5             (i) do $\mathbb{R}_{PTT}\leftarrow(\mathbb{R}_{PTT}+PTT_{i})$ (ii) add $\mathbb{ID}_{PTT_{i}}$ to patient profile, $\mathbb{P}_{i}$ (iii) call $\mathbb{BN}_{SC}(\mathbb{ID}_{PTT_{i}},\mathbb{H}_{PTT_{i}})$   /* later PTT integrity verification */

6             Return: Success ($PTT_{i}$ added to $\mathbb{R}_{PTT}$)

7      else

8             Error: $(\mathbb{R}_{PTT}+PTT_{i})$ contains conflicts   /* $PTT_{i}$ revision required to add */

9            

10       end if

11      

12else

13       Error: $PTT_{i}$ cannot be created (incomplete PTT)

14 end if

Algorithm 4 Patient Treatment Team (PTT) Creation

IX-C Patient Health Records

The term ”Electronic Health Record” (EHR) refers to an electronic version of a patient’s medical history that is kept on file by the healthcare provider over time. It may include all the administrative and clinical information pertinent to the patient’s care under a specific provider, such as demographics, progress notes, issues, medications, vital signs, previous medical history, immunizations, laboratory information, and radiology reports. For this study, we only consider ten (10) types of health records for each patient. Table III shows the health record ID, name, description, and potential creators.

TABLE III: Patient Health Records

Record ID	Record Name	Record Description	Record Creator
HR1001	Demographic Info	Patient’s information	Patient, Support Staff
HR1002	Previous Medical History	Old medical records from another hospital	Patient, Support Staff
HR1003	Immunizations	Immunization records that are administered over time	Patient, Pathology Lab Technician
HR1004	Allergies	Various allergies sources, triggering condition, remediation	Patient, Support Staff, Pathology Lab Technician
HR1005	Visit Notes	Contains physiological data, disease description, advice, follow-up, visit details	Doctor, Nurse
HR1006	Medications and Prescription	Prescribed medications including name, dosage, etc.	Doctor
HR1007	Pathology Lab Works	Blood work	Pathology Lab Technician
HR1008	Radiology Lab Works	Imaging and Radiology Lab results	Radiology Lab Technician
HR1009	Billing and Insurance	Bank account and insurance policy Information	Patient, Support Staff, Billing Officer
HR1010	Payer Transactions	Bills of doctor visit, lab works, and medications	Billing Officers, Insurance Agent

IX-D Health Record Operations

Many operations are executed in the healthcare industry to perform required operations. Some common operations are view/read, add/write, update/modify, share, delete, etc. This study considers only three operations: read, write, and update. Users of patients’ health records perform these operations. In the read operation, users can only view or read healthcare records or resources if the request is valid and complies with all applicable policies. The state of the data is not changed in this operation, ensuring data integrity. However, it can compromise confidentiality and privacy if the access requested is granted without appropriate credentials. On the other hand, the write operation changes the state of the records or data. If proper policy enforcement is not ensured, it breaks the integrity of the data. The update operation also changes health data to correct errors or adds new data at the end of the old data. Same as write, it changes data integrity. Table IV contains the details of the operations with ID, name, and functionalities. In our future Communications, other operations like share and delete will be added to the framework.

HIPAA privacy policy mandates that users should only access a patient’s protected health information if they have permission or consent from the patient. However, there are some cases where a patient’s consent is not needed such as the billing process, and anonymous data sharing with research organizations and marketing agents. HIPAA security policy mandates to put the right access control mechanism to protect patient’s protected health information. We keep the proposed framework to focus on treatment team-based data access. All users should not perform all operations on all health records. In this work, users have operations permission based on their job role or functionalities. Also, health data nature and sensitivity are considered to give the permissions. Table V shows the user-oriented operations. Fig. 16, 17, 18, and 19 show the use cases diagrams for users and their given operation permissions.

TABLE IV: Health Record Operations

ID	Operation	Functionalities
R	Read	Viewing patient’s healthcare data
W	Write	Creating new patient’s healthcare data
U	Update	Correcting erroneous or appending patient’s healthcare data

TABLE V: User Oriented Health Records Operations

Record ID	Record Name	Read	Write	Update
HR1001	Demographic Info	Patient, Doctor, Support Staff, EC	Patient, Support Staff	Patient, Support Staff
HR1002	Previous Medical History	Doctor, Patient	Patient, Doctor	Patient, Doctor
HR1003	Immunizations	Doctor, Patient, Patho Lab Tech	Patho Lab Tech	Patho Lab Tech
HR1004	Allergies	Doctor, Patient, Nurse	Patient, Patho Lab Tech	Patient, Patho Lab Tech
HR1005	Visit Notes	Doctor, Nurse, Patient, EC	Doctor	Doctor
HR1006	Medications and Prescription	Doctor, Patient, Nurse, Pharmacist, Insurance Agent, EC	Doctor	Doctor
HR1007	Pathology Lab Works	Patho Lab Tech, Doctor, Patient, EC	Patho Lab Tech	Patho Lab Tech
HR1008	Radiology Lab Works	Radio Lab Tech, Doctor, Patient, EC	Radio Lab Tech	Radio Lab Tech
HR1009	Billing and Insurance	Patient, Billing Officer, Insurance Agent	Billing Officer, Patient	Billing Officer, Patient
HR1010	Payer Transactions	Patient, Billing Officer, Insurance Agent	Billing Officer, Insurance Agent	Billing Officer, Insurance Agent

Figure 16: Patient and Doctor Use Cases for Read Operation.

Figure 17: Users Use Cases for Read Operation.

Figure 18: Users Use Cases for Write Operations.

Figure 19: Users Use Cases for Update Operations.

IX-E Sample Users Profile

Users perform different operations according to their job responsibilities and applicable policy set. If they follow the policy, then the operations are in policy compliance; otherwise, they are violations. Users are grouped into major five categories: ((i) patient, (ii) emergency contact, (iii) providers, (iv) pharmacist, and (v) insurance agents. Other users such as business associates, clearing houses, etc are not considered in this report. They would be included in the future extension works. Table VI shows ten (10) patients’ information with six (6) attributes: patient ID, name, date of birth, gender, phone, and email. For every patient, an emergency contact person is included who is the contact point if there is any emergency. Table VII contains ten (10) emergency contact information with ID, name, date of birth, phone, email, patient ID, and relationship with the patient.

Table VIII tabulates ten (10) providers’ information with provider ID, name, date of birth, title, phone, and email. For this study, we consider doctors, nurses, support staff, radiology lab technicians, pathology lab technicians, and billing officers are the main providers. Pharmacists’ and insurance agents’ information is given in Table IX and X. They also access protected health information for processing prescriptions and insurance claims. We keep them as part of the patient treatment team members. They must be authorized to access any patient data. Patient’s consent must be given to them. Otherwise, the proposed framework doesn’t allow them to access data.

TABLE VI: Patient Profiles

Patient ID	Name	Date of Birth	Gender	Phone	Email
PT1001	Jordan	DOB11251980	Male	+15306524342	[email protected]
PT1002	Simon	DOB10151982	Male	+15737524481	[email protected]
PT1003	Tatum	DOB11051984	Male	+14324386527	[email protected]
PT1004	Thomas	DOB12201986	Male	+16609079598	[email protected]
PT1005	David	DOB05091975	Male	+15702917315	[email protected]
PT1006	Alexander	DOB01271978	Male	+16578059479	[email protected]
PT1007	Sarah	DOB09281970	Female	+12058912490	[email protected]
PT1008	Ronald	DOB03151979	Male	+13238648870	[email protected]
PT1009	Rebecca	DOB12251985	Female	+14426746222	[email protected]
PT1010	Emma	DOB10151995	Female	+16098632161	[email protected]

TABLE VII: Emergency Contact Profiles

Id	Name	Date of Birth	Phone	Email	Patient	Relationship
EC1001	Olivia	DOB11041992	+15135030830	[email protected]	PT1001	Sister
EC1002	Isabella	DOB12281972	+12246579011	[email protected]	PT1002	Aunt
EC1003	Amelia	DOB07011999	+15166694568	[email protected]	PT1003	Mother
EC1004	Alice	DOB12251998	+12164898791	[email protected]	PT1004	Spouse
EC1005	Eleanor	DOB09111990	+14305361691	[email protected]	PT1005	Spouse
EC1006	Benjamin	DOB10071980	+15772628573	[email protected]	PT1006	Friend
EC1007	Theodore	DOB06281992	+15646892293	[email protected]	PT1007	Son
EC1008	Henry	DOB08061982	+15416532424	[email protected]	PT1008	Brother
EC1009	Arthur	DOB12101994	+16025371089	[email protected]	PT1009	Brother
EC1010	Liam	DOB02101987	+13217057450	[email protected]	PT1010	Cousin

TABLE VIII: Provider Profiles

Provider Id	Name	Date of Birth	Title	Phone	Email
PR1001	Andrew	DOB11041992	Doctor	+14016296781	[email protected]
PR1002	Sophia	DOB12281972	Doctor	+16805970987	[email protected]
PR1003	Linda	DOB07011999	Doctor	+12522173068	[email protected]
PR1004	Oscar	DOB12251998	Nurse	+12488860746	[email protected]
PR1005	William	DOB09111990	Nurse	+18026758468	[email protected]
PR1006	Damien	DOB10071980	Support Staff	+13194615516	[email protected]
PR1007	Douglas	DOB06281992	Support Staff	+18597638767	[email protected]
PR1008	Robert	DOB08061982	Radiology Tech	+18502557057	[email protected]
PR1009	Victoria	DOB12101994	Pathology Tech	+12837975034	[email protected]
PR1010	James	DOB02101987	Billing Officer	+17712104375	[email protected]

TABLE IX: Pharmacist Profiles

Pharmacist ID	Name	Date of Birth	Title	Company	Phone	Email
PHR1001	Justin	DOB12121984	Pharmacist	EverGreen Pharmacy	+12564014540	[email protected]
PHR1002	Madison	DOB15071977	Pharm Technician	BlueSky Pharmacy	+15134414566	[email protected]

TABLE X: Insurance Agent Profiles

Agent ID	Name	Date of Birth	Title	Company	Phone	Email
ICA1001	Jasper	DOB21091955	Senior Agent	Anthem Health Plan	+13524606592	[email protected]
ICA1002	Hanan	DOB17021985	Agent	Care Health Insurance	+18189025033	[email protected]

IX-F Provenance Environment

For policy provenance, we have opted for a private blockchain infrastructure, specifically utilizing the Ethereum private network deployed through the Go implementation of the Ethereum (geth) client. This decision is to ensure data security and maintain control over policy-provenance activities. This private network uses the Proof of Authority (PoA) consensus algorithm, known as Clique, to mine and confirm the audit trails. Further, when we have proof of compliance algorithm ready, the clique algorithm can be modified to change block structure according to requirements.

Figure 20: Miner Node Operations.

Fig. 20 shows the miner node, responsible for the end-to-end process of transaction handling. Beginning with the submission of transactions. Once a transaction is submitted, the miner node takes charge of including it in a block and subsequently engages in the mining process to validate the block. Furthermore, the miner node actively publishes this mined data to all other nodes within the network, ensuring a synchronized and updated ledger across the entire system.

Figure 21: Audit Blockchain Genesis Block.

Fig. 21 shows the configuration file for the genesis block of our private network. In the context of blockchain technology, a genesis block is an initial block in the chain, and this JSON file encapsulates crucial information defining the network’s foundational parameters. Within this file, the ”chainId” attribute is set to ”12345,” signifying the unique identifier assigned to our private network. The ”period” attribute represents a defined period, specifying the block time, which dictates the interval between the creation of consecutive blocks in the blockchain.

Figure 22: Frontend Interaction.

Figure 23: User Interface for Patient

Figure 24: User Interface for Provider.

Figure 25: Informed Consent Transaction.

Fig. 26 shows the system for controlling access to audit trails involves the protection of sensitive user information, executed operations, or health data access. Limited access is granted only to users with designated privileges, following policies. When a user seeks verification, the Integrity Verifier retrieves the block ID and block hash from the audit blockchain. The verifier then queries the public blockchain for the block hash corresponding to the audit blockchain block ID. If the audit block hash matches the stored hash on the public blockchain, the verifier confirms the data as unaltered. Any mismatch signals potential tampering in the audit blockchain. It’s important to note that all blocks in the audit blockchain undergo addition through a consensus mechanism. A single-bit modification invalidates all blocks from the tampered block, indicating any form of alteration. Acting as a blind and trusted entity, the Integrity Verifier, serving as an API or Oracle, ensures data confidentiality, refrains from data modification, and conducts secure verifications for user requests initiated through the user interface.

Figure 26: Integrity Verifier.

X Conclusion

The paper proposes a blockchain-based approach to address the challenges of healthcare policy compliance. It focuses on enforcing patient-provider agreements (PPAs) and other policies through smart contracts on the blockchain. The use of blockchain technology ensures that policies are enforced and provides an immutable trail for policy compliance. The document highlights the importance of maintaining provenance, which involves recording and preserving the history of policy enforcement activities. Blockchain is used to store audit trails and ensure the integrity of recorded events.

The proposed approach includes a consensus mechanism called Proof of Compliance (PoC) to verify the compliance status of access requests. This mechanism involves a network of distributed and decentralized auditor nodes that perform compliance checking for the given audit trails. The results of the compliance checks determine whether an access request is compliant or non-compliant with the policies.

The paper discusses the components of the proposed approach, including the Patient-Provider Agreement (PPA), informed consent, contract-based access control, policy provenance, and policy compliance. It also provides an overview of the implementation and experimental evaluation of the proposed approach on the Ethereum blockchain.

In conclusion, the paper presents a comprehensive solution for healthcare policy compliance using blockchain technology. The proposed approach ensures that policies are enforced, provenance is maintained, and compliance is verified through the use of smart contracts and distributed auditor nodes. The experimental evaluation demonstrates the effectiveness of the approach in ensuring policy compliance and maintaining the integrity of policy enforcement activities. This research has significant implications for improving the security and privacy of healthcare data and enhancing the trustworthiness of healthcare systems. Future research directions are also discussed to further enhance and extend the proposed compliance frameworks.

XI Future Directions

We’re aiming to put in place a complete step-by-step process for a compliance algorithm and link it up with the system. Additionally, we’re looking ahead to expand this system and utilize it to minimize health insurance fraud as part of the proposed compliance framework.