EP2537135A1 - Clinical payment network system and methods - Google Patents

Abstract

A complex set of performance related requirements defined initially in a clinical trial agreement are functionally evaluated to determine an action responsive to a successful evaluation. A first message identifying a first event initiated transaction within the performance of a clinical trial provides an identification of an investigator and a first event defined data set. Executable template code blocks, specific to the clinical trial and investigator, are retrieved from a distributed database. The executable template code blocks represent declarative* statements that represent discrete operational and financial requirements derived from the clinical trial agreement corresponding to the clinical trial and investigator. An application is executed to determine whether the first event data evaluates successfully against the executable template code blocks. Successful evaluation generates a second event that provides a second message, including the identification of the investigator, clinical trial, and a second event defined data set to the distributed computer system.

Description

[0001 ] CLINICAL PAYMENT

NETWORK SYSTEM AND METHODS [0002]

[0003] This application claims the benefit of U.S. Provisional Application No. 61 /306,425, filed February 1 9, 201 0, and which is expressly incorporated by reference.

[0004] Background of the Invention

[0005] Field of the Invention:

[0006] The present invention is generally related to the field of financial transactions as typically involved in medical research and, more particularly, to a computer-implemented financial management system and methods capable of managing clinical trials, including payments made within the context of a distributed clinical trial in accordance with the terms of the controlling agreements.

[0007] Description of the Related Art:

[0008] Clinical trials are conventionally required to establish the safety and efficacy of health interventions involving, for example, drugs, diagnostics, and devices. While early stage trials may be quite small, a later stage trial can involve thousands of patient participants. While the number of investigators actively involved in a clinical trial is dependent on the trial enrollment requirements and disease state, often hundreds of investigators are required. These investigators will be involved in the treatment and periodic follow-up of individual patients for periods that can range from several weeks to months and many may span multiple years. These investigators will often be concurrently involved in multiple trials, where each investigator for each trial will be required to manage a unique set of patient participants, with each set having distinct treatment and follow-up requirements.

[0009] Sponsors of clinical trials, conventionally pharmaceutical, biotech, medical device companies, research centers, hospitals, and other similar entities, will contract to pay investigators, clinical research organizations (CROs), laboratories, subjects (also referred to as patient participants), research centers, hospitals, and other similar entities, to perform, manage, or participate in certain operational events in the course of clinical trials. Investigators are exemplary of the primary entities that undertake the operational management and responsibility for a clinical trial. Typically, an investigator must make timely payments to affiliates, such as laboratories, infusion centers, x-ray and related imaging facilities, pharmacies, and other third parties whose products and services are utilized in the performance of a clinical trial. Up-front costs for training and establishing the necessary infrastructure to direct a clinical trial are also paid by the investigator. Investigators are also typically required to initially underwrite the costs of enrolling and screening prospective patient participants as well as the ongoing costs of the trial subjects and necessary health professionals. Participation fees and related expenses payable to the patient participants must also be advanced by the investigator.

[001 0] Currently, investigators for clinical trials are paid on an industry average of between 90 and 1 80 days or more after invoicing costs to a sponsor or CRO or in the case where the CRO or sponsor is responsible for generating an invoice on behalf of the investigator. In either case the sponsor or CRO is often the primary source of delay. In cases where the investigators are required to submit expense support or other reports for approval before an invoice can be submitted for payment, further delay is incurred due to this additional review and approval process.

[001 1 ] Investigators, however, often must pay their invoices on a standard 30 days net schedule. This cash flow imbalance is highly discouraging to investigators. About 52% of investigators in the United States that undertake a clinical trial only perform a single trial. Clinical trials registered with the US Food and Drug Administration (FDA) are expanding globally not only for the purpose of patient access, but also for access to investigators.

[001 2] Given that the cost to bring a new drug to market is currently estimated to be in the range of $800 million to $ 1 billion, increasing year over year, and that the duration of clinical trials is increasing, often due to enrollment shortfalls, retaining investigators is essential to reducing the overall new drug costs. The principal reason given by investigators who stop participating in clinical trials is the failure to receive payment on-time and in- full from sponsors and CROs. The underlying issue is the lack of efficient, and often of any meaningful, automation to track, manage, and reimburse investigators in a timely manner.

[001 3] On a global basis, nearly $65 billion is currently paid annually to research and develop pharmaceuticals, devices, diagnostics, and other similar research. Unfortunately, a new drug candidate almost always requires a highly specialized trial protocols imposing, among otherthings, complex sets of conditions that must be met in order to receive payment authorization. Approximately 10,000 new trials are filed each year with the FDA and corresponding international agencies. Furthermore, the protocol and payment conditions are typically specified in a complex clinical trial agreement (CTA) that are often separately negotiated between the sponsor or CRO and each participating investigator. Each phase III clinical trial conventionally requires, on average, 50 to 100 investigative sites. Phase IV trials commonly involve hundreds to thousands of investigative sites. Given a typical number of two protocol amendments over the course of a trial for every CTA, the sponsor or CRO must evaluate and reevaluate hundreds of agreements on an ongoing basis. The potentially different definition of terms, different specifications of milestone requirements and the manner of evaluation, as well as different effective dates, makes funding a clinical trial even more complex.

[001 4] As a result, much of the financial accounting performed in managing a clinical trial is done manually or by using non-specific clinical trial computer automation programs, such as spreadsheets and generic accounting systems. Conventional computer automation, even if tailored by a sponsor or CRO specific to one designated clinical trial or specific business, quickly becomes too complex and unwieldy to accurately manage the clinical trial subject to the increasingly divergent CTA differences.

[001 5] Further, investigators are primarily responsible for data entry. They must therefore deal with the varying contract types and terms involved in the trial as a whole when trying to correctly categorize and document an expense or record a receivable. The result is that both investigators, sites, research staff, sponsors, and CROs incur significant time costs that would be better spent on clinical trial research. Lengthy reconciliation processes and contention between the sponsor or CRO and investigators are the common result.

[001 6] Due to the complexities and manual processes required, sponsors have been increasingly outsourcing the payment process to the CROs. Although this moves most of the burden to the CROs, an additional burden is then created on both the sponsors and CROs. Specifically, sponsors now have to account for the operations of a retained CRO, including accurately reporting, both internally and externally, the costs of the clinical trial. This is often complicated due to the untimely posting of reports by the CROs and the non-GAAP and other standardized reporting requirements imposed by the sponsor. Additionally, a sponsor will often use multiple CROs, resulting in inconsistent reporting and lack of visibility of clinical trial expense across a single trial let alone many ongoing trials. For some organizations, this also creates regulatory reporting challenges at the local levels. With the recent Patient Protection and Affordable Care Act of 2009 (H.R. 3590 and Section 6002) signed into law on March 23, 201 0, accuracy and consistency of transparent research expense reporting is now required for all US companies.

[001 7] An additional complication that arises from the CRO outsourcing is the potential for compromising the confidentiality of patient, financial, and other information provided, gathered, and created in a client trial. Not only is a CRO an independent company, but CROs will often be concurrently involved in multiple clinical trials across different sponsors. Commingling of this data, including the potential for commingling, by a CRO may also be subject to regulatory restrictions on the handling of personal/privacy data as gathered from participant patients. The need by the sponsors to also maintain the study data secure and uncompromised while at the same time readily accessible within the scope of the organization and clinical trial adds further complications.

[001 8] Consequently, a need exists for a clinical trial payment system that can efficiently and accurately manage clinical trials, particularly including invoicing and payments made between sponsors, CROs, and investigators. Such a system should be able to preclude the potential for commingling data or compromising the confidentiality of the data.

[001 9] Summary of the Invention

[0020] Thus, a general purpose of the present invention is to provide an efficient a computer-implemented system and methods for managing clinical trials, including the accounting and payments made within the context of a distributed clinical trial in accordance with the terms of a clinical trial agreement, master services agreement, research agreements, and other agreements containing financial terms.

