System for dynamic, secure retrieval of sensitive data and methods thereof

Abstract

A system and methods are provided for locating and retrieving sensitive clinical data. The Dynamic Clinical Data Exchange Platform of the inventive System serves as a trusted proxy for the Requestor Device with the Source Device. Upon receiving a data request from the Requestor Device, the inventive Platform vets the Requestor Device, uses metadata to identify and locate the source storing the required clinical events for retrieval, opens a secure connection at an Endpoint of the identified Source Device, requests a security token from the Source Device, assembles Standards-based API calls, and passes an executable bundle containing the security token and the API call to the Requestor Device. The Requestor Device executes the API call, using the security token to directly retrieve clinical data from the Source Device without the data passing through the inventive Platform of the inventive System.

Description

System for Dynamic, Secure Retrieval of Sensitive Data and Methods ThereofFIELD OF THE INVENTION

[0001] The present invention relates to secure data transmission in healthcare record systems, and, more specifically, to systems and methods to locate data in disparate locations and to securely authenticate and authorize access to Standards- based APIs to obtain data in real time.BACKGROUND OF THE INVENTION

[0002] Healthcare data are protected and governed by federal and state laws to ensure privacy and confidentiality, which must be maintained while providing prompt access to the patient’s healthcare data, since fast access may be lifesaving. Yet, efficient and secure access is difficult because healthcare data are captured and stored in millions of diverse locations, systems, and devices. Different systems and vendors manage and store clinical data differently, z.e., in ways that make seamless exchange impossible. These source entities may include providers, aggregators, Health Information Exchanges (HIEs), electronic medical record (EMR) systems, population health systems, health plan applications, and the like. Data requesting entities may include individuals trying to retrieve their own healthcare data, healthcare providers seeking to obtain data on patients, health insurers needing data on an insuree, government health agencies, and others authorized to obtain confidential data.

[0003] Standards developments are currently being widely adopted. These include the Fast Healthcare Interoperability Resource standard by HL7 (a global industry standard for passing healthcare data between systems) and include rules implementing legislation from the 21stCentury Cures Act of 2016 and the resulting ONC Rule. These standards have facilitated the standardized and real-time exchange of clinical data, regardless of where it is and how it is stored. The Fast Healthcare Interoperability Resource is also known as “FHIR,” which is registered as a US trademark for “downloadable text files containing standards which are used to enable electronic exchange of healthcare documents and information” by Health Level Seven International, Inc. The current (or future) standards developments and the current (or future) rules and regulations to facilitate interoperability in the electronicexchange of healthcare data between requesting and source entities are herein termed “Exchange Standards” and data formatted accordingly is termed “Standards-based data.”

[0004] Authorized data requesting entities can now sometimes employ systems that use the Exchange Standards to access Application Programming Interfaces (APIs) implemented at data sources to access such Standards-based data. But, to comply with government security regulations for exchanging Protected Health Information (PHI), each of these data relationships requires authentication and authorization in real time. This is typically accomplished using the OAuth 2.0 protocol, which may optionally be used with extensions from the open-source SMART framework, which defines launch contexts, specific permissions for accessing types of healthcare data, and standardized OAuth 2.0 flows adapted for healthcare data exchange. Nonetheless, setting up and configuring both requesting entities and data source entities to use current Exchange Standards for enabling data exchange is a time-consuming and expensive investment. Yet, even if both requesting and source entities are configured to use current Exchange Standards, maintaining point-to-point data relationships in a dynamic environment with innumerable requesting and source entities is, in practice, currently not possible. Changing data needs and timing on the requesting entity side, new clinical events at the source entity, and possibly changing endpoints also add to the dynamic nature. This healthcare interoperability scaling problem is sometimes referred to as an m*n problem. Direct point-to-point connections create m*n potential connections, where m (millions of requestor devices, such as, hospitals, clinics, specialists, labs, pharmacies, etc.) times n (millions of source devices, such as EHR systems, clinicians, providers, lab systems, monitoring devices, etc.) would equal trillions of potential connections. Even with the current technology and the latest standards, a scaling problem remains.

[0005] An additional problem is that obtaining healthcare data often requires information that the requesting entity may not have or that may be difficult or impossible to obtain. The requesting entity may not know what data is in existence, what existing data is available, and which source entity might have the data. This is a metadata or ‘completeness’ problem. The metadata / completeness problem is not rare. In most scenarios and use cases, the requesting entity does not have sufficient information to make the appropriate requests for clinical data, since they typicallyhave incomplete metadata about sources that are storing a particular patient’s relevant data and / or what clinical events (e.g., doctor visits, hospital stays, test results) are even in existence. For example, a patient in the emergency room may not remember locations and dates of other medical procedures that may be relevant to the current situation, so the doctors cannot obtain the data needed for optimum treatment. To make all clinical events for each person readily available to a requesting entity, the metadata about these events needs to include sufficient information to make secure, dynamic API calls to access and retrieve those source data, which is not possible with the current implementations of Standards-based data exchange.

[0006] Current, conventional approaches to sharing clinical data attempt to aggregate the clinical data. Examples are HIEs and private companies that collect data from many data sources, house those data, and make the amassed data available to requesting entities. Most notably, the Trusted Exchange Framework and Common Agreement (TEFCA) framework (also a provision of the 21stCentury Cures Act of 2016) is an attempt at an aggregator solution at a national scale in the United States. Even if TEFCA may eventually function as intended, it, or other aggregators, still cannot solve the existing scaling and metadata completeness problems.

[0007] The essential needs of the healthcare system, from providing appropriate and timely care to containing unsustainable growth in healthcare costs, continue to increase. Yet, clinical data cannot currently be exchanged in a way that meets these increasing needs. Requesting entities cannot currently locate and securely retrieve all relevant clinical data in a standard format from any source entity in real time. Though the Standards-based data and APIs are a first step in enabling the real-time exchange of clinical data, they do not solve the scaling and metadata problems.

[0008] The current scaling problem cannot be solved with conventional point-to- point relationships, which are static and difficult to set up and maintain. There is a need for dynamic exchange of clinical data, z.e., providing the ability to create secure just-in-time connections to relevant source APIs when specific data are needed by a requesting entity.

[0009] Further, there is a need to solve the completeness problem of identifying all relevant data with limited metadata available.

[0010] An additional problem is that all requesting entities do not have the technical skills and / or technical support to use the newly implemented Standards- based systems to retrieve needed clinical data. It would be advantageous to provide asystem that enables even non-technical requesting entities to seamlessly and automatically retrieve data.SUMMARY OF THE INVENTION

[0011] The inventive System for Dynamic, Secure Retrieval of Sensitive Data and Methods Thereof (the “System and Methods” or “the invention”) enable secure access to healthcare data exposed via Standards-based APIs via a security token brokering module and methods. The invention enables a Requestor Device 200 (associated with a requesting entity) via a Dynamic Clinical Data Handler 220 to dynamically connect to the APIs at Endpoint(s) 390 of a Source Device 300 (associated with a source entity) at which the relevant Standards-based data is stored and to, further, securely retrieve the Standards-based data. However, the invention does not require the maintenance of point-to-point connections between the innumerable requesting entities needing to access relevant stored data and the equally innumerable healthcare source entities responsible for providing secure storage of clinical data. Instead, the invention acts as a token broker to facilitate a direct data connection between the Requestor’s Clinical Data Handler 220 and the Source’s Endpoint(s) 390. The token brokering without data intermediation has many benefits including improved speed of transmission, enhanced security, reduced cost, and elimination of errors, omissions, and duplication.

[0012] The invention fully automates the retrieval of clinical data via Standards- based APIs. The inventive System is architected as a modular, tiered, scalable, and expandable tech stack that comprises a Dynamic Clinical Data Exchange Platform 100 (“Platform 100”), which includes constituent modules, that facilitates the direct secure connection between the Requestor’s Clinical Data Handler 220 and the Source’s Endpoint(s) 390. (The Endpoint 390 is any API exposed by Source Device 300 that implements the Exchange-Standard, enabling the Standards-based exchange of clinical data.) The inventive System comprises at least the Platform 100, and it preferably comprises Dynamic Clinical Data Handlers 220 deployed to each Requestor Device 200. Preferably, the inventive System further comprises a Clinical Event Capture Service 350 deployed to each Source Device 300.

[0013] In the preferred embodiment, the inventive System and Method allow a Requestor that is registered with the Inventive System, to send a request (from its Dynamic Clinical Data Handler 220) with Personally Identifiable Patient Information(PII) (such as the patient’s first and last name, date of birth (DoB), gender, home address, and the last four digits of a social security number or other identification number) to the inventive Platform 100. The Platform 100 searches for all source locations that have medical records matching the PII to generate a list of source locations, which is returned to the Requestor. The Requestor or Requestor Device 200 selects the records to be retrieved and from which source location the records are to be retrieved. The inventive System conducts Requestor / Source security token authorization for the selected records. Preferably the inventive Platform 100 also calculates any payment required by the Source for the requested records and prompts a Requestor or Requestor Device 200 for payment, if needed. The inventive System then provides a time-based security token, the use of which allows the Requestor’s Dynamic Clinical Data Handler 220 to open a direct session with the Source Device 300 and to receive the clinical records stored by the Source Device 300, without passing the healthcare data through the Platform 100.

[0014] To enable the scalable healthcare data interoperability, the Platform 100 obtains a security token (such as an OAuth access token or a token from another (or a future) delegated and / or distributed authorization system) from Source Endpoint 390 (where the identified data is stored), assembles an API call to facilitate the connection of the Requestor Device 200 to the Endpoint 390, and combines the retrieved security token, the relevant clinical events to be retrieved, and the fully assembled API call into an executable bundle that is passed to the Clinical Data Handler 220 for execution. The Clinical Data Handler 220 runs each bundle against the appropriate Exchange- Standard Endpoint 390 with the appropriate queries. The Clinical Data Handler 220 instantly establishes a connection with the Endpoint 390 using the endpoint information and the security token provided in the executable bundle, makes the Standards-based API call, and retrieves the relevant data without data intermediation by the Platform 100.

[0015] By managing and encapsulating all the endpoint-specific information, standardizing the output format for the Requestor, and providing an executable bundle, the inventive System makes the retrieval of clinical data completely automated and seamless for the requesting entity. This fully optimizes flexibility, scalability, and productivity for requesting entity at an unprecedented level. Therefore, even if the requesting entity lacks technical skills or support, therequesting entity can obtain the needed clinical data through the automatic data retrieval process provided.

