Zero knowledge proof data platform

Abstract

A single- or multi-modal approach to converting data in the form of various standardized – and non-standardized – formats to types that are accepted by ZK proving systems is disclosed. three distinct approaches are described. The approaches involve dynamically or manually pulling criteria from standardized sources, such as ClinicalTrials.gov, from a study protocol document, or another first- or third-party source, and parsing it into a normalized structure which is then converted into a Merkle tree. The approaches also involve pulling health data from a variety of sources, including patient-mediated ones such as SMART-on-FHIR, TEFCA QHINs, and manually, to a personal mobile device, clinician's device such as a computer or measuring tool, or server environment including on-premises, private, and public clouds.

Description

Docket No. HUMI-0001.W001ZERO KNOWLEDGE PROOF DATA PLATFORMBACKGROUND

[0001] Most zero knowledge proving systems have significant limitations in the size and structure of inputs it can accept. This is particularly the case with zk-SNARKs and systems that are feasible to execute on consumer mobile devices, including smartphones. Furthermore, different proving systems excel at operating on certain elliptic curves and are inefficient on others. In-tum, data formats like FHIR utilize a record and bundle system, which includes a large number of nested fields which also makes them extremely large for direct input into some proving systems. In addition, most standardized data formats that incorporate publickey certificates and issuer signatures, including FHIR SMART Health Cards and W3C’s Verifiable Credentials, use the ECDSA elliptic curve, which is currently an effective industry standard. While very efficient for purposes that involve trusted parties and centralized platforms, it is not necessarily the best curve for creating privacy-preserving consensus mechanisms such as with a ZK-proof-based blockchain. These constraints make it desirable for a patient-mediated health data attestation system to efficiently operate on different curves, as appropriate for each step, while minimizing trusted parties and privacy compromises.BRIEF DESCRIPTION OF THE DRAWINGS

[0002] FIG. 1 depicts a drawing of an example of a Zero-Knowledge (ZK) proof data platform.

[0003] FIG. 2 depicts a drawing of an example of a ZK proof clinical system.

[0004] FIG. 3 depicts a drawing of an example of a minimal -touch, minimal -circuit system.

[0005] FIG. 4 depicts an on-device ZK circuit for a minimal -touch, minimal -circuit system.

[0006] FIG. 5 depicts a drawing of an example of a maximal -touch, single-circuit system.

[0007] FIG. 6 depicts an on-device ZK circuit for a maximal -touch, single-circuit system.

[0008] FIG. 7 depicts a drawing of an example of a hybrid, multi -circuit system.DETAILED DESCRIPTION

[0009] A claimed solution rooted in computer technology overcomes problems specifically arising in the realm of computer technology. In various embodiments, a computing system is configured to use Zero- Knowledge (ZK) proofs in a data management system. ZK proof computation on your own device allows you to prove to someone you know something without revealing the data itself. We can verify validity, compliance, and quality of study data, trial, or other context without revealing data. For example, a determination as to whether data has been collected can be made, then a proof that the data was properly collected can be generated then provided to another party without revealing it. For example, checks can be at a personal level, with personal data, sent to a block chain (assuming the implementation includes a block chain for the ZK proof) for audit to prove the data was properly collected.

[0010] Can automate several processes within clinical trials; centralized monitoring (a framework pushed by regulatory bodies such as the FDA as a means of overseeing clinical trial quality) / remote monitoring. Direct source verification (someone sits in site as data comes in; and verifies the data was properly collected)Docket No. HUMI-OOOLWOOl for centralized monitoring (though the process is decentralized in the sense verification can occur in different places) is generally used.

[0011] Private monitoring is a way to monitor quality of data without revealing any personal data and without centralized monitoring (e.g., a ZK proof is created where the data is provided, which is also where verification occurs using all applicable data). Private data can then be packaged for a purpose appropriate for its use within a given context. We have cryptography doing it for us, which gives the same benefits of central monitoring without the overhead and immense cost and gives you significantly more privacy and security, plus more visibility in the study. A human or artificial agent verifies the correct gathering of data. Locally (on-device) bifurcated quality monitoring and data collection (“private monitoring”) provides more visibility than any of the other approaches. Indeed, view access could be provided to the public because the ZK proofs prevent a reveal of the underlying personal data.

[0012] FIG. 1 depicts a drawing 100 of an example of a ZK proof data platform. The drawing 100 includes a ZK network 102, local ZK node 104 coupled to the ZK network 102, a sponsor device 106 coupled to the local ZK node 104, a wallet 108 coupled to the sponsor device 106, a view access datastore 110 coupled to the sponsor device 106, shared space 112, a local ZK node 114 coupled to the ZK network 102, a participant device 116 coupled to the local ZK node 114, a wallet 118 coupled to the participant device 116, a private data datastore 120 coupled to the participant device 116, a local ZK node 124 coupled to the ZK network 102, a regulator device 126 coupled to the shared space 112 and the local ZK node 124, and a wallet 128 coupled to the regulator device 126.

[0013] The ZK network 102 can be implemented as part of a network or, more generally, a computer- readable medium (CRM). Assuming a CRM includes a network, the network can be an applicable communications network, such as the Internet or an infrastructure network. The term “Internet” as used in this paper refers to a network of networks that use certain protocols, such as the TCP / IP protocol, and possibly other protocols, such as the hypertext transfer protocol (HTTP) for hypertext markup language (HTML) documents that make up the World Wide Web (“the web”). More generally, a network can include, for example, a wide area network (WAN), metropolitan area network (MAN), campus area network (CAN), or local area network (LAN), but the network could at least theoretically be of an applicable size or characterized in some other fashion (e.g., personal area network (PAN) or home area network (HAN), to name a couple of alternatives). Networks can include enterprise private networks and virtual private networks (collectively, private networks). As the name suggests, private networks are under the control of a single entity. Private networks can include a head office and optional regional offices (collectively, offices). Many offices enable remote users to connect to the private network offices via some other network, such as the Internet.

[0014] In operation, the ZK network 102 receives ZK proofs from ZK nodes, such as the local ZK nodes 104, 114, and 124. In a specific implementation, the ZK network 102 includes a ZK-snark-based blockchain (but alternatives may include ZK-stark or some other applicable technology); a ZK proof from a ZK node is added to the chain using its consensus mechanism in this specific implementation.Docket No. HUMI-OOOl.WOOl

[0015] The local ZK node 104 includes an engine that carries out functionality appropriate for a ZK node of a ZK node network, such as generating ZK proofs. For example, a local ZK node engine can generate a noninteractive ZK proof. In a specific implementation, the local ZK node 104 has direct connection to the ZK network 102 by serving as a pro ver in the ZK system.

[0016] The engines and datastores of the diagram 100 can be connected using a CRM. A CRM is intended to represent a computer system or network of computer systems. A “computer system,” as used herein, may include or be implemented as a specific purpose computer system for carrying out the functionalities described in this paper. In general, a computer system will include a processor, memory, non-volatile storage, and an interface. A typical computer system will usually include at least a processor, memory, and a device (e.g., a bus) coupling the memory to the processor. The processor can be, for example, a general- purpose central processing unit (CPU), such as a microprocessor, or a special-purpose processor, such as a microcontroller.

[0017] Memory of a computer system includes, by way of example but not limitation, random access memory (RAM), such as dynamic RAM (DRAM) and static RAM (SRAM). The memory can be local, remote, or distributed. Non-volatile storage is often a magnetic floppy or hard disk, a magnetic-optical disk, an optical disk, a read-only memory (ROM), such as a CD-ROM, EPROM, or EEPROM, a magnetic or optical card, or another form of storage for large amounts of data. During execution of software, some of this data is often written, by a direct memory access process, into memory by way of a bus coupled to nonvolatile storage. Non-volatile storage can be local, remote, or distributed, but is optional because systems can be created with all applicable data available in memory.

[0018] Software in a computer system is typically stored in non-volatile storage. Indeed, for large programs, it may not even be possible to store the entire program in memory. For software to run, if necessary, it is moved to a computer-readable location appropriate for processing, and for illustrative purposes in this paper, that location is referred to as memory. Even when software is moved to memory for execution, a processor will typically make use of hardware registers to store values associated with the software, and a local cache that, ideally, serves to speed up execution. As used herein, a software program is assumed to be stored at an applicable known or convenient location (from non-volatile storage to hardware registers) when the software program is referred to as “implemented in a computer-readable storage medium.” A processor is considered “configured to execute a program” when at least one value associated with the program is stored in a register readable by the processor.

[0019] In one example of operation, a computer system can be controlled by operating system software, which is a software program that includes a file management system, such as a disk operating system. One example of operating system software with associated file management system software is the family of operating systems known as Windows from Microsoft Corporation of Redmond, Wash., and their associated file management systems. Another example of operating system software with its associated file management system software is the Linux operating system and its associated file management system. The file management system is typically stored in the non-volatile storage and causes the processor to executeDocket No. HUMI-0001.W001 the various acts required by the operating system to input and output data and to store data in the memory, including storing files on the non-volatile storage.

[0020] The bus of a computer system can couple a processor to an interface. Interfaces facilitate the coupling of devices and computer systems. Interfaces can be for input and / or output (I / O) devices, modems, or networks. I / O devices can include, by way of example but not limitation, a keyboard, a mouse or other pointing device, disk drives, printers, a scanner, and other I / O devices, including a display device. Display devices can include, by way of example but not limitation, a cathode ray tube (CRT), liquid crystal display (LCD), or some other applicable known or convenient display device. Modems can include, by way of example but not limitation, an analog modem, an IDSN modem, a cable modem, and other modems. Network interfaces can include, by way of example but not limitation, a token ring interface, a satellite transmission interface (e.g. “direct PC”), or other network interface for coupling a first computer system to a second computer system. An interface can be considered part of a device or computer system.

[0021] Computer systems can be compatible with or implemented as part of or through a cloud-based computing system. As used in this paper, a cloud-based computing system is a system that provides virtualized computing resources, software and / or information to client devices. The computing resources, software and / or information can be virtualized by maintaining centralized services and resources that the edge devices can access over a communication interface, such as a network. “Cloud” may be a marketing term and for the purposes of this paper can include any of the networks described herein. The cloud-based computing system can involve a subscription for services or use a utility pricing model. Users can access the protocols of the cloud-based computing system through a web browser or other container application located on their client device.

[0022] A computer system can be implemented as an engine, as part of an engine, or through multiple engines. As used in this paper, an engine includes at least two components: 1) a dedicated or shared processor or a portion thereof; 2) hardware, firmware, and / or software modules executed by the processor. A portion of one or more processors can include some portion of hardware less than all of the hardware comprising any given one or more processors, such as a subset of registers, the portion of the processor dedicated to one or more threads of a multi -threaded processor, a time slice during which the processor is wholly or partially dedicated to carrying out part of the engine’s functionality, or the like. As such, a first engine and a second engine can have one or more dedicated processors, or a first engine and a second engine can share one or more processors with one another or other engines. Depending upon implementation-specific or other considerations, an engine can be centralized, or its functionality distributed. An engine can include hardware, firmware, or software embodied in a computer-readable medium for execution by the processor. The processor transforms data into new data using implemented data structures and methods, such as is described with reference to the figures in this paper.

[0023] The engines described in this paper, or the engines through which the systems and devices described in this paper can be implemented as cloud-based engines. As used in this paper, a cloud-based engine is an engine that can run applications and / or functionalities using a cloud-based computing system. All or portions of the applications and / or functionalities can be distributed across multiple computing devicesDocket No. HUMI-0001.W001 and need not be restricted to only one computing device. In some embodiments, the cloud-based engines can execute functionalities and / or modules that end users access through a web browser or container application without having the functionalities and / or modules installed locally on the end-users’ computing devices.

