Applying Software Patterns to Address Interoperability in Blockchain-based Healthcare Apps

1. INTRODUCTION

• Blockchain properties including decentralization, transparency, and immutability support trustless transactions directly between parties without a centralized intermediary.The paper situates blockchain’s interest in applications beyond cryptocurrency, including healthcare.Source: §1 · p. 1
• Ethereum smart contracts enable decentralized apps that support direct interaction between end users and providers.Smart contracts control digital-asset exchanges according to established rules or agreements.Source: §1 · p. 1
• The paper applies software patterns to modularize and support extensibility in blockchain-based apps addressing healthcare interoperability.It defines interoperability as different systems and apps communicating, exchanging data, and using the information exchanged.Source: §1 · p. 1

2.1 Overview of Blockchain

• Blockchain maintains an ordered, growing transaction history through cryptographic verification and consensus across a decentralized network.Its shared records provide transparency, incorruptibility, and robustness without a single point of failure.Source: §2.1 · p. 2

2.2 Addressing Healthcare Interoperability via Blockchain-based Apps

• Healthcare interoperability requires systems to exchange and use data, while few published studies address software design considerations for implementing blockchain-based healthcare apps effectively.The section frames software engineering practices such as modularity and extensibility as important in this domain.Source: §2.2 · p. 3

2.2.1 Challenge 1: Maintaining Evolvability While Minimizing Integration Complexity.

• Because blockchain data is immutable and difficult to modify in mass, healthcare apps need evolvable data and contracts that minimize impact on existing clients.Deployed healthcare systems may not be easy to change over time.Source: §2.2.1 · p. 3

2.2.2 Challenge 2: Minimizing Data Storage Requirements.

• Storing data for thousands or millions of participants can burden the blockchain, making data sharing and flexible management of individual health concerns key design considerations.The section identifies Flyweight as a pattern for sharing common intrinsic data while allowing individual extrinsic data to vary.Source: §2.2.2 · p. 3

2.2.3 Challenge 3: Balancing Integration Ease with Security Concerns.

• Blockchain’s cryptography and resilient peer-to-peer network may support interoperability requirements, but storing patient data on-chain carries significant risks even when encryption is applied.The section identifies Proxy as a way to facilitate interoperability while keeping sensitive patient data from being directly encoded on-chain.Source: §2.2.3 · pp. 3–4

2.2.4 Challenge 4: Tracking Relevant Health Changes Across Large Patient Populations.

• Disconnected providers and organizations face delayed or absent information flow, while tracking relevant changes across many patient contracts is difficult.The section points to Publisher-Subscriber as an approach to detecting relevant changes in Ethereum contracts.Source: §2.2.4 · p. 4

3.1 Structure and Functionality of DASH

• DASH provides patients with a portal to access and update medical records and submit prescription requests, while providers review data and fulfill requests according to patient permissions.The app uses an Ethereum test blockchain and a SMART on FHIR data schema; patient and provider accounts are supported in its initial state.Source: §3.1 · p. 4

3.2 Key Implementation Challenges of DASH

• Extending DASH to new departmental users exposed tight coupling, duplicated resources, and scalability challenges.The prototype was effective for its initial purposes before the extension effort.Source: §3.2 · p. 5
• Tight coupling between storage and access, and between entities and their creation mechanism, forced contract rewrites that propagated to client-code changes.On an immutable blockchain, changing design choices can require new contracts and leave existing contracts obsolete, increasing implementation effort and computational and storage costs.Source: §3.2 · p. 5
• Duplicating common resources across departments increases storage and makes updates difficult to keep correct and timely.If copies are not all updated, they may need reevaluation or recollection to ensure data integrity.Source: §3.2 · p. 5
• A server that constantly watches patient-account events to notify providers does not scale when many parties need updates about interacting parties.The authors redesigned DASH using foundational software patterns to address these implementation challenges while addressing healthcare interoperability challenges.Source: §3.2 · p. 5

4. APPLYING FOUNDATIONAL SOFTWARE PATTERNS TO BLOCKCHAIN-BASED HEALTH APPS

• Foundational software patterns are presented as applicable to blockchain-based health apps to address interoperability challenges and implementation concerns.The section connects concerns described in the healthcare overview and the DASH case study.Source: §4 · p. 5

4.1 Overview of Solidity