[0021 ] This is achieved in the present invention by providing, within a distributed computer system, a first message identifying a first event initiated transaction within the performance of a clinical trial provides an identification of an investigator and a first event defined data set. Executable template code blocks, specific to the clinical trial and investigator, are retrieved from a distributed database. The executable template code blocks include declarative statements that represent distinct operation and financial requirements derived from the clinical trial agreement corresponding to the clinical trial and investigator. An application dynamically incorporates the executable template code blocks and is executed to determine whether the first event data evaluates successfully against the executable template code blocks. A successful evaluation generates a second event that provides a second message, including the identification of the investigator, clinical trial, and a second event defined data set, to the distributed computer system. An accounting engine may then distribute corresponding documents and transactions to appropriate organizations. [0022] An advantage of the present invention is that a constrained natural language, defined as a contract meta language (CML), is used to encode operational or performance related contractual terms, specifically including financial terms, from an unconstrained language agreement. The resulting contract specific CML is entered and converted into an interpretable script, a compilable programming language, or otherwise rendered as machine readable code (MRC). The conversion process also renders a specification of a user interface (Ul) that is descriptive, interpretable, or compilable, enabling user entry of data corresponding to possible compliant operational contractual term data. The Ul specification and rendered MRC are stored for subsequent retrieval selectively in response to a sequenced event or operational business event. The MRC is executed to determine whether data associated with the event fulfills the criteria of the operational contractual terms.

[0023] Another advantage of the present invention is that the distributed computer system implements a data-pod architecture that allows participating organizations, such as sponsors, investigators, laboratories, central institutional review boards, research companies, and CROs, to maintain clinical trial specific data within discrete data storage systems within data centers designated or hosted by the organizations. The organizations and their agents have shared use of a remote application Ul and corresponding business logic that is configurable dependent on data-pod stored data.

[0024] A further advantage of the present invention is that the distributed computer system enables a global Clinical Payment Network where, for unique combinations of organizations and investigators, a uniform workflow is created and individualized, enabling transactions to be efficiently processed and, where appropriate, initiate financial accounting and payments to members of the Payment Network. [0025] Still another advantage of the present invention is that CML can be efficiently resolved from clinical trial agreement and other agreements that bear on the performance of the trial. CML statements are discrete and declarative, enabling a complex clinical trial agreement to be accurately entered as a constrained natural language. A CML authoring tool allows entry of discrete CML statements using a form-based user interface and a library of generic and, optionally, semi-customized statement templates.

[0026] Yet another advantage of the present invention is that financial accounting and payments, particularly to participant patients, can be distributed in a variety of manners, including using reloadable or non-reloadable debit or credit cards, bank transfers, bank drafts, checks, and the like. Payments can be released on a schedule determined against the completion of the relevant clinical trial milestones or individual activities, with the ability to cross-check performance against records originated by, for example, the relevant clinical trial investigator. Past payments and frequencies can also be considered as a basis for avoiding fraud.

[0027] Brief Description of the Drawings

[0028] Figure 1 illustrates a preferred distributed data processing operating environment within which preferred embodiments of the present invention can be effectively utilized.

[0029] Figure 2 is a block diagram providing a representational view of a service-oriented architecture implemented using an enterprise service bus for a distributed data processing operating environment within which preferred embodiments of the present invention can be effectively utilized. [0030] Figure 3A is a block diagram providing a representational view of the distributed services and systems as implemented in a preferred embodiment of the present invention.

[0031 ] Figure 3B provides a block diagram of an application server instance and an associated data-pod as implemented in a preferred embodiment of the present invention.

[0032] Figure 4 provides a block diagram illustrating the message process flow, including dispatching, as implemented in a preferred embodiment of the present invention.

[0033] Figure 5 illustrates the process flow for generating contract meta- language statements and the resolution of valid statements to Ul specifications and parameterized executable code blocks as implemented in a preferred embodiment of the present invention.

[0034] Figure 6 is a detail block diagram of the contract meta-language library store as implemented in a preferred embodiment of the present invention.

[0035] Figure 7 illustrates a preferred process flow for generating a message from an actionable event as implemented in a preferred embodiment of the present invention.

[0036] Figure 8 illustrates a preferred process flow for validating and evaluating the contents of a received message as implemented in a preferred embodiment of the present invention.

[0037] Figure 9 illustrates a preferred process flow for invoicing and distributing financial payments in accordance with a preferred embodiment of the present invention.

[0038] Figure 10 provides an image rendering of a template-based data entry form enabling parameterization of a CML template Ul or code block template beginning with a generic, user-selected base template in accordance with a preferred embodiment of the present invention.

[0039] Figure 1 1 provides an image rendering of a template-based data entry form showing the completed parameterization of a CML template Ul or code block template.

[0040] Detailed Description of the Invention

[0041 ] The present invention is described in the preferred context of a distributed computer system capable of supporting global access and use within the context of managing clinical trials, further specifically with regards to the handling of financial transactions. The present invention is, however, properly capable of handling all operational transactions within clinical trials and, further, to operational transactions within distributed computer systems requiring complex, typically determinant evaluation of operational conditions. These capabilities will become clear in the following detailed description of the invention, wherein like reference numerals are used to designate like parts depicted in one or more of the figures.

[0042] Referring to Figure 1 , a preferred environment of a distributed data processing system 10 typically includes heterogeneous computer platforms interconnected through a network 1 2, conventionally the global Internet network. Servers 14, 1 6, 1 8 are typically located in data centers, either owned or operated by a clinical trial organization or hosted by a third- party subject to security constraints. The servers 14, 1 6, 1 8, typically host, locally or through the network 1 2, any number of often varied clients 20, 22.

[0043] For purposes of the present discussion, an organization is defined as a legal entity, preferably represented by a main company that is the parent company for a given clinical trial. Organizations can include other companies that are separate legal entities, such as wholly owned subsidiaries, where financial results role up to a parent organization. An organization can view another organization if the first organization is the custodian for the second, the two organizations are linked by inviting or accepting another organization into their network of business partners, or list themselves as public in the Payment Network. The present embodiments preferably require each organization and each study have a custodian. Because all organizations may not be members of the Payment Network, organizations that are within the network can create other organizations and be the designated custodian. Once an Organization that is currently being managed by a custodian joins the Payment Network, the joining organization can elect to become the custodian of their own organization and have the privileges of self administration.

[0044] A subject is a person participating in a clinical trial; typically, a participant patient.

[0045] A protocol is a document that describes the inclusion and exclusion criteria for subjects, visit schedule including procedures and tests to be performed and why. The protocol specifies the statistical analysis methods to be used, the primary endpoint and secondary endpoints, and lists all known safety issues and methods of collecting adverse events. In short the protocol outlines the methodology of the experiment to be performed, who can participate, and what the anticipated outcome should be.

[0046] A sponsor is a pharmaceutical, biotech or medical device company, or a research center or doctor that proposes to perform a clinical trial, testing a defined set of efficacious claims and to test that the product is safe. A device trial can test efficacy outcomes and specific claims for advertising purposes. [0047] A site is a facility that participates in the clinical trial and enrolls subjects based on the protocol inclusion criteria. Sites can be University hospitals, managed care hospitals, research M.D.s and related centers, primary and specialized care doctors.

[0048] A Clinical Research Organizations perform services related to research and development and are contracted to perform a verity of clinical trial related services.

[0049] A custodian or custodial organization is the organization that is responsible for maintaining defaults, configuration of workflows, data, security, personnel, and all other data of an organization. An organization can be a custodian of another organization or itself.

[0050] Of the different distributed data processing architectures potentially suitable for implementation of the present invention, the service- oriented architecture (SOA) is preferred. The use of distinct, modular business information services, effectively as the de-constructed elements of the desired business information service system, is preferred as it allows loose coupling of services and systems, particularly including with respect to end-users of the client platforms 20, 22. In the implementation of the presently preferred Clinical Payment Network, the server 14 preferably represents a Clinical Payment Network application engine and system data-pod. Multiple instances of server 1 6 preferably represent different organizations, such as sponsors, CROs, sites, eClinial systems hosted by third-parties, organizations, data warehouses, and similar entities. Multiple instances of server 1 8 preferably represent public services, such as banks, payment clearing houses, currency exchanges, and similar entities.