[0024] As used in this paper, datastores are intended to include repositories having any applicable organization of data, including tables, comma-separated values (CSV) fries, traditional databases (e.g., SQL), or other applicable known or convenient organizational formats. Datastores can be implemented, for example, as software embodied in a physical computer-readable medium on a general- or specific-purpose machine, in firmware, in hardware, in a combination thereof, or in an applicable known or convenient device or system. Datastore-associated components, such as database interfaces, can be considered “part of’ a datastore, part of some other system component, or a combination thereof, though the physical location and other characteristics of datastore-associated components is not critical for an understanding of the techniques described in this paper.

[0025] Datastores can include data structures. As used in this paper, a data structure is associated with a way of storing and organizing data in a computer so that it can be used efficiently within a given context. Data structures are generally based on the ability of a computer to fetch and store data at any place in its memory, specified by an address, a bit string that can be itself stored in memory and manipulated by the program. Thus, some data structures are based on computing the addresses of data items with arithmetic operations, while other data structures are based on storing addresses of data items within the structure itself. Many data structures use both principles, sometimes combined in non-trivial ways. The implementation of a data structure usually entails writing a set of procedures that create and manipulate instances of that structure. The datastores, described in this paper, can be cloud-based datastores. A cloud based datastore is a datastore that is compatible with cloud-based computing systems and engines.

[0026] Referring once again to the example of FIG. 1, the local ZK node 104 is “local” with respect to the sponsor device 106 (e.g., the local ZK node 104 may be on the sponsor device 106). For example, if the local ZK node 104 is on the sponsor device 106, the local ZK node engine can generate a noninteractive ZK proof on-device (meaning, in this instance, on the sponsor device 106).

[0027] Depending upon the context in which the ZK network 102 is used, a sponsor could be a pharma company, a financial institution, a marketing company, or some other entity with an interest in viewing data used to generate ZK proofs that are provided to the ZK network 102. For illustrative purposes, a healthcare- related example is assumed for much of the description provided below. As such, the term “study” is used to describe instances in which the ZK proofs are used in a healthcare-related study, but the term “study” might be changed to some other term in a different context.

[0028] The sponsor device 106 can be implemented as a computer system, such as a mobile device, desktop computer, workstation, or other applicable device. A single sponsor entity, or a single agent of the entity, may or may not have multiple devices suitable for use as the sponsor device 106, each of which may have a separate, shared, or partially separated and partially shared datastore relevant to the ZK functions described in association with FIG. 1. The various devices may also have distinct, shared, or partially sharedDocket No. HUMI-OOOl.WOOl engines. For illustrative purposes, the sponsor device 106 is treated as a device that has access to all applicable datastores and engines of a sponsor.

[0029] At least conceptually, the wallet 108 has a unique identifier (UID) and a collection of UIDs of other wallets and data items associated with those other wallets. The specific manner in which wallets identify other wallets (e.g., as a whitelist) or data items (e.g., as a direct or indirect ID) is usually implementationspecific, though it need not be. It is typically up to the device that gathers data to create the whitelists, etc., which may be shareable by other ZK nodes. For illustrative purposes, a data item is treated as “view access” data if a wallet includes access to it, though in various implementations the permissions could include other types of access permissions. In the examples provided in this paper, view access is assumed to give an entity the ability to share the data with other entities via permissions in applicable wallets. For example, once a data item has been whitelisted for an entity, that entity can whitelist the data item for other entities in the ZK network.

[0030] The view access datastore 110 includes data associated with ZK proofs of the ZK network 102 for which the sponsor device 106 has permission to view, as determinable from the wallet 108. There is no technological prohibition against the sponsor device to be treated as a participant device (described below), which would mean a datastore on the sponsor device 106 or to which the sponsor device 106 has access may include more than just view access data, either for the same study or for a different one. There is similarly no technological prohibition against the sponsor device to be treated as a regulator device (described below), though that could lead to some non-technological incompatibilities with at least some studies, such as if a pharmaceutical company was a sponsor and the Food and Drug Administration (FDA) was a regulator.

[0031] Optionally, the sponsor device 106 can be coupled to the shared space 112, which can be implemented in a cloud. The shared space 112 would typically be shared with the regulator device 126 but could be shared with other sponsors in alternatives. A sponsor can prepare documents, data, protocols, etc. (collectively “prepared sponsor data”), which can include eCTD, doc, PDF, xl, db, and other formats. The data used to prepare documents would be in a datastore (not shown). The prepared sponsor data is uploaded by the sponsor device 106 (or another sponsor device) to the shared space 112. The discussion of shared space 112 is continued below with reference to the regulator device 126.

[0032] The local ZK node 114 is “local” with respect to the participant device 116 (e.g., the local ZK node 114 may be on the participant device 116). The participant device 116 and wallet 118 can be like the sponsor device 106 and wallet 108, but due to the role of the participant relative to the sponsor, the configurations may be different. For example, the participant device 116 may collect private data (e.g., in accordance with data collection protocols set by the sponsor or regulator that are communicated via the sponsor or regulator wallet permissions) that would not be collected by a sponsor or regulator.

[0033] In a specific implementation, the private data datastore 120 includes a Personal Health Information (PHI) encrypted datastore (e.g., data that has been directly entered by the user or an agent thereof; a local Fast Healthcare Interoperability Resources (FHIR) / U.S. Core Data for Interoperability (USCDI) Electronic Health Record (EHR) datastore from EHR providers, such as Epic, Allscripts, or Athenahealth, which is what a clinic or hospital may use to store EHR or electronic medical record (EMR), obtained via publicly-Docket No. HUMI-0001.W001 available APIs and a patient-facing portal; and / or a local wearable data datastore containing data associated with a wearable device communicated from the wearable device via near-field communications technology, including a transmitter on the wearable device and a receiver on the user device). ZK proofs use private data to generate proof of such data. These proofs are sent from the ZK node 114 to the ZK network 102, which, depending upon the implementation, may include putting the proofs on a blockchain.

[0034] The regulator device 126 includes a local ZK node 124 (which in this case is local to the regulator device 124), and a wallet 128 (which includes permissions for one or more studies or collections of events). The regulator device 126 could be under the control of the food and drug administration (FDA), an institutional review board (IRB), or the like. In a specific implementation, permissions for the wallet 128 are set by a study team, providing, e.g., read access to adverse event records, protocol adherence records, patient data entry records, site data entry records, etc. The wallet 128 can be implemented as, for example, a browser extension.

[0035] In an implementation that includes a shared space, the regulator device 126 can communicate with the sponsor device 106 via the shared space 112. For example, the sponsor device 106 can upload prepared documents to the shared space 112 for review by the regulator and the regulator can upload instructions (e.g., requests for additional documentation, requests to modify protocols, etc.) for consideration by the sponsor. In a specific implementation, the regulator owns the shared space 112 (stored in the cloud), but the regulator may have other relevant data that might be applicable to provisioning via ZK proof to the ZK network (datastore not shown). There is no technological reason the regulator could not maintain a datastore of private data that is controlled and distributed via the ZK network.

[0036] If further security is desired, the sponsor may treat data provided to the shared space as private data, sending ZK proofs of the data and ZK proofs associated with actions that have been taken. In this implementation, the shard space can be considered (or actually be) part of the ZK network 102.

[0037] On an ongoing basis, participants can participate in a study, maintaining private data on their participant devices while ZK proofs associated with data collection can be monitored by sponsors in real time to ensure data collection and other protocols of the study are being properly observed. A regulator can do the same, potentially with a different data set. There can be levels of access that vary depending upon the participant, sponsor, and / or regulator.

[0038] It should be noted there can be a great many different sponsors for different studies on the same ZK network. There may be more than one regulator if there are multiple different studies, as well. There may also be multiple participants for each study, potentially overlapping across different studies. Private data associated with ZK proofs provided in a first study context may be relevant to a second study, which may enable a sponsor to identify an appropriate participant for enrollment in a new study. Advantageously, the participant can retain ownership of the private data and decide whether to share it.

[0039] FIG. 2 depicts a drawing 200 of an example of a ZK proof clinical system. In this example, Zero Knowledge Succinct Non-interactive Argument of Knowledge (ZK-SNARK) is used for illustrative purposes. The drawing 200 includes a clinical platform 202 with a ZK-SNARK blockchain 204, a clinician device 206 with a clinical microservice 208, a patient device 210 with a clinical microservice 212, and anDocket No. HUMI-0001.W001 electronic data capture (EDC) engine 214 with a clinical microservice 216. The clinical microservices 208, 212, and 216 provide ZK proofs associated with data collected at the clinician device 206, patient device 210, and EDC engine 214, respectively, in response to relevant protocols received by the devices from the clinical platform 202 (and which can instead or in addition be received as ZK proofs via clinical microservice). The clinical platform can include a LEO program on a blockchain (e.g., a circuit), and the clinical microservices on various devices can download the program.

[0040] In a specific implementation, the clinician device 206 includes a Clinical Trial Management System (CTMS). The CTMS can show a clinician what data has been properly collected for a patient and where a patient is in atrial timeline, taking into account previously completed tests and tests completed for the current trial. It will also check to see if the data itself was properly generated. For example, if a survey, the ZK proof can provide sufficient information to know if the appropriate app was used; if data from a wearable device, the ZK proof can provide sufficient information to know from what kind of wearable device the data was obtained; etc. The engines used to enable these two mechanisms (confirming data was collected and confirming data was collected appropriately) can be referred to collectively as a gate integrity engine. The blockchain can also be used to flag when a test is done that is not supposed to be done (e.g., if a step was skipped or the test is not part of the protocol at all).

[0041] Monitoring the blockchain can be accomplished via a clinical dashboard, for which permissions can be granted as appropriate. Data acquired from the monitoring can be packaged for presentation to participants, as appropriate for the participant.

[0042] Could use any Layer 2 (or higher) ZK blockchain (any blockchain that can include ZK functionality aka “ZK Rollup Blockchain”) with a ZK circuit. ZK-SNARK, ZK-STARK, ZKVM, and ZK-SYNCH are different flavors of implementing zero-knowledge proofs into blockchain. In the analogy of bitcoin, you have a ledger and notes (metadata); balance is part of the core consensus protocol. ZK Proof is not a note; it is part of the core consensus protocol. Aspects of the technology described in this paper are also applicable to Layer 1 ZK blockchains (any blockchain that includes ZK Proof as part of core consensus mechanism) or “ZK Proof circuit.”

[0043] API is a common language to describe a study protocol. For example, the following flow can be followed: Study Protocolconversion engineLEO program (lives on the blockchain and is populated to all applicable devices). This may or may not be possible for all study protocols. Specifically, the number of LEO programs may be less than the number of study protocols. The conversion engine can convert a study protocol from any applicable format (paper or digital).

[0044] CRFs have been paper-based, with manual transcription on site. There is a lot of error and fraud that takes place in transcription at a site. Fraud and error are generally untraceable. A trustless system that removes human intervention where the data is generated for a clinical trial will be much more difficult to trick, whether due to error or fraud. There are also clinician outcome assessments that can be completed on a device with a clinical microservice for gate integrity, ensuring the right data is collected at the right time by the right person, for example. This can also include historical comparisons (e.g., detecting if a clinician copies and pastes portions from a previous trial into the current trial or enters data that appears to deviateDocket No. HUMI-OOOl.WOOl from what is expected; the comparisons can be characterized as finding data to be acceptable if it falls within the bounds of two similarity thresholds).

[0045] There is an exacerbated need for remote monitoring. There are a lot of electronic sources of data that can contribute to trials in comparison to conventional where a patient visits a clinic to get a trial done. With any trial, quality is important, requiring integrity regarding compliance to protocols and compliance to regulatory requirements. There are barriers to sharing critical variables between trials. The industry wants to move to decentralized global trial framework for trials but need data collection validation, as opposed to simple data collection with post hac quality checking. Patients can be empowered with privacy and instant data return and patient devices can be empowered with data collection validation.