[0016] In more detail, to obtain the security token, the Dynamic Clinical Data Exchange Platform 100 comprises a Security Token Broker (Steps 2d to 2g of Subprocess 2 below) for obtaining the security token from the Source Device 300 (which has been identified as having relevant data). The Security Token Requestor L5 requests (Step 2e) a security token from a Source Endpoint 390 to be used in dynamic API calls, without maintaining a persistent connection. After inspecting the validity of the request, the Endpoint 390 will issue (Step 2f) a time-limited security token to the Security Token Requestor L5, which will transmit (Step 2g) the security token to a Clinical Event Query / Data Request Handler LI of the Requestor Device 200.

[0017] To create the executable bundle, an API Call Assembler L6 assembles (Step 3c of Subprocess 3 below) the Exchange- Standard API calls based on data that the Platform 100 stores about Exchange- Standard APIs of Source Endpoints 390 and on information about the Clinical Event Query / Data Request Handler LI of the Requestor Device 200. The API Call Assembler L6 passes (Step 3d) the fully assembled API call to the Clinical Event Query / Data Request Handler LI. The Clinical Event Query / Data Request Handler LI assembles (Step 3e) an executable bundle containing the security token and the API call and then passes the executable bundles to the Requestor’s Clinical Data Handler 220.

[0018] The Clinical Data Handler 220 executes the API calls directly to Source Endpoint 390 (using the Source-specific API calls and security tokens). This establishes a secure connection to the Exchange- Standard APIs of the Source Endpoint 390 and enables the dynamic, secure retrieval of the relevant healthcare data.

[0019] Since the Dynamic Clinical Data Exchange Platform 100 serves as a central trusted proxy service that brokers authentication without data intermediation, temporary data access relationships between the Requestors and the Sources are enabled. There is no longer a need to go through the prohibitively slow and expensive process of establishing and maintaining a data relationship between every possible Requestor and Source. Thus, the scaling m*n problem is solved.

[0020] By separating the security token broker and the API call assembly from the actual data retrieval, the Platform 100 completely avoids touching PHI, whichensures that Sources do not consider the Platform 100 an aggregator (which assures the Sources that the inventive System could not possibly profit from data stewarded by the system). The ultimate control of who receives the data from the Source is left in the ultimate control of the Source. This separation of the Platform 100 from the direct data connection between the Requestor Device 200 and the Source Device 300 also effectively eliminates a possible attack surface for PHI hacks and leaks.

[0021] In a preferred embodiment, the present invention also facilitates the location of the relevant data that needs to be retrieved. In this embodiment, the inventive System further comprises a Person-Level Clinical Event Locator (Steps lb to li, Subprocess 1) that enables the Requestor Device 200 to programmatically locate the Source Endpoint(s) 390 at which the relevant healthcare data is stored. In this embodiment of the invention with locator functionality, a Clinical Event Locator module enables a Requestor Device 200, via its Dynamic Clinical Data Handler 220, to query a metadata directory (Clinical Event Metadata Directory DI) that will return any clinical event data meeting the criteria that was input as a query into the Requestor Devices 200 by the Requestor. (The Requestor may be a human user, a type of artificial intelligence, a computer program, or the like.) That complete set of clinical data returned from the Clinical Event Metadata Directory DI is used by the Requestor and / or Requestor Device 200 as a basis for the identification of a subset of events for which a request for clinical data needs to be made. This step of requesting clinical data is initiated by the Clinical Data Handler 220 with a second API call to initiate the Security Token Broker service, which in turn will initiate the Dynamic API Call Assembler L6. This embodiment of the invention is functional to locate all records by inventorying clinical event metadata and querying the inventoried data, which solves the problem of missing important or critical data. This locator functionality solves the metadata and / or completeness problem.

[0022] In another embodiment of the invention, the Dynamic Clinical Data Exchange Platform 100 further comprises a Fee Clearing Service (Steps 4a to 4e) that determines any costs of clinical data requests, checks the authorization and available funds / credit line associated with the Requestor Device 200, and then records incurred costs in a ledger tracking all liabilities associated with Requestor Devices 200 and any fees owed to source entities. This service automates and makes dynamic the payment aspect for clinical data requests, eliminating the need for one- off payment arrangements between Requestor Devices 200 and Source Devices 300.This functionality solves the scaling problem related to the financial aspect of clinical data exchange.

[0023] Another embodiment adds ongoing event transmission functionality. In this embodiment, the Dynamic Clinical Data Exchange Platform 100 further comprises a Clinical Event Subscription Emulator Service (Steps 5a to 5g) that allows Requestor Devices 200 to ‘subscribe’ (request to receive newly created clinical records) to clinical events that meet certain query parameters (e.g., all ‘my’ medical records for a person / consumer, all patient records for members of a health insurance plan, etc.). This functionality emulates a subscription service in which a Requestor Device 200 would subscribe to every Source Device 300 to obtain new encounter data (based on metadata matching the query parameters) by maintaining connection relationships between the Requestor Device 200 and every Source Device 300 that might ever have a clinical record of interest. But a true subscription service of this kind would result in the m*n problem. This invention solves this m*n problem, by allowing the Requestor Device 200 to sign up to receive “abstract events” via the Subscription Emulator Service. The abstract events may be future events and may occur at sources that are unknown or at sources with which the Requestor has no relationship. But by using the Subscription functionality, the Requestor can receive new clinical data within seconds of the creation of the data - without maintaining a connection to the Source Device 300, and even without having an established data relationship with the Source Device 300.

[0024] In an embodiment, the inventive System further comprises a Clinical Event Update service that captures clinical events at Source Devices 300 in real time and transmits them to the Platform 100, ensuring that the clinical events in the centralized Clinical Event Metadata Directory DI are always complete and current.

[0025] In a further embodiment, the inventive System further comprises an Administrative Module with a web-based UI that is used to allow administrators (Source Admin 301) associated with the Source Devices 300 and administrators (Requestor Admin 201) associated with the Requestor Devices 200 to register their organizations with the inventive System and to maintain administrative information required for these entities to participate in the advantages of the instant invention.

[0026] In summary, the present invention solves the problems currently preventing efficient secure exchange of clinical data between source entities and requesting entities. The invention solves the scaling problem by enabling the Requestor Device200 to request dynamic, real-time access to healthcare data corresponding to identified metadata without setup and maintenance of a connection with a data Source Device 300. To provide this functionality, the Platform 100 acts as a central connection and trust broker, facilitating security token generation, and providing dynamic API calls.

[0027] The embodiment of the invention that includes the locator service solves the metadata / completeness problem by capturing and inventorying metadata about all clinical events from Source Devices 300 and by enabling a Requestor Device 200 to identify relevant healthcare data from the stored metadata that is made available.

[0028] One object of the invention is to provide a specialized Security Token Broker Module that facilitates just-in-time, temporary data relationships in a dynamic environment between requesting entities and source entities in real time, without maintaining static point-to-point connections between the innumerable requesting entities and source entities. This solves the scaling problem of the current healthcare data retrieval system.

[0029] Another object of the invention is to efficiently capture and store metadata in an accessible manner, to identify the location of the Source Device 300 storing needed healthcare data, and, thereby, to allow a Requestor Device 200 to connect to a Source Device 300 storing needed healthcare data - even without any prior knowledge of the existence of the data or the identity of the data location. This solves the metadata and / or completeness problem of the above-described prior art systems and methods.

[0030] These and other objects, features, and advantages of the present invention will become more readily apparent from the attached drawings and from the detailed description of the preferred embodiments which follow.BRIEF DESCRIPTION OF DRAWINGS

[0031] FIG. 1 is an overview diagram of the major processing devices utilized by the inventive System for Dynamic, Secure Retrieval of Sensitive Data and Methods Thereof and of their interactions including the Dynamic Clinical Data Exchange Platform 100, the Requestor Device 200, and the Source Device 300.

[0032] FIG. 2 is a detailed illustration of the devices, logic components, and data storage components of the invention. It also shows interactions between the DynamicClinical Data Exchange Platform 100, the Requestor Device 200, the Source Device 300, and other components.

[0033] FIG. 3 is a sequence diagram that shows Steps la to li of Subprocess 1 including the Person-Level Clinical Event Locator service (Steps lb to li).

[0034] FIG. 4 is a sequence diagram that shows Steps 2a to 2g of Subprocess 2 including the Security Token Broker Module (Steps 2d to 2g).

[0035] FIG. 5 is a sequence diagram that shows Steps 3a to 3h of Subprocess 3 including the Dynamic API Call Assembler (Steps 3a to 3d).

[0036] FIG. 6 is a sequence diagram that shows Steps 4a to 4e of Subprocess 4 illustrating the Fee Clearing process.

[0037] FIG. 7 is a sequence diagram that shows Steps 5a to 5i of Subprocess 5 illustrating the clinical event subscription emulator process using the Clinical Event Subscription Service L8B.

[0038] FIG. 8 is a sequence diagram illustrating the Steps Illa to Ulf of the Clinical Event Metadata Update process.DETAILED DESCRIPTION OF THE INVENTION

[0039] In overview, the inventive System for Dynamic, Secure Retrieval of Sensitive Data and Methods Thereof enable a Requestor Device 200 to retrieve clinical data from any Source Device 300 by using the Dynamic Clinical Data Exchange Platform 100, which serves as a trusted proxy for the Requestor Device 200. As seen in the FIG. 1 overview of the inventive System, the inventive System comprises a Platform 100 that interacts with Dynamic Clinical Data Handlers 220 (each deployed to a Requestor Device 200). Preferably the inventive System further comprises Clinical Event Capture Services 350 (each deployed to a Source Device 300). The Platform 100 properly vets the Requestor Device 200 that has made a data request and then applies to the Source’s Endpoint(s) 390 to request and receive a security token. The Platform 100 assembles Exchange-Standard API calls and passes an executable bundle containing the security token and the API call to the Requestor’s Clinical Data Handler 220. The Clinical Data Handler 220 executes the executable bundle, which allows it to directly and securely connect to the Endpoint(s) 390 using the security token from the Platform 100 (without the Platform 100 acting as an intermediary between the Clinical Data Handler 220 and the Endpoint(s) 390).This allows the Requestor Device 200 to retrieve the relevant clinical data from the Source Device 300.

[0040] The Source Device 300 represents any computing device of a source entity that uses the inventive System’s functionalities and Exchange Standard capabilities to participate in the dynamic exchange of healthcare data that is enabled by the Platform 100. The modules of the inventive System that are used by the Source Device 300 are preferably both locally deployed (Clinical Event Capture Service 350 and Exchange- Standard Endpoint 390) and cloud-based (Dynamic Clinical Data Exchange Platform 100). Healthcare data is captured and stored in a manner that allows the Source Device 300 to provide the healthcare data in Exchange-Standard format when appropriate API calls are made.

