A FAIL-CLOSED ARCHITECTURE FOR CRYPTOGRAPHICALLY ENFORCED RECIPIENT AUTHORIZATION IN CLINICAL TRIAL DATA DELIVERY

Sai Krishna Puli

A FAIL-CLOSED ARCHITECTURE FOR CRYPTOGRAPHICALLY ENFORCED RECIPIENT AUTHORIZATION IN CLINICAL TRIAL DATA DELIVERY

Authors

Sai Krishna Puli

Greer, SC, USA

Keywords:

Clinical Trial Data Governance, Recipient Binding, Fail-Closed Delivery, Maker–Checker Control, Formal Verification, Audit Ledger, Zero Trust Routing

Synopsis

Clinical trial data moves through a long chain of custody before it ever reaches anyone outside the organization that generated it — from a sponsor's protocol down through sub-protocols, projects, and investigators, to the patients and the individual samples and results a delivery contains. Send that data to the wrong recipient and the consequences are not abstract: exposed patient information, a broken confidentiality agreement, a mandatory regulatory report, and a relationship between sponsor and vendor that may not recover. Most systems in production today still treat a delivery's recipient as a field on a record, checked by a person before it goes out the door. That approach works right up until it doesn't, and when it fails, it tends to fail quietly, which is worse. This paper makes the case that correct delivery should be something the system checks, not something a person remembers to check — a single authorization invariant covering who the data belongs to, who is entitled to receive it, what scope was actually approved, whether the payload matches what was signed off on, whether any transformation applied to it was the right one, and whether it reached the correct channel. We build a reference architecture around that idea: a governed entity graph in place of a rigid organizational hierarchy, a versioned Recipient Binding Authority in place of a mutable address field, a fail-closed verification gate, maker–checker approval on every binding change, cryptographic manifest integrity, and an immutable ledger underneath the entire pipeline. The formal invariant Φ(D) and the theorem built on top of it state precisely what the architecture guarantees and under which assumptions — and we're upfront about the limits of that claim. A zero-tolerance objective is a design target the system is built toward, not a promise that any implementation of it is unbreakable, and we spend real space discussing the common-mode failures that could take down more than one layer of the design at once, rather than if risk away. The paper closes with a proposed evaluation approach built on fault injection and comparison against the conventional baseline, and a look at how the design maps onto the regulatory landscape a real clinical trial must operate inside.

References

[1] U.S. Food and Drug Administration, "21 CFR Part 11 — Electronic Records; Electronic Signatures," Code of Federal Regulations, Title 21, 1997 (as amended).

[2] International Council for Harmonisation, "ICH E6(R2): Integrated Addendum to ICH E6(R1), Guideline for Good Clinical Practice," Step 4, 2016.

[3] U.S. Department of Health and Human Services, "Standards for Privacy of Individually Identifiable Health Information (HIPAA Privacy Rule)," 45 C.F.R. Parts 160, 164, 2000 (as amended).

[4] U.S. Department of Health and Human Services, "Minimum Necessary Requirement," 45 C.F.R. §§ 164.502(b), 164.514(d).

[5] European Parliament and Council of the European Union, "Regulation (EU) 2016/679 (General Data Protection Regulation)," Official Journal of the European Union, 2016.

[6] European Data Protection Board, "Guidelines 4/2019 on Article 25 Data Protection by Design and by Default," 2020.

[7] International Organization for Standardization, "ISO/IEC 27001:2022 — Information Security Management Systems — Requirements," 2022.

[8] U.S. National Institute of Standards and Technology, "Special Publication 800-207: Zero Trust Architecture," S. Rose et al., 2020.

[9] D. F. Ferraiolo and D. R. Kuhn, "Role-Based Access Control," in Proc. 15th National Computer Security Conference, 1992, pp. 554–563.

[10] R. Sandhu, E. J. Coyne, H. L. Feinstein, and C. E. Youman, "Role-Based Access Control Models," IEEE Computer, vol. 29, no. 2, pp. 38–47, 1996.

[11] D. E. Bell and L. J. LaPadula, "Secure Computer Systems: Mathematical Foundations," MITRE Technical Report MTR-2547, 1973.

[12] J. H. Saltzer and M. D. Schroeder, "The Protection of Information in Computer Systems," Proc. IEEE, vol. 63, no. 9, pp. 1278–1308, 1975.

[13] L. Lamport, R. Shostak, and M. Pease, "The Byzantine Generals Problem," ACM Trans. Program. Lang. Syst., vol. 4, no. 3, pp. 382–401, 1982.

[14] M. Castro and B. Liskov, "Practical Byzantine Fault Tolerance," in Proc. 3rd Symp. Operating Systems Design and Implementation (OSDI), 1999, pp. 173–186.

[15] F. B. Schneider, "Implementing Fault-Tolerant Services Using the State Machine Approach: A Tutorial," ACM Comput. Surv., vol. 22, no. 4, pp. 299–319, 1990.

[16] A. Avizienis, J.-C. Laprie, B. Randell, and C. Landwehr, "Basic Concepts and Taxonomy of Dependable and Secure Computing," IEEE Trans. Dependable Secure Comput., vol. 1, no. 1, pp. 11–33, 2004.

[17] L. Lamport, Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers. Boston, MA: Addison-Wesley, 2002.

[18] D. Jackson, Software Abstractions: Logic, Language, and Analysis, rev. ed. Cambridge, MA: MIT Press, 2012.

[19] R. C. Merkle, "A Digital Signature Based on a Conventional Encryption Function," in Advances in Cryptology —

CRYPTO '87, Lecture Notes in Computer Science, vol. 293, Springer, 1988, pp. 369–378.

[20] W. Diffie and M. E. Hellman, "New Directions in Cryptography," IEEE Trans. Inf. Theory, vol. 22, no. 6, pp. 644–654, 1976.

[21] S. Haber and W. S. Stornetta, "How to Time-Stamp a Digital Document," J. Cryptology, vol. 3, no. 2, pp. 99–111, 1991.

[22] L. Sweeney, "k-Anonymity: A Model for Protecting Privacy," Int. J. Uncertainty, Fuzziness and Knowledge-Based Systems, vol. 10, no. 5, pp. 557–570, 2002.

[23] C. Dwork, "Differential Privacy," in Proc. 33rd Int. Conf. Automata, Languages and Programming (ICALP), 2006, pp. 1–12.

[24] A. Mosleh, "Common Cause Failures: An Analysis Methodology and Examples," Reliability Engineering & System Safety, vol. 34, no. 3, pp. 249–292, 1991.

[25] CDISC and HL7, "FHIR to CDISC Joint Mapping Implementation Guide," version 1.0.0, 2021.