[0046] The clinical microservices 208, 212, 214 are provided to relevant parties to the clinical system. It can be a plugin. WebAssembly (WASM) enables us to run programs of the CPU that is running it from the web and can be used to generate ZK proofs. Graphics Processing Unit (GPU) for the Web (WEBGPU) is a layer on top of that for extra features. Advantageously, because WASM and WEBGPU are industry standards, it can be expected to work on most devices. This can increase the probability microservices are placed as close as possible to the data source and to the data repository. It should be noted it is not always possible to achieve adoption, so cloud-based microservices may be used instead, which would keep the microservices on devices that have an app (e.g., a patient device) but sponsors, regulators, etc. may not be inclined to use an app, making it necessary to move microservices off the device(s).

[0047] Microservice will prevent upload to the blockchain for errors that can be localized. In theory, each device could have a copy of the ZK circuit but in practice, that isn’t as useful as just uploading and letting the blockchain decide.

[0048] From the perspective of a participant in any study, your device is coupled to, in the context of health records, various EHR datastores, such as from clinics and hospitals. The participant can pull data from any EHR datastore and provide to another EHR datastore. So, the participant becomes a master of their records and each potential EHR datastore gets those records the participant allows them to have. The participant is similarly coupled to a plurality of EDC engines of various sponsors. Advantageously, the data just “shows up” where permissions are granted. There is no need for scanning, sending emails, etc. This may be referred to as instant data return, which remains near the top of the list for unmet or not adequately met patient demands. (Incentive programs also need to be figured out to encourage seamless sharing with instant data return.)

[0049] It may be noted data can be pulled to a client device but is stored encrypted identifiable by default. Identifiability is important so the client knows what data they want to share. A patient may be granted permission to access patient’s own data after a study is complete. The patient can then (or later) send the data to an EHR destination or other destination. In this way, e.g., a physician would instantly gain access to the data that was shared. In some instances, a patient may not be allowed to see the data (e.g., because blinded for a study), but could still send it on to a physician (who might receive a notification that the data cannot be shared with the patient). An example of immediate patient data return would be if a sponsor discovered a medical emergency in data to which a patient was blinded, the sponsor could send the data toDocket No. HUMI-OOOl.WOOl the patient’s physician. If it is something particularly dangerous, the physician may have the authority to reveal it to the patient. Adverse effects, anomalies, etc. can be prime candidates for immediate patient return. IRB typically controls where data needs to be sent and when, which can be accomplished immediately using the techniques described in this paper; no telephone calls, fax of data, etc. (a very manual process currently). Immediate patient return can also be directly to the patient (as opposed to the physician). Patient return can also be provided at the end of the study, at some time after the study ends, at some interval within the study, etc. Thus, when a patient is subjected to a blind, the patient can be told why the data is locked and when the data will be unlocked.

[0050] Because a patient is in control, they can obtain compensation for sharing their data with any applicable party, such as potential sponsors. (And there are sponsors willing to pay for it.) The data is suitable for reproduction, which can decrease costs for future sponsors who can acquire it from patients that would provide the same data and / or data using the same protocols. Because attributes of data can be made queryable, identification of data with specificity is possible.

[0051] The EDC engines of sponsors gather information, but they need auditors to identify and deal with errors in the data, CRFs, and compare EDC data to CRF. Mismatches are relatively common, and it is not obvious who is the source of truth. Post hac error correction is inferior to instant (correct) data return. We verify data and also verify, when the data shows up, what it was. By putting the data back up on the blockchain, an alert can be generated immediately, without waiting for auditors to do the job. Integrity (data collected correctly) and validation (was it done correctly, matching other stuff, and was it done the right way); validation can be interrelated with previous data, allowing the detection of errors that would otherwise have been missed, such as if a test was done properly but was done out of order.

[0052] In the analogy of bitcoin, you have balance going into a transaction; you might have a note, such as a timestamp or description. When the “balance” changes over time, the chain of events provides visibility into the entire path. If somebody screws with the balance, it would be noticed. If someone screws with a note, it would only be noticed if checked. The ZK proofs described in this paper can use the “notes” as part of the consensus mechanism. So, if something is done wrong, the blockchain will fail to do anything else.

[0053] An example of trustless product verification can be understood using the following example.

[0054] Proof A: Drug administered

[0055] Proof B: Wearable sample

[0056] Proof C: X-ray

[0057] Proof D: Clinical outcome assessment

[0058] Proof E: Protocol amendment

[0059] Proof F: Adverse event handled by site

[0060] Proof G: Interim data review

[0061] Proof H: Journal article

[0062] Proof I: Study team submission

[0063] Proof J: IRB review process

[0064] Proof K: FDA review processDocket No. HUMI-OOOl.WOOl

[0065] Proof A + Proof B + Proof C = Proof ABC (study data collection); Proof D + Proof E + Proof F = Proof DEF (study events); Proof G + Proof H = Proof GH (data analysis); and Proof I + Proof J + Proof K = Proof UK (regulatory). Proof ABC + Proof DEF + Proof GH + Proof UK = Proof of product’s overall safety and efficacy.

[0066] Study Definition Repository (SDR) within the Digital Data Format (DDF) is poised to become a standard. It is desirable to use standards, whatever they may be, for the purpose of adoption of the technological solutions provided. So SDR may allow us to receive more study protocols. The patient data marketplace concept can be more generally applied across any personal data (purchases, emails, usage data, documents created, etc.), as described by way of example in this paper. Techniques described in this paper allow not only personal data ownership, but agency over such data.

[0067] A multi-modal approach can be used to convert data in the form of various standardized and nonstandardized formats to types that are accepted by ZK proving systems. Herein described are three distinct approaches based on constraints of an end user device, the specific application of the method, and the environment in which it is being applied. In these examples, all three approaches involve dynamically or manually pulling criteria from standardized sources, such as ClinicalTrials.gov, from a study protocol document, or another first- or third-party source, and parsing it into a normalized structure which is then converted, by way of example, into a Merkle Tree. In most methods explored here, this occurs on the serverside to maximize efficiency on the end user device and is then dynamically or manually downloaded to the device on which health records are stored. All approaches also involve pulling health data from a variety of sources, including patient-mediated ones such as SMART-on-FHIR, TEFCA QHINs, and manually, to an end user device, such as a patient’s personal device, a clinician’s computer, or a measuring tool, or server environment including on-premises, private, and public clouds.

[0068] Other elements shared by these approaches are: 1. Applicability to health data in various standardized and custom formats, including FHIR, HL7, OMOP, C-CDA, Apple Health data including Verifiable Health Records, custom Humine™-designed data formats, and other emerging and future data formats that are in various stages of standardization. 2. Applicability to various formats of attestation criteria in standardized and custom formats, including FHIR’s Research Study, FHIR R6’s StudyEligibilityCriteria, HL7 Group and Evidence Variable profiles, CQL and other phenotyping languages and formats, OMOP queries and ETL processes, custom Humine™-de signed formats, terminology and content standards such as LOINC and SNOMED, and other emerging and future data formats that are in various stages of standardization. 3. Hashing original payloads as received by data sources, including in the form of FHIR resources. 4. Generating nullifiers for each record that is correlation-attack resistant by ensuring fixed length values and robust device-bound sources of entropy data. Nullifiers ensure that records are only able to be owned by one user while the system also being resistant to users forgetting login credentials by losing their passwords manager. Nullifiers are later sent to a blockchain or other data storage systems such a centralized database, based on the specific application or environment. 5. Verifying the provided signature / certificate of the record, if available from record types such as FHIR Health Cards or W3C Verifiable Credentials, with the issuer’s public key downloaded in the record retrieval process. Depending on the original record, itsDocket No. HUMI-0001.W001 source, the type of signature / certificate, scenario the approach is applied in, and said approach, this is conducted within a ZK circuit or outside of it. 6. Proving core attestation statements using each approach’s respective inputs while employing leading cryptographic methods such as Merkle-inclusion-proofs, parse- Merkle-trees, range-proofs, predicate-proofs, and more as appropriate for each attestation request’s criteria and its operating environment.

[0069] FIG. 3 depicts a drawing 300 of an example of a minimal -touch, minimal-circuit system. The minimal-touch, minimal-circuit approach is advantageous in scenarios in which certain parties can be trusted, including an application provider, such as Humine. The drawing 300 includes a first ZK proof external data source 310, a criteria external data source 320, a verification server 330 coupled to the first ZK proof external data source 310 and the criteria external data source 320, a health records external data source 340, and a verification client 350 coupled to the health records external data source 340 and the first ZK proof external source 310.

[0070] The verification server 330 represents an engine that includes a first ZK circuit 332 and a criteria transformation engine 334, the latter of which includes, standardized criteria data 336, normalized criteria 337, and a normalized criteria Merkle tree 338. The components 336 to 338 include datastores and engines for processing data into the indicated format in turn, starting with data from the criteria external data source 320.

[0071] The verification client 350 represents an engine that includes a normalized criteria Merkle tree 352, a standardized data format 354, an issuer public key 356, a field parsing engine 358, a record hashing engine 360, a signature verification engine 362, a data Merkle tree 364, a bundle hash commitment 366, a devicebound entropy 368, and a first ZK circuit 370. The components 352, 354, 356, 364, 366, and 368 at least include a datastore with the data indicated by the label. The first ZK circuit is illustrated in more detail with reference to FIG. 4.

[0072] FIG. 4 depicts a drawing 400 of an example of an on-device ZK circuit for a minimal -touch, minimal -circuit system. The drawing 400 illustrates a circuit suitable for use as a ZK circuit, such as the first ZK circuit 370 of FIG. 3. The drawing 400 includes a normalized criteria Merkle tree 402, a data Merkle tree 404, a bundle hash commitment 406, device-bound entropy 408, a first ZK circuit 370, a criteria Merkle Root 416, a first ZK proof coupled to the first ZK circuit 370, and a nullifier 420. The components 402 to 408 and 416 to 420 at least include a datastore with the data indicated by the label.

[0073] The first ZK circuit 370 includes a Merkle root computation engine 410, an attestation requirements confirmation engine 412, and a nullifier generation engine 414. The Merkle root computation engine 410 has access to the normalized criteria Merkle tree and provides the criteria Merkle root 416 as output. The attestation requirements confirmation engine has access to the normalized criterial Merkle tree 402 and the data Merkle tree 404 and confirms attestation requirements. The nullifier generation engine 414 has access to the bundle hash commitment 406 and the device-bound entropy 408 and provides the nullifier 420 as output.

[0074] The minimal-touch, minimal-circuit approach involves hashing a health data record, originally in forms such as FHIR, OMOP, etc. to produce a hash commitment. The approach also includes generating aDocket No. HUMI-OOOl.WOOl unique nullifier using the hash commitment and a device -bound entropy value, and, if available, verifying the provided signature / certificate of the record.

[0075] The approach also includes parsing the record into a normalized structure that includes only the fields that are necessary for the criteria being applied and mirrors the structure of said criteria. This parsing occurs on-device but is conducted outside of a ZK circuit as certain devices, particularly lower-end personal mobile phones, cannot execute circuits in a timely manner which necessitates the prioritization of proving to what is most vital to trust and privacy. Converted the normalized structure into a Merkle Tree, again mirroring its counterpart on the criteria side.

[0076] The health data and criteria Merkle trees, hash commitment, and nullifier are provided as input to ZK Circuit 1. The circuit’s Proving Function 1 compares the two Merkle trees utilizing the aforementioned cryptographic methods as appropriate. The criteria Merkle tree is used to compute its Merkle root. If appropriate of the use case and used in conjunction with a blockchain that involves ZK proofs as part of its core consensus mechanism, the proof is sent in a transaction while the criteria Merkle root, nullifier and hash commitment are stored as public mappings with Merkle roots or plainly. Alternatively, these values are stored in another data storage system, such as a data vault, database, etc.