[0041] The Requestor Device 200 comprises any computing device of a requesting entity that uses the inventive System’s functionalities and Exchange- Standard capabilities to participate in the process of dynamically obtaining healthcare data. The modules of the inventive System that are used by the Requestor Device 200 are preferably both locally deployed (Dynamic Clinical Data Handler 220) and in the cloud (Platform 100). The Requestor Device 200 is a recipient of clinical data in a standard format from the Source Device 300. The current healthcare data standards employ a Resource-based architecture that structures clinical information through discrete, well-structured components called "data elements," each containing specific values and metadata. This approach transforms complex healthcare information into manageable, standardized units. For example, a Patient Resource includes basic patient demographics, contact information, and data relationships, such as links to a clinician or organization. The relational connections between associated Resources allow complex structures to be built. The current Standards-based Resources utilize Uniform Resource Locators (URLs) as unique identifiers to enable precise location. The technical implementation relies on standard web formats, specifically XML and JSON, which serve dual purposes. These formats provide robust machine-readable structures for automated processing while maintaining human readability.

[0042] As shown in detail in FIG. 2, the embodiments of the inventive System comprise some or all of the following logic components: Clinical Event Query / Data Request Handler LI, the Person / Patient Matching Module L2, the Clinical Event Lookup L3, the Clinical Event Update Handl er / Service L4A and L4B, the Security Token Requestor L5, the API Call Assembler L6, the Fee Management Service L7,the Clinical Event Subscription Service / Handler L8A and L8B, and the Admin Module L9A and L9B. The embodiments of the inventive System comprise some or all of the following databases: Clinical Event Metadata Directory DI, Person / Patient Master Database D2, Provider Master D3, Endpoint Directory D4, Source Master Database D5, Requestor Master D6, Payer Master D7, Fee Management Database D8, Clinical Event Subscription Data D9, and Audit Trails and BAM Database DIO. The embodiment of the invention providing the maximum functionality comprises all logic components and all databases.

[0043] The Dynamic Clinical Data Handler 220 is a component that is deployed to the Requestor Device 200. It handles a number of functions including the interaction with the Dynamic Clinical Data Exchange Platform 100 and API calls directly to Exchange- Standard Endpoints 390, as well as interactions / integration with modules internal to the Requestor Device 200.

[0044] The Clinical Event Capture Service 350 is a component that is deployed to the Source Device 300. The Clinical Event Capture Service 350 functions to assist in detecting and processing new clinical events via integration with clinical data sources at the Source Device 300 in real time (as well as other interactions / integration with modules internal to the Source Device 300). Then it securely transmits metadata about new clinical events to the inventive System’s platform 100 (Process III).

[0045] In one aspect of the invention, the Dynamic Clinical Data Handler 220 and the Clinical Event Capture Service 350 are applications installed in an isolated environment, such as in containers (partially virtualized environments similar to lightweight virtual machines) with portable application images run using the operating system kernel of the Requestor Device 200 or Source Device 300.Although the use of containers is not critical to the invention, it is preferred due to the advantages they provide, such as higher efficiency, elimination of “it works on my machine” development-production parity problems, consistent environment, rapid development and deployment, scalability, minimal impact on the host device, and a short launch time (only starting a process, not an entire operating system). In an aspect of the invention, the container is a Docker container run by a Docker engine installed at the Requestor Device 200 or Source Device 300.

[0046] The Clinical Event Query / Data Request Handler LI provides API services, initially, to clinical event queries and, subsequently, to data requests. Handler LI operates as a dedicated external-facing handler of the Dynamic Clinical DataExchange Platform 100. It functions as an interface layer, with all core business logic and data access operations delegated to internal logic components (L2, L3, and L6). This architectural separation enables the deployment of firewall infrastructure between external-facing and internal components. By isolating the external interface from core business logic, the system implements security best practices through segmentation between modules and controlled access to internal modules. This design ensures that external requests are properly validated and sanitized before being processed by internal modules, maintaining both operational security and system integrity.

[0047] The preferred embodiment comprises the Person / Patient Matching Module L2 that serves as the identity resolution component within the Platform 100 as a step in providing locator functionality to the system. This module receives (from Clinical Event Query / Data Request Handler LI in Step lb below) person identifying information extracted from clinical event queries and executes (Step 1c) matching logic to establish accurate person identity matches within the Person / Patient Master Database D2. Healthcare person matching is complex because healthcare data may be incomplete, inconsistent, or erroneous. The Person / Patient Matching Module L2 utilizes state-of-the-art patient matching algorithms. It may employ one or multiple complementary algorithmic approaches to achieve accuracy in patient identification while accommodating the inherent complexities and data quality challenges inherent in healthcare data systems. In one aspect of the invention, deterministic matching is employed, which uses exact matching algorithms using specific data elements, such as name, address, birthday, identification numbers, medical record numbers, and the like. In another aspect of the invention, probabilistic matching is used. It assigns weighted scores to various demographic and identifying elements, such as, for example, demographic data (such as name variations, date of birth, gender, address history), contact information (such as phone numbers, email addresses, emergency contacts), clinical identifiers (insurance member IDs, provider-specific patient numbers), and, if available, biometric elements (such as fingerprints or other unique biological markers). In a further aspect of the invention, the Person / Patient Matching Module L2 may use fuzzy logic to handle common data variations such as nickname usage (Robert / Bob, Richard / Dick, etc.), phonetic similarities, transposed characters, and cultural name variations. In an additional aspect of the invention, the Person / Patient Matching Module L2 uses machine learning to improve matchingaccuracy by learning from manual review decisions and identifying patterns in successful matches. Preferably, the L2 module implements a comprehensive matching workflow that balances accuracy requirements with system performance needs. In one aspect of the invention, upon receiving the person-identifying parameters (from the Clinical Event Query / Data Request Handler LI), the Person / Patient Matching Module L2 implements patient matching using multiple algorithmic approaches, by performing probabilistic matching with weighted scoring of demographic elements, applying fuzzy logic to handle data variations and common name alternatives, and / or utilizing machine learning algorithms that improve matching accuracy based on manual review decisions. The Module L2 applies one or more matching algorithms until either a match is established with required confidence (upon which a Person Key is returned (Step Id) to the Handler LI) or an empty result set is returned. This systematic approach ensures that personidentifying parameters are accurately matched with relevant clinical events.

[0048] The encrypted Person / Patient Master Database D2 holds the information about persons / patients to allow the Person / Patient Matching Module L2 to match (Step 1c) the queries originating from the Requestor Device 200 to relevant clinical events. This information may be updated and optimized, as needed, to enable the best practices in patient matching. To add another layer of protection to the personally identifiable information (PII), encryption / decry ption is implemented for the Person / Patient Master Database D2. All PII (such as first name, last name, date of birth, gender, and current address) used in industry-standard patient matching algorithms are encrypted in transit and at rest in compliance with federally approved encryption standards. These encryption standards preferably include Transport Layer Security (TLS) versions 1.2 or 1.3 and Advanced Encryption Standard (AES) with a 256-bit key (AES-256), which ensure data confidentiality and integrity in compliance with HIPAA and NIST security standards. The PII data are also stored in a manner separate and apart from any clinical event identifiers; and those clinical event identifiers are also encrypted in transit and at rest using the same technologies as the PII transport / storage.

[0049] TLS provides confidentiality, integrity, and authentication through a series of mechanisms, including public key cryptography, symmetric encryption, and cryptographic hash functions. The steps for securing healthcare data in transit may include initiating a TLS handshake between a client and a server, verifying digitalcertificates, establishing a shared symmetric key using RSA or DHE key exchange, encrypting data at the transport layer using AES or AES-GCM, and verifying integrity using Hash-based Message Authentication Code (HMAC) or Authenticated Encryption with Associated Data (AEAD).

[0050] The healthcare data are encrypted using AES-256 encryption before transmission over secure channels or public channels. The inventive System includes components for key generation, data serialization, encryption, secure transport, decryption, and key management. In an example, an AES-256 Encryption Engine accepts 128-bit blocks of plaintext healthcare data, uses a 256-bit symmetric key, an performs multiple rounds of encryption including SubBytes, ShiftRows, MixColumns, and AddRoundKey operations. A Data Preparation Module extracts PHI and other structured data from an EHR or clinical data source and formats data into a FHIR-compliant JSON or XML object. A Key Management System generates and securely stores 256-bit AES keys, optionally uses a hybrid encryption model where the AES key is encrypted using RSA-4096 or ECC public key and is shared with the intended recipient, and ensures periodic key rotation and revocation. A Transmission Layer allows data to be transmitted via HTTPS or another secure transport system. The encrypted data may be embedded within Exchange- Standard Resources or encapsulated in encrypted payloads. A Decryption Module decrypts the AES key using the recipient's private key if hybrid encryption is employed, uses the decrypted AES key to decrypt the data block-by-block, and verifies integrity using HMAC or SHA-256 checksum. The inventive System optionally includes an AES- GCM Mode that implements a Galois / Counter Mode for authenticated encryption, ensuring integrity along with confidentiality.

[0051] The Requestor’s Handler LI passes (Step le) the person matching results (the Person Key determined by the Person / Patient Matching Module L2 received in Step Id) along with specific query parameters to the Clinical Event Lookup Module L3. Then the Clinical Event Lookup Module L3 executes (Step If) searches across Clinical Event Metadata Directory DI to locate all relevant healthcare events associated with the identified patient.

[0052] The Clinical Event Metadata Directory DI is a database storing the clinical event metadata, which is needed to provide person / patient level information about the existence and the location of clinical data in the inventive ecosystem. It also ties together related information such as patient / member, provider / system, endpoint, andpayer information. The Clinical Event Metadata Directory DI needs to be “fed” with metadata from clinical data sources (such as preferably via Clinical Event Capture Service 350). The metadata comprises PII patient matching elements (for example, patient first / last name, date of birth (DoB), gender, home address, last four digits of social security number, and the like) and further comprises one or more of the event date and time, clinical event types (for example, inpatient, outpatient, specialist, lab, etc.), and source location identifiers.

[0053] After the Clinical Event Lookup Module L3 has located all healthcare events relevant to the query, the result set is returned (Step Ih) to the Clinical Event Query / Data Request Handler LI which will return (Step li) the results set to the Requestor’s Dynamic Clinical Data Handler 220. The Requestor and / or the Requestor Dynamic Clinical Data Handler 220 will select (Step 2a) the clinical event data to be retrieved and then pass (Step 2a) that ‘clinical events-for-retrieval’ list or subset to the Clinical Event Query / Data Request Handler LI. The Handler LI uses the clinical events-for-retrieval list to determine (Step 2d) which Endpoints 390 will need to be contacted to retrieve the clinical event data needed and then passes (also Step 2d) the list of Endpoints 390 to the Security Token Requestor L5.