[0051 ] As illustrated in Figure 2, a preferred SOA implementation 30 employs an enterprise service bus (ESB) 32 as a middleware layer interconnecting disparate service requesters 34_η __N and service providers 36·, __M. The enterprise service bus 32 preferably implements a messaging fabric with the capability to host an embedded set of function-added components 38, including service adaptors and protocol converters, routing and event controls, and, optionally, performance management and monitoring instrumentation. Distributed service requesters 34 _η __N and providers 36·, __M can, at least from an architectural point of view, uniformly connect to and through the ESB 32 utilizing a consistent integration pattern to implement the various business processes necessary to collectively implement the desired distributed data processing system 1 0.

[0052] The function of the ESB 32 is to route messages, representing network protocol specific requests and responses, between service requesters 34_η __N and service providers 36·, __M, subject to ESB-based network protocol conversion. Other embedded component 38 functions that can be implemented in the ESB 32 include support for asynchronous messaging, alternate and enhanced message routing capabilities, standardized authorization, and authentication and audit controls, including interfaces to external standard LDAP services. Standard web services protocols, such as Simple Object Access Protocol (SOAP) and Representational State Transfer (REST) can also be implemented through embedded components 38. Messaging protocols, such as Microsoft Message Queuing (MSMQ), Windows Communication Foundation (WCF), Microsoft .NET Framework, Internet Information Services (IIS), Microsoft Distributed Transactions Coordinator (MSDTC) are also used. A service consumer can also implement a structured document server in order to support hypertext (HTTP) and other extensible markup language (XML) based protocols. Application specific and other proprietary network protocols may also be implemented as needed.

[0053] The preferred system architecture of the Clinical Payment Network 50 is generally shown in Figure 3A. Primary operational control and supervision is performed by a system server 52 hosted within a system data center by or on behalf of the owner of the Clinical Payment Network 50. Preferably, a system data-pod 54 is also hosted within the system data center. The system server 52 and system data-pod 54 interoperate to provide for the control and storage of system-wide configuration data, security information defining access rights among and between the different entities accessing the various resources within and that connect to the Clinical Payment Network 50, and the collection and analysis of administrative data reflecting the ongoing use and performance of the Clinical Payment Network 50. In particular, the system data-pod 54 includes a database (not shown) that preferably stores generic data, public within the Clinical Payment Network 50, that identifies known data pods within the network, participating and related organizations, study names, and authentication and other security data appropriate to enable secure users logins and study data access. The system data-pod 54 also preferably contains data sufficient to perform global data-pod discovery. Thus, subject to managed security constraints, the system data-pod 54 operates largely as network accessible storage resource specifically for the system server 52 and generally for other systems that are in and connect to the Clinical Payment Network 50.

[0054] Multiple application servers 56 are preferably provided to execute at least the core components of a clinical payment application that effectively implements the Clinical Payment Network 50. In the preferred embodiments, the clinical payment application is implemented using the software as a service (SaaS) and service oriented service (SOA) architectures. The application servers 56 are preferably geographically distributed.

[0055] Unlike conventional SaaS systems, data storage for the clinical payment application is preferably distributed to multiple organization data- pods 58 and multiple study data-pods 60, 62. These organization data-pods 58 and study data-pods 60, 62 are maintained under the control of individual organizations, as defined above, that participate in the Clinical Payment Network 50. Organizations, such as sponsors, CROs, pharmacies, laboratories, sites, and other entities, may each act as a custodial organization and thereby control access to data contained in a corresponding organization data-pod 58 instance and one or more study data-pods 60, 62. Preferably, the data-pods 54, 58, 60, 62 each have a single custodial organization. Conversely, an organization may be custodian for one or more study data pods 60, 62 and one corresponding organization data-pod 58. Custodial organizations may grant access to non-custodial organizations, typically by way of invitation or a defined corporate relation. This allows non-custodial organizations to access defined portions of the custodial organization data- pod 58 instance and a one or more corresponding study data-pod 60, 62 instances, dependent on the functional role of the non-custodial organization. As such, the Clinical Payment Network 50 can provide comprehensive access, subject to security controls, to all entities that participate in any particular study.

[0056] Financial and other services 64 generally are permitted access to and are accessible as needed from the Clinical Payment Network 50. Preferably, these services 64 include currency transfers, consultants performing regulatory compliance reviews, clinical systems hosted by third-parties and organization data warehouses, and specialized data sources. In particular, financial services will be provided by banks and similar institutions. Other services are supported as needed, and preferably include specialty CROs with specific capabilities, electronic and remote data capture services, data warehouses maintained by or on behalf of sponsors or other entities. Preferably, a client application implementing a Clinical Payment Network 50 interface (not separately shown) is provided to these services 64 to enable custodial organization defined role appropriate interactions with the financial and other services 64.

[0057] Preferred implementations 70 of an organization data-pod 58' instance, study data-pod 60' instance, and an application server 72 instance is shown in Figure 3B. The system data-pod 54 is structured essentially the same as an organization data-pod 58'. The organization data-pod 58' receives messages sent through the ESB 32 via the network 1 2 and a corresponding service requestor stub 34'. Messages are received in an inbox 74 and typically held for review. The organization data-pod 58' includes a database 76 that stores data specific to the corresponding custodial organization. The database 76 provides structured storage of data according to multiple schemas. In a preferred embodiment, schemas are provided for accounting, general organization structure, such as personnel, divisions, departments, companies, locations, addresses, security information and authorizations, budgets, contracts and CML support, configuration, notifications and reports, and text files.

[0058] A study data-pod 60' includes a message inbox 78 and study database 80. The inbox 78 receives and typically holds incoming messages for review. The study database preferably stores all of the information specific to a particular clinical trial. Study data-pods preferably provide structured storage for how clinical trials are set, including general information about sponsors, sub-sponsors, areas, cohorts, visits, procedures, CRF's, sites, subjects and events. Isolation of the study data on the basis of one study per data-pod, i.e., to a study data-pod 60' instance placed and maintained under the control of the custodial organization, precludes accidental or other unauthorized access to the study data. The potential of commingling data from multiple studies and from different custodial organization subnetworks is efficiently avoided. [0059] A potentially consequential issue exists in that the distributed data-pods 58, 60, 62 likely exist in domains different from those of the application servers 56. Conventionally, cross-domain database transactions have a limited ability to implement transaction-based reliability measures. The preferred embodiments implementing the present invention advantageously utilize the capabilities of the ESB 32 to create reliable asynchronic transactions for message transmission between the distributed data-pods 54, 58, 60, 62 and the application servers 56 by way of the ESB 32. Consequently, where high-reliability is required, messages are routed through the ESB 32. Otherwise, the application servers 56 may utilize direct network 1 2 connections to the inboxes and data-pod resident databases, subject to decreased reliability margins.

[0060] An application server 72 instance is preferably implemented as a high-performance computer system, real or virtual. An application server process 82 is executed to coordinate the processing of messages as received by organization and study data-pod 58', 60' instances that are effectively assigned to the application server 72 instance. Preferably, when a message is queued in an associated inbox 74, 78, notice is provided over the network 1 2 to the application server process 82 and recorded in an event database 84. Performance permitting, the application server process 82 retrieves the message and, where the message contains a CML statement, a CML evaluation engine 86 is used to execute or otherwise process the CML statement. The execution result is a result object that includes a boolean status state. Where the execution result status is True, the result object will also typically identify a completion procedure to be performed. If false, execution of the CML statement is simply terminated.

[0061 ] To execute the completion procedure, the result object representation of the message is transferred to a messages engine 87 that provides execution support for the set of possible completion procedures. In executing the completion procedure, the messages engine 87 will perform one or more operations that typically involves the accessing and potentially modifying data stored by the system data-pod 54, accessing and modifying data stored in the associated combination of organization and study databases 76, 80 and generating new messages that contain CML statements that typically in sequence implement some business operation. These forwarded by the application server process 82 through a corresponding service provider stub 36' and the ESB 32 for delivery.