• Solidity is a Turing-complete language for writing Ethereum smart contracts and DApps.The paper notes that this provides possible solutions to healthcare interoperability challenges.Source: §4.1 · p. 5
• A Solidity contract acts as a class-like prototype instantiated as an SCA, with a unique address and persistent state; it should be treated as a singleton to avoid storage overhead.Applications typically store the SCA address in configuration or a database to access its state and functions.Source: §4.1 · p. 5
• Solidity supports inheritance, polymorphism, and abstract contracts, enabling foundational software patterns to be applied to smart-contract design challenges.Abstract contracts provide declaration headers without implementations and cannot be compiled into an SCA.Source: §4.1 · p. 6

4.2.1 Applying Abstract Factory to Address Interoperability Challenge 1.

• Abstract Factory contract instances create related departmental contracts, reducing client dependence on concrete implementations and easing extensions, but adding storage and computation overhead through indirection.Without the factory, clients must import and call each specific factory and make runtime decisions as departments and subdivisions expand.Source: §4.2.1 · pp. 6–8

4.2.2 Applying Flyweight to Address Interoperability Challenge 2.

• Flyweight separates shared intrinsic information from patient-specific data, reuses account representations, and registers unique identifiers to prevent duplicate accounts.This reduces redundancy and the cost of changing shared data, though factory transactions add complexity and may delay availability of a valid contract address.Source: §4.2.2 · pp. 9–10

4.2.3 Applying Proxy to Address Interoperability Challenge 3.

• Proxy contracts provide lightweight metadata and audit trails while deferring patient data access and storage variations to heavyweight implementations.The proxy can preserve its interface as storage options change; the paper notes that indirection can cause disparate behavior and that on-chain contract addresses limit its ability to hide the real object, so server-side proxies remain useful.Source: §4.2.3 · pp. 11–12

4.2.4 Applying Publisher-Subscriber to Address Interoperability Challenge 4.

• Publisher-Subscriber sends patient-related event notifications to interested care-team subscribers, avoiding repeated event filtering and allowing topics or subscribers to be added with minimal implementation changes.Patient activity processing can be performed by a back-end server to avoid blockchain computation overhead.Source: §4.2.4 · p. 13
• Publisher-Subscriber adds update delays, on-chain filtering computation costs, and event-notification execution costs; broader on-chain topics with detailed off-chain filtering are a workaround.Ethereum blocks are added roughly every 12 seconds, and transaction priority can delay message processing; fine-grained filtering can cause gas shortages or unacceptable costs.Source: §4.2.4 · p. 14
• Modularizing contract and server-side code with software patterns supports extensibility, customization, and separation of concerns through loosely coupled components.The paper emphasizes evaluating the overall workflow and applicable patterns to make healthcare-chain communications robust and customizable.Source: §4.2.4 · pp. 14–15
• Publisher-Subscriber lets health providers subscribe to patient-account activity; all subscribed providers are notified of prescription requests, but only permissioned providers can respond.A permissioned provider’s response updates patient data.Source: §4.2.4 · p. 15
• Flyweight and Abstract Factory patterns create and register a patient account contract when needed, while Patient Registry returns its address for patient-record reads and writes.If a patient does not exist, a new account is registered; a read request in that case returns the new account address with an empty data field.Source: §4.2.4 · p. 15
• The server uses a Proxy wrapper around a generic MongoDB database object, decoupling data-store choice from other operations and delaying access to the actual data.The separate patient-record database was created for testing and backup.Source: §4.2.4 · p. 15

• Prior work covers healthcare blockchain solutions and design principles for blockchain applications, but relatively few papers focus on realizing software patterns in blockchains.Source: §4.3 · p. 15

• MedRec uses database Gatekeepers to access local databases governed by permissions stored on its blockchain.Source: §4.4 · p. 16
• Peterson et al. propose a healthcare blockchain with centralized trust and a Proof of Interoperability based on FHIR conformance for network consensus.Source: §4.4 · p. 16

• Porru et al. analyze open-source repositories and recommend collaboration, effective testing, and evaluation of suitable software architecture for blockchain development.Source: §4.5 · p. 16
• Bartoletti et al. identify nine recurring smart-contract patterns, including Oracles for external services and Polls for voting [Bartoletti and Pompianu 2017].Source: §4.5 · p. 16

• DASH’s extension exposed tightly coupled designs, duplicated resources, and scalability limitations amid four interoperability priorities: evolvability, storage, security, and population-scale tracking.Source: §5 · p. 16
• Abstract Factory, Flyweight, Proxy, and Publisher-Subscriber decouple entity creation and access, maximize resource sharing, and improve DASH’s scalability.Source: §5 · p. 16
• Future work will identify a practical healthcare blockchain design process and experimentally compare software patterns with alternative designs.Source: §5 · p. 16