[0077] On an attribution requester’s system / device: ZK Circuit 1 is embedded on the device along with its ZK proving system. The approach includes retrieving proof and other related data from either ZK Circuit 1’s blockchain, near-field communications like NFC, Bluetooth, or QR code, or other data storage system. The system also operates dynamically after being triggered by relevant changes on the blockchain or data storage system.

[0078] Verify ZK Proof 1 by calling the verify command using a Verifying Key (if applicable to the proving system): This takes proof ZK Proof 1, and the public input, criteria Merkle tree, which is sourced from the device / server / system (likely the same source as initially downloaded to the patient / record owner’s device) as input to verify that this criteria was used by the prover to generate ZK Proof 1 and the prover had the necessary data to satisfy the requirements. This confirms to the requester that the patient / health record owner satisfies the criteria posed.

[0079] A benefit with this approach is it is the most efficient of the examples provided in this paper and requires the least amount of processing power. It is most effective in environments where there are parties that can be trusted to perform parsing operations and signature verification, reducing the load taken by the ZK circuit itself. It is also effective in multi-elliptic-curve applications, where the initial health record has an issuer, such as a healthcare provider’s EHR or government agency signing W3C verifiable credentials in the form of FHIR SMART Health Cards. The verification of the signature occurs on-device using publickeys that are available from the issuer. The drawback is a larger Trusted Computing Base (TCB) may be required, which increases the attack surface but is also less trust-less which is not an ideal long-term solution for maximum patient trust and hence it may be used as a stop-gap until ZK proving systems include multiple elliptic curves, public -private-key encryption standards evolve to ones that are more applicable to ZK systems, and as devices gain more processing power and ASICs designed for ZK proving.Docket No. HUMI-0001.W001

[0080] FIG. 5 depicts a drawing 500 of an example of a maximal -touch, single-circuit system. The maximal -touch, single-circuit approach is advantageous in scenarios in which almost no parties can be trusted, including the application provider. The key differentiation with this approach compared to the other two illustrative approaches described in this paper is that it is the most trustless one, where entire raw records are provided as input to a single ZK circuit with minimal pre-processing. The drawing 500 includes a first ZK proof external source 510, a criteria external data source 520, a verification server 530 coupled to the first ZK proof external data source 510 and the criteria external data source 520, a health records external data source 540, and a verification client 550 coupled to the health records external data source 540 and the first ZK proof external source 510.

[0081] The verification server 530 represents an engine that includes a first ZK circuit 532 and a criteria transformation engine 534, the latter of which includes, standardized criteria data 536, normalized criteria 537, and a normalized criteria Merkle tree 538. The components 536 to 538 include datastores and engines for processing data into the indicated format in turn, starting with data from the criteria external data source 520.

[0082] The verification client 550 represents an engine that includes a normalized criteria Merkle tree 552, a standardized data format 554, an issuer public key 556, a field parsing engine 558, a record hashing engine 560, a signature verification engine 562, a data Merkle tree 564, a device-bound entropy 568, and a first ZK circuit 570. (The components 558 to 564 are depicted as components of the first ZK circuit 570.) The components 552, 554, 556, 564, and 568 at least include a datastore with the data indicated by the label. The first ZK circuit is illustrated in more detail with reference to FIG. 6.

[0083] FIG. 6 depicts a drawing 600 of an example of an on-device ZK circuit for a maximal -touch, singlecircuit system. The drawing 600 illustrates a circuit suitable for use as a ZK circuit, such as the first ZK circuit 570 of FIG. 5. The drawing 600 includes a normalized criteria Merkle tree 602, a data Merkle tree 604, a bundle hash commitment 606, device-bound entropy 608, a first ZK circuit 570, a criteria Merkle Root 616 provided as a public mapping to the first ZK proof external datastore 510, a first ZK proof coupled to the first ZK circuit 570 and provided as a proof forms consensus to the first ZK proof external datastore 510, a nullifier 620 provided as a public mapping to the first ZK proof external datastore 510, and a bundle hash commitment 666 provided as a public mapping to the first ZK proof external datastore 510. The components 602 to 608, 616 to 620, and 666 at least include a datastore with the data indicated by the label.

[0084] On a patient or health record owner’s device, a raw health data record, originally in the forms of FHIR, OMOP, etc. is converted into a large single type or format, appropriate for the ZK proving system being used. In addition to the raw record, a device-bound entropy value, issuer public-key (if applicable), criteria Merkle tree, and other external data is provided as input to a single ZK-circuit, ZK Circuit 1. The ZK Circuit 1’s proving function is for hashing the health data record to produce a hash commitment, generating a unique nullifier using the hash commitment and the entropy value, and, if available, verifying a provided signature / certificate of the record. Ideally, the ZK proving system would natively support acceleration of the signature / certificate ’s elliptic curve.Docket No. HUMI-OOOl.WOOl

[0085] You can then parse the record into a normalized structure that includes only the fields that are necessary for the criteria being applied and mirrors the structure of said criteria and convert the normalized structure into a Merkle Tree, again mirroring its counterpart on the criteria side. The health data record and criteria Merkle trees are compared using the aforementioned cryptographic methods as appropriate. The criteria Merkle tree is used to compute its Merkle root. If appropriate of the use case and used in conjunction with a blockchain that involves ZK proofs as part of its core consensus mechanism, the proof is sent in a transaction while the criteria Merkle root, nullifier, and hash commitment are stored as public mappings with Merkle roots or plainly. Alternatively, these values are stored in another data storage system, such as a data vault, database, etc.

[0086] On the attribution requester’s system / device: ZK Circuit 1 is embedded on the device along with its ZK proving system. Proof and other related data are retrieved from either ZK Circuit 1’s blockchain, near-field communications like NFC, Bluetooth, or QR code, or other data storage system. This system also operates dynamically after being triggered by relevant changes on the blockchain or data storage system. ZK Proof 1 can be verified by calling the verify command using a Verifying Key (if applicable to the proving system). This takes proof ZK Proof 1, and the public input, criteria Merkle tree, which is sourced from the device / server / system (likely the same source as initially downloaded to the patient / record owner’s device) as input to verify that this criteria was used by the prover to generate ZK Proof 1 and the prover had the necessary data to satisfy the requirements . This confirms to the requester that the patient / health record owner satisfies the criteria posed.

[0087] The maximal -touch, single-circuit approach is the most trustless as it performs almost all operations within a ZK circuit. It ensures that records used for responding to the attestation request are not mutated or injected with other external data by the application provided during the proving process. Although the most robust and trustless approach, it also requires the most compute power and would rely on hardware acceleration provided by ZK-specific ASICs embedded within the device to feasibly be applied to real-word contexts using current over-the-counter technology, especially for personal mobile devices. This is desirable to the extent other approaches could be considered stop-gap measures while compute and standards progress to accommodate this approach to trust-less attestation for healthcare data.

[0088] FIG. 7 depicts a drawing 700 of an example of a hybrid, multi-circuit system. The hybrid, multicircuit approach is advantageous for balancing privacy and trustlessness with performance. It leverages two or more different ZK proving systems to achieve a result that is the most trustless, save for a single -circuit all-encompassing approach of the prior one, while relying on software optimizations on consumer-grade CPUs. GPUs, Secure Enclaves, and Neural accelerators to deliver performance. The drawing 700 includes a first ZK proof external data source 710, a criteria external data source 720, a verification server 730 coupled to the first ZK proof external data source 710 and the criteria external data source 720, a health records external data source 740, and a verification client 750 coupled to the health records external data source 740 and the first ZK proof external source 710.

[0089] The verification server 730 represents an engine that includes a first ZK circuit 732, a second ZK circuit 733, and a criteria transformation engine 734, the latter of which includes, standardized criteria data,Docket No. HUMI-0001.W001 normalized criteria, and a normalized criteria Merkle tree. The components of the criteria transformation engine 734 include datastores and engines for processing data into the indicated format in turn, starting with data from the criteria external data source 720. See FIGS. 3 and 5 for an illustration of the components in a criteria transformation engine.

[0090] The verification client 750 represents an engine that includes a normalized criteria Merkle tree 752, a standardized data format 754, an issuer public key 756, a data Merkle tree 764, a bundle hash commitment 766, a device-bound entropy 768, a second ZK proof 769, a first ZK circuit 770 that provides the second ZK proof 769, a first ZK circuit 780, a criteria Merkle root 792, a first ZK proof 794 that is provided by the first ZK circuit 780 to the first ZK proof external data source 710 as a proof forms consensus, a nullifier 796, and a second ZK proof 798 provided by the first ZK circuit 780 to the first ZK proof external data source 710 as a public mapping. The components 752, 754, 756, 764, 766, 768, and 769 at least include a datastore with the data indicated by the label. The second ZK circuit 770 includes a field parsing engine 758 that provides the data Merkle tree 764, a record hashing engine 760 that provides the bundle hash commitment 766, and a signature verification engine 762 that provides a record signature verification result. The first ZK circuit 780 includes a Merkle root computation engine 782 that has access to the normalized criteria Merkle tree 752 and provides the criteria Merkle root to the first ZK proof external data source 710 as a public mapping, an attestation requirements confirmation engine 784 that has access to the normalized Merkle tree and the data Merkle tree and provides an attestation requirements confirmation result, and a nullifier generation engine 786 that has access to the bundle hash commitment 766 and the device-bound entropy 768 and provides the nullifier 796 to the first ZK proof external data source 710 as a public mapping.

[0091] The hybrid, multi-circuit approach refers to ZK Circuit 2 as the initial circuit of which’s proving system is better optimized for operating on the issuer’s signature / certificate’s elliptic curve and is better optimized for parsing large data in raw format. ZK Circuit 1 is the final circuit that conducts the attestation checks and, optionally, is associated with a blockchain that can form a consensus on its proofs. On the patient or health record owner’s device, the raw health data record, originally in the forms of FHIR, OMOP, etc. is converted into a large single type or format, appropriate for ZK Circuit 2’s proving system. In addition to the raw record, an issuer public-key (if applicable), a criteria Merkle tree, and other external data is provided as input to ZK Circuit 2’s proving function, within which the health data record is hashed to produce a hash commitment and, if available, a provided signature / certificate of the record is verified. Ideally, this ZK proving system would natively support acceleration of the signature / certificate’s elliptic curve. The record is parsed into a normalized structure that includes only the fields that are necessary for the criteria being applied and mirrors the structure of said criteria. The normalized structure is converted into a Merkle Tree, again mirroring its counterpart on the criteria side. The proving function generates ZK Proof 2, along with the data Merkle tree, and hash commitment. Then ZK Circuit 1’s proving function is called passing in ZK Proof 2, the data Merkle tree, hash commitment, and device-bound entropy value, within which a unique nullifier is generated using the hash commitment and the entropy value; the data and criteria Merkle trees are compared using the aforementioned cryptographic methods as appropriate; and the criteria Merkle tree is used to compute its Merkle root. If appropriate of the use case and used in conjunction with a blockchainDocket No. HUMI-OOOl.WOOl that involves ZK Circuit 1’s proving system as part of its core consensus mechanism, ZK Proof 1 is sent in a transaction while ZK proof 2, criteria Merkle root, and nullifier are stored as public mappings with Merkle roots or plainly. Alternatively, these values are stored in another data storage system, such as a data vault, database, etc.