[0062] A conventional Web server 88 is provided as part of the application server 72 to enable network access to the application server process 82 by users of client systems 20, 22 who have authenticated privileges that permit at least some degree of access to the data held in the organization data-pod 58' or study data-pod 60'. Preferably, the Web server 88 enables presentation of a form-based interface to users with possible data access to any combination of system, organization, and study data-pods 54, 58', 60'. When users of the client systems 20, 22 act to enter new or revised data through an application server 72, one or more events are triggered typically resulting in some combination of data modification in the associated organization and study data-pods 58', 60' and the creation of new messages to be transmitted to one or more other data-pods.

[0063] In an alternate embodiment of the present invention, active data- pods may be implemented by functionally combining an instance of the application server 72 with either an organization data-pod 58' or study data- pod 60'. These active data pods are distributed as with the preferred passive data-pods. Some efficiencies are gained, including collocation of the application server at an organization controlled data center, reduced security complexities, and lower potential network latency. Reliance on the on the larger Clinical Payment Network 50 is reduced and creates the potential for partial if not full independent operation.

[0064] As illustrated in Figure 4 for the preferred embodiments of the present invention, a messages engine 90 is implemented, in part, using a Microsoft Message Queue (MSMQ) cluster 92. The MSMQ cluster 92 is further provided as one of the ESB embedded components 38. Messages, for example from study and organization data-pods 94, 96, 98, whenever sourced, are transferred to the ESB 32 and then to input queues 100_η __N present in the MSMQ cluster 92. Preferably, each of the input queues 100_η __N is assigned a category of message types to handle. As messages are received by the MSMQ cluster 92, the message type is decoded and the message routed to a corresponding input queue 100_η __N.

[0065] The input queues 100^ __N are progressively read by one or more queue dispatchers 1 02_{η .Μ}. These queue dispatchers 102_{η .Μ} inspect and dispatch the messages to message identified target destinations, such as, for example study and organization data-pods 1 08, 1 10, 1 1 2. The dispatched messages are directed to one or more of the inbox queues associated with each of the data-pods 108, 1 1 0, 1 1 2, as well as the inbox associated with the system data-pod 54. Messages that are invalid or otherwise cannot be successfully dispatched are initially transferred to an error queue 106. As then queued, these failed messages are re-targeted to the system data-pod 54 inbox and marked for administrative or procedural review. When performance permits, failed messages are sequentially dispatched through the queue dispatchers 102·, __Μ.

[0066] By default, messages received in an organization or study inbox 108, 1 10, 1 1 2, are held for consideration by a representative of the corresponding organization. The representative preferably reviews the inbox queued messages and may selectively accept or reject the action defined by the corresponding message. Where accepted, the action is functionally executed, typically resulting in an update of the underlying data store. Upon completion of the action, a corresponding status message is generated and sent to a data-pod corresponding input queue 100_η __N typically for return to the data-pod that sourced the sequentially prior message. Some messages, most notably simple status messages, message acknowledgments, and other non- transactional messages, may be immediately accepted through a data-pod inbox and updated to the underlying data store. Administrative, management, and configuration related messages are preferably automatically accepted.

[0067] Messages received by the system data-pod 104 are preferably handled autonomously by default. As before, messages are initially received and queued in the corresponding data-pod 104 inbox. If marked for review, the message is held in the inbox for administrative or procedural review. Otherwise, in summary, the message is processed and, as appropriate, processed against the appropriate CML code blocks.

[0068] Referring to Figure 5, a contract meta-language representation of a clinical trial agreement is preferably constructed utilizing a CML authoring tool 1 20. The product of the authoring tool 1 20 includes a parameterized Ul specification and a parameterized executable code block or machine-readable code. The Ul specification describes a user interface screen tailored to allow a client user to make constrained, form-oriented entries for the corresponding CML statement. The parameterized executable code block contains an executable statement or set of statements preferably representing a source code fragment that can be interpreted, compiled, or otherwise made executable to implement a logic function and set of one or more the completion procedures that, together, will functionally implement the corresponding CML statement. [0069] A given source clinical trial agreement 1 22 is reviewed by a data entry clerk to identify quantifiable operational and performance related contractual terms. As such terms are identified, the data entry clerk utilizes a form-oriented user interface (Ul) 1 24 to enter the corresponding CML statement. A base template most closely matching the nature of the term is selected 1 26 from a CML library 1 28 containing base templates. Custom templates can be created and added to the CML library 1 28 for subsequent reuse. Figure 10 shows an exemplary base template 290 as displayed in a Ul form to a data entry clerk upon selection from the CML library 1 28. The initial constrained natural language representation of this exemplary template instance is: When INPUT subjects have a subject status of SELECT, pay $ AMOUNT. [0070] The template can present any number of parameterizable elements. Based on the specific contractual term considered in the clinical trial agreement 1 22, the data entry clerk can then enter corresponding parameters for this template instance. With parameterization, the constrained natural language template instance is: When 3 subjects have a subject status of On Study, pay $5000. [0071 ] Figure 1 1 provides a representation of the corresponding Ul form presented template 300 with these parameterization values entered. The selectable values entered in the parameterizable elements of a template are constrained by reference to the CML library 1 28. Specifically, the CML specification underlying the form shown in Figure 1 1 is preferably represented by a CML template Ul specification: When {Integerl rinteger} Subjects Have Subject Status of {Strl rstring} Pay {Amtl rdecimal} where a brace enclosed word identifies a variable type and an italicized word is a system-defined keyword. Labels for variable type instances are specified as {labe type}. Note, these specific stylings are for purposes of clarity in the present discussion; other stylings, including color and other syntactic presentation, may be used in practice. The Ul specification is preferably maintained separate from the parameterization values.

[0072] The corresponding CML template code block specification is: When {Integerel rinteger} [[Subjects]] Have [[[Subject Status]]]

of {Strl rstring}

Pay {Amtl rdecimal} where double brackets identify a dynamic object, also referred to as a token, and triple brackets identify an object property. Thus, as defined, 'Subject Status' is a property of the object 'Subjects'. Tokens and corresponding permitted token properties are stored in the CML library 1 28.

[0073] Particularly for CML template code block specifications, the code specification can be further rendered to produce a corresponding code fragment that is functionally executable. Preferably, the code fragment is rendered as a source code fragment that can then be prepared for execution through use of an interpreter or compiler. As an example, the above CML template code block specification can be rendered as a C# source code fragment: if( GetSubjectsByStatus( "{String}" ).Count() = = {integer} )

ExecuteTransaction( {decimal} ) [0074] Six further examples of the constrained natural language specification system as implemented in a preferred embodiment of the present invention are presented below.

[0075]

Template (as retrieved from CML library): (1 ) For Every INPUT Subject(s) with Visit SELECT Status of SELECT

- Record Transaction (2) For Every INPUT Subject(s) when All CRFs for Visit SELECT

are Status SELECT

- Record Transaction (3) For Every INPUT Subject(s) when All CRFs for Visit SELECT

are Status SELECT

and Procedure SELECT

at Visit SELECT

is Status SELECT

- Record Transaction (4) When Local IRB Status is SELECT or Drug Status is SELECT

- Record Transaction (5) When CTA Status is SELECT

- Set SELECT to INPUT (6) When Subject Status is SELECT and SELECT are Greater Than INPUT

- Decrease SELECT by INPUT and Record Transaction Parameterized Template (clinical trial agreement specific): (1 ) For Every 3 Subject(s) with Visit Screening Status of Complete

- Record Transaction (2) For Every 1_ Subject(s) when All CRFs for Visit Randomization

are Status Monitored

- Record Transaction (3) For Every1 Subject(s) when All CRFs for Visit Week 1

are Status Frozen

and Procedure Colonoscopy

at Visit Screening

is Status Complete

- Record Transaction (4) When Local IRB Status is Approved or Drug Status is Shipped

- Record Transaction (5) When CTA Status is Executed

- Set Screen Fail Credits to 5 (6) When Subject Status is Screen Fail and Screen Fail Credits