[0054] The Security Token Requestor L5 receives this data request (a list of Endpoints 390) from Handler LI, opens secure connections with the Endpoints 390, and makes security token requests for each of the Endpoints 390 from which the Requestor wants to receive data. Though FIG. 2 shows Security Token Requestor L5 opening a secure connection with only one Endpoint 390, multiple Endpoints 390 at multiple Sources may be opened based on the list of Endpoints 390 passed from the Handler LI. The inventive System has previously established a reputation with the Source Device 300, and the Source Device 300 trusts that the inventive System will ensure that the Requestor Device 200 (and each request from that Device 200) is legitimate and trustworthy. This is accomplished through the initial vetting of the Requestor Device 200 during onboarding and through ongoing monitoring, which preferably includes verifying that the Requestor Device 200 has been given the authority to request a given encounter (to the extent that it is verifiable). The type of consent used may be ‘implied consent,’ as it is currently used in the healthcare field such as when the Requestor has blanket authorization from the person / patient to access clinical data. Since the Source Device 300 trusts the Security Token Requestor L5 when it makes a token request, the Source Device 300 returns a security token.

[0055] The Security Token Requestor L5 receives the security token(s) and passes (Step 2g) the retrieved security token(s) to the Clinical Event Query / Data Request Handler LI. This actuates the Handler LI to pass (Step 3a) the clinical event information to the API Call Assembler L6.

[0056] The API Call Assembler L6 retrieves (Step 3b) endpoint-related information (such as configuration data) for the relevant Endpoint 390 from the Endpoint Directory Database D4, and it also retrieves (Step 3c) relevant requestor- related information about the Dynamic Clinical Data Handler 220 (including the desired output format defined by the Exchange-Standard version) from the Requestor Master D6. The API Call Assembler L6 combines this retrieved API endpoint configuration data, and Handler 220’ s requirements and constructs standards- compliant API calls formatted according to the established healthcare data exchange protocols. The Exchange- Standard APIs organize clinical data into discrete Resources such as, for example, Patient, Encounter, Observation, DiagnosticReport, and Medication. The API Call Assembler L6 will consider these resources and relationships and construct API calls that can correctly retrieve the expected complete clinical data sets while respecting the Exchange Standard’s architecture. The API Call Assembler L6 assembles and then passes (Step 3d) the fully assembled API calls (that will enable Requestor Devices 200 to execute (Step 3g) precise, targeted data retrieval operations) back to the Handler LI. The Handler LI combines the security token received from the Security Token Requestor L5 (Step 2g), information about the relevant clinical events to be retrieved, and the fully assembled API call and bundles them into an executable bundle for automated execution. The Handler LI passes the executable bundles to the Requestor’s Dynamic Clinical Data Handler 220.

[0057] The Exchange-Standard Endpoint Directory D4, mentioned above, lists all endpoints known in the ecosystem (syndicated by the inventive System) and / or captured in the onboarding process of the Source Device 300. This information is needed to programmatically evaluate and access Exchange- Standard APIs at the Endpoints 390 of the Sources.

[0058] Another database, Provider Master D3, supplements the Endpoint Directory D4 as well as ancillary lookups, e.g., in onboarding new Source Devices 300. The Provider Master D3 contains all known providers (source entities), systems at all relevant levels with their primary (and any secondary) identifiers such as NationalProvider Identifier (NPI), and other information. This information will be populated and updated frequently from sources such as from the Centers for Medicare and Medicaid Services (CMS), the National Plan and Provider Enumeration System (NPPES), NPI, and other government or regulatory agencies responsible for issuing or organizing healthcare provider identifiers.

[0059] In the embodiments comprising a Fee Management Service L7, the Fee Management Service L7 is a module that manages the complex, multi-stakeholder economic relationships that govern access to clinical information across distributed healthcare networks. Stakeholders include patients, providers (such as clinicians or health systems), payers (such as health plans or government agencies), researchers, and technology vendors; each have distinct economic interests that must be balanced to create sustainable, equitable access to clinical information while incentivizing data sharing and interoperability. Thus, though optional, the Fee Management Service L7 provides advantages in a fully automatic system.

[0060] The Fee Management Service L7 may process incoming data requests through fee calculation algorithms, validate requestor financial standing and authorization parameters, reconcile source / provider compensation requirements, and execute real-time financial transactions that enable seamless healthcare data commerce while maintaining audit controls and regulatory compliance. The Fee Management Service L7 checks the fee schedules for the source entity, checks the requesting entity’s fee parameters and balances, and either clears the fees and updates the balances of the requesting entity and source entity or issues an appropriate message to the Requestor Device 200 that the fee cannot be processed, which might occur due to lack of funds or due to a rule exception of the Requestor Device 200.

[0061] In the embodiments that provide the subscription functionality, the Platform 100 further provides a Clinical Event Subscription Emulator service (Steps 5a to 5g) that enables sophisticated, real-time monitoring and automated delivery of healthcare data to authorized subscribers. This subscription functionality provides proactive, event-driven data delivery mechanisms that can respond immediately to clinical events rather than relying solely on reactive query-response patterns. This subscription service provides for prompt availability of critical clinical information while implementing privacy protection and regulatory compliance. This subscription framework allows Requestor Devices 200 to establish persistent monitoring arrangements for clinical events that satisfy specific query parameters,enabling proactive healthcare data delivery for diverse use cases, such as for patientcentered care coordination, population health management, insurance member monitoring, and research cohort tracking.

[0062] The Clinical Event Update Handler L4A and Clinical Event Update Service L4B operate as a real-time ingestion and synchronization service within the inventive System providing comprehensive event-driven capabilities for maintaining current, accurate clinical event information.

[0063] The Clinical Event Update Handler L4A is a ‘listener’ module that exposes APIs to be called by Source Devices 300 whenever there is a new clinical event that needs to be logged into the Clinical Event Metadata Directory DI. This external Handler L4A provides scalable interfaces that enable Source Devices 300 to reliably transmit clinical event notifications to the Platform 100. Preferably the clinical event data is communicated using the current Exchange- Standard protocols and standards, but the Handler L4A can optionally be configured to receive data communicated via other exchange protocols, such as via direct messaging, proprietary APKs, HL7v2, and new or emerging healthcare communication standards. When a new event is received, the Clinical Event Update Handler L4A performs the necessary updates to the Clinical Event Metadata Directory DI.

[0064] The Clinical Event Subscription Service / Handler L8A and L8B monitor new entries in the Clinical Event Metadata Directory DI (such as by implementing efficient change detection algorithms that can identify new clinical events immediately upon their availability) and determine if any Requestor subscriptions match the new entries. For any matches, the service then automatically executes the data request steps of the Clinical Event Update Service L4B and Security Token Requestor L5 and ‘fires’ an event to a listener module at the subscribing Requestor Device 200 (which is preferably provided in the System’s SDK or Integration Toolkit) for further processing. This Logic component has two parts - an externally facing Handler L8A and the core business logic, Clinical Event Subscription Service L8B, that also accesses data, separating the internal and externally facing components for security.

[0065] The Admin Module L9A and L9B handles all onboarding of Source Devices 300 and Requestor Devices 200 (via User Interfaces (UI) and APIs), account and credentials management of the Source Devices 300 and Requestor Devices 200, and other administrative functions. This logic component also has two parts - anexternally facing, web-based user interface and the core business logic, which provides advantages in maintaining the security boundaries.

[0066] Various functionalities of the inventive System for Dynamic, Secure Retrieval of Sensitive Data and Methods Thereof are enabled by the following Subprocesses (also referred to as modules). Though the inventive System for Dynamic, Secure Retrieval of Sensitive Data and Methods Thereof may preferably be implemented with the full functionality described in the Subprocesses below, the inventive System and Methods can be employed with less than the full complement of functionality. For example, in one embodiment, the inventive System and Methods may be implemented without the Fee Clearing Using Fee Management Service L7 (which may be implemented at a later date, if desired). In a second embodiment, the inventive Systems and Methods may be implemented without the functionality provided by the Clinical Event Subscription Emulation Using Clinical Event Subscription Service L8B (which may be implemented at a later date, if desired).SUBPROCESS 1 (Steps la to li): Person-Level Clinical Event Locator (Steps lb to li), shown in FIG. 3:

[0067] Step la - The Requestor Device 200 uses an implementation of the Dynamic Clinical Data Handler 220 and the security credentials issued during the onboarding process, to assemble a query for the sought clinical data, which contains, for example, PII, a date range for which clinical events are sought, and possibly additional parameters (e.g., which type of clinical event: inpatient, outpatient, specialist, lab, etc.). Then the Handler 220 opens an authenticated encrypted session (such as using TLS) with the Clinical Event Query / Data Request Handler LI and passes the query.

[0068] Step lb - The Clinical Event Query / Data Request Handler LI passes the person-identifying parameters to the Person / Patient Matching Module L2.

[0069] Step 1c - The Person / Patient Matching Module L2 uses person matching logic combined with querying the Person / Patient Master Database D2 (which is encrypted for protection of PII data) to find a possible match.

[0070] Step Id - If a match can be established with the required confidence, Person / Patient Matching Module L2 returns a Person Key to the Clinical Event Query / Data Request Handler LI; if no match with the required confidence is established, an empty result set is returned.

[0071] Step le - If a Person Key has been returned, the Clinical Event Query / Data Request Handler LI passes the Person Key along with other query parameters to the Clinical Event Lookup L3.

[0072] Step If - The Clinical Event Lookup L3 queries Clinical Event Metadata Directory DI for any clinical events that match the Person Key and the other query parameters.

[0073] Step 1g - The Clinical Event Lookup L3 preferably then queries the Payer Master D7 for any Payer information that may further specify the clinical event information / request. The Payer Master D7 is a database storing information about all known payers. It will be used to the extent possible to tie clinical events / encounters to the health plan covering the person for specific dates or date ranges, also known as Date of Service (DoS).

[0074] Step Ih - The Clinical Event Lookup L3 returns the results set to the Clinical Event Query / Data Request Handler LI; if no clinical event that matches the Person Key and the other query parameters is established, an empty result set is returned.

[0075] Step li - If no Person Key has been returned by Person / Patient Matching Module L2, as defined in Person / Patient Master Database D2, or if an empty result set has been returned by the Clinical Event Lookup L3, the Clinical Event Query / Data Request Handler LI will return the appropriate results code and an empty result set to the Dynamic Clinical Data Handler 220; otherwise it will return the results set to the Dynamic Clinical Data Handler 220 and allow display or automated processing of the results set on the Requestor Device 200 for the requesting entity to view and / or allow the Requestor Device 200 or a type of logic or artificial intelligence to otherwise programmatically process the results set to decide if the information about the clinical event is needed (for example, at times, the Requestor already has the information about a particular clinical event, so does not need it retrieved). The results set may contain any clinical events that match the Person Key, which may include one or more of the following: type of service, date(s) of service, and provider information that corresponds to the clinical event, and, optionally, other information regarding the clinical event requested.