[0092] On an attribution requester’s system / device, ZK Circuit 1 and ZK Circuit 2 are embedded on the device along with their respective proving systems and include retrieving proofs and related data from either ZK Circuit 1’s blockchain, near-field communications like NFC, Bluetooth, or QR code, or other data storage system. This system also operates dynamically after being triggered by relevant changes on the blockchain or data storage system. Verify both ZK Proof 1 and ZK Proof 2 by calling their proving system’s verify command on Function 1 and Function 2. Verify Function 1 takes proof ZK Proof 1, and public inputs ZK Proof 2, and the criteria Merkle tree from the device / server / system (likely the same source as initially downloaded to the patient / record owner’s device) as input to verify if this criteria was used by the prover to generate ZK Proof 1 and the prover had the necessary data to satisfy the requirements, and if the ZK Proof 2 was the same in the proving step. Verify Function 2 takes proof ZK Proof 2 to verify if the parsing process was conducted properly. This confirms to the requester that the patient / health record owner satisfies the criteria posed.

[0093] The hybrid, multi-circuit approach strikes a balance between the other two approaches by leveraging the strengths of multiple proving systems to minimize the requirement of trusted parties and minimize additional processing overhead. It applies chain-credentialling to generate a complex set of credentials which implements data-minimization and reduces traceability. Two proving systems are shown in this example, but in practice this approach uses many proving systems to achieve optimal performance and integrity. Proving systems are chosen based on available data’s size, complexity, and which elliptic curves its signatures / certificates are generated on, device constraints of the patient / record owner, attribution requester, and other third party stakeholders such as government agencies (FDA, etc.) and additional multiuse purposes. This approach also decouples various stages of parsing and verification with any blockchainbased consensus system that might also be involved. This ensures high performance and high adaptability to multiple use cases and as initial use cases evolve.

[0094] ZKP-Backed Eligibility Credentialing Functionality involves generating structured, reusable clinical trial eligibility credentials derived from ZK proofs computed over normalized, patient-controlled health data. Each credential proves conformance to defined inclusion / exclusion logic (e.g., “meets criteria X, Y, Z”) without disclosing any underlying personal health information. Proofs are computed on-device and bound to the trial ID, eligibility schema version, credential validity window, and patient-held consent metadata.

[0095] Alignment:

[0096] • HL7 Vulcan Study Eligibility Criteria and Research Study resources

[0097] • HL7 Group and Evidence Variable profiles

[0098] • CQL and FHIR Library / Measure standards

[0099] • USCDI data elements via FHIR US Core and IPA profilesDocket No. HUMI-OOOl.WOOl

[0100] • W3C Verifiable Credentials and Selective Disclosure

[0101] • TEFCA Individual Access Services (IAS) + Facilitated FHIR Exchange

[0102] • LOINC, SNOMED CT, RxNorm ontologies

[0103] Rationale: Replace centralized EMR-based pre-screening with verifiable, patient-generated eligibility attestations that are privacy-preserving, cryptographically authentic, and usable across sponsor and site ecosystems. These credentials form the trust substrate for compliant, decentralized trial enrollment. A ZPR-Backed Eligibility Credentialing Engine, which can be coupled to one of the systems described with reference to FIGS. 1 to 7, enables, using one or more subengines, where each bullet point below can be considered the functionality of a subengine, configured to:

[0104] • Sponsor-side eligibility intake without direct access to source health records

[0105] • Patient-side portability and reuse across trials or referral registries

[0106] • Clinical protocol traceability (via eligibility schema version hashes or circuit identifiers)

[0107] • Verifier-side ZK validation logic without data disclosure

[0108] Examples Include:

[0109] • A patient receives a Group resource defining inclusion logic for Trial A. zClinical compiles the logic into a ZK circuit, evaluates their FHIR-normalized data locally, and produces a reusable eligibility credential embedded in a SMART Health Link (SHL) / Verifiable Credential (VC) format.

[0110] • The credential includes a blinded commitment to the data fields involved (e.g., age, diagnosis code, lab value) and the proof n attesting that the logic was satisfied as of date X.

[0111] • The credential includes metadata fields for trial Id, schema Version Hash, expiration, budget Remaining, and consent Reference.

[0112] • The sponsor-side verifier confirms the credential's proof signature, schema hash match, and integrity of the eligibility claim — all without seeing any PHI.

[0113] SMART Health Link and Verifiable Credential Wrapping Functionality: Package ZKP -backed eligibility credentials into portable, patient-controlled formats using the HL7 SMART Health Link (SHL) and / or W3C Verifiable Credential (VC) data models. These wrappers enable patients to present structured proof of eligibility — derived from local ZKP execution — via a secure, signed payload embedded in a QR code or deep link, with optional access-scoped metadata, expiration, selective disclosure controls, and revocation handles.

[0114] Alignment:

[0115] • HL7 SMART Health Cards and Links Implementation Guide (2025)

[0116] • W3C Verifiable Credentials Data Model 2.0 (draft)

[0117] • VC Selective Disclosure BBS+ and SD-JWT standards

[0118] • SHL access.inline Json and access.inline Reference

[0119] • W3C Decentralized Identifiers (DIDs)

[0120] • JWT / JSON-LD representations

[0121] • OAuth2 and HL7 scopes (launch, patient / Observation.read, etc.)Docket No. HUMI-0001.W001

[0122] Rationale: These wrapping formats define the bridge between zClinical’s privacy-preserving ZKP outputs and the broader clinical research ecosystem’s credential verification capabilities. They allow credentials to be securely presented at point-of-care, via remote sponsor portals, or directly to research registries. A SMART Health Link and Verifiable Credential Wrapping Engine, which can be coupled to one of the systems described with reference to FIGS. 1 to 7, enables, using one or more subengines, where each bullet point below can be considered the functionality of a subengine, configured to use SHL and VC formats that are:

[0123] • Portable: Encodable as QR, URI, file payload, or embedded deep link

[0124] • Cryptographically verifiable: Signature-based origin trust without centralized validation

[0125] • Patient-mediated: Disclosure happens only when the patient chooses to present

[0126] • Interoperable: Built on widely adopted standards (FHIR, VC, SHL) supported by Apple, Google, governments, and clinical software vendors

[0127] Examples include:

[0128] • zClinical generates an eligibility credential after verifying that a patient satisfies a Group-defined logic set. This credential is then encoded into a SMART Health Link inline Json payload with a digital signature, expiry, and embedded metadata for trial Id, schema Hash, and budget Remaining.

[0129] • The patient is presented with a QR code and deep link pointing to the credential; both are valid for a 7-day period and revocable by local user action.

[0130] • Alternatively, the credential is rendered in a W3C VC format (@context, type, credential Subject, proof) and signed using the app’s private key. The VC includes a status field referencing a revocation registry or self-expiring timestamp, plus optional selective disclosure fields (e.g., disclosing “Meets eligibility” without revealing which criteria were used).

[0131] Credential Presentation via QR Code and Short Link Functionality: Enable patient-mediated presentation of ZKP-backed eligibility credentials via compact delivery formats — specifically, QR codes, shortlinks, or URI-embedded payloads — that encapsulate or reference cryptographically verifiable proof data. These mechanisms allow eligibility credentials to be displayed, transmitted, or scanned across clinical contexts (e.g., trial screening, eConsent platforms, POC registries) without requiring patient logins or direct system integrations.

[0132] Alignment:

[0133] • HL7 SMART Health Link (SHL) QR conventions

[0134] • SHL access. inline Json, inline Reference, and expires attributes

[0135] • W3C Verifiable Credential presentation standards

[0136] • IETF URI schemes

[0137] • ISO / IEC 18004 QR Code model

[0138] • Apple Wallet / Pass Kit QR rendering analogs

[0139] • OAuth2 “resource indicators”

[0140] • NIST SP 800-63D guidelines on QR-based identity presentationDocket No. HUMI-0001.W001

[0141] Rationale: While the credential container (SHL / VC) defines what is shared, this section protects how it is presented (e.g., the mechanics of device-generated, user-controlled, verifier-readable visual or linkbased representations of credential content). A Credential Presentation via QR Code and Short Link Engine, which can be coupled to one of the systems described with reference to FIGS. 1 to 7, enables, using one or more subengines, where each bullet point below can be considered the functionality of a subengine, configured to provide formats that are:

[0142] • Portable across modalities (scanned, clicked, pasted, embedded)

[0143] • Trust-preserving (cryptographically signed and timestamped)

[0144] • Decentralized (no cloud fetch required unless explicitly referenced)

[0145] • Optimized for clinical edge cases (e.g., no Wi-Fi at site, non-integrated trial systems, or Bring- Your-Own-Device eligibility matching)

[0146] Examples Include:

[0147] • zClinical renders a SMART Health Link containing a ZKP-derived eligibility credential as a QR code, visible within the mobile app, scannable at trial intake.

[0148] • A recruiter portal receives a shortlink from the patient (e.g., humine.link / abcl23), which resolves to a local or cloud-hosted signed credential that the verifier can validate offline.

[0149] • Credential payloads include trial Id, issuer, proof Method, expires, and optionally budget Remaining, so that the presentation is self-describing and bounded in time or usage.

[0150] • Upon successful scan, the verifier’s system may trigger a response workflow (e.g., display confirmation, initiate consent onboarding, or request enriched disclosure via OAuth handshake), without needing to authenticate or re-query the patient’s data.

[0151] FHIR / OMOP-Based Data Normalization for ZKP Execution Functionality: Transform heterogeneous patient health data sources — including FHIR R4 resources (from SMART on FHIR endpoints), Blue Button claims (CARIN BB), CCD documents, Apple Health records, and manually entered data — into a unified, queryable format (FHIR or OMOP CDM) suitable for structured eligibility logic evaluation and zero-knowledge proof generation. This normalization occurs fully on-device and preserves source identifiers, terminological fidelity (e.g., LOINC, SNOMED CT), and consent scoping metadata for traceable, bounded proof construction.

[0152] Alignment:

[0153] • HL7 US Core and International Patient Access (IP A) Implementation Guides

[0154] • HL7 OMOP+FHIR IG (2025 ballot)

[0155] • OHDSI OMOP CDM v6.0 and cohort querying conventions

[0156] • CARIN Blue Button IG (payer claims)

[0157] • FHIR Mapping Language (Structure Map); Value Set / Concept Map for terminology translation

[0158] • HealthKit FHIR abstractions (e.g., Observation from device-generated data)

[0159] • TEFCA Individual Access Service (IAS) interoperability rules

[0160] • W3C Data Minimization and Purpose-Binding best practicesDocket No. HUMI-OOOl.WOOl

[0161] Rationale: Eligibility logic requires consistent structural and semantic representation of clinical concepts, regardless of origin. This section protects Humine’s ability to support cross-source data normalization as a prerequisite for verifiable, local trial matching. A FHIR / OMOP -Based Data Normalization for ZKP Execution Engine, which can be coupled to one of the systems described with reference to FIGS. 1 to 7, enables, using one or more subengines, where each bullet point below can be considered the functionality of a subengine, configured to ensure:

[0162] • Data minimization through standardization and scoped extraction

[0163] • Terminological mapping consistency for computable logic compatibility

[0164] • Portable, schema-bound datasets as canonical ZKP inputs

[0165] • Clinical and regulatory traceability from ZK output to input derivation path (e.g., “proof 7i was derived from two Observations using LOINC codes 4548-4 and 2339-0 from source X”)

[0166] Examples include:

[0167] • A patient retrieves FHIR data from two hospital systems (EHR A, EHR B) and claims data from a payer via CARIN BB. zClinical maps all resources into a unified FHIR store and then transforms them into OMOP CDM v6.0 tables for cohort logic evaluation.

[0168] • Value Set expansion is used to map SNOMED CT conditions and LOINC lab codes into trialspecific inclusion sets. All transformations are logged and bound to the patient's consent artifact.

[0169] • Proof circuits execute against normalized tables (e.g., condition_occurrence, measurement) to determine eligibility, while preserving origin traceability through Provenance and source_concept_id fields.