are Greater Than 0

- Decrease Screen Fail Credits by j_ and Record Transaction CML Template Ul Specification (1 ) For Every {Integerl :lnteger} Subject(s) with Visit {Visit 1 :Visit}

Status of {VisitStatusl : Visit Status}

- Record Transaction (2) For Every {Integerl :lnteger} Subject(s) when All CRFs

for Visit {Visit 1 :Visit}

are Status {CRFStatusl :CRF Status}

- Record Transaction (3) For Every {Integerl :lnteger} Subject(s) when All CRFs

for Visit {Visit 1 :Visi†}

are Status {CRFStatusl :CRF Status}

and Procedure {Procedurel :Procedure}

at Visit {Visi†2: Visit}

is Status {ProcedureStatusl :Procedure Status} - Record Transaction (4) When Local IRB Status is {IRBStatusl :Local IRB Status}

or Drug Status is {DrugStatusl :Drug Status} - Record Transaction (5) When CTA Status is {CTAStatusl :CTA Status}

- Set {CMLVariablel :CML Variable} to {Integerl :ln†eger} (6) When Subject Status is {SubjectStatusl :Subject Status}

and {CMLVariablel :CML Variable} are Greater Than {Integerl :ln†eger} - Decrease {CMLVariable2:CML Variable} by {In†eger2:ln†eger} and Record Transaction CML Template Code Block Specification (1 ) For Every {Integerl rlnteger} [[Subject(s)]] with [[[Visit]]] {Visit 1 :Visit}

[[[Status]]] of {VisitStatusl : Visit Status}

- Record Transaction (2) For Every {Integerl rlnteger} [[Subject(s)]] when All CRFs

for [[[Visit]]] {Visit 1 :Visit}

are [[[Status]]] {CRFStatusl :CRF Status}

- Record Transaction (3) For Every {Integerl rlnteger} [[Subject(s)]] when All CRFs

for [[[Visit]]] {Visit 1 :Visit}

are [[[Status]]] {CRFStatusl :CRF Status}

and [[[Procedure]]] {Procedurel :Procedure}

at [[[Visit]]] {Visi†2:Visit}

is [[[Status]]] {ProcedureStatusl : Procedure Status} - Record Transaction (4) When [[Local IRB]] [[[Status]]] is {IRBStatusl :Local IRB Status}