[0076] Step Ij - If the results set is empty, or if the requesting entity does not decide to retrieve any Clinical Event data, Requestor Device 200 will close theconnection (or if idle for more than 15 minutes from the time of the request, preferably, the Requestor Device 200 session times out and terminates).

[0077] This completes Subprocess 1: Person-Level Clinical Event Locator.SUBPROCESS 2 - Security Token Broker, shown in FIG. 4:

[0078] Step 2a - With the results set of Step Ih, Requestor Device 200, via Dynamic Clinical Data Handler 220, will (such as through a generic or use-case specific and automated routine and preferably using the same secure session already established in Step la), select which clinical event data, if any, should be retrieved, and then pass that ‘clinical events-for-retrieval’ subset to the Clinical Event Query / Data Request Handler LI. The number of clinical events to be retrieved varies. A single clinical event may be located at a single Endpoint 390. Or one clinical event may be located at one Endpoint 390 with another clinical event located at a different Endpoint 390. Or multiple clinical events may be located at the same Endpoint 390.

[0079] Step 2b + 2c: The Clinical Event Query / Data Request Handler LI preferably calls Fee Management Service L7 to determine the costs of the requested clinical event data and whether those costs are covered and cleared. (This optional, but preferred, functionality is further described below in Subprocess 4 - Fee Clearing using Fee Management Service L7.) If an exception is flagged, Clinical Event Query / Data Request Handler LI will return the appropriate exception message to the Requestor Device 200 for exception handling. The exception handling may be handled via decisions made manually or programmatically, such as by a human Requestor, an artificial intelligence Requestor, or a computer program.

[0080] Step 2d - The Clinical Event Query / Data Request Handler LI determines from the returned clinical events set which Endpoints 390 will need to be contacted to retrieve the desired clinical event data to return to the Requestor Device 200. Then the Clinical Event Query / Data Request Handler LI passes the list of one or more endpoints set to Security Token Requestor L5.

[0081] Step 2e + 2f - The Security Token Requestor L5 will then open secure connections (such as by using TLS versions 1.2 / 1.3) with each Endpoint(s) 390 that has been determined to have the clinical events to be retrieved. The Security Token Requestor L5 then, for each Endpoint 390 from list of one or more endpoints set, (1.) requests security token(s) based on the detailed endpoint versioning and otherinformation stored in the Exchange-Standard Endpoint Directory D4 from the Source’s Endpoint 390 API implementations, (2.) receives the security token(s) from the Endpoint 390, and (3.) closes the connect! on(s).

[0082] Step 2g - The Security Token Requestor L5 passes the retrieved security tokens to the Clinical Event Query / Data Request Handler LI for further processing (see Step 3a below).

[0083] This completes Subprocess 2 - Security Token Broker.SUBPROCESS 3 - Dynamic Exchange-Standard API Calling Using Dynamic API Call Assembler L6 (Steps 3a to 3d), shown in FIG. 5:

[0084] Step 3a - Triggered by Step 2g (and by no exceptions returned in Step 2g), the Clinical Event Query / Data Request Handler LI will pass the clinical event information (which includes the previously defined data elements in pre-requisite Step la) to API Call Assembler L6. Preferably, this clinical event information includes specific Standards-based resource requirements and scope limitations that will determine the minimal data access permissions needed for the request.

[0085] Step 3b - The API Call Assembler L6 retrieves all relevant endpoint- related information from Exchange- Standard Endpoint Directory D4 which includes relevant Exchange- Standard versions and other connection and content-related information. For example, it may include Endpoint capability statements containing authorization endpoints (such as / .well-known / smart-configuration, / .well- known / udap, and / .well-known / openid-configuration), supported scopes (such as patient / , user / , system / *), available launch contexts (such as patient (launch / patient) and encounter (launch / encounter)), and OAuth 2.0 flow specifications for each Standards-based Endpoint 390.

[0086] Step 3c - The API Call Assembler L6 retrieves relevant requestor-related information from the Requestor Master D6. The Requestor Master D6 is a database containing all data of formally onboarded active and inactive Requestor Devices 200, that enables Requestor Devices’ secure queries and data requests and administrative functions including fee clearing. Although capturing different information, the data of the Requestor Master D6 overlaps to a degree with the data of the Source Master Database D5 (a database that contains all information about providers / systems that are formally onboarded with the inventive System), because numerous Source Devices 300 can also be registered as Requestor Devices 200.

[0087] The relevant requestor-related information that the API Call Assembler L6 has retrieved from the Requestor Master D6 contains information about the Dynamic Clinical Data Handler 220, which includes the proper output format (Exchange- Standard version) for internal processing. In an example, this Requestor Master D6 information may further include pre-registered client credentials (client id, redirect uri, public keys), approved scope templates based on the Requestor's role and use case, and launch context preferences (patient-facing vs. provider-facing applications). Then the API Call Assembler L6 assembles Exchange- Standard API calls for each Endpoint 390 and all relevant clinical event records to be retrieved at that Endpoint 390. In an example, the API Call Assembler L6 follows least privilege access principles and constructs minimal scope requests such as, for patient-specific queries: patient / Observation.read patient / Condition.read patient / Patient.read.

[0088] Step 3d - The API Call Assembler L6 assembles one or more Exchange Standard-compliant API calls and passes fully assembled API calls back to the Clinical Event Query / Data Request Handler LI for further processing. A fully assembled API call contains the parameters and syntax to execute the API calls in a ‘black box’ manner. The fully assembled API call includes the endpoint-related information to connect to and establish a valid session with the Endpoint 390, requestor-related information, clinical event information, the format of the request, and any specific parameters for the requests (such as the .read request parameter), including an ID or metadata that identifies the patient for whom the data is being requested.

[0089] Step 3e - The Clinical Event Query / Data Request Handler LI combines the results received in Steps 2g (retrieved security tokens) and 3d (fully assembled API calls) and bundles them for automated execution to create an executable bundle. Then the Handler LI passes the executable bundles back to the Requestor’s Dynamic Clinical Data Handler 220.

[0090] Step 3f - The Dynamic Clinical Data Handlers 220 of the implementation of the Requestor Devices 200 receive Exchange- Standard API call executable bundles and run each bundle against the appropriate Exchange- Standard Endpoint 390 with the appropriate queries. The installation of the Dynamic Clinical Data Handler 220 is essentially a black-box model, as the SDK provided for a Requestor Device 200 includes a ready -to-use execution engine that the Requestor Device 200can preferably use out-of-the box (optionally, the execution engine can be modified if desired).

[0091] Step 3g - Dynamic Clinical Data Handler 220 establishes a connection with the Exchange- Standard Endpoint 390 of the Source Device 300 using the endpoint information and the security token provided in the executable bundle and makes the Standards-based API call as prepared by API Call Assembler L6.

[0092] Step 3h - Typically, after validating security credentials including the security token provided by Security Token Requestor L5, the Endpoint 390 will retrieve the clinical data for the clinical event requested and return the information to the Dynamic Clinical Data Handler 220 that is calling for the data. However, the Source Device 300 is ultimately in control of releasing the clinical data. In an aspect of the invention, the inventive Platform 100 makes information regarding the Requestor Device 200 (such as the IP address that originated the request API call) known to the Source Device 300. While not expected, the Source Device 300 could refuse to release the clinical data at the point of it being requested by the Requestor Device 200 with a valid security token; therefore, the Source has the ultimate control of the clinical data release, giving the source ultimate control. The output from the Endpoint 390 is standardized (by the Exchange Standard in use). Groups of data are returned in a known format (such as JSON or XML) that is then passed back to the Requestor Device 200. It may be passed back in native Exchange- Standard format or may be passed back in a transformed state via functionality provided by transformation services. For example, the transformation services may map, batch or de-batch the data before passing it back.

[0093] Step 3i - the Dynamic Clinical Data Handler 220 will use content in the executable bundle to validate the returned data and, implemented by and aided by the Requestor Device 200, to transform it into the desired internal format and pass the information to the appropriate destination (data warehouse, use case-specific system, etc.). The Dynamic Clinical Data Handler 220 will then close the connection with the Exchange- Standard Endpoint 390.

[0094] This completes Subprocess 3 - Dynamic Exchange- Standard API Calling.SUBPROCESS 4 - Fee Clearing Using Fee Management Service L7, shown onFIG. 6:

[0095] This subprocess is preferably, but optionally, implemented in the inventive System and Methods.

[0096] Step 4a - The Clinical Event Query / Data Request Handler LI calls the Fee Management Service L7 with the ‘clinical events-for-retrieval’ subset. (See Step 2a above.)

[0097] Step 4b - The Fee Management Service L7 retrieves the Requestor’s fee rules and credit or credit balance from the Requestor Master D6 (the line representing Step 4b is not shown extending from Fee Management Service L7 to Requestor Master D6 on FIG. 2 due to illustration issues and crowding of FIG. 2).

[0098] Step 4c - The Fee Management Service L7 retrieves any applicable fees due to the source entity(s) from the Fee Management Database D8, which is a database that contains all relevant information regarding allowed fees, and which is managed by Fee Management Service L7. The Fee Management Service L7 then calculates the fees and determines if there are any fee rules that are not being met or if the required funds are not available.

[0099] Step 4d - If the fees clear the checks in Steps 4b to 4c, the Fee Management Service L7 records the fees in the transaction ledger and updates the balances of the requesting entity and the source entity in the Fee Management Database D8.

[0100] Any exceptions or potential fee entry reversals will be dealt with in accordance with accounting principles.

[0101] Step 4e - The Fee Management Service L7 returns the appropriate results codes (success or exception code(s)) to the Clinical Event Query / Data Request Handler LI.

[0102] This completes Subprocess 4 - Fee Clearing.SUBPROCESS 5 - Clinical Event Subscription Emulation Using Clinical Event Subscription Service L8B, shown on FIG. 7:

[0103] This subprocess is preferably, but optionally, implemented in the inventive System and Methods.

[0104] Step 5a - Whenever the Clinical Event Update Service L4B processes metadata for new events (see Subprocess III, Clinical Event Metadata Update,below) it will pass all relevant information (including person / patient matching information) to the Clinical Event Subscription Service L8B.

[0105] Step 5b - Clinical Event Subscription Service L8B then will check for matching subscriptions in Clinical Event Subscription Database D9, which is a database containing all relevant information to manage the Clinical Event Subscription Service L8B, such as subscription matching criteria and related subscription data. If no matches are found, the cycle ends.