[0170] • Data sources are tagged with purpose Of Use, data Source Type, and retrieved At, ensuring downstream credential proofs disclose nothing beyond what was explicitly authorized.

[0171] Trial Protocol-to-Circuit Compiler Functionality: Transform structured clinical trial protocol definitions — authored in CDISC USDM, PRM, SPIRIT 2023, HL7 Vulcan Digital Protocol, or FHIR Research Study / Group / Evidence Variable resources — into executable constraint systems suitable for zeroknowledge proof generation and eligibility credentialing.

[0172] The compiler ingests sponsor-issued protocol metadata (eligibility logic, study arms, visit structure, temporal constraints, and exclusion conditions) and automatically generates a cryptographically bound Eligibility Circuit IR (Intermediate Representation). The resulting circuit can be compiled into a ZK- compatible domain-specific language (e.g., Leo, Circom, Noir) and executed on-device to produce verifiable proofs of protocol compliance or eligibility.

[0173] Alignment:

[0174] • CDISC USDM vl.O — trial schema, study design, and computable eligibility constructs

[0175] • CDISC Protocol Representation Model (PRM) — standardized encoding of protocol logic and visit schedule

[0176] • SPIRIT 2023 — structured protocol authoring for digital implementation

[0177] • HL7 Vulcan Digital Protocol (2025 draft) — eligibility and SoA (Schedule of Activities) models

[0178] • HL7 FHIR Research Study, Evidence Variable, and Group resources

[0179] • Leo, Circom, Noir — ZK circuit languages for eligibility logic compilationDocket No. HUMI-OOOl.WOOl

[0180] • Git-style versioning or hash-anchoring of protocol schema versions

[0181] Rationale: The compiler is the translation engine that operationalizes clinical protocol logic into verifiable computation. A Trial Protocol-to-Circuit Compiler Engine, which can be coupled to one of the systems described with reference to FIGS. 1 to 7, enables, using one or more subengines, where each bullet point below can be considered the functionality of a subengine, configured to:

[0182] • Transform machine-readable protocol models (USDM, PRM, SPIRIT) into executable eligibility circuits.

[0183] • Maintain one-to-one traceability between protocol versions and generated circuit hashes, enabling IRB / FDA-auditable lineage of every eligibility proof.

[0184] • Guarantee immutability and correctness of compiled logic, reducing site error and protocol deviation risk.

[0185] • Support cross-sponsor reusability — eligibility modules can be recombined or reused across trials with differing proof gates while preserving provenance.

[0186] • Facilitate rapid protocol amendments by detecting schema diffs and regenerating new circuit versions without manual reprogramming.

[0187] Examples include:

[0188] • A sponsor publishes its protocol in CDISC USDM format defining inclusion / exclusion logic, arms, and time windows. zClinical parses the JSON, extracts the eligibility node, converts it into a ZK constraint system (e.g., “age > 18,” “HbAlc > 7,” “no history of stroke”), and outputs a Leo circuit. The compiled circuit hash is bound to the trial Id and stored in the credential metadata.

[0189] • An updated version of the protocol (v2.1) is recompiled; new circuit and schema hashes are generated, automatically revoking outdated eligibility proofs and prompting credential re-issuance.

[0190] • The system maintains an internal audit log linking USDM document ID — > compiled circuit hash — > eligibility credential ID for transparent version provenance.

[0191] • Multi-trial networks share a standardized library of compiled eligibility modules across sponsors under CDISC and HL7 interoperability rules.

[0192] On-Device Computable Phenotype Evaluation Functionality: Evaluate machine-readable trial eligibility criteria directly on-device using computable phenotype logic against locally normalized patient data in FHIR or OMOP format. Supports both interpretive and compiled execution modes, allowing logic to be evaluated via Clinical Quality Language (CQL) or transformed into ZKP-executable circuits. Eligibility rules may reference temporal constraints, value thresholds, condition sets, or logic expressions built from sponsor-issued artifacts (e.g., FHIR Library, Measure, Evidence Variable, Group, or CDISC USDM criteria).

[0193] Alignment:

[0194] • HL7 CQL, FHIR Library, Measure, and Plan Definition resources

[0195] • HL7 Evidence Variable and Group profiles for study eligibility

[0196] • HL7 Vulcan Digital Protocol (draft)

[0197] • OHDSI Atlas phenotype logic and standardized OMOP cohort definitionsDocket No. HUMI-OOOl.WOOl

[0198] • CDISC Unified Study Definition Model (USDM) - Eligibility Criteria entity

[0199] • SPIRIT 2023 - computable protocol modeling

[0200] • Leo, Circom, Noir (ZK circuit languages)

[0201] • ISO / IEC 19794 (expression and logic portability standards)

[0202] Rationale: Eligibility criteria must be machine-evaluable, version-controlled, and patient-side executable to enable privacy-preserving trial matching. An On-Device Computable Phenotype Evaluation Engine, which can be coupled to one of the systems described with reference to FIGS. 1 to 7, enables, using one or more subengines, where each bullet point below can be considered the functionality of a subengine, configured to:

[0203] • Execute sponsor-issued computable logic on patient-controlled data without transmitting any raw facts

[0204] • Bind proofs to eligibility logic identifiers (e.g., trial Eligibility Schema Hash)

[0205] • Verify criteria match state with ZK auditable provenance, enabling trust without disclosing inputs

[0206] • Maintain lineage and updateability across eligibility definitions (e.g., trial updates trigger schema recompile)

[0207] Examples include:

[0208] • A patient downloads a trial eligibility Library resource from a sponsor via FHIR, defining criteria such as “age > 50, HbAlc > 7.0, and no prior stroke.” zClinical either (1) interprets the CQL logic on-device or (2) compiles it into a ZK circuit and executes over the patient’s local FHIR / OMOP data store.

[0209] • The logic output (match / non-match) is cryptographically proven via ZKP, and the credential embeds the eligibility schema hash and timestamp of execution.

[0210] • The app supports dynamic re-evaluation (e.g., “recheck eligibility next month”), multi-trial logic handling, and optional logic parameterization (e.g., trial sites may add exclusions locally).

[0211] • The resulting proof and credential are valid even if the patient changes systems or locations — no re-evaluation occurs unless explicitly triggered or data changes.

[0212] Consent-Gated Proof Generation Functionality: Ensure that the generation, issuance, and disclosure of any zero-knowledge proof or eligibility credential is explicitly gated by a structured, user- controlled consent artifact. Consent must be actively granted and scoped to the specific use case (e.g., screening for Trial X), and its metadata (e.g., purpose, expiration, scope, data fields authorized) must be cryptographically referenced within the resulting proof or credential. Enforcement of this gate occurs on- device prior to eligibility evaluation, and no proofs may be computed or shared without validated consent state.

[0213] Alignment:

[0214] • HL7 FHIR Consent resource (R4 and R5)

[0215] • IHE Privacy Consent on FHIR (PCF) Implementation Guide

[0216] • HL7 Security Labeling and Data Segmentation for Privacy (DS4P)

[0217] • GDPR Article 7 (explicit consent) and 6(l)(a) (processing based on consent)

[0218] • HIPAA Individual Right of Access (45 CFR § 164.524)Docket No. HUMI-OOOl.WOOl

[0219] • W3C Data Minimization and Purpose Specification principles

[0220] • TEFCA QTF § 4.4 (Individual Access Exchange policy constraints)

[0221] Rationale: Consent is not just a compliance requirement — in Humine’s architecture, it is a first- class cryptographic gate that defines when proofs can be computed and what may be disclosed. A Consent- Gated Proof Generation Engine, which can be coupled to one of the systems described with reference to FIGS. 1 to 7, enables, using one or more subengines, where each bullet point below can be considered the functionality of a subengine, configured to:

[0222] • Enforce real-time consent evaluation prior to proof execution

[0223] • Bind proof validity to an auditable consent artifact ID or hash

[0224] • Allow scoped consent reuse, revocation, and time expiration

[0225] • Support downstream trust by making verifiers aware of the scope and authority of the patient’s consent at the time of credential issuance

[0226] Examples include:

[0227] • A patient launches zClinical and views a structured consent form indicating that eligibility for Trial A will be evaluated using their local EHR and Apple Health data, and that the resulting credential may be shared with Sponsor X for screening purposes only.

[0228] • Upon agreement, the app generates a FHIR Consent resource encoding the terms, and hashes the resource ID and signature timestamp into the ZKP input.

[0229] • The resulting eligibility credential includes a consent Reference field, allowing downstream verifiers to confirm that proof generation was authorized and bounded in scope.

[0230] • The app prevents credential generation if no active consent exists, or if the consent has expired, been revoked, or does not cover the requested data domains or use case.

[0231] • If the patient later revokes the consent, zClinical invalidates or removes related credentials from local storage and, optionally, from revocation registries.

[0232] Verifier-Side Acceptance and Role Handling Functionality: Define standardized mechanisms for trial sponsors, clinical sites, contract research organizations (CROs), and registry platforms to receive, validate, and log ZKP-backed eligibility credentials presented by patients. Verification occurs either locally (offline) or via a trust endpoint using the embedded signature, circuit metadata, and consent reference. The verifier system authenticates the credential’s origin, confirms proof validity and schema integrity, checks revocation or expiration status, and records validation events in an auditable, privacy-preserving format (e.g., via FHIR Provenance or Audit Event).

[0233] Alignment:

[0234] • HL7 SMART Health Links (SHL) Verifier Patterns (2025 IG)

[0235] • W3C Verifiable Credential verification methods (Data Integrity vl .1, JSON-LD Signatures, SD- JWT VC)

[0236] • HL7 FHIR Audit Event, Provenance, and Verification Result resources

[0237] • TEFCA QTF Section 7 (Trust and Verification Frameworks)

[0238] • IHE Basic Audit Log Patterns (BALP)Docket No. HUMI-0001.W001

[0239] • ISO 29115 / NIST SP 800-63C (Authenticator Assurance Levels)

[0240] • OAuth2 Token Introspection and Mutual TLS-bound access tokens

[0241] Rationale: While earlier sections address credential generation and presentation, this section protects the trust layer that connects zClinical’s proofs to enterprise and regulatory workflows. Humine’s verifier-side framework ensures that trial stakeholders can trust credential authenticity without direct access to source data, fulfilling regulatory and operational needs for eligibility traceability, auditability, and fraud prevention. A Verifier-Side Acceptance and Role Handling Engine, which can be coupled to one of the systems described with reference to FIGS. 1 to 7, enables, using one or more subengines, where each bullet point below can be considered the functionality of a subengine, configured to:

[0242] • Decouple credential consumption from raw PHI access while maintaining audit readiness

[0243] • Standardize proof validation across ecosystems (e.g., CROs, decentralized site networks, and sponsor portals)

[0244] • Support SDK and API commercialization, enabling Humine’s verification logic to embed into third-party platforms

[0245] • Ensure GCP / Part 11 compliance via auditable verification events and signed outcome records

[0246] Examples include:

[0247] • A sponsor’s clinical operations portal receives a SMART Health Link from a patient containing a ZKP -backed eligibility credential. The portal’s verifier module validates the embedded proof signature, confirms the credential’s trial Id and schema Hash match the active protocol version, checks the consent reference’s validity, and logs the result via a FHIR Verification Result and Audit Event.

[0248] • A decentralized site uses an embedded zClinical SDK to automatically verify a patient’s credential offline during intake, displaying a “verified eligibility” token and timestamp without accessing any PHI.

[0249] • The CRO’s monitoring dashboard aggregates Verification Result and Audit Event entries across multiple sites, providing a regulatory-grade audit trail demonstrating compliant, privacy-preserving eligibility verification.

[0250] • Revocation status is checked against a credential status list, and expired or tampered proofs are invalidated automatically.