or [[Drug]] [[[Status]]] is {DrugStatusl :Drug Status} - Record Transaction (5) When [[CTA]] [[[[Status]]] is {CTAStatusl :CTA Status}

- Set {CMLVariablel :CML Variable} to {Integerl :ln†eger} (6) When [[Subject]] [[[Status]]] is {SubjectStatusl :Subject Status}

and {CMLVariablel :CML Variable} are Greater Than {Integerl :ln†eger} - Decrease {CMLVariable2:CML Variable} by {In†eger2:ln†eger} and Record Transaction Source Code Fragments (1 ) if (AndEvent(EligibleStudyEvents.WithStatus({VisitStatusl })

.ForVisit({Visitl })))

{

return RecordTransaction(ForEvery({ln†egerl }));

}

return base.Evaluate(args); (2) if (AndEvent(AIICRFsForVisit({Visitl }),

EligibleS†udyEvents.A†Visit({Visitl })

.WithStatus({CRFStatus 1 })))

{

return RecordTransaction(ForEvery({ln†egerl }));

}

return base. Evaluate(args); (3) if (AndEvent(AIICRFsForVisit({Visitl }),

EligibleS†udyEvents.A†Visit({Visitl }).WithStatus({CRFStatusl }))) {

if (AndEven†(EligibleStudyEven†s

.ForProcedure({Procedurel })

.A†Visit({Visi†2})

.WithStatus({ProcedureStatusl })))

{

return RecordTransaction(ForEvery({ln†egerl }));

}

}

return base.Evaluate(args); (4) if (OrEvent(EligibleStudyEvents.WithStatus({IRBStatusl }),

EligibleStudyEvents.WithStatus({DrugStatusl }))) {

return RecordTransaction(First());

}

return base.Evaluate(args); (5) if (AndEven†(EligibleS†udyEven†s.Wi†hS†a†us({CTAS†a†usl })))

{

return Se†Variable(First(), {CMLVariablel }, {Integer^"! });

}

return base.Evaluate(args); (6) if (AndEvent(EligibleStudyEvents.WithStatus({SubjectStatusl })))

{

if (AndVariable({CMLVariablel }, {Integerl }))

{

return RecordTransaction(Decremen†Variable(Always(), {CMLVariable2}, {Integer2}));

}

}

return base.Evaluate(args); [0076] Referring to Figure 6, at least a portion of the CML library 1 28 is shown diagrammatically. Whether stored in an XML or other text document or as database records, a user definable collection 1 62 contains dynamic objects 1 64 and lists of corresponding permitted properties 1 66. Exemplary objects 1 62 and corresponding permitted property lists 1 64 are presented in Table 1 :

[0077]

[0078] A system defined collection 1 68 contains variable types 1 70 and predefined keywords 1 72. These variable types and keywords are preferably related only by the shared, system defined nature. Variable types can be simple or defined. Simple types include, for example, 'integer', 'string', and 'date'. Defined types are program objects defined typically in the support libraries used in the runtime evaluation of the CML statements. A variable type of 'visit' may be thus defined as either zero or a positive integer. A variable type of 'procedure' may be defined as an array of type 'string', while 'procedure status' may be defined by an enumeration. A variable type of, for example, 'CML variable' may be established to allow access to some system or application-specific value.

[0079] Exemplary simple and defined variable types 1 70 are listed in

Table 2

[0080]

[0081 ] The preferred embodiments of the present invention include a standard set of defined variable types. These variables types and the selection of corresponding acceptable values are derived from the study configuration information stored in the system data-pod 104 and are thus available for all studies. As listed in Table 2, these standard defined variable types are further specified as follows: {Cohort} A selection of all cohorts (or treatment arms) in the selected study, such as "Placebo", "Active Drug", etc.

{Visit Type} A selection of all visit types, such as "Screening", "On

Study", "Follow Up", defined for the selected study.

{Visit} A selection of all visits defined for the selected study, such as "Screening", "Visit 1 ", "Week 1 2", etc. {Procedure} A selection of all procedures defined for the selected study, such as "Vital Signs", "Colonoscopy", "Physical Exam", etc.

{CRF} A selection of all case report forms defined for the

selected study, such as "Lab", "Demographics", "Medical History" [0082] The listed custom defined type represents defined variable type objects that are typically specified at the level of a custodial organization and therefor available to use in all studies that the organization is involved with.

[0083] While variable types allow entry of type constrained values, keywords perform both semantic and syntactic functions. Keywords can be used syntactically to increase the simple natural language readability of CML statements as well as allowing industry specific keywords to be used in place of possibly conforming, though generic keywords. Placement of keywords within a CML statement, as an element of the natural language structure, permits semantic inference of the operation intended to be performed by a particular CML statement. Since CML statements are relatively concise, the semantic analysis is neither too ambiguous nor too burdensome. [0084] Exemplary predefined keywords 1 72 are listed in Table 3:

[0085]

[0086] System and user-defined templates 1 74 include a base template set 1 76 predefined by the system. Customized base templates 1 78 can be created by a user and stored for future reuse. The base template set 1 76 is constructed from common, meaningful combinations of the objects 1 64, types 1 70, properties 1 66 and keywords 1 72.

[0087] The provision of dynamic objects 1 64 and properties 1 66 allows users to dynamically create new operational events and corresponding constraint properties. When a dynamic object 1 64 is created and one or more properties 1 66 specified, the object name and corresponding list of constraints are automatically added to the CML library 1 28. The new object 1 64 is then immediately available to be used or selected in entering a negotiated clinical trial source contract 1 22 term. In a preferred embodiment, these new dynamic objects 1 64 are used to describe unique operational events in a clinical trial. Exemplary new objects include 1 64: Study Drug, Study Status, Subject Status, Site Status, Subject Visits, Procedures and Contract Status. In the creation of customized templates 1 78, dynamic objects 1 64 are also referenced as tokens. Every occurrence of an operational event has an associated event date.

[0088] Object properties define the available states or operational outcomes of an outcome field defined within a dynamic object. Given a dynamic object 'Subject Status', the object property type of the outcome could be {string}. Where multiple object properties may be associated with the 'Subject Status' field of the dynamic object, a valid inference would be to autonomously select a {text box} display component over a {text field} or {list} for presentation of multiple object properties. Alternately, the outcome field could be expressly defined, during parameterization 1 30 of the base template, to have a Ul display variable type of {string}, a Ul display description of "Patient Status", and a Ul display component type of {list}.

[0089] In the latter instance, the CML template Ul form would present a list component populated with the object properties associated with the 'Subject Status' dynamic object, subject to being filtered by the associated identity of the clinical trial, trial site, and trial investigator. In one case, the filtered object properties might be "dropped", "enrolled", "early termination", and "completed". For a different investigator or site within the same trial, the filtered object properties might be "active", "pending", and "inactive".

[0090] Returning to Figure 5, a parameterized CML statement is parsed and generated 1 32. In parsing the CML statement as represented by the CML template Ul specification, specified fields, descriptions, display components, and values are identified. Any missing information is defaulted where appropriate. An inferencing operation is performed, as necessary, to identify and select suitable information to complete the CML template Ul specification. The preferred result is an appropriately qualified Ul markup specification that defines a form element usable to allow user entry and edit of the CML statement values. In the presently preferred embodiments of the present invention, the underlying CML template Ul specification is sufficiently descriptive to act as a useful markup language within the domain of the present invention. Other Ul markup languages, including for example the XML User Interface Language (XUL), may be alternately used. The generation 1 32 step may also be used, as may be required, to organize and adjust the format of the CML template Ul specification in preparation for subsequent storage and use.

[0091 ] Similarly, the CML template code block specification is parsed 1 32 to apply defaults and inference any additional information appropriate to create a fully formed CML template code block specification. A parameterized executable code block is generated 1 32 from the CML template code block specification. This code block preferably represents a code fragment containing one or more source statements in the Microsoft C# language. While C# is presently preferred, the code generation 1 32 operation can be adapted to produce the executable code block in number of other source languages. Java, JavaScript, Lua, and Go are suitable alternative source languages. The generated executable code block is preferably prepared for storage in source form, though a compiled instance may be cached.

[0092] The functional completeness and logic of the generated CML template Ul specification and CML template code block specification, including the generated executable code block, is then validated 1 34. If any aspect of the specifications are incomplete or improperly structured, include any logical inconsistencies, are not interpretable or compilable without errors, or otherwise incurs any other validation failure, the parameterized template is returned 1 24 for inspection and correction by the data entry clerk.

[0093] Where the CML template Ul and code block specifications are determined valid, a template record 1 36, preferably suitable for storage in a data-pod resident database, is created. The parameterized CML Ul specification 1 38 and parameterized CML code block specification 1 40 are copied into one aspect of the template record 1 36. This aspect is then preferably stored in an organization level data-pod instance 142.

[0094] The dynamic objects, earlier selected as parameterization values for use in the evaluation of the specifications 1 38, 140, are preferably stored in another, separate aspect of the template record 1 36. This latter aspect is preferably stored in the study data-pod 144 used for the source contract 1 22 corresponding clinical trial. Thus, the study specific parameterization values, as tokens, are stored separate from the CML Ul and code block specifications 1 38, 140.

[0095] By rendering the set of contract terms contained in the source agreement 1 22 as a collected set of CML statements, automation of the source agreement is functionally achieved. The source agreement 1 22 can be a compilation of one or more agreements that, together, represent and define the operational and procedural events necessary to implement a study protocol. Amendments and other changes made are reflected by adding, modifying, and removing altered contract term corresponding CML statements. Consequently, the impact of changing source agreement 1 22 terms is minimal. The CML statements are, in effect, atomic.

[0096] As discussed above, the effective execution of CML statements is performed in response to the transit of operational events, as conveyed by messages, through an application server process 82 instance as executed on the application servers 56. With reference to Figure 7, the initial generation of an operational event will occur in response to any number of different actions taken by sponsors, CROs, investigators and others, including other automated systems, that interact with the distributed data processing system 10. An exemplary action by a user is the addition of new information, such as performed through a data-entry form. Upon submission of form entered data, an operational event is generated 1 92. The event is associated with event related data 1 94, particularly including the data associated with the event generation, such as the data provided through the data-entry form, and information identifying the clinical trial and sufficient to identify the associated organization and study data-pods, the corresponding investigator and site, and related details, as applicable. The message is prepared 1 96 and transmitted 1 98 through a corresponding service requester 34. The message is routed through the cluster 92 and to an application server process executed by the servers 56.

[0097] Referring to Figure 8, a CML statement execution engine 210, as implemented in a preferred embodiment of the present invention, is embedded with an application server process 82 executed on the servers 56. The engine 210 initially receives an operational event via the message inbox of an associated study data-pod 60', 62'. As each operational event is received 21 2, the event related data is saved to an event database 21 4 and a notification is sent effectively to the CML engine 21 0 indicating that a new operational event has been received and is awaiting review.

[0098] The initial step in processing a new operational event is to validate 21 6 the event. Validation is performed to verify the source and data integrity of the operational event. Additional validation and fraud detection tests are preferably performed as a prerequisite to making the operational event available for CML evaluation.

[0099] Operational events that fail validation must be subjected to further review. Preferably, the event is passed to a review process 21 8, typically involving some degree of human intervention. Within the review process 21 8, the reviewer may accept, reject, or edit and resubmit the operational event to retry validation 21 6. [0100] Provided an operational event has passed all validation tests or has otherwise been accepted on behalf of the CML engine 210, the operational event is released 220 into a pending status awaiting CML evaluation.

[0101 ] Preferably, the CML statement evaluator, as implemented within the CML statement execution engine 210, can operate in several different modes depending on, for example, the desired performance level of the CML statement execution engine 210, typically as measured by event throughput and a transaction latency limit. The presently available CML statement evaluator modes include incremental, full, expected, and forecast. Incremental mode is the preferred default mode. In incremental mode, only new valid operational events 228, received within the last evaluation cycle, are considered in determining the CML statements to be evaluated, preferably defined as an evaluation set. The last evaluation cycle is defined as the period of time after the CML statement execution engine 210 last finished the complete evaluation of an event. If the evaluation set contains an "all sites" or study-wide operational event 230, such as study status, then the evaluation preferably switches immediately to full mode.

[0102] For full mode, all current, valid operational events are selected 232 in determining the evaluation set. In expected mode, the CML evaluation runs largely consistent with full mode. An additional, expected set of operational events are also included. Specifically, this expected set of events are those events identified according to the relevant study protocol as expected to already have occurred but have not yet been received by the CML statement execution engine 210. In forecast mode, the CML evaluation again largely runs consistent with the full mode of operation. The additional operational events considered in determining the additional forecast set includes all of the operational events yet to be received, beginning from the current time point through to the end of the clinical trial or study.

[0103] Once the evaluation set is established, the CML statement evaluator determines 234 the distinct set of study locations referenced in the evaluation set. Only CML statements associated with these study locations need to be evaluated. A study location is typically the same as a site with a persistent, physical address, such as a hospital, medical office, or clinic.

[0104] For each identified study location, only the CML statements corresponding to the contract terms associated with a particular study location need be selected for evaluation 236. In one embodiment, CML statements can be further classified by operational event types so that upon import or entry of operational event data, only CML statements for a chosen classification will be evaluated, thereby improving the efficiency of the CML statement evaluator.

[0105] If subject relative operational events exist 238 in the evaluation set for a particular study location, the corresponding CML statements are evaluated 240 for each referenced subject. Subjects that do not appear in the evaluation set are not processed. If no subject related events are present in the evaluation set for a particular study location, the CML statements are evaluated 248 once with respect to the study location only.

[0106] CML statements are preferably defined by a CMLStatementTem plate class. This class contains two significant properties. A "CML" property contains the CML template Ul specification that is parsed and used to render Ul controls to collect values for each dynamic object property and variable defined in a given CML statement. The values collected are preferably stored in the event database 214 as name/value pair "tokens". The other property, denominated "Code", contains CML template code block specification. This specification includes source statements that, when interpreted, compiled, or otherwise processed, produces machine readable code executable by an application server 56 instance and capable of producing a result value. In operation, the CML statement evaluator determines the execution produced result value against the CML statements against operational events to determine whether or not a transaction is needed. In a preferred embodiment, the code fragment provided by the CML template code block specification contains defined "markers" that identify a particular token and property. Prior to execution of the code fragment, the markers are identified and, by a dynamic revision of the code fragment, the markers are replaced with the corresponding parameterized value for the template token instance.

[0107] In a preferred embodiment of the present invention, a generic CMLStatementEvaluator base class is defined. This class implements a virtual "Evaluate()" method that accepts an arbitrary number of parameters to support future enhancements and backwards compatibility. Execution of the Evaluate() method will return an enumeration, called "CMLStatementResult". The virtual evaluate method can be overridden by any CMLStatementEvaluator derived class. The base class also provides a number of protected properties and methods that can be used by derived classes.

[0108] As implemented in the preferred embodiments, to evaluate a CML statement, the CML statement evaluator first checks to determine if a CMLStatementEvaluator instance has already been compiled for the CML statement. Since the code generated for a particular CML template code block specification and parameterization list of tokens and variables is the same, the source code fragment may be compiled once and cached for use in subsequent evaluations. In the absence of a compiled instance, the corresponding source code is dynamically modified and then an executable code generator is invoked. Specifically, source code fragment is parsed to substitute markers for corresponding token property values and variable values. The resulting source code is next wrapped in a class extending CMLStatementEvaluator. The C# compiler is then invoked to produce a compiled instance. This CMLStatementEvaluator object is used subsequently by the CML statement evaluator to evaluate operational events for this unique CML statement.

[0109] The CML statement evaluator implements the necessary environment to execute the instantiated CMLStatementEvaluator object by invoking the virtual "Evaluate()" method. Functionally, execution of the compiled code fragment performs a logical condition testing of the values defined in the compiled code fragment against each operational event in the evaluation set of operational events. The order of the conditions evaluated against an operational event is preferably not constrained to be sequential. For example, the temporal order of evaluation of an operational event can occur before, during, and after another operational event.

[01 1 0] At execution completion, a CMLStatementResult object is returned as a result 242. If this result 242 matches a defined value corresponding to False, the evaluation of the CML statement terminates 250. The evaluation result 242 will be False unless all operational events required by the CML statement are present.

[01 1 1 ] If the result 242 corresponds to a defined True value, then all operational events associated with the transaction are satisfied, but a frequency or quantity component of the CML statement has not been satisfied. For example, where the CML statement specifies a counted requirement, such as "For Every 2 Subjects", a corresponding transaction term will be saved 252 to maintain state in the ongoing evaluation of CML statements.

[01 1 2] An evaluation result 242 of TrueWithTransaction will occur when all operational events associated with the CML statement are satisfied and all frequency or quantity components of the CML statement has also been satisfied. In this case, a CMLTransaction object is created and initialized with information identifying the study location (PI), contract owner, whether a sponsor or CRO, a description of the operational events that satisfied the transaction and the source of those events, and other information needed to create a financial or non-financial transaction. This object is then sent to a contractor organization data-pod inbox for processing. Notably, a CML evaluation is only concerned with evaluating the conditions that determine if and when a transaction should be generated. The CML evaluation is agnostic concerning the details of the actual underlying transaction.

[01 1 3] An exemplary transaction flow 260 illustrating an efficient application of the Clinical Payment Network 50 is presented in Figure 9. The transaction flow 260 will typically occur in clinical trial and other related agreements, such as clinical research agreements, whenever sponsors and CROs are required to issue reimbursements and other payments to or on behalf of investigators in a manner specified by a clinical trial agreement. The transaction flow 260 demonstrates the effective collection of reimbursement information, an approval review, and completion resulting in the disbursement of funds.

[01 1 4] Investigators 262 include doctors, hospitals, other health care providers who are involved in the performance and management of a particular clinical trial. Subjects 264, as patient participants, are typically associated with the investigators 262 who undertook the enrollment of the subjects 264 as well as providing ongoing treatment and follow-up visits. These subjects 264 are also identified as participating in the same clinical trial. Affiliates 266 are also directly associated with the subjects 264 generally under the direction of the investigator 262. Affiliates 266 are typically laboratories, pharmacies, and other supporting product and service providers. [01 1 5] Preferably, on entry into a trial, the investigators, 262, subjects 264, and affiliates 266 are permitted access through an application server 56 instance to the trial corresponding organization and study data-pods 58, 60. Access is constrained to reflect the specific roles of the investigators 262, subjects 264, and affiliates 266. As potentially reimbursable expenses are incurred including, for example, equipment purchase payments, the investigators 262, subjects 264, and affiliates 266 may access the study relevant organization and study data-pods 58, 60 as appropriate to submit expense reports, expense support, and other information requested or required for consideration of the underlying payment request. Access is typically performed through use of the Web form-based interface provided by a Web server 88 hosted on a corresponding application server 56 instance also associated with the corresponding organization and study data-pods 58, 60.

[01 1 6] The application server 56 instance associated with the trial organization and study data-pods 58, 60 operates, in this example, as an accounting engine 268. That is, the receipt of reimbursement requests results in the selection and evaluation of CML statements that collectively implement or relate to qualifying payment requests and related accounting business operations. This selection of CML statements is implicit, arising from a cascade of operational and procedural events deriving from the postings of reimbursement requests and related information. The specifics of the business operations carried out as a consequence are as defined in an applicable source agreement 1 22 and as reduced to a corresponding collection of CML statements.

[01 1 7] Thus, for example, the collection of CML statements, upon evaluation, progressively define a business processes of collecting and organizing the provided reimbursement data and, at defined intervals, sequencing the documentation through selected reviewers to obtain any required pre-approvals. The reimbursement requests by subjects 264 and affiliates 266 may run at different intervals and be examined by different reviewers who may be categorically specialized for these different types of requests.

[01 1 8] To the extent that pre-approvals are received, the result may be that the accounting engine 268 will typically generate invoices 1 70 or other financial documents on behalf of the investigators 262, subjects 264, and affiliates 266 at times applicable to the different organization roles as defined through the CML statements and sufficiency of the reimbursement requests and supporting information provided functionally as defined by the controlling agreements. Generated invoices are again sequenced to the necessary reviewers as necessary to gain invoice approval 272. The approved invoice 272 is then routed to a payment engine 274. Like the accounting engine, the payment engine 274 is an application server 56 instance also associated with the trial organization and study data-pods 58, 60. This application server 56 instance is functionally characterized as a payment engine 274, reflecting execution of the payment business processes implemented by the cascade of events initiated by the receipt of the approved invoice 270.

[01 1 9] Again, depending on the specifics of the collected CML statements upon evaluation, final approval request messages may be sent from the payment engine 274 to the sponsor 276 and any CRO 278. These organizations 276, 278 act to provide a final approval, realized as one or more messages sent, as appropriate, to the organization and study data-pods 58, 60 associated with the application server 56 instance representing the payment engine 274. These messages, as received, represent events to the payment engine 274. Depending on the manner of payment specified functionally by the trial controlling agreements, the business processes controlling the manner and timing of disbursements are executed by the payment engine 274. As denoted by the dashed lines, funds are forwarded from the sponsor 276, directly or through the CRO 278, as needed to replenish the working account provided the sponsor 276 or the CRO 278 effectively managed by the payment engine 274. Appropriate payments are separately directed to the investigators 262, subjects 264, and affiliates 266. In addition, refunds can be similarly handed through execution of these business operations.

[01 20] Of note, clinical trials often provide payments to subjects of a particular study using payment cards, such as credit, debit, prepaid including reloadable cards that store electronic funds or link to corresponding deposit accounts or the issuance of a check, ACH payment, or wire transfer. This arrangement allows the investigator, CRO, or sponsor to issue payments to subjects for travel and meals, completion of trial milestones, office visits, and other payment events specified typically in the clinical trial agreement. The timetables and requirements that trigger payment events to subjects and organizations are therefore reducible to a set of CML statements as discussed above.

[01 21 ] The use of electronic payment systems has numerous advantages, such by eliminating the need for investigators to pay subjects and then seek reimbursement from the sponsor. The primary drawback is that these systems create an additional opportunity for fraud and the potential for processing errors.

[01 22] In a preferred embodiment, fraud detection is carried out on a trial site basis, and not necessarily on a trial subject basis. This is accomplished, at least in part, by the system server 52 maintaining a site-specific fraud score for each trial site. The fraud score is preferably based on evaluating the subject payment requests received for trial subjects associated with that trial site. In particular, the evaluation is advantageously based on the clinical trial agreement or other source document of operational or performance event terms. Thus, assessing the likelihood that a given payment request is fraudulent is driven by the underlying contractual expectations. This vets payment requests against the terms of the protocol itself and permits substantial if not complete automation of the fraud reduction process. Alternatively or in addition, payment requests can be compared against electronic data from various clinical management systems, such as IVRS, IWRS, CTMS, EDC, DMS and other systems storing clinical data, to identify deviations at the time of the payment request. Post analysis of prior trials can be used to build anticipatory fraud scores and identify potentially fraudulent or erroneous payment requests previously paid.

[01 23] In a preferred embodiment, the payment engine 274 includes a fraud detection engine that reports, for example, payment event identifiers, payment event type information, required event data to the system server 52. This information can be used to determine or otherwise implicitly define, a permissible timing or sequence of payment events. Timing may be absolute in calendar terms, or relative, such as days elapsed from the trial start or days prior to and after a scheduled visit date. The trial protocol may define an allowed payment window for a given payment event. A payment request corresponding to that payment event may be evaluated by comparing the actual timing to the permissible payment window. A request and frequency of requests outside of the window may be flagged as fraudulent or otherwise weighted to indicate the likelihood of fraud.

[01 24] Each site submits or otherwise authorizes payment requests for trial subjects concurrent with the processing of the subjects through the ongoing payment events. In turn, the fraud engine receives and processes the payment requests in view of the originating trial site. Thus, as each payment request is evaluated against the payment requirements defined by the trial protocol, the fraud engine will update the corresponding fraud score maintained for that trial site based on the weighted likelihood that the request is fraudulent.

[01 25] Combined with the described operation of the fraud engine, fraud can be further reduced in clinical trials that use payment cards for compensating trial subjects. Each payment card is associated within the Clinical Payment Network 50 with a corresponding trial subject and the primary trial site for that subject. During the trial, preferably in response to payment requests, the fraud engine can retrieve the corresponding transaction history.

[01 26] Current and historical transactions are evaluated to identify deviations from the expected sequence and amount of the transactions. If any deviations are identified, the fraud score associated with that trial site is updated as a weighted function of the identified deviations. Each fraud value determined by the weighted function may be computed or otherwise determined actuarially or empirically to reflect the likelihood of a fraud in the context of the site payment transaction history. Preferably, payment requests made by subjects associated with that trial site will be denied if the fraud score exceeds a defined threshold.

[01 27] Additionally, or alternatively, the overall fraud score of a site may be considered in decision to approve, deny, or flag an individual subject's payment transaction. For example, if the timing, amount, or other aspect of the payment request for a particular subject deviates from a norm determined from the events of other patient participants, that payment may still be allowed if the overall fraud score of the site is low or denied if the site's fraud score is high, though the score is still below the defined threshold for refusing all payment requests. [01 28] Thus, an efficient a computer-implemented system and methods for managing clinical trials, including payments made within the context of a distributed clinical trial in accordance with the terms of a clinical trial agreement, has been described. While the present invention has been described particularly with reference to typically human oriented clinical trials, the present invention is also applicable to other complex systems where efficient and reliable communications are required, coupled with defining and efficiently managing the security concerns for the data being routed through the system.

[01 29] In view of the above description of the preferred embodiments of the present invention, many modifications and variations of the disclosed embodiments will be readily appreciated by those of skill in the art. It is therefore to be understood that, within the scope of the appended claims, the invention may be practiced otherwise than as specifically described above.

Claims

Claims 1 . A computer implemented method of evaluating a complex set of financial and operational requirements defined in relation to the performance of a clinical trial, said method comprising:

a) receiving, from a distributed computer system, a first message identifying a first event initiated transaction within the performance of a clinical trial, said message including an identification of an investigator and a first event defined data set;

b) selecting a subset of executable template code blocks from a distributed database, wherein said subset is specific to said clinical trial and said investigator, wherein said executable template code blocks of said subset represent a plurality of declarative statements, wherein each said declarative statement represents a discrete financial requirement derived from a clinical trial agreement corresponding to said clinical trial and said investigator; c) executing an application dynamically incorporating said set of executable template code blocks, wherein said first message is evaluated by said application to determine whether said first event defined data evaluates successfully against said set of executable template code blocks, wherein a successful evaluation generates a second event; and