[0106] Step 5c and 5d - If any matches are found, the Clinical Event Subscription Service L8B will call the Security Token Requestor L5 to execute the functionality of the Subprocess 2 (Security Token Broker) described above to retrieve a security token(s).

[0107] Step 5e and 5f - The Clinical Event Subscription Service L8B will also call the API Call Assembler L6 to execute the Dynamic API Assembly subprocess described in functionality / Subprocess 3 (Dynamic Exchange- Standard API Calling) above to create fully assembled API calls for each Endpoint 390 and all relevant clinical event records to be retrieved at that Endpoint 390.

[0108] Step 5g - The Clinical Event Subscription Service L8B combines the results received in Steps 5c (security token) and 5f (API calls) and bundles them for automated execution, passing the executable bundles back to the Clinical Event Subscription Handler L8A with all relevant information for further processing.

[0109] Step 5h - The Clinical Event Subscription Service L8B retrieves security credentials configured in Requestor Master D6 and passes them to the Clinical Event Subscription Handler L8A.

[0110] Step 5i - The Clinical Event Subscription Handler L8A calls the Requestor’s Dynamic Clinical Data Handler 220 with the executable bundle (as defined in Step 3e) by establishing a secure connect! on / sessi on (securely, as defined regarding Person / Patient Master Database D2) using the credentials retrieved in Step 5h to initiate further processing. This is similar to the creation and execution of the executable bundle by the Clinical Event Query / Data Request Handler LI described above, except that in this case the call is not a response to a request from the Requestor Device 200.

[0111] Steps 5j to 5m - These steps match the steps taken by the Dynamic Clinical Data Handler 220 in Steps 3f - 3i, as described above, therefore leveraging the same capabilities with no need for modification or addition.

[0112] Preferably Step 5a (the addition of a clinical event via the Clinical Event Update Service L4B) also triggers the Clinical Event Subscription Service L8B to initiate any relevant clinical event subscriptions in real time.

[0113] This completes Subprocess 5 - Clinical Event Subscription Emulation.

[0114] The following paragraphs describe components and subprocesses that are initially set up and / or that support the main invention.SUBPROCESS I - Source Registration:

[0115] To use the inventive System and Method, the Source needs to be registered and onboarded. Typically, this would require a contractual agreement and preliminary configuration steps.

[0116] A Source Administrator 301 (or “Source Admin” 301) is an authorized user (or users) who is empowered to act on behalf of a source entity. The Source Admin 301 sets up, configures, and maintains all parameters required by the inventive System of the present invention to enable a Source Device 300 to participate in the processes facilitated by the inventive System. Typically, the user is a human user, but functions performed by the Source Admin 301 may optionally be fulfilled in part or in whole by a type of artificial intelligence.

[0117] Step la - The Source Admin 301 creates an account with login credentials that include a unique username and admin-specific information such as email, phone number, first name, last name, and title. The inventive System, in the Admin UI L9A (which uses the business logic in the Admin Module L9B), requires attestation that the user is authorized to act on behalf of the source organization that wants to register one or more Exchange- Standard endpoints for clinical data exchange. The information to be provided includes data about the organization, such as any national identifiers like NPI, plan ID, or CMS H-Contract ID; configuration information (IP addresses, TCP / IP port numbers) for the Exchange- Standard Endpoints 390); and any endpoint information, and related transaction fee information (fee structure and pricing details for purchase of clinical event(s) / record(s)).

[0118] Step lb - Once the Admin Module L9B has validated the information, the information will then be persisted to the Source Master Database D5, which is the database that contains all information about sources / providers and provider systems that are onboarded with the inventive System, and which is a subset of the Provider Master Database D3. This information is added to the Source Master Database D5when the Source Admin 201 initially registers or later updates their profile information in a web-based UI. When the validation is successful, a notice regarding the successful registration will preferably be displayed to the Source Admin 301 in the Admin UI L9A.

[0119] After the initial registration, the Source Admin 301 may preferably return to the Admin UI L9A at times to perform updates and maintenance of information.

[0120] This completes the Source Registration subprocess. After registration, the Source Device 300 will provide clinical data / encounter metadata. Preferably, this is done in real time or near real time to ensure that the Clinical Event Metadata Directory DI is maintained in a current and complete state. The Source Device 300 captures encounter / clinical data events and makes API calls to the Platform 100. Preferably, an SDK is provided to enable easy, fast, reliable, and secure Source Device 300 enablement of the functionalities of the inventive System and Methods.SUBPROCESS II - Requestor Registration:

[0121] To use the inventive System and Method, the Requestor needs to be registered, validated, and onboarded. This requires the Requestor to implement suitable technical capabilities to make the appropriate API calls to the Platform 100, to handle returned artifacts, and to use them to make data access calls to Sources Devices 300. Preferably, an SDK is provided to enable easy, fast, reliable, and secure Requestor Device 200 enablement of the functionalities of the inventive System and Methods.

[0122] The Requestor Administrator 201 (or Requestor Admin 201) is an authorized user associated with the requesting entity who can set up, configure and maintain all parameters required by the Dynamic Clinical Data Exchange Platform 100 for a Source organization 200 to participate in the processes facilitated by the inventive Dynamic Clinical Data Exchange Platform 100. Typically, the Requestor Admin 201 is a human user, but functions performed by the Requestor Admin 201 may optionally be fulfilled in part, or in whole, by a type of artificial intelligence. Typically, the requesting entity is the paying customer of the inventive System and Method.

[0123] Step Ila - The Requestor Admin 201 creates an account (with login credentials to include unique username such as email, phone number, first name, last name, and title) in Admin UI L9A (which uses the business logic in Admin ModuleL9B) for the organization that wants to register one or more Requestor Device 200 (instances) for clinical data requests. The information that needs to be provided preferably includes data about the organization including any national identifiers like NPI, plan ID, or CMS H-Contract ID; information that allows the verification of the organization and its status as an authorized Requestor of clinical data; the administrator’s contact information; configuration information (IP addresses, TCP / IP port numbers) for the Dynamic Clinical Data Handler 220 (which needs to be installed by the requesting entity for each of its instances); and any endpoint information and related transaction fee information (payment details including wire transfer, ETF, credit rating numbers (e.g., DUNS) to enable automated processing of clinical data and subsequent clearing of payments.

[0124] Step lib - Once the Admin Module L9B has validated the information, the information will then be persisted to the Requestor Master D6, and the successful registration will be displayed to the Requesting Entity Admin 201 in the Admin UI L9A

[0125] After the initial registration, Requesting Entity Admin 201 may preferably return to the Admin UI L9A at times to perform updates and maintenance of information.

[0126] This completes the Requestor Registration subprocess.SUBPROCESS III - Clinical Event Metadata Update shown in FIG. 8:

[0127] This subprocess requires that a Source Device 300 has previously registered (Subprocess I - Source Registration) and that component Clinical Event Capture Service 350 has been deployed at the source entity’s organization. Subprocess III is a metadata capture module. It is self-contained with the exception that Update Service L4B notifies the Clinical Event Subscription Handler L8B that there may be a new clinical event that could be relevant to a subscription.

[0128] Step Illa - Any creation of a new clinical event (any recording of clinical activities on a patient such as a visit, procedure, telehealth consultations, lab test, prescriptions order or fill, specialty referral, admission / discharge, etc.) data at a Source Device 300 triggers the Clinical Event Metadata Update Process via the Clinical Event Capture Service 350, which ‘listens’ to previously configured events at the Source Device 300. Preferably, the Capture Service 350 is based on an SDK provided by the inventive System for Source Device 300, which preferably affordsout-of-the-box event listeners (e.g., for commonly used EMR systems) and allows for the creation of additional custom ‘listeners.’ The Capture Service 350 captures all relevant information about a new clinical event, including date and time, clinical event types like inpatient, outpatient, specialist, lab, etc. and PII patient matching elements such as the patient first / last name, date of birth, gender, home address, and the last four digits of the social security number). Then Capture Service 350 initiates a secure API call to the Clinical Event Update Handler L4A to transmit that information for use in the Dynamic Clinical Data Exchange Platform 100. While this exchange process is not native within the Exchange- Standard protocol stack, V- DRLS leverages the same technologies as the Exchange- Standard Security Module and the same data element definitions as defined in Exchange-Standard resources which can be found in detail at the following link: https: / / www.hl7.org / fhir / secpriv- module.html.

[0129] Step Illb - The business logic component, the Clinical Event Update Service L4B, then validates the information and initiates a series of steps to ‘register’ the clinical event in various databases.

[0130] Step IIIc - The Update Service L4B, checks the Person / Patient Master Database D2 for matches on previously registered persons using commonly accepted patient matching best practices (such as, for example, the patient’s last name, first name, gender, DoB, last four digits of Social Security number, and address).

[0131] If a match is found, the Update Service L4B retrieves the matching PersonlD (an internal identifier used by the inventive System) to be used in the creation of a new Clinical Data Event.

[0132] Optionally, the Update Service L4B updates the person record with any added information e.g., an ID used by the Source Device 300).

[0133] Or, if no match is found, the Update Service L4B creates a new person record with a new PersonlD.

[0134] Step Hid - The Update Service L4B, checks Exchange-Standard Endpoint Directory D4 (populated either from syndicated endpoint directory data, from Source Admin entries or from prior Clinical Event updates) for matches of the endpoint information provided by the Source Device 300.

[0135] If a match is found, the Update Service L4B retrieves the matching EndpointID (an internal identifier used by the inventive System) to be used in the creation of a new Clinical Data Event.

[0136] Or, if no match is found, the Update Service L4B creates a new Exchange- Standard endpoint record and a new EndpointID. In this case, the new endpoint information needs to be validated, and the Source Administrator 301 will be notified and prompted to provide additional information about the Endpoint 390 so it can be programmatically addressed for data retrieval.

[0137] Step Hie - If any payer identifying information (e.g., Plan Market Name, Plan Parent Name, CMS H-Contract ID, State Insurance ID, etc.) is included in the clinical event information received from the Source Device 300 (which is optional), Update Service L4B checks Payer Master D7 for matches.

[0138] If a match is found, the Update Service L4B retrieves the matching PayerlD (an internal identifier used by the inventive System) to be used in the creation of a new Clinical Data Event.

[0139] Or, if no match is found, the Update Service L4B creates a new Payer record and a new PayerlD.

[0140] Step Ulf using L4B - The Update Service L4B, checks Clinical Event Metadata Directory DI for matches, z.e., duplicates based on received information as well as PersonlD and EndpointID.

[0141] If a duplicate is found, an exception process with a notification to the Source Admin 301 is initiated by the Update Service L4B.