[0251] Privacy Budget and Limited-Use Proof Tracking Functionality: Implement cryptographically verifiable mechanisms that limit, monitor, or enforce how many times a patient’s credential, proof, or underlying dataset may be used or presented. A privacy budget manager — executed on-device or via privacy-preserving distributed ledger — tracks disclosure events and enforces consent-bounded usage limits (e.g., number of proofs, time-bound reusability, or trial-specific scopes). The budget logic may be enforced using ZK range proofs, nonce-based counters, or blinded commitment updates. Each use is logged in an auditable but privacy-respecting form (e.g., via hashed provenance tokens), ensuring patient control and preventing credential abuse, replay, or data exhaustion.

[0252] Alignment:

[0253] • W3C Verifiable Credentials — Selective Disclosure (SD-JWT and BBS+)Docket No. HUMI-OOOl.WOOl

[0254] • W3C VC StatusList2021 (credential revocation and usage tracking)

[0255] • HL7 FHIR Consent, Audit Event, and Provenance for usage recording

[0256] • NIST Privacy Framework vl.O — Data Minimization and Use Limitation principles

[0257] • IETF Privacy Pass / Blind Token protocols (reference model)

[0258] • ISO / IEC 27552 — privacy governance controls

[0259] • TEFCA QTF §7.4 (Purpose of Use and Access Minimization)

[0260] Rationale: As Humine scales zClinical credentials across trials, sponsors, and registry networks, it must ensure data minimization and controlled credential reusability while preserving patient trust. A Privacy Budget and Limited-Use Proof Tracking Engine, which can be coupled to one of the systems described with reference to FIGS. 1 to 7, enables, using one or more subengines, where each bullet point below can be considered the functionality of a subengine, configured to prevent:

[0261] • Credential replay or sharing across unintended contexts

[0262] • Overexposure of derived proof data through repeated use

[0263] • Cross-sponsor correlation that could de-anonymize participants

[0264] The privacy budget enforces a zero-trust disclosure policy, ensuring each proof remains tied to explicit consent and use limits. It provides sponsors and regulators with measurable proof of compliance with data minimization principles under HIPAA, GDPR, PHIPA, and TEFCA. Examples include:

[0265] • A patient receives a trial eligibility credential with a privacy budget allowing three valid presentations within 30 days. Each presentation triggers a local counter update and generates a new ZK range proof attesting that the counter remains >0 without revealing the actual count. Once the counter reaches zero, subsequent presentations fail validation until a new consent or credential is issued.

[0266] • The credential metadata includes a budget Remaining field (encrypted commitment) and a budget Policy reference linking to the governing consent resource.

[0267] • The verifier system checks the proof s freshness and confirms the credential’s inclusion in a valid status list or privacy budget registry.

[0268] • A time-based rule resets the privacy budget monthly, automatically invalidating expired proofs and prompting the patient to re-authorize access.

[0269] Time-Locked and Revocable Credential Management Functionality: Implement lifecycle controls for ZKP-backed credentials that enforce time-bound validity, revocation, and reissuance without compromising privacy or decentralization. Each credential includes a cryptographically verifiable expiration window and an optional reference to a revocation registry or status endpoint. When the credential expires or is revoked (e.g., due to protocol update, consent withdrawal, or eligibility logic change), it can no longer be validated by verifier systems. The revocation or expiration state is represented via a lightweight ZK inclusion / exclusion proof or verifiable status list, enabling revocation checks without revealing the credential content or patient identity.

[0270] Alignment:

[0271] • W3C Verifiable Credentials StatusList2021 and RevocationList2020 specifications

[0272] • HL7 SMART Health Links expiration and metadata extensions (expires, valid From)Docket No. HUMI-OOOl.WOOl

[0273] • HL7 FHIR meta. expiration Date, Provenance, and Audit Event for credential event logging

[0274] • OAuth2 Token Revocation (RFC 7009) and Mutual TLS-bound access tokens

[0275] • ISO / IEC 23220-1 (Digital identity credential lifecycle management)

[0276] • TEFCA QTF §8.2 (Trust continuity, credential expiration, and renewal governance)

[0277] Rationale: Regulatory-grade verifiability requires every credential to be temporally constrained and revocable. Time-locked validity ensures that proofs correspond only to current eligibility schemas and up- to-date health data, while revocation enables IRB, sponsor, or patient-driven invalidation of credentials when conditions change. This architecture provides end-to-end control and transparency while ensuring Humine’s system remains compliant, tamper-resistant, and scalable across multi-sponsor environments. A Time- Locked and Revocable Credential Management Engine, which can be coupled to one of the systems described with reference to FIGS. 1 to 7, enables, using one or more subengines, where each bullet point below can be considered the functionality of a subengine, configured to provide:

[0278] • Decentralized validity enforcement: No central service required for expiration or revocation verification; verifiers can independently confirm credential status using a ZK-based registry or signed metadata block.

[0279] • Dynamic reissuance: New credentials are automatically recompiled from updated eligibility circuits (e.g., after protocol amendment or new consent).

[0280] • Non-correlation of status checks: Revocation or expiry verification does not expose patient identifiers or usage patterns.

[0281] • Regulatory traceability: Every reissuance or revocation event can be cryptographically tied to a protocol version, consent artifact, and time stamp.

[0282] Examples include:

[0283] • A credential includes a valid From and valid Until timestamp in its metadata. During verifier validation, the proof s embedded time commitment is checked against the verifier’s system clock, confirming that the credential is still within the valid window.

[0284] • When a trial protocol is updated (new inclusion / exclusion criteria), zClinical automatically regenerates the eligibility circuit and reissues credentials with updated schema hashes and expiration tags; previous credentials are marked invalid in the revocation registry.

[0285] • If a patient withdraws consent, the corresponding credential ID is added to a privacy-preserving status list, and subsequent verifier checks return “revoked” using a ZK proof-of-exclusion.

[0286] • Revocation logic may be triggered by system events (e.g., data update) or explicit user actions, and all transitions are recorded in an Audit Event for compliance documentation.

[0287] Multilingual and Code-System Localized Circuit Compilation Functionality: Enable the trial eligibility compiler to interpret and transform study logic across multiple languages, code systems, and regional terminologies, generating zero-knowledge proof circuits that preserve semantic equivalence across jurisdictions. The system automatically translates eligibility definitions and associated terminologies — such as ICD-10-CA, SNOMED-UK, LOINC-FR, RxNorm-US, and SNOMED-INT— into unified circuit parameters using HL7 ConceptMap and Value Set translation services. It also supports multilingual protocolDocket No. HUMI-OOOl.WOOl authoring (e.g., English, French, Spanish, Mandarin) by aligning eligibility expressions and natural -language annotations to the underlying standardized logical structure. This ensures that ZK proofs derived in one jurisdiction remain syntactically and semantically verifiable in another without exposing underlying data.

[0288] Alignment:

[0289] • HL7 FHIR Terminology Service API (R4 and R5)

[0290] • HL7 Value Set, Code System, and Concept Map resources for code translation and crosswalks

[0291] • SNOMED CT (International and regional extensions), ICD-10-CA, ICD-11, LOINC, RxNorm, pCLOCD

[0292] • HL7 International Patient Summary (IPS) — for multilingual cross-border interoperability

[0293] • ISO 639-1 (language codes), ISO 17115 (health informatics terminologies)

[0294] • CDISC USDM and PRM (regionalized protocol data exchange formats)

[0295] • TEFCA Facilitated FHIR Exchange (for U.S. data) and pan-Canadian Infoway PS-CA profiles

[0296] Rationale: To operate globally, Humine’s zClinical platform must compile eligibility circuits that can execute over locally coded EHR data while maintaining fidelity to sponsor-issued logic. This section protects the infrastructure for cross-terminology translation, localization, and semantic normalization — a necessary capability as international sponsors (EU, Canada, APAC) adopt CDISC / HL7-aligned digital protocols. A Multilingual and Code-System Localized Circuit Compilation Engine, which can be coupled to one of the systems described with reference to FIGS. 1 to 7, enables, using one or more subengines, where each bullet point below can be considered the functionality of a subengine, configured to provide:

[0297] • Semantic consistency: Eligibility logic and ZK circuits remain interoperable even when data originates in different code systems or languages.

[0298] • Jurisdictional compliance: Supports data provenance and terminology alignment with local privacy and healthcare standards (PHIPA, GDPR, HIPAA).

[0299] • Multilingual trust: Patients and regulators can verify consent and proof disclosures in their own language without logic divergence.

[0300] • Regulatory readiness: Anticipates global adoption of IPS-based clinical summaries and cross- border credential verification (aligned with EMA, Health Canada, and FDA convergence initiatives).

[0301] Examples Include:

[0302] • A sponsor in the U.S. publishes an eligibility schema in CDISC USDM using ICD-10-CM and SNOMED-INT codes. A patient in Ontario retrieves the same logic through zClinical, which automatically maps terms to ICD-10-CA and pCLOCD via FHIR Concept Map and regenerates a semantically equivalent circuit. The proof is executed locally, and the resulting credential is valid for both U.S. and Canadian verifiers.

[0303] • A French clinical site uses a localized zClinical interface where eligibility logic and consent forms are rendered in French while the compiled circuit and underlying data use English-based international terminology. The resulting ZK proof references the canonical code URIs rather than text labels, ensuring verifiable equivalence.Docket No. HUMI-OOOl.WOOl

[0304] • A multi-region sponsor updates its eligibility criteria, and zClinical automatically regenerates regionalized circuits, each tied to the same global schema Hash for cross-border verifiability.

[0305] Credential Chaining and Reuse Across Trials Functionality: Enable the secure composition, referencing, and reuse of multiple ZKP -backed eligibility or participation credentials across distinct clinical trials, registries, and research programs. Credential chaining establishes a verifiable lineage between prior and subsequent credentials, allowing proofs of participation, screening, or eligibility to be linked cryptographically without re-exposing underlying data or personally identifiable information. Each credential in the chain includes cryptographic pointers (hashes or references) to predecessor credentials and their consent artifacts, enabling verifiers to confirm provenance and continuity while maintaining participant anonymity.

[0306] Alignment:

[0307] • W3C Verifiable Credential “chained credentials” and evidence properties (VC Data Model 2.0 draft)

[0308] • HL7 FHIR Provenance, Document Reference, and Audit Event resources

[0309] • HL7 EBM (Evidence -Based Medicine) and Research Study linkage patterns

[0310] • CDISC USDM “linked study” and “cohort membership” entities

[0311] • HL7 Vulcan Digital Protocol (cross-trial eligibility frameworks)

[0312] • TEFCA QTF §9.3 (multi-network trust propagation)

[0313] • JSON Web Proof (JWP) and Decentralized Identifiers (DIDs) for credential linkage

[0314] • ISO / IEC 23220-2 (Chained Credential Lifecycle Management)

[0315] Rationale: Clinical trial participants increasingly move across multiple research programs and sponsors. Humine’s credential chaining system allows for privacy-preserving continuity of participation by enabling eligibility or participation credentials to serve as verifiable anchors for future engagement — without central registries, raw data reuse, or re-identification risk. A Credential Chaining and Reuse Across Trials Engine, which can be coupled to one of the systems described with reference to FIGS. 1 to 7, enables, using one or more subengines, where each bullet point below can be considered the functionality of a subengine, configured to provide:

[0316] • Longitudinal trust propagation: Sponsors or CROs can verify that a patient previously participated in or qualified for related studies without direct access to prior trial data.

[0317] • Regulatory auditability: Provenance and chain-of-custody logs demonstrate compliance with protocol evolution, consent continuity, and eligibility integrity.

[0318] • Participant efficiency: Reduces redundant pre-screening, accelerates trial enrollment, and enhances patient experience.