d) providing, in response to said second event, a second message, including said identification of said investigator, said clinical trial, and a second event defined data set, to said distributed computer system. 2. A method of reducing fraud in a clinical trial that uses payment cards or checks for compensating trial subjects participating in the clinical trial, said method comprising: associating each payment card with a given trial subject and, correspondingly, with a given trial site that is managing participation of the trial subject in the clinical trial;

receiving, for any given payment request, electronic data including one or more transaction parameters;

comparing the one or more received transaction parameters with corresponding stored transaction parameters that are defined by a clinical trial protocol, to identify deviations from the stored transaction parameters;

comparing the one or more received transaction parameters with corresponding stored electronic data from various clinical management systems (IVRS, IWRS, CTMS, EDC, DMS and other systems storing clinical data), to identify deviations;

if any deviations are identified, updating a fraud score that is maintained for the trial site, as a function of the identified deviations; and denying the payment request if the updated fraud score for the site exceeds a defined threshold. method of claim 2, wherein updating the fraud score comprises computing one or more weighting values as a function of the identified deviations, said weighting values representing the likelihood that the payment request is fraudulent, and updating the fraud score for the site as a function of the one or more weighting values or the frequency of one or more of the weighting values. 4. The method of claim 2, wherein the received and stored transaction parameters include a time parameter that defines a relative or absolute timing for which a corresponding payment request is deemed valid, and wherein comparing the received and stored transaction parameters comprises comparing a stored time parameter, as defined by the trial protocol, to a received time parameter. 5. The method of claim 2, wherein the trial protocol defines a number of payment events, for which payment card funding is authorized, and wherein the received and stored transaction parameters include a payment event identifier and comparing the received and stored transaction parameters comprises comparing the received and stored payment event identifiers to identify the defined payment event corresponding to the payment request, to then compare a received timing parameter received for the payment request, against a stored timing parameter defined by the trial protocol for the identified payment event. 6. A computer implemented method of functionally executing a natural language contractual agreement, said method comprising the steps of: a) identifying a plurality of contractual terms within a natural language contractual agreement, wherein each said contractual term includes a variable element and wherein each said variable element has a defined value;

b) reducing said plurality of contractual terms to respective constrained natural language declarative statements, wherein said variable elements are respectively present in said constrained natural language declarative statements;

c) parameterizing said variable elements to provide respective parameterized variable elements in each said constrained natural language declarative statement; and

d) recording said defined values with respect to said parameterized variable elements, whereby said defined values can be associated with corresponding ones of said parameterized variable elements, wherein said defined values are recorded separate from said constrained natural language declarative statements. 7. The computer implemented method of Claim 6 further comprising the step of autonomously generating respective machine source code fragments for said constrained natural language declarative statements, wherein said respective machine source code fragments retain an identification of said parameterized variable elements.