[0142] If no duplicate is found, a new Clinical Event record will be created by the Update Service L4B in the Clinical Event Metadata Directory DI, which preferably includes event date / time, event type PersonlD, EndpointID, Source Device 300, PayerlD.

[0143] This completes the Source Registration subprocess.Audit Trails and BAM Database

[0144] In an embodiment of the inventive System and Methods, an Audit Trails and BAM Database D10 contains detailed logs of all events relevant to ensuring, and / or tracking, secure, proper (according to the inventive System’s operating rules and contractual obligations) and compliant operations of the inventive System and the ability for all audit stakeholders (including source entities, requesting entities, regulators, third-party auditors, and the inventive System) to audit and trace any and all information as needed or desired. This data is relevant for operational metrics(such as Business Activity Monitoring (BAM)) and is used for KPIs and dashboarding.Examples

[0145] In a first example of use of the inventive System and Methods, a patient seeks to retrieve all his / her personal clinical records using a third-party application (app). Assuming that the patient has provided consent for the app platform to access his / her personal clinical records and that the app platform is integrated with a Dynamic Clinical Data Handler 220, the app platform can initiate a request for all the clinical events for the patient. This request typically includes a time period or time range. For example, the initial request made by the app platform through Dynamic Clinical Data Handler 220 for this patient would preferably be an automatic request for events at dates up to the current date, but subsequently the app platform, through Handler 220, would only need to perform an incremental update. The Handler 220 can be configured to issue queries at certain, defined time periods to maintain the patient’s records in a current state. Alternatively, the app vendor can subscribe to clinical data events for this patient, getting the latest clinical events pushed to the app platform (and the patient’s app) in real time. The retrieval of all clinical data for the patient, regardless of where it is stored, can be performed without any configuration or manual steps and in real time.

[0146] In a second example of use, the inventive System and Methods enables a provider or clinician to retrieve medical records for an unconscious patient, for example, may be admitted to the emergency room (ER). The patient’s driver’s license is located, but it is from a state over a thousand miles away. The health system with which the ER is associated does not have any of the patient’s health records, which are important to make informed decisions and avoid complications and perhaps even death. If the electronic medical records system at the ER is integrated with the inventive System, the Dynamic Clinical Data Handler 220 can automatically initiate a request for all the clinical events for the patient, which include history, medications, allergies, notes, and lab tests. Handler 220 returns the results from the inventive System and provides the ER doctor with a complete picture of the patient in a matter of seconds. Further, if the patient’s regular doctor has subscribed to the clinical events subscription service, records about the patient’s ER visit will be automatically returned to the medical record system of the regulardoctor, keeping the doctor’s records current with records of medical events that are unknown to the regular doctor.

[0147] In yet another use case, a longitudinal patient record can be automatically maintained through use of the inventive System and Methods. For example, an insurance company or other payer may wish to keep a longitudinal patient record showing the complete history of all clinical events for a patient. If the payer’s clinical data operation is integrated with the inventive System, the payer’s Dynamic Clinical Data Handler 220 can automatically initiate a request for the entire longitudinal record for a patient. The inventive System and Methods can easily keep the patient’s record current by issuing queries at certain intervals for any new records. Alternatively, the payer can subscribe to clinical data events for their patients, getting the latest clinical events pushed to the Platform 100 in real time. Use of the inventive System and Methods enables retrieval of all clinical data for the patient, regardless of where the data is stored. And the retrieval can be performed without any configurations or manual steps and in real time.

[0148] The modules herein described may refer to software, firmware and / or circuitry that is / are configured to perform or cause the performance of one or more operations consistent with the present disclosure. Software may be embodied as a software package, code, instructions, instruction sets and / or data recorded on non- transitory computer readable storage mediums. Firmware may be embodied as code, instructions or instruction sets, and / or data that are hard-coded (e.g., nonvolatile) in memory devices. Circuitry may comprise, for example, singly or in any combination, hardwired circuitry, programmable circuitry such as computer processors comprising one or more individual instruction processing cores, state machine circuitry, software and / or firmware that stores instructions executed by programmable circuitry. The modules may collectively or individually be embodied as circuitry that forms a part of the Dynamic Clinical Data Handler 220, the Clinical Event Query / Data Request Handler LI, the Clinical Event Capture Service 350, the Platform 100, or another module of the inventive System.