[0319] • Cross-sponsor interoperability: Supports credential reuse in registries or trial networks governed by varying privacy jurisdictions (HIPAA, GDPR, PHIPA).

[0320] Examples include:

[0321] • A patient completes a Phase II trial with a participation credential containing a ZKP attesting to “completion status.” When enrolling in a Phase III study, zClinical references the prior credential’s hash,Docket No. HUMI-OOOl.WOOl generates a new ZKP attesting to both the new eligibility logic and verified prior participation, and issues a chained credential embedding both references.

[0322] • A multi-sponsor registry receives chained credentials that link eligibility proofs from multiple trials conducted by different institutions. Each credential includes a blinded hash of the preceding credential and its trial Id, maintaining verifiability without exposing content or patient identifiers.

[0323] • Upon protocol amendment, zClinical automatically regenerates an updated chain link (credential v2) that includes references to the previous credential and consent state. This enables auditors to confirm historical compliance without retrieving obsolete proofs.

[0324] • A regulator reviewing a patient’s chain of participation can cryptographically confirm the authenticity, order, and validity of each credential link using embedded signatures and schema hashes.

[0325] Incentive-Linked ZKP Credentialing Functionality: Implement a verifiable, consent-gated incentive framework in which generation, validation, or reuse of a ZKP-backed credential triggers programmable rewards, reimbursements, or engagement credits — without disclosure of underlying data. Incentive events are bound to proof authenticity, consent scope, and usage conditions and can be verified by sponsors, CROs, or third-party payment processors using cryptographic signatures or secondary ZK proofs of event completion. All incentive transactions are executed only after successful validation of a ZKP credential and are logged in an auditable, privacy-preserving ledger. Incentive issuance and redemption logic can occur entirely on-device or through API-level integrations with digital wallets, sponsor systems, or institutional accounting platforms.

[0326] Alignment:

[0327] • W3C Verifiable Credentials Data Model 2.0 with Selective Disclosure and status extensions

[0328] • OAuth 2.0 / OpenlD Connect for tokenized authorization

[0329] • HL7 FHIR Consent, AuditEvent, and PaymentNotice resources

[0330] • TEFCA Individual Access Services (IAS) and Purpose-of-Use limitations

[0331] • NIST Digital Identity Guidelines (NIST SP 800-63C, Assurance Level 2+)

[0332] • ISO 12812-8 (Digital Tokenization and Reward Transactions)

[0333] • IETF Token-Based Proof-of-Possession / Privacy Pass analogs

[0334] Rationale: This capability transforms Humine’s credentialing layer into an ethical incentive infrastructure — allowing sponsors to compensate participants for verified engagement while maintaining zero-knowledge privacy. It establishes a measurable, cryptographically auditable link between data use authorization (consent) and economic participation (incentive), creating a new compliance -safe alternative to conventional data-broker or claims-based reward models. An Incentive-Linked ZKP Credentialing Engine, which can be coupled to one of the systems described with reference to FIGS. 1 to 7, enables, using one or more subengines, where each bullet point below can be considered the functionality of a subengine, configured to provide:

[0335] • Differentiation: Directly distinguishes Humine from IAS-class interoperability vendors that lack built-in participant incentive logic.Docket No. HUMI-OOOl.WOOl

[0336] • Trust scalability: Enables verifiable compensation without PHI exchange, satisfying IRB and ethics board scrutiny.

[0337] • Operational flexibility: Allows sponsors to fund recruitment or follow-up activities via automated, event-driven micro-transactions tied to proof validation.

[0338] • Regulatory defensibility: Aligns with emerging FDA / NIH guidance encouraging fair participant compensation under demonstrably privacy-preserving systems.

[0339] Examples include:

[0340] • A sponsor validates a participant’s eligibility credential (proof n) through a SMART Health Link. Upon successful verification, the sponsor’s payment API receives a cryptographic token asserting “credential verified under consent ID C-789”. The payment processor releases a micro-incentive to the participant’s registered wallet — without learning the participant’s identity or health attributes.

[0341] • The participant later completes an eDiary task or follow-up proof; zClinical generates a new ZKP attesting to task completion. The proof triggers automatic credit issuance, logged via a FHIR PaymentNotice containing only credential ID, consent reference, and anonymized transaction hash.

[0342] • A Patient Advocacy Group partnership deploys reward campaigns where members earn verifiable engagement points for generating pre-screening proofs. Each point transaction is backed by a proof-of-validity hash and bounded by consented purpose (“trial matching only”).

[0343] • Anti-replay safeguards ensure each credential or proof can trigger payment only once, enforced via blinded commitment counters and privacy-budget state tracking.

Claims

Docket No. HUMI-0001.W001CLAIMSWhat is claimed is:

1. A system comprising: a first Zero-Knowledge (ZK) circuit on a verification client-side device that includes: a Merkle root computation engine; an attestation requirements confirmation engine; a nullifier generation engine; wherein, in operation, the Merkle root computation engine has access to a normalized criteria Merkle tree and provides a criteria Merkle root to a first ZK proof external data source as a public mapping; the attestation requirements confirmation engine has access to the normalized criteria Merkle tree and a data Merkle tree and provides an attestation requirements confirmation result; the nullifier generation engine has access to a bundle hash commitment and device-bound entropy and provides a nullifier to the first ZK proof external data source as a public mapping; the first ZK circuit provides a first ZK proof to the first ZK proof external data source as a proof forms consensus if the attestation requirements confirmation result confirms the attestation requirements; wherein the criteria Merkle root, nullifier, and first ZK proof are designed for use by a verification server-side first ZK circuit to generate a verification result.

2. The system of claim 1 comprising: a field parsing engine with access to a standardized format that is received from a health records external data source and that provides the data Merkle tree to the attestation requirements confirmation engine.

3. The system of claim 1 comprising: a record hashing engine with access to a standardized format that is received from a health records external data source and that provides the bundle hash commitment to the nullifier generation engine.

4. The system of claim 1 comprising: a record signature verification engine with access to a standardized format and an issuer public key that are received from a health records external data source and that generates a record signature verification result.

5. The system of claim 1 wherein the first ZK circuit includes a field parsing engine, a record hashing engine, and a record signature verification engine.

6. The system of claim 1 wherein a second ZK circuit includes a field parsing engine, a record hashing engine, and a record signature verification engine, and wherein: the second ZK circuit provides a second ZK proof to the first ZK circuit;Docket No. HUMI-0001.W001 the first ZK circuit provides the second ZK proof to the first ZK proof external data source as a public mapping; the criteria Merkle root, nullifier, first ZK proof, and second ZK proof are designed for use by a verification server-side first ZK circuit and a second ZK circuit to generate a verification result.

7. The system of claim 1 wherein a verification server-side criteria transformation engine has access to a criteria external data source and provides the normalized criteria Merkle tree to the verification client-side device, wherein at times during operation the criteria transformation engine includes in one or more datastores standardized criteria data, normalized criteria, and the normalized criteria Merkle tree.

8. The system of claim 1 comprising a ZK proof-backed eligibility credentialing engine configured to perform functions selected from a group consisting of: sponsor-side eligibility intake without direct access to source health records; patient-side portability and reuse across trials or referral registries; clinical protocol traceability via eligibility schema; verifier-side ZK validation logic without data disclosure; two or more of these.

9. The system of claim 1 comprising a SMART health link and verifiable credential wrapping engine configured to perform functions selected from a group consisting of: portability via encodable as QR, URI, file payload, or embedded deep link; cryptographical verifiability using signature-based origin trust without centralized validation; patient-mediatable by ensuring disclosure happens only when the patient chooses to present; interoperability by utilizing widely adopted standards supported by Apple, Google, governments, and clinical software vendors; two or more of these.

10. The system of claim 1 comprising a credential presentation via QR code and short link engine configured to provide formats selected from a group consisting of portable across modalities; trustpreserving; decentralized; optimized for clinical edge cases; two or more of these.

11. The system of claim 1 comprising a FHIR / OMOP-based data normalization for ZK proof execution engine configured to perform functions selected from a group consisting of: data minimization through standardization and scoped extraction; terminological mapping consistency for computable logic compatibility; portable, schema-bound datasets as canonical ZK proof inputs; clinical and regulatory traceability from ZK output to input derivation path; two or more of these.Docket No. HUMI-0001.W00112. The system of claim 1 comprising a trial protocol-to-circuit compiler engine configured to perform functions selected from a group consisting of: transform machine-readable protocol models into executable eligibility circuits; maintain one-to-one traceability between protocol versions and generated circuit hashes, enabling IRB / FDA-auditable lineage of every eligibility proof; guarantee immutability and correctness of compiled logic, reducing site error, and protocol deviation risk; support cross-sponsor reusability wherein eligibility modules are recombined or reused across trials with differing proof gates while preserving provenance; facilitate rapid protocol amendments by detecting schema diffs and regenerating new circuit versions without manual reprogramming; two or more of these.

13. The system of claim 1 comprising an on-device computable phenotype evaluation engine configured to perform functions selected from a group consisting of: execute sponsor-issued computable logic on patient-controlled data without transmitting raw facts; bind proofs to eligibility logic identifiers; verify criteria match state with ZK auditable provenance, enabling trust without disclosing inputs; maintain lineage and updateability across eligibility definitions; two or more of these.

14. The system of claim 1 comprising a consent-gated proof generation engine configured to perform functions selected from a group consisting of: enforce real-time consent evaluation prior to proof execution; bind proof validity to an auditable consent artifact ID or hash; allow scoped consent reuse, revocation, and time expiration; support downstream trust by making verifiers aware of the scope and authority of the patient’s consent at the time of credential issuance; two or more of these.

15. The system of claim 1 comprising a verifier-side acceptance and role handling engine configured to perform functions selected from a group consisting of: decouple credential consumption from raw PHI access while maintaining audit readiness; standardize proof validation across ecosystems; support SDK and API commercialization, enabling verification logic to embed into third-party platforms; ensure GCP / Part 11 compliance via auditable verification events and signed outcome records; two or more of these.Docket No. HUMI-0001.W00116. The system of claim 1 comprising a privacy budget and limited-use proof tracking engine configured to perform functions selected from a group consisting of: credential replay or sharing across unintended contexts; overexposure of derived proof data through repeated use; cross-sponsor correlation to de-anonymize participants; two or more of these.

17. The system of claim 1 comprising a time-locked and revocable credential management engine configured to perform functions selected from a group consisting of: decentralized validity enforcement; dynamic reissuance; non-correlated of status checks; regulatory traceability; two or more of these.

18. The system of claim 1 comprising a multilingual and code-system localized circuit compilation engine configured to perform functions selected from a group consisting of: eligibility logic and ZK circuits remain interoperable even when data originates in different code systems or languages; data provenance and terminology alignment with local privacy and healthcare standards; multilingual trust; regulatory readiness; two or more of these.

19. The system of claim 1 comprising a credential chaining and reuse across trials engine configured to perform functions selected from a group consisting of: longitudinal trust propagation by enabling sponsors or CROs to verify that a patient previously participated in or qualified for related studies without direct access to prior trial data; regulatory auditability with provenance and chain-of-custody logs demonstrating compliance with protocol evolution, consent continuity, and eligibility integrity; participant efficiency by eliminating redundant pre-screening, accelerating trial enrollment, and enhancing patient experience; cross-sponsor interoperability by supporting credential reuse in registries or trial networks governed by varying privacy jurisdictions; two or more of these.

20. The system of claim 1 comprising an incentive-linked ZK proof credentialing engine configured to perform functions selected from a group consisting of: distinguish the system from IAS-class interoperability vendors that lack built-in participant incentive logic; enable verifiable compensation without PHI exchange, satisfying IRB and ethics board scrutiny; allow sponsors to fund recruitment or follow-up activities via automated, event-driven microtransactions tied to proof validation; regulatory defensibility; two or more of these.

Images