[0149] The inventive System and Methods processes data and returns results to meet the needs of the requesting entities. Particularly, the person matching and clinical event retrieval are optimized (such as by in -memory, indexing, and the like) to provide fast results. The roundtrip to get the security token(s) from the Source Device(s) 300 is critical to fast data retrieval, so this pathway is also optimized forspeed. The Clinical Event Subscription Emulation of Subprocess 5 can be deprioritized (compared to the person matching and security token retrieval, when necessary (such as in extreme load cases), since the retrieval of this data does not need to meet a specific response-time metric. For example, if the executable bundle provided in the subscription service is delivered to the Requestor Device 200 in a time frame of a few seconds or a minute or two, this is a satisfactory length of time.

[0150] Because the inventive System and Methods are based on a modular, tiered, scalable, and expandable tech stack, the functionalities provided may be implemented simultaneously or sequentially. For example, the Requestor Device 200 and the Source Device 300 may first be made compliant with the Exchange Standard to be used. The Dynamic Clinical Data Handler 220 may be installed at the Requestor Device 200. The Clinical Event Capture Service 350 may be installed at the Source Device 300. Then the initial functionality of the Clinical Event Query / Data Request Handler LI, the Person / Patient Matching Module L2, the Clinical Event Lookup L3, the Clinical Event Update Handler / Service L4A and L4B, the Security Token Requestor L5, and the API Call Assembler L6 may be implemented. In one embodiment of the invention, the inventive System and Methods consists of this initial functionality. In another embodiment, the implementation of the initial functionality is an interim solution with, at a later date, the enhancing functionality of the Fee Management Service L7 added. In a further embodiment, the Clinical Event Subscription Service / Handler L8A and L8B are implemented at a later date. In the preferred embodiment, which fully automates dynamically locating and retrieving clinical data, the primary functionalities, the Fee Management Service L7, and the Clinical Event Subscription Service / Handler L8A and L8B are implemented.

[0151] Though the disclosure is directed to the exchange of healthcare data, the inventive System and Methods presented is applicable to solve other data exchange technological problems. For example, a college admissions office may be seeking information about college applicants. The college applicants give consent to the admission office (the requesting entity) to obtain personal information from any of a number of source entities that are registered with the system, such as high schools, other colleges, online educational institutes, employers, or the like which are set up with Standards-based endpoints. The inventive System receives a request for applicant data from the Requestor Device 200, obtains security tokens from SourceDevices 300 with relevant applicant data, and provides an executable bundle to the Requestor Device 200, which connects securely to the Endpoint(s) 390 of the Source Device 300 to obtain private data about the applicant, by using the steps described above.

[0152] The instant invention provides a token broker system that dynamically mediates authentication and facilitates a point-to-point connection between a Requestor Device 200 and a Source Device 300 without requiring pre-established security relationships. This solves the current scaling problem and eliminates the need to create expensive and time-consuming point-to-point connections between every requestor and every data source, which does not scale across millions of healthcare entities.

[0153] The instant invention also provides a robust locator functionality to solve the metadata / completeness problem. Requestor Devices can locate the data needed, even if it is not known if the data exists, it is not known where the data might be stored, and / or it is not known how to access the data.

[0154] Since many modifications, variations, and changes in detail can be made to the described preferred embodiments of the invention, it is intended that all matters in the foregoing description and shown in the accompanying drawings be interpreted as illustrative and not in a limiting sense. Thus, the scope of the invention should be determined by the appended claims and their legal equivalents.

Claims

AMENDED CLAIMS received by the International Bureau on 09 December 2025 ( 09.12.2025)What is claimed is:

1. A system to retrieve clinical data comprising: a Dynamic Clinical Data Exchange Platform (100) comprising: a Clinical Event Query / Data Request Handler (LI) which: receives a ‘clinical events-for-retrieval’ list from a Dynamic Clinical Data Handler (220); wherein the ‘clinical events-for- retrieval’ list comprises one or more selected clinical event data to be retrieved; and determines a list of one or more endpoints set associated with the ‘clinical events-for-retrieval’ list; a Security Token Requestor (L5) that: receives the list of one or more endpoints set from the Clinical Event Query / Data Request Handler (LI); establishes a secure connection with a Source Endpoint (390) from the list of one or more endpoints set; requests a security token from each Source Endpoint (390) in the list of one or more endpoints set; and receives the security token from the Source Endpoint (390); an API Call Assembler (L6) which: retrieves connection and content-related information for the Source Endpoint (390); retrieves requestor-related information comprising proper output format; creates a fully assembled API call; and passes the fully assembled API call to the Clinical Event Query / Data Request Handler (LI); andwherein the Clinical Event Query / Data Request Handler (LI) combines the security token with the fully assembled API call to create an executable bundle and passes the executable bundle to the Dynamic Clinical Data Handler (220) for execution to enable the Dynamic Clinical Data Handler (220) to establish a secure direct connection with the Source Endpoint (390) to retrieve the clinical event data without the clinical event data passing through the Dynamic Clinical Data Exchange Platform (100).

2. The system of claim 1, further comprising: a Clinical Event Metadata Directory (DI) storing metadata about clinical events; wherein the metadata comprises one or more of the following: PII patient matching elements, clinical event types, clinical event dates, and source location identifiers.

3. The system of claim 1, further comprising: a Person / Patient Matching Module (L2) that receives patient identifying information from clinical event queries, implements at least one patient matching algorithm, queries an encrypted Person / Patient Master Database (D2) using the patient matching algorithm, and returns a unique person identifier when matching confidence exceeds a predetermined threshold.

4. The system of claim 3, wherein: the Person / Patient Matching Module (L2) utilizes at least one of the following: deterministic matching using exact matching algorithms, probabilistic matching with weighted scoring of demographic elements, fuzzy logic to handle data variations, and machine learning algorithms that improve matching accuracy.

5. The system of claim 1, further comprising: a Clinical Event Capture Service (350) deployed to a Source Device (300) that monitors the Source Device (300) for new clinical events in real time, captures metadata about the new clinical events, and transmits the metadata to the Dynamic Clinical Data Exchange Platform (100) via secure API calls.

6. The system of claim 5, wherein: the Clinical Event Capture Service (350) comprises event listeners that detect clinical activities comprising at least one of the following: visits, procedures, telehealth consultations, lab tests, prescription orders, specialty referrals, and admissions and / or discharges.

7. The system of claim 1, further comprising: a Fee Management Service (L7) that processes incoming data requests through fee calculation algorithms, validates requestor financial standing, and executes real-time financial transactions.

8. The system of claim 7, wherein: the Fee Management Service (L7) checks fee schedules for source entities, verifies requesting entity fee parameters and balances, and either clears fees and updates balances or issues appropriate exception messages.

9. The system of claim 1, further comprising: a Clinical Event Subscription Service (L8B) that monitors new entries in a Clinical Event Metadata Directory (DI), determines if any Requestor subscriptions match new entries, and automatically executes data request steps for matching entries.

10. The system of claim 9, wherein: the Clinical Event Subscription Service (L8B) enables Requestor Devices (200) to receive new clinical data upon data creation without maintaining persistent connections to a Source Device (300).

11. The system of claim 1, further comprising: an Exchange-Standard Endpoint Directory (D4) that lists all endpoints known in the system to retrieve clinical data and stores endpoint-related information needed to programmatically evaluate and access Exchange-Standard APIs at Source Endpoint (390).

12. The system of claim 11, wherein: the API Call Assembler (L6) retrieves endpoint- related information from the Exchange-Standard Endpoint Directory (D4) comprising at least one of the following: Exchange-Standard versions, authorization endpoints, supported scopes, available launch contexts, and OAuth 2.0 flow specifications.

13. The system of claim 1, further comprising: a Requestor Master database (D6) containing data of formally onboarded Requestor Devices (200) that enables secure queries and data requests, wherein the API Call Assembler (L6) retrieves requestor-related information from the Requestor Master database (D6).

14. The system of claim 1, wherein: the Dynamic Clinical Data Handler (220) and Clinical Event Capture Service (350) are deployed as containerized applications in isolated environments using container technology.

15. The system of claim 2, wherein: the Clinical Event Metadata Directory (DI) stores encrypted personally identifiable information (PII) separate from clinical event identifiers, with both PII and clinical event identifiers encrypted in transit and at rest using federally approved encryption standards.

16. The system of claim 15, wherein: the encryption standards include Transport Layer Security (TLS) versions 1.2 or 1.3 for data in transit and AES-256 for data at rest.

17. The system of claim 1, wherein: the executable bundle contains endpoint -related information to connect to and establish a valid session with the Source Endpoint (390), requestor-related information identifying the Requestor that has been authorized, and specific parameters including patient identification metadata.

18. The system of claim 1, wherein: the API Call Assembler (L6) constructs API calls following least privilege access principles with minimal scope requests based on the clinical event data to be retrieved and an authorized access level of the Requestor.

19. The system of claim 1, wherein: the system operates using current Exchange Standards and OAuth 2.0 protocol for authentication and authorization.

20. A method for retrieving clinical data comprising:(1) receiving, at a Clinical Event Query / Data Request Handler (LI) of a Dynamic Clinical Data Exchange Platform (100), a 'clinical events-for- retrieval' list from a Dynamic Clinical Data Handler (220) deployed to a Requestor Device (200); wherein the 'clinical events-for-retrieval' list comprises one or more selected clinical event data to be retrieved;(2) determining, by the Clinical Event Query / Data Request Handler (LI), a list of one or more endpoints set associated with the ‘clinical events-for- retrieval' list;(3) receiving, at a Security Token Requestor (L5), the list of one or more endpoints set from the Clinical Event Query / Data Request Handler (LI);(4) establishing, by the Security Token Requestor (L5), a secure connection with a Source Endpoint (390) from the list of one or more endpoints set;(5) requesting, by the Security Token Requestor (L5), a security token from the Source Endpoint (390);(6) receiving, by the Security Token Requestor (L5), the security token from the Source Endpoint (390);(7) retrieving, by an API Call Assembler (L6), connection and content- related information regarding the Source Endpoint (390);(8) retrieving, by the API Call Assembler (L6), requestor-related information comprising proper output format;(9) assembling, by the API Call Assembler (L6), a fully assembled Exchange Standard-compliant API call that includes the connection and content-related information and the requestor-related information;(10) passing, by the API Call Assembler (L6), the fully assembled Exchange Standard-compliant API call to the Clinical Event Query / Data Request Handler (LI);(11) combining, by the Clinical Event Query / Data Request Handler (LI), the security token with the fully assembled Exchange Standard-compliant API call to create an executable bundle;(12) passing, by the Clinical Event Query / Data Request Handler (LI), the executable bundle to the Dynamic Clinical Data Handler (220) for execution; and(13) executing, by the Dynamic Clinical Data Handler (220), the executable bundle using the security token to establish a secure direct connection with the Source Endpoint (390) to retrieve the clinical data without the clinical data passing through the Dynamic Clinical Data Exchange Platform (100).

21. The method of claim 20, further comprising: storing, in a Clinical Event Metadata Directory (DI), metadata about clinical events; wherein the metadata comprises one or more of the following: PII patient matching elements, clinical event types, clinical event dates, and source location identifiers.

22. The method of claim 21, further comprising:(1) receiving, by a Person / Patient Matching Module (L2), patient identifying information from clinical event queries;(2) implementing, by the Person / Patient Matching Module (L2), at least one patient matching algorithm;(3) querying, by the Person / Patient Matching Module (L2), an encrypted Person / Patient Master Database (D2) using the patient matching algorithm; and(4) returning, by the Person / Patient Matching Module (L2), a unique person identifier when matching confidence exceeds a predetermined threshold.

23. The method of claim 22, wherein: implementing the at least one patient matching algorithm comprises utilizing at least one of the following: deterministic matching using exact matching algorithms, probabilistic matching with weighted scoring of demographic elements, fuzzy logic to handle data variations, and machine learning algorithms that improve matching accuracy.

24. The method of claim 20, further comprising:(1) monitoring, by a Clinical Event Capture Service (350) deployed to a Source Device (300), the Source Device (300) for new clinical events in real time;(2) capturing, by the Clinical Event Capture Service (350), metadata about the new clinical events; and(3) transmitting, by the Clinical Event Capture Service (350), the metadata to the Dynamic Clinical Data Exchange Platform (100) via secure API calls.

25. The method of claim 24, wherein: monitoring for new clinical events comprises detecting clinical activities comprising any one of the following: visits, procedures, telehealth consultations, lab tests, prescription orders, specialty referrals, and admissions / discharges.

26. The method of claim 20, further comprising:(1) processing, by a Fee Management Service (L7), incoming data requests through fee calculation algorithms;(2) validating, by the Fee Management Service (L7), requestor financial standing and authorization parameters; and(3) executing, by the Fee Management Service (L7), real-time financial transactions.

27. The method of claim 20, further comprising:(1) passing, by a Clinical Event Update Service (L4B), metadata for a new clinical event to a Clinical Event Subscription Service (L8B);(2) determining, by the Clinical Event Subscription Service (L8B), if any Requestor subscriptions match the new clinical event; and(3) automatically executing, by the Clinical Event Subscription Service (L8B), data request steps for the new clinical event that matches any Requestor subscription.

28. The method of claim 27, wherein: automatically executing data request steps enables Requestor Devices (200) to receive new clinical data within seconds of data creation without maintaining persistent connections to Source Devices (300).

29. The method of claim 20, wherein: retrieving connection and content-related information comprises accessing an Exchange-Standard Endpoint Directory (D4) that lists all endpoints known in the system to retrieve clinical data and stores endpoint-related information needed to programmatically evaluate and access Exchange-Standard APIs.

30. The method of claim 20, wherein: retrieving requestor-related information comprises accessing a Requestor Master database (D6) containing data of formally onboarded Requestor Devices (200) that enables secure queries and data requests.

31. The method of claim 20, wherein: establishing the secure connection and executing the executable bundle are performed using containerized applications deployed in isolated environments using container technology.

32. The method of claim 21, further comprising: encrypting personally identifiable information (PII) separate from clinical event identifiers, with both PII and clinical event identifiers encrypted in transit and at rest using encryption standards.

33. The method of claim 32, wherein: encrypting comprises using Transport Layer Security (TLS) versions 1.2 or 1.3 for data in transit and AES-256 for data at rest.

34. The method of claim 20, wherein: creating the executable bundle comprises endpoint-related information to connect to and establish a valid session with the Source Endpoint (390), requestor-related information identifying the Requestor that has been authorized, and specific parameters comprising patient identification metadata.

35. The method of claim 20, further comprising:(1) performing initial vetting of Requestor Devices (200) during onboarding; and(2) conducting ongoing monitoring that includes verifying authorization to request given clinical encounters; wherein establishing trust with Source Devices (300) is based on initial vetting and ongoing monitoring.

36. The method of claim 20, wherein: the method operates using current Exchange Standards and OAuth 2.0 protocol for authentication and authorization.

37. A computer-implemented method for security token brokering in healthcare data exchange, the method comprising: receiving, at a Security Token Requestor (L5), a list of Standards-based endpoints from a Clinical Event Query / Data Request Handler (LI); establishing secure connections with an Endpoint (390); requesting a security token from the Endpoint (390) for specific clinical data access scopes; receiving a security token from the Endpoint (390), the security token including access permissions and expiration times; terminating the secure connections with the Endpoint (390) after the security token has been retrieved; transmitting the security token to the Clinical Event Query / Data Request Handler LI; creating, by an API Call Assembler L6, a fully assembled API call; transmitting the fully assembled API call to the Clinical Event Query / Data Request Handler LI; combining, by the Clinical Event Query / Data Request Handler LI, the fully assembled API call and the security token to create an executable bundle and passes the executable bundle to the Dynamic Clinical Data Handler (220); and passing the executable bundle to the Dynamic Clinical Data Handler (220) to enable the Dynamic Clinical Data Handler (220) to establish a secure direct connection with the Endpoint (390) to retrieve clinical data without the clinical data passing through the Dynamic Clinical Data Exchange Platform (100).

38. A computer-implemented method for scalable healthcare data interoperability, the method comprising: eliminating the need to maintain point-to-point connections between Requestors and Sources by: providing a Platform (100) that comprises a central trusted proxy service that brokers authentication without data intermediation; creating temporary data access relationships between the Requestors and the Sources through time-limited security tokens; enabling dynamic discovery of relevant clinical data across multiple healthcare systems; facilitating direct data transfer between Requestors that have been authorized and Sources without passing healthcare data through the Platform (100); and maintaining system scalability regardless of the number of Requestors and Sources.

39. The method of claim 38, further comprising: automating tracking and clearing of fees to be exchanged between Requestors and Sources.

40. The method of claim 38, further comprising: upon detection of a new clinical event received by Platform (100), determining if the new clinical event is related to a subscription of one of the Requestors; and if the new clinical event is related to a subscription, facilitating direct data transfer between the one of the Requestors and a one of the Sources without passing the healthcare data through the Platform (100).

Images