AU2011217881A1 - 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

WO 2011/103523 PCT/US2011/025570 1 [0001] CLINICAL PAYMENT 2 NETWORK SYSTEM AND METHODS 3 4 [0002] 5 6 7 8 9 [0003] This application claims the benefit of U.S. Provisional Application 10 No. 61/306,425, filed February 19, 2010, and which is expressly incorporated 11 by reference. 12 13 14 [0004] Background of the Invention 15 [0005] Field of the Invention: 16 [0006] The present invention is generally related to the field of 17 financial transactions as typically involved in medical research and, more 18 particularly, to a computer-implemented financial management system and 19 methods capable of managing clinical trials, including payments made within 20 the context of a distributed clinical trial in accordance with the terms of the 21 controlling agreements. 22 23 24 [0007] Description of the Related Art: 25 [0008] Clinical trials are conventionally required to establish the 26 safety and efficacy of health interventions involving, for example, drugs, 27 diagnostics, and devices. While early stage trials may be quite small, a later 28 stage trial can involve thousands of patient participants. While the number of WO 2011/103523 PCT/US2011/025570 -2 1 investigators actively involved in a clinical trial is dependent on the trial 2 enrollment requirements and disease state, often hundreds of investigators are 3 required. These investigators will be involved in the treatment and periodic 4 follow-up of individual patients for periods that can range from several weeks 5 to months and many may span multiple years. These investigators will often 6 be concurrently involved in multiple trials, where each investigator for each 7 trial will be required to manage a unique set of patient participants, with each 8 set having distinct treatment and follow-up requirements. 9 [0009] Sponsors of clinical trials, conventionally pharmaceutical, 10 biotech, medical device companies, research centers, hospitals, and other 11 similar entities, will contract to pay investigators, clinical research organizations 12 (CROs), laboratories, subjects (also referred to as patient participants), 13 research centers, hospitals, and other similar entities, to perform, manage, or 14 participate in certain operational events in the course of clinical trials. 15 Investigators are exemplary of the primary entities that undertake the 16 operational management and responsibility for a clinical trial. Typically, an 17 investigator must make timely payments to affiliates, such as laboratories, 18 infusion centers, x-ray and related imaging facilities, pharmacies, and other 19 third parties whose products and services are utilized in the performance of a 20 clinical trial. Up-front costs for training and establishing the necessary 21 infrastructure to direct a clinical trial are also paid by the investigator. 22 Investigators are also typically required to initially underwrite the costs of 23 enrolling and screening prospective patient participants as well as the ongoing 24 costs of the trial subjects and necessary health professionals. Participation fees 25 and related expenses payable to the patient participants must also be 26 advanced by the investigator. 27 [0010] Currently, investigators for clinical trials are paid on an industry 28 average of between 90 and 180 days or more after invoicing costs to a WO 2011/103523 PCT/US2011/025570 -3 1 sponsor or CRO or in the case where the CRO or sponsor is responsible for 2 generating an invoice on behalf of the investigator. In either case the sponsor 3 or CRO is often the primary source of delay. In cases where the investigators 4 are required to submit expense support or other reports for approval before 5 an invoice can be submitted for payment, further delay is incurred due to this 6 additional review and approval process. 7 [0011] Investigators, however, often must pay their invoices on a 8 standard 30 days net schedule. This cash flow imbalance is highly 9 discouraging to investigators. About 52% of investigators in the United States 10 that undertake a clinical trial only perform a single trial. Clinical trials 11 registered with the US Food and Drug Administration (FDA) are expanding 12 globally not only for the purpose of patient access, but also for access to 13 investigators. 14 [0012] Given that the cost to bring a new drug to market is currently 15 estimated to be in the range of $800 million to $1 billion, increasing year over 16 year, and that the duration of clinical trials is increasing, often due to 17 enrollment shortfalls, retaining investigators is essential to reducing the overall 18 new drug costs. The principal reason given by investigators who stop 19 participating in clinical trials is the failure to receive payment on-time and in 20 full from sponsors and CROs. The underlying issue is the lack of efficient, and 21 often of any meaningful, automation to track, manage, and reimburse 22 investigators in a timely manner. 23 [0013] On a global basis, nearly $65 billion is currently paid annually 24 to research and develop pharmaceuticals, devices, diagnostics, and other 25 similar research. Unfortunately, a new drug candidate almost always requires 26 a highly specialized trial protocols imposing, among other things, complex sets 27 of conditions that must be met in order to receive payment authorization. 28 Approximately 10,000 new trials are filed each year with the FDA and WO 2011/103523 PCT/US2011/025570 -4 1 corresponding international agencies. Furthermore, the protocol and payment 2 conditions are typically specified in a complex clinical trial agreement (CTA) 3 that are often separately negotiated between the sponsor or CRO and each 4 participating investigator. Each phase III clinical trial conventionally requires, 5 on average, 50 to 100 investigative sites. Phase IV trials commonly involve 6 hundreds to thousands of investigative sites. Given a typical number of two 7 protocol amendments over the course of a trial for every CTA, the sponsor or 8 CRO must evaluate and reevaluate hundreds of agreements on an ongoing 9 basis. The potentially different definition of terms, different specifications of 10 milestone requirements and the manner of evaluation, as well as different 11 effective dates, makes funding a clinical trial even more complex. 12 [0014] As a result, much of the financial accounting performed in 13 managing a clinical trial is done manually or by using non-specific clinical trial 14 computer automation programs, such as spreadsheets and generic accounting 15 systems. Conventional computer automation, even if tailored by a sponsor or 16 CRO specific to one designated clinical trial or specific business, quickly 17 becomes too complex and unwieldy to accurately manage the clinical trial 18 subject to the increasingly divergent CTA differences. 19 [0015] Further, investigators are primarily responsible for data entry. 20 They must therefore deal with the varying contract types and terms involved in 21 the trial as a whole when trying to correctly categorize and document an 22 expense or record a receivable. The result is that both investigators, sites, 23 research staff, sponsors, and CROs incur significant time costs that would be 24 better spent on clinical trial research. Lengthy reconciliation processes and 25 contention between the sponsor or CRO and investigators are the common 26 result. 27 [0016] Due to the complexities and manual processes required, 28 sponsors have been increasingly outsourcing the payment process to the WO 2011/103523 PCT/US2011/025570 -5 1 CROs. Although this moves most of the burden to the CROs, an additional 2 burden is then created on both the sponsors and CROs. Specifically, sponsors 3 now have to account for the operations of a retained CRO, including 4 accurately reporting, both internally and externally, the costs of the clinical 5 trial. This is often complicated due to the untimely posting of reports by the 6 CROs and the non-GAAP and other standardized reporting requirements 7 imposed by the sponsor. Additionally, a sponsor will often use multiple CROs, 8 resulting in inconsistent reporting and lack of visibility of clinical trial expense 9 across a single trial let alone many ongoing trials. For some organizations, 10 this also creates regulatory reporting challenges at the local levels. With the 1] recent Patient Protection and Affordable Care Act of 2009 (H.R. 3590 and 12 Section 6002) signed into law on March 23, 2010, accuracy and consistency 13 of transparent research expense reporting is now required for all US 14 companies. 15 [0017] An additional complication that arises from the CRO outsourcing 16 is the potential for compromising the confidentiality of patient, financial, and 17 other information provided, gathered, and created in a client trial. Not only 18 is a CRO an independent company, but CROs will often be concurrently 19 involved in multiple clinical trials across different sponsors. Commingling of 20 this data, including the potential for commingling, by a CRO may also be 21 subject to regulatory restrictions on the handling of personal/privacy data as 22 gathered from participant patients. The need by the sponsors to also maintain 23 the study data secure and uncompromised while at the same time readily 24 accessible within the scope of the organization and clinical trial adds further 25 complications. 26 [0018] Consequently, a need exists for a clinical trial payment system 27 that can efficiently and accurately manage clinical trials, particularly including 28 invoicing and payments made between sponsors, CROs, and investigators.

WO 2011/103523 PCT/US2011/025570 -6 1 Such a system should be able to preclude the potential for commingling data 2 or compromising the confidentiality of the data. 3 4 5 [0019] Summary of the Invention 6 [0020] Thus, a general purpose of the present invention is to provide 7 an efficient a computer-implemented system and methods for managing 8 clinical trials, including the accounting and payments made within the context 9 of a distributed clinical trial in accordance with the terms of a clinical trial 10 agreement, master services agreement, research agreements, and other 1] agreements containing financial terms. 12 [0021] This is achieved in the present invention by providing, within a 13 distributed computer system, a first message identifying a first event initiated 14 transaction within the performance of a clinical trial provides an identification 15 of an investigator and a first event defined data set. Executable template code 16 blocks, specific to the clinical trial and investigator, are retrieved from a 17 distributed database. The executable template code blocks include declarative 18 statements that represent distinct operation and financial requirements derived 19 from the clinical trial agreement corresponding to the clinical trial and 20 investigator. An application dynamically incorporates the executable template 21 code blocks and is executed to determine whether the first event data evaluates 22 successfully against the executable template code blocks. A successful 23 evaluation generates a second event that provides a second message, 24 including the identification of the investigator, clinical trial, and a second event 25 defined data set, to the distributed computer system. An accounting engine 26 may then distribute corresponding documents and transactions to appropriate 27 organizations.

WO 2011/103523 PCT/US2011/025570 -7 1 [0022] An advantage of the present invention is that a constrained 2 natural language, defined as a contract meta language (CML), is used to 3 encode operational or performance related contractual terms, specifically 4 including financial terms, from an unconstrained language agreement. The 5 resulting contract specific CML is entered and converted into an interpretable 6 script, a compilable programming language, or otherwise rendered as 7 machine readable code (MRC). The conversion process also renders a 8 specification of a user interface (UI) that is descriptive, interpretable, or 9 compilable, enabling user entry of data corresponding to possible compliant 10 operational contractual term data. The UI specification and rendered MRC are 11 stored for subsequent retrieval selectively in response to a sequenced event or 12 operational business event. The MRC is executed to determine whether data 13 associated with the event fulfills the criteria of the operational contractual 14 terms. 15 [0023] Another advantage of the present invention is that the distributed 16 computer system implements a data-pod architecture that allows participating 17 organizations, such as sponsors, investigators, laboratories, central 18 institutional review boards, research companies, and CROs, to maintain 19 clinical trial specific data within discrete data storage systems within data 20 centers designated or hosted by the organizations. The organizations and 21 their agents have shared use of a remote application UI and corresponding 22 business logic that is configurable dependent on data-pod stored data. 23 [0024] A further advantage of the present invention is that the 24 distributed computer system enables a global Clinical Payment Network where, 25 for unique combinations of organizations and investigators, a uniform 26 workflow is created and individualized, enabling transactions to be efficiently 27 processed and, where appropriate, initiate financial accounting and payments 28 to members of the Payment Network.

WO 2011/103523 PCT/US2011/025570 -8 1 [0025] Still another advantage of the present invention is that CML can 2 be efficiently resolved from clinical trial agreement and other agreements that 3 bear on the performance of the trial. CML statements are discrete and 4 declarative, enabling a complex clinical trial agreement to be accurately 5 entered as a constrained natural language. A CML authoring tool allows entry 6 of discrete CML statements using a form-based user interface and a library of 7 generic and, optionally, semi-customized statement templates. 8 [0026] Yet another advantage of the present invention is that financial 9 accounting and payments, particularly to participant patients, can be 10 distributed in a variety of manners, including using reloadable or 1] non-reloadable debit or credit cards, bank transfers, bank drafts, checks, and 12 the like. Payments can be released on a schedule determined against the 13 completion of the relevant clinical trial milestones or individual activities, with 14 the ability to cross-check performance against records originated by, for 15 example, the relevant clinical trial investigator. Past payments and frequencies 16 can also be considered as a basis for avoiding fraud. 17 18 19 [0027] Brief Description of the Drawings 20 [0028] Figure 1 illustrates a preferred distributed data processing 21 operating environment within which preferred embodiments of the present 22 invention can be effectively utilized. 23 [0029] Figure 2 is a block diagram providing a representational view of 24 a service-oriented architecture implemented using an enterprise service bus for 25 a distributed data processing operating environment within which preferred 26 embodiments of the present invention can be effectively utilized.

WO 2011/103523 PCT/US2011/025570 -9 1 [0030] Figure 3A is a block diagram providing a representational view 2 of the distributed services and systems as implemented in a preferred 3 embodiment of the present invention. 4 [0031] Figure 3B provides a block diagram of an application server 5 instance and an associated data-pod as implemented in a preferred 6 embodiment of the present invention. 7 [0032] Figure 4 provides a block diagram illustrating the message 8 process flow, including dispatching, as implemented in a preferred 9 embodiment of the present invention. 10 [0033] Figure 5 illustrates the process flow for generating contract meta 11 language statements and the resolution of valid statements to UI specifications 12 and parameterized executable code blocks as implemented in a preferred 13 embodiment of the present invention. 14 [0034] Figure 6 is a detail block diagram of the contract meta-language 15 library store as implemented in a preferred embodiment of the present 16 invention. 17 [0035] Figure 7 illustrates a preferred process flow for generating a 18 message from an actionable event as implemented in a preferred embodiment 19 of the present invention. 20 [0036] Figure 8 illustrates a preferred process flow for validating and 21 evaluating the contents of a received message as implemented in a preferred 22 embodiment of the present invention. 23 [0037] Figure 9 illustrates a preferred process flow for invoicing and 24 distributing financial payments in accordance with a preferred embodiment of 25 the present invention. 26 [0038] Figure 10 provides an image rendering of a template-based 27 data entry form enabling parameterization of a CML template UI or code WO 2011/103523 PCT/US2011/025570 - 10 1 block template beginning with a generic, user-selected base template in 2 accordance with a preferred embodiment of the present invention. 3 [0039] Figure 11 provides an image rendering of a template-based 4 data entry form showing the completed parameterization of a CML template 5 UI or code block template. 6 7 8 [0040] Detailed Description of the Invention 9 [0041] The present invention is described in the preferred context of a 10 distributed computer system capable of supporting global access and use 11 within the context of managing clinical trials, further specifically with regards 12 to the handling of financial transactions. The present invention is, however, 13 properly capable of handling all operational transactions within clinical trials 14 and, further, to operational transactions within distributed computer systems 15 requiring complex, typically determinant evaluation of operational conditions. 16 These capabilities will become clear in the following detailed description of the 17 invention, wherein like reference numerals are used to designate like parts 18 depicted in one or more of the figures. 19 [0042] Referring to Figure 1, a preferred environment of a distributed 20 data processing system 10 typically includes heterogeneous computer 21 platforms interconnected through a network 12, conventionally the global 22 Internet network. Servers 14, 16, 18 are typically located in data centers, 23 either owned or operated by a clinical trial organization or hosted by a third 24 party subject to security constraints. The servers 14, 16, 18, typically host, 25 locally or through the network 12, any number of often varied clients 20, 22. 26 [0043] For purposes of the present discussion, an organization is 27 defined as a legal entity, preferably represented by a main company that is the 28 parent company for a given clinical trial. Organizations can include other WO 2011/103523 PCT/US2011/025570 1 companies that are separate legal entities, such as wholly owned subsidiaries, 2 where financial results role up to a parent organization. An organization can 3 view another organization if the first organization is the custodian for the 4 second, the two organizations are linked by inviting or accepting another 5 organization into their network of business partners, or list themselves as 6 public in the Payment Network. The present embodiments preferably require 7 each organization and each study have a custodian. Because all 8 organizations may not be members of the Payment Network, organizations 9 that are within the network can create other organizations and be the 10 designated custodian. Once an Organization that is currently being managed 11 by a custodian joins the Payment Network, the joining organization can elect 12 to become the custodian of their own organization and have the privileges of 13 self administration. 14 [0044] A subject is a person participating in a clinical trial; typically, a 15 participant patient. 16 [0045] A protocol is a document that describes the inclusion and 17 exclusion criteria for subjects, visit schedule including procedures and tests to 18 be performed and why. The protocol specifies the statistical analysis methods 19 to be used, the primary endpoint and secondary endpoints, and lists all known 20 safety issues and methods of collecting adverse events. In short the protocol 21 outlines the methodology of the experiment to be performed, who can 22 participate, and what the anticipated outcome should be. 23 [0046] A sponsor is a pharmaceutical, biotech or medical device 24 company, or a research center or doctor that proposes to perform a clinical 25 trial, testing a defined set of efficacious claims and to test that the product is 26 safe. A device trial can test efficacy outcomes and specific claims for 27 advertising purposes.

WO 2011/103523 PCT/US2011/025570 - 12 1 [0047] A site is a facility that participates in the clinical trial and enrolls 2 subjects based on the protocol inclusion criteria. Sites can be University 3 hospitals, managed care hospitals, research M.D.s and related centers, 4 primary and specialized care doctors. 5 [0048] A Clinical Research Organizations perform services related to 6 research and development and are contracted to perform a verity of clinical 7 trial related services. 8 [0049] A custodian or custodial organization is the organization that is 9 responsible for maintaining defaults, configuration of workflows, data, security, 10 personnel, and all other data of an organization. An organization can be a 11 custodian of another organization or itself. 12 [0050] Of the different distributed data processing architectures 13 potentially suitable for implementation of the present invention, the service 14 oriented architecture (SOA) is preferred. The use of distinct, modular business 15 information services, effectively as the de-constructed elements of the desired 16 business information service system, is preferred as it allows loose coupling of 17 services and systems, particularly including with respect to end-users of the 18 client platforms 20, 22. In the implementation of the presently preferred 19 Clinical Payment Network, the server 14 preferably represents a Clinical 20 Payment Network application engine and system data-pod. Multiple instances 21 of server 16 preferably represent different organizations, such as sponsors, 22 CROs, sites, eClinial systems hosted by third-parties, organizations, data 23 warehouses, and similar entities. Multiple instances of server 18 preferably 24 represent public services, such as banks, payment clearing houses, currency 25 exchanges, and similar entities. 26 [0051] As illustrated in Figure 2, a preferred SOA implementation 30 27 employs an enterprise service bus (ESB) 32 as a middleware layer 28 interconnecting disparate service requesters 34 1-N and service providers 361 -M WO 2011/103523 PCT/US2011/025570 - 13 1 The enterprise service bus 32 preferably implements a messaging fabric with 2 the capability to host an embedded set of function-added components 38, 3 including service adaptors and protocol converters, routing and event controls, 4 and, optionally, performance management and monitoring instrumentation. 5 Distributed service requesters 34 1-N and providers 36 1-M can, at least from an 6 architectural point of view, uniformly connect to and through the ESB 32 7 utilizing a consistent integration pattern to implement the various business 8 processes necessary to collectively implement the desired distributed data 9 processing system 10. 10 [0052] The function of the ESB 32 is to route messages, representing 11 network protocol specific requests and responses, between service requesters 12 3 4 1-N and service providers 361-M' subject to ESB-based network protocol 13 conversion. Other embedded component 38 functions that can be 14 implemented in the ESB 32 include support for asynchronous messaging, 15 alternate and enhanced message routing capabilities, standardized 16 authorization, and authentication and audit controls, including interfaces to 17 external standard LDAP services. Standard web services protocols, such as 18 Simple Object Access Protocol (SOAP) and Representational State Transfer 19 (REST) can also be implemented through embedded components 38. 20 Messaging protocols, such as Microsoft Message Queuing (MSMQ), Windows 21 Communication Foundation (WCF), Microsoft .NET Framework, Internet 22 Information Services (IIS), Microsoft Distributed Transactions Coordinator 23 (MSDTC) are also used. A service consumer can also implement a structured 24 document server in order to support hypertext (HTTP) and other extensible 25 markup language (XML) based protocols. Application specific and other 26 proprietary network protocols may also be implemented as needed. 27 [0053] The preferred system architecture of the Clinical Payment 28 Network 50 is generally shown in Figure 3A. Primary operational control and WO 2011/103523 PCT/US2011/025570 - 14 1 supervision is performed by a system server 52 hosted within a system data 2 center by or on behalf of the owner of the Clinical Payment Network 50. 3 Preferably, a system data-pod 54 is also hosted within the system data center. 4 The system server 52 and system data-pod 54 interoperate to provide for the 5 control and storage of system-wide configuration data, security information 6 defining access rights among and between the different entities accessing the 7 various resources within and that connect to the Clinical Payment Network 50, 8 and the collection and analysis of administrative data reflecting the ongoing 9 use and performance of the Clinical Payment Network 50. In particular, the 10 system data-pod 54 includes a database (not shown) that preferably stores 11 generic data, public within the Clinical Payment Network 50, that identifies 12 known data pods within the network, participating and related organizations, 13 study names, and authentication and other security data appropriate to enable 14 secure users logins and study data access. The system data-pod 54 also 15 preferably contains data sufficient to perform global data-pod discovery. 16 Thus, subject to managed security constraints, the system data-pod 54 17 operates largely as network accessible storage resource specifically for the 18 system server 52 and generally for other systems that are in and connect to the 19 Clinical Payment Network 50. 20 [0054] Multiple application servers 56 are preferably provided to 21 execute at least the core components of a clinical payment application that 22 effectively implements the Clinical Payment Network 50. In the preferred 23 embodiments, the clinical payment application is implemented using the 24 software as a service (SaaS) and service oriented service (SOA) architectures. 25 The application servers 56 are preferably geographically distributed. 26 [0055] Unlike conventional SaaS systems, data storage for the clinical 27 payment application is preferably distributed to multiple organization data 28 pods 58 and multiple study data-pods 60, 62. These organization data-pods WO 2011/103523 PCT/US2011/025570 - 15 1 58 and study data-pods 60, 62 are maintained under the control of individual 2 organizations, as defined above, that participate in the Clinical Payment 3 Network 50. Organizations, such as sponsors, CROs, pharmacies, 4 laboratories, sites, and other entities, may each act as a custodial organization 5 and thereby control access to data contained in a corresponding organization 6 data-pod 58 instance and one or more study data-pods 60, 62. Preferably, 7 the data-pods 54, 58, 60, 62 each have a single custodial organization. 8 Conversely, an organization may be custodian for one or more study data 9 pods 60, 62 and one corresponding organization data-pod 58. Custodial 10 organizations may grant access to non-custodial organizations, typically by 1] way of invitation or a defined corporate relation. This allows non-custodial 12 organizations to access defined portions of the custodial organization data 13 pod 58 instance and a one or more corresponding study data-pod 60, 62 14 instances, dependent on the functional role of the non-custodial organization. 15 As such, the Clinical Payment Network 50 can provide comprehensive access, 16 subject to security controls, to all entities that participate in any particular study. 17 [0056] Financial and other services 64 generally are permitted access 18 to and are accessible as needed from the Clinical Payment Network 50. 19 Preferably, these services 64 include currencytransfers, consultants performing 20 regulatory compliance reviews, clinical systems hosted by third-parties and 21 organization data warehouses, and specialized data sources. In particular, 22 financial services will be provided by banks and similar institutions. Other 23 services are supported as needed, and preferably include specialty CROs with 24 specific capabilities, electronic and remote data capture services, data 25 warehouses maintained by or on behalf of sponsors or other entities. 26 Preferably, a client application implementing a Clinical Payment Network 50 27 interface (not separately shown) is provided to these services 64 to enable WO 2011/103523 PCT/US2011/025570 - 16 1 custodial organization defined role appropriate interactions with the financial 2 and other services 64. 3 [0057] Preferred implementations 70 of an organization data-pod 58' 4 instance, study data-pod 60' instance, and an application server 72 instance 5 is shown in Figure 3B. The system data-pod 54 is structured essentially the 6 same as an organization data-pod 58'. The organization data-pod 58' 7 receives messages sent through the ESB 32 via the network 12 and a 8 corresponding service requestor stub 34'. Messages are received in an inbox 9 74 and typically held for review. The organization data-pod 58' includes a 10 database 76 that stores data specific to the corresponding custodial 11 organization. The database 76 provides structured storage of data according 12 to multiple schemas. In a preferred embodiment, schemas are provided for 13 accounting, general organization structure, such as personnel, divisions, 14 departments, companies, locations, addresses, security information and 15 authorizations, budgets, contracts and CML support, configuration, 16 notifications and reports, and text files. 17 [0058] A study data-pod 60' includes a message inbox 78 and study 18 database 80. The inbox 78 receives and typically holds incoming messages 19 for review. The study database preferably stores all of the information specific 20 to a particular clinical trial. Study data-pods preferably provide structured 21 storage for how clinical trials are set, including general information about 22 sponsors, sub-sponsors, areas, cohorts, visits, procedures, CRF's, sites, subjects 23 and events. Isolation of the study data on the basis of one study per data-pod, 24 i.e., to a study data-pod 60' instance placed and maintained under the control 25 of the custodial organization, precludes accidental or other unauthorized 26 access to the study data. The potential of commingling data from multiple 27 studies and from different custodial organization subnetworks is efficiently 28 avoided.

WO 2011/103523 PCT/US2011/025570 - 17 1 [0059] A potentially consequential issue exists in that the distributed 2 data-pods 58, 60, 62 likely exist in domains different from those of the 3 application servers 56. Conventionally, cross-domain database transactions 4 have a limited abilityto implement transaction- based reliability measures. The 5 preferred embodiments implementing the present invention advantageously 6 utilize the capabilities of the ESB 32 to create reliable asynchronic transactions 7 for message transmission between the distributed data-pods 54, 58, 60, 62 8 and the application servers 56 by way of the ESB 32. Consequently, where 9 high-reliability is required, messages are routed through the ESB 32. 10 Otherwise, the application servers 56 may utilize direct network 12 connections 11 to the inboxes and data-pod resident databases, subject to decreased 12 reliability margins. 13 [0060] An application server 72 instance is preferably implemented as 14 a high-performance computer system, real or virtual. An application server 15 process 82 is executed to coordinate the processing of messages as received 16 by organization and study data-pod 58', 60' instances that are effectively 17 assigned to the application server 72 instance. Preferably, when a message 18 is queued in an associated inbox 74, 78, notice is provided over the network 19 12 to the application server process 82 and recorded in an event database 84. 20 Performance permitting, the application server process 82 retrieves the 21 message and, where the message contains a CML statement, a CML 22 evaluation engine 86 is used to execute or otherwise process the CML 23 statement. The execution result is a result object that includes a boolean status 24 state. Where the execution result status is True, the result object will also 25 typically identify a completion procedure to be performed. If false, execution 26 of the CML statement is simply terminated. 27 [0061] To execute the completion procedure, the result object 28 representation of the message is transferred to a messages engine 87 that WO 2011/103523 PCT/US2011/025570 - 18 1 provides execution support for the set of possible completion procedures. In 2 executing the completion procedure, the messages engine 87 will perform one 3 or more operations that typically involves the accessing and potentially 4 modifying data stored by the system data-pod 54, accessing and modifying 5 data stored in the associated combination of organization and study databases 6 76, 80 and generating new messages that contain CML statements that 7 typically in sequence implement some business operation. These forwarded 8 by the application server process 82 through a corresponding service provider 9 stub 36' and the ESB 32 for delivery. 10 [0062] A conventional Web server 88 is provided as part of the 11 application server 72 to enable network access to the application server 12 process 82 by users of client systems 20, 22 who have authenticated privileges 13 that permit at least some degree of access to the data held in the organization 14 data-pod 58' or study data-pod 60'. Preferably, the Web server 88 enables 15 presentation of a form-based interface to users with possible data access to 16 any combination of system, organization, and study data-pods 54, 58', 60'. 17 When users of the client systems 20, 22 act to enter new or revised data 18 through an application server 72, one or more events are triggered typically 19 resulting in some combination of data modification in the associated 20 organization and study data-pods 58', 60' and the creation of new messages 21 to be transmitted to one or more other data-pods. 22 [0063] In an alternate embodiment of the present invention, active data 23 pods may be implemented by functionally combining an instance of the 24 application server 72 with either an organization data-pod 58' or study data 25 pod 60'. These active data pods are distributed as with the preferred passive 26 data-pods. Some efficiencies are gained, including collocation of the 27 application server at an organization controlled data center, reduced security 28 complexities, and lower potential network latency. Reliance on the on the WO 2011/103523 PCT/US2011/025570 - 19 1 larger Clinical Payment Network 50 is reduced and creates the potential for 2 partial if not full independent operation. 3 [0064] As illustrated in Figure 4 for the preferred embodiments of the 4 present invention, a messages engine 90 is implemented, in part, using a 5 Microsoft® Message Queue (MSMQ) cluster 92. The MSMQ cluster 92 is 6 further provided as one of the ESB embedded components 38. Messages, for 7 example from study and organization data-pods 94, 96, 98, whenever 8 sourced, are transferred to the ESB 32 and then to input queues 1 0 0 1-N 9 present in the MSMQ cluster 92. Preferably, each of the input queues 10 0 1-N 10 is assigned a category of message types to handle. As messages are received 11 by the MSMQ cluster 92, the message type is decoded and the message 12 routed to a corresponding input queue 10 0 1-N 13 [0065] The input queues 1 0 0 1-N are progressively read by one or more 14 queue dispatchers 10 2 1-m. These queue dispatchers 1 0 2 1-m inspect and 15 dispatch the messages to message identified target destinations, such as, for 16 example study and organization data-pods 108, 110, 112. The dispatched 17 messages are directed to one or more of the inbox queues associated with 18 each of the data-pods 108, 110, 112, as well as the inbox associated with the 19 system data-pod 54. Messages that are invalid or otherwise cannot be 20 successfully dispatched are initially transferred to an error queue 106. As then 21 queued, these failed messages are re-targeted to the system data-pod 54 22 inbox and marked for administrative or procedural review. When 23 performance permits, failed messages are sequentially dispatched through the 24 queue dispatchers 1 0 2 1-M. 25 [0066] By default, messages received in an organization or study inbox 26 108, 110, 112, are held for consideration by a representative of the 27 corresponding organization. The representative preferably reviews the inbox 28 queued messages and may selectively accept or reject the action defined by WO 2011/103523 PCT/US2011/025570 - 20 1 the corresponding message. Where accepted, the action is functionally 2 executed, typically resulting in an update of the underlying data store. Upon 3 completion of the action, a corresponding status message is generated and 4 sent to a data-pod corresponding input queue 1 0 0 1-N typically for return to the 5 data-pod that sourced the sequentially prior message. Some messages, most 6 notably simple status messages, message acknowledgments, and other non 7 transactional messages, may be immediately accepted through a data-pod 8 inbox and updated to the underlying data store. Administrative, management, 9 and configuration related messages are preferably automatically accepted. 10 [0067] Messages received by the system data-pod 104 are preferably 11 handled autonomously by default. As before, messages are initially received 12 and queued in the corresponding data-pod 104 inbox. If marked for review, 13 the message is held in the inbox for administrative or procedural review. 14 Otherwise, in summary, the message is processed and, as appropriate, 15 processed against the appropriate CML code blocks. 16 [0068] Referring to Figure 5, a contract meta-language representation 17 of a clinical trial agreement is preferably constructed utilizing a CML authoring 18 tool 120. The product of the authoring tool 120 includes a parameterized UI 19 specification and a parameterized executable code block or machine-readable 20 code. The UI specification describes a user interface screen tailored to allow 21 a client user to make constrained, form-oriented entries for the corresponding 22 CML statement. The parameterized executable code block contains an 23 executable statement or set of statements preferably representing a source 24 code fragment that can be interpreted, compiled, or otherwise made 25 executable to implement a logic function and set of one or more the 26 completion procedures that, together, will functionally implement the 27 corresponding CML statement.

WO 2011/103523 PCT/US2011/025570 -21 1 [0069] A given source clinical trial agreement 122 is reviewed by a data 2 entry clerk to identify quantifiable operational and performance related 3 contractual terms. As such terms are identified, the data entry clerk utilizes a 4 form-oriented user interface (UI) 124 to enter the corresponding CML 5 statement. A base template most closely matching the nature of the term is 6 selected 126 from a CML library 128 containing base templates. Custom 7 templates can be created and added to the CML library 128 for subsequent 8 reuse. Figure 10 shows an exemplary base template 290 as displayed in a UI 9 form to a data entry clerk upon selection from the CML library 128. The initial 10 constrained natural language representation of this exemplary template 1] instance is: 12 13 When INPUT subjects have a subject status of SELECT, pay $AMOUNT. 14 15 [0070] The template can present any number of parameterizable 16 elements. Based on the specific contractual term considered in the clinical trial 17 agreement 122, the data entry clerk can then enter corresponding parameters 18 for this template instance. With parameterization, the constrained natural 19 language template instance is: 20 21 When 3 subjects have a subject status of On Study, pay $5000. 22 23 [0071] Figure 11 provides a representation of the corresponding UI 24 form presented template 300 with these parameterization values entered. The 25 selectable values entered in the parameterizable elements of a template are 26 constrained by reference to the CML library 128. Specifically, the CML 27 specification underlying the form shown in Figure 11 is preferably represented 28 by a CML template UI specification: WO 2011/103523 PCT/US2011/025570 - 22 1 2 When {Integerl :integer} Subjects Have Subject Status of {Strl :string} 3 Pay {Amtl:decimal} 4 5 where a brace enclosed word identifies a variable type and an italicized word 6 is a system-defined keyword. Labels for variable type instances are specified 7 as {label:type}. Note, these specific stylings are for purposes of clarity in the 8 present discussion; other stylings, including color and other syntactic 9 presentation, may be used in practice. The UI specification is preferably 10 maintained separate from the parameterization values. 11 [0072] The corresponding CML template code block specification is: 12 13 When {lIntegerel :integer} [[Subjects]] Have [[[Subject Status]]] 14 of {Strl :string} 15 Pay {Amtl:decimal} 16 17 where double brackets identify a dynamic object, also referred to as a token, 18 and triple brackets identify an object property. Thus, as defined, 'Subject 19 Status' is a property of the object 'Subjects'. Tokens and corresponding 20 permitted token properties are stored in the CML library 128. 21 [0073] Particularly for CML template code block specifications, the code 22 specification can be further rendered to produce a corresponding code 23 fragment that is functionally executable. Preferably, the code fragment is 24 rendered as a source code fragment that can then be prepared for execution 25 through use of an interpreter or compiler. As an example, the above CML 26 template code block specification can be rendered as a C# source code 27 fragment: 28 29 if( GetSubjectsByStatus( "{String}" ).Counto= ={integer} 30 ExecuteTransaction( {decimal} 31 WO 2011/103523 PCT/US2011/025570 - 23 1 [0074] Six further examples of the constrained natural language 2 specification system as implemented in a preferred embodiment of the present 3 invention are presented below. 4 [0075] 5 Template (as retrieved from CML library): 6 7 (1) For Every INPUT Subject(s) with Visit SELECT Status of SELECT 8 - Record Transaction 9 10 (2) For Every INPUT Subject(s) when All CRFs for Visit SELECT 11 are Status SELECT 12 - Record Transaction 13 14 (3) For Every INPUT Subject(s) when All CRFs for Visit SELECT 15 are Status SELECT 16 and Procedure SELECT 17 at Visit SELECT 18 is Status SELECT 19 - Record Transaction 20 21 (4) When Local IRB Status is SELECT or Drug Status is SELECT 22 - Record Transaction 23 24 (5) When CTA Status is SELECT 25 - Set SELECT to INPUT 26 27 (6) When Subject Status is SELECT and SELECT are Greater Than INPUT 28 - Decrease SELECT by INPUT and Record Transaction 29 30 31 Parameterized Template (clinical trial agreement specific): 32 33 (1) For Every 3 Subject(s) with Visit Screening Status of Complete 34 - Record Transaction 35 36 (2) For Every I Subject(s) when All CRFs for Visit Randomization 37 are Status Monitored 38 - Record Transaction 39 WO 2011/103523 PCT/US2011/025570 - 24 1 (3) For Every I Subject(s) when All CRFs for Visit Week 1 2 are Status Frozen 3 and Procedure Colonoscopy 4 at Visit Screening 5 is Status Complete 6 - Record Transaction 7 8 (4) When Local IRB Status is Approved or Drug Status is Shipped 9 - Record Transaction 10 11 (5) When CTA Status is Executed 12 - Set Screen Fail Credits to 5 13 14 (6) When Subject Status is Screen Fail and Screen Fail Credits 15 are Greater Than 0 16 - Decrease Screen Fail Credits by Iand Record Transaction 17 18 19 CML Template UI Specification 20 21 (1) For Every {Integer1 :Integer} Subject(s) with Visit {Visit1 :Visit} 22 Status of {VisitStatus :Visit Status} 23 - Record Transaction 24 25 (2) For Every {Integer1 :Integer} Subject(s) when All CRFs 26 for Visit {Visit1 :Visit} 27 are Status {CRFStatus1 :CRF Status} 28 - Record Transaction 29 30 (3) For Every {Integer1 :Integer} Subject(s) when All CRFs 31 for Visit {Visit1 :Visit} 32 are Status {CRFStatus1 :CRF Status} 33 and Procedure {Procedurel :Procedure} 34 at Visit {Visit2:Visit} 35 is Status {ProcedureStatus] :Procedure Status} 36 - Record Transaction 37 38 (4) When Local IRB Status is {IRBStatus :Local IRB Status} 39 or Drug Status is {DrugStatus1 :Drug Status} 40 - Record Transaction 41 WO 2011/103523 PCT/US2011/025570 - 25 1 (5) When CTA Status is {CTAStatusl:CTA Status} 2 - Set {CMLVariablel:CML Variable} to {Integer1:Integer} 3 4 (6) When Subject Status is {SubjectStatusl :Subject Status} 5 and {CMLVariablel:CML Variable} 6 are Greater Than {Integerl :Integer} 7 - Decrease {CMLVariable2:CML Variable} by {Integer2:Integer} 8 and Record Transaction 9 10 1] CML Template Code Block Specification 12 13 (1) For Every {Integer1 :Integer} [[Subject(s)]] with [[[Visit]]] {Visit] :Visit} 14 [[[Status]]] of {VisitStatus :Visit Status} 15 - Record Transaction 16 17 (2) For Every {Integer1 :Integer} [[Subject(s)]] when All CRFs 18 for [[[Visit]]] {Visit1:Visit} 19 are [[[Status]]] {CRFStatus1 :CRF Status} 20 - Record Transaction 21 22 (3) For Every {Integer1 :Integer} [[Subject(s)]] when All CRFs 23 for [[[Visit]]] {Visit1:Visit} 24 are [[[Status]]] {CRFStatus1 :CRF Status} 25 and [[[Procedure]]] {Procedurel :Procedure} 26 at [[[Visit]]] {Visit2:Visit} 27 is [[[Status]]] {ProcedureStatusl :Procedure Status} 28 - Record Transaction 29 30 (4) When [[Local IRB]] [[[Status]]] is {IRBStatus1 :Local IRB Status} 31 or [[Drug]] [[[Status]]] is {DrugStatus1 :Drug Status} 32 - Record Transaction 33 34 (5) When [[CTA]] [[[[Status]]] is {CTAStatusl:CTA Status} 35 - Set {CMLVariable]:CML Variable} to {Integer]:Integer} 36 37 (6) When [[Subject]] [[[Status]]] is {SubjectStatusl :Subject Status} 38 and {CMLVariablel:CML Variable} 39 are Greater Than {Integerl :Integer} 40 - Decrease {CMLVariable2:CML Variable} by {Integer2:Integer} 41 and Record Transaction WO 2011/103523 PCT/US2011/025570 - 26 1 2 Source Code Fragments 3 4 (1) if (AndEvent(EligibleStudyEvents.WithStatus({VisitStatus]1}) 5 .ForVisit({Visit1 }))) 6 { 7 return RecordTransaction(ForEvery({Integer1 })); 8 } 9 return base.Evaluate(args); 10 11 12 (2) if (AndEvent(AIICRFsForVisit({Visit]1}), 13 EligibleStudyEvents.AtVisit({Visit]1}) 14 .WithStatus({CRFStatus1 }))) 15 { 16 return RecordTransaction(ForEvery({Integer1 })); 17 } 18 return base.Evaluate(args); 19 20 (3) if (AndEvent(AlICRFsForVisit({Visit]1}), 21 EligibleStudyEvents.AtVisit({Visit1 }).WithStatus({CRFStatus1 }))) 22 { 23 if (AndEvent(EligibleStudyEvents 24 .ForProcedure({Procedure1}) 25 .AtVisit({Visit2}) 26 .WithStatus({ProcedureStatus1 }))) 27 { 28 return RecordTransaction(ForEvery({Integer1 })); 29 } 30 } 31 return base.Evaluate(args); 32 33 (4) if (OrEvent(EligibleStudyEvents.WithStatus({IRBStatus1 }), 34 EligibleStudyEvents.WithStatus({DrugStatus] }))) 35 { 36 return RecordlTransaction(Firsto); 37 } 38 return base.Evaluate(args); 39 WO 2011/103523 PCT/US2011/025570 - 27 1 (5) if (AndEvent(EligibleStudyEvents.WithStatus({CTAStatus1 }))) 2 { 3 return SetVariable(Firsto, {CMLVariablel }, {lintegerl }); 4 } 5 return base.Evaluate(args); 6 7 (6) if (AndEvent(EligibleStudyEvents.WithStatus({SubjectStatus1 }))) 8 { 9 if (AndVariable({CMLVariablel }, integerr 1})) 10 { 11 return RecordTransaction(DecrementVariable(Always(), 12 {CMLVariable2}, {linteger2})); 13 } 14 } 15 return base.Evaluate(args); 16 17 [0076] Referring to Figure 6, at least a portion of the CML library 128 18 is shown diagrammatically. Whether stored in an XML or other text document 19 or as database records, a user definable collection 162 contains dynamic 20 objects 164 and lists of corresponding permitted properties 166. Exemplary 21 objects 162 and corresponding permitted property lists 164 are presented in 22 Table 1: 23 [0077] 24 Table 1 25 Object Properties 26 Subject Status, ID 27 Visit Name, Status 28 CaseReportForm Name, Status 29 Procedure Name, Status 30 Study Name, Status, ID, Investigator 31 [0078] A system defined collection 168 contains variable types 170 and 32 predefined keywords 172. These variable types and keywords are preferably WO 2011/103523 PCT/US2011/025570 - 28 1 related only by the shared, system defined nature. Variable types can be 2 simple or defined. Simple types include, for example, 'integer', 'string', and 3 'date'. Defined types are program objects defined typically in the support 4 libraries used in the runtime evaluation of the CML statements. A variable type 5 of 'visit' may be thus defined as either zero or a positive integer. A variable 6 type of 'procedure' may be defined as an array of type 'string', while 7 'procedure status' may be defined by an enumeration. A variable type of, for 8 example, 'CML variable' may be established to allow access to some system 9 or application-specific value. 10 [0079] Exemplary simple and defined variable types 170 are listed in 1] Table 2: 12 [0080] 13 Table 2 14 Simple Variable Types Defined Variable Types 15 {integer} {Cohort} 16 {string} {Visit Type} 17 {decimal} {Visit} 18 {date} {Procedure} 19 {decimal percentage} {CRF} 20 {money} {<custom defined var type>} 21 {time} 22 [0081] The preferred embodiments of the present invention include a 23 standard set of defined variable types. These variables types and the selection 24 of corresponding acceptable values are derived from the study configuration WO 2011/103523 PCT/US2011/025570 - 29 1 information stored in the system data-pod 104 and are thus available for all 2 studies. As listed in Table 2, these standard defined variable types are further 3 specified as follows: 4 5 {Cohort} A selection of all cohorts (or treatment arms) in the 6 selected study, such as "Placebo", "Active Drug", 7 etc. 8 {Visit Type} A selection of all visit types, such as "Screening", "On 9 Study", "Follow Up", defined for the selected 10 study. 11 {Visit} A selection of all visits defined for the selected study, 12 such as "Screening", "Visit 1", "Week 12", etc. 13 {Procedure} A selection of all procedures defined for the selected 14 study, such as "Vital Signs", "Colonoscopy", 15 "Physical Exam", etc. 16 {CRF} A selection of all case report forms defined for the 17 selected study, such as "Lab", "Demographics", 18 "Medical History" 19 20 [0082] The listed custom defined type represents defined variable type 21 objects that are typically specified at the level of a custodial organization and 22 therefor available to use in all studies that the organization is involved with. 23 [0083] While variable types allow entry of type constrained values, 24 keywords perform both semantic and syntactic functions. Keywords can be 25 used syntactically to increase the simple natural language readability of CML 26 statements as well as allowing industry specific keywords to be used in place 27 of possibly conforming, though generic keywords. Placement of keywords 28 within a CML statement, as an element of the natural language structure, 29 permits semantic inference of the operation intended to be performed by a 30 particular CML statement. Since CML statements are relatively concise, the 31 semantic analysis is neither too ambiguous nor too burdensome.

WO 2011/103523 PCT/US2011/025570 - 30 1 [0084] Exemplary predefined keywords 172 are listed in Table 3: 2 [0085] 3 Table 3 4 Keywords 5 When All Set Record 6 If Issue Increase Transaction 7 Of First Decrease Release 8 Have Last Return Holdback 9 Pay Less Not Claim 10 For Greater And 11 Every Equal Or 12 Where Than Is 13 [0086] System and user-defined templates 174 include a base template 14 set 176 predefined by the system. Customized base templates 178 can be 15 created by a user and stored for future reuse. The base template set 176 is 16 constructed from common, meaningful combinations of the objects 164, types 17 170, properties 166 and keywords 172. 18 [0087] The provision of dynamic objects 164 and properties 166 allows 19 users to dynamically create new operational events and corresponding 20 constraint properties. When a dynamic object 164 is created and one or more 21 properties 166 specified, the object name and corresponding list of constraints 22 are automatically added to the CML library 128. The new object 164 is then 23 immediately available to be used or selected in entering a negotiated clinical 24 trial source contract 122 term. In a preferred embodiment, these new dynamic 25 objects 164 are used to describe unique operational events in a clinical trial. 26 Exemplary new objects include 164: Study Drug, Study Status, Subject Status, 27 Site Status, Subject Visits, Procedures and Contract Status. In the creation of WO 2011/103523 PCT/US2011/025570 -31 1 customized templates 178, dynamic objects 164 are also referenced as 2 tokens. Every occurrence of an operational event has an associated event date. 3 [0088] Object properties define the available states or operational 4 outcomes of an outcome field defined within a dynamic object. Given a 5 dynamic object 'Subject Status', the object property type of the outcome could 6 be {string}. Where multiple object properties may be associated with the 7 'Subject Status' field of the dynamic object, a valid inference would be to 8 autonomously select a {text box} display component over a {text field} or {list} 9 for presentation of multiple object properties. Alternately, the outcome field 10 could be expressly defined, during parameterization 130 of the base template, 11 to have a UI display variable type of {string}, a UI display description of 12 "Patient Status", and a UI display component type of {Iist}. 13 [0089] In the latter instance, the CML template UI form would present 14 a list component populated with the object properties associated with the 15 'Subject Status' dynamic object, subject to being filtered by the associated 16 identity of the clinical trial, trial site, and trial investigator. In one case, the 17 filtered object properties might be "dropped", "enrolled", "early termination", 18 and "completed". For a different investigator or site within the same trial, the 19 filtered object properties might be "active", "pending", and "inactive". 20 [0090] Returning to Figure 5, a parameterized CML statement is parsed 21 and generated 132. In parsing the CML statement as represented by the CML 22 template UI specification, specified fields, descriptions, display components, 23 and values are identified. Any missing information is defaulted where 24 appropriate. An inferencing operation is performed, as necessary, to identify 25 and select suitable information to complete the CML template UI specification. 26 The preferred result is an appropriately qualified UI markup specification that 27 defines a form element usable to allow user entry and edit of the CML 28 statement values. In the presently preferred embodiments of the present WO 2011/103523 PCT/US2011/025570 - 32 1 invention, the underlying CML template UI specification is sufficiently 2 descriptive to act as a useful markup language within the domain of the 3 present invention. Other UI markup languages, including for example the XML 4 User Interface Language (XUL), may be alternately used. The generation 132 5 step may also be used, as may be required, to organize and adjust the format 6 of the CML template UI specification in preparation for subsequent storage 7 and use. 8 [0091] Similarly, the CML template code block specification is parsed 9 132 to apply defaults and inference any additional information appropriate 10 to create a fully formed CML template code block specification. A 11 parameterized executable code block is generated 132 from the CML template 12 code block specification. This code block preferably represents a code 13 fragment containing one or more source statements in the Microsoft C# 14 language. While C# is presently preferred, the code generation 132 15 operation can be adapted to produce the executable code block in number of 16 other source languages. Java, JavaScript, Lua, and Go are suitable alternative 17 source languages. The generated executable code block is preferably 18 prepared for storage in source form, though a compiled instance may be 19 cached. 20 [0092] The functional completeness and logic of the generated CML 21 template UI specification and CML template code block specification, including 22 the generated executable code block, is then validated 134. If any aspect of 23 the specifications are incomplete or improperly structured, include any logical 24 inconsistencies, are not interpretable or compilable without errors, or otherwise 25 incurs any other validation failure, the parameterized template is returned 124 26 for inspection and correction by the data entry clerk. 27 [0093] Where the CML template UI and code block specifications are 28 determined valid, a template record 136, preferably suitable for storage in a WO 2011/103523 PCT/US2011/025570 - 33 1 data-pod resident database, is created. The parameterized CML UI 2 specification 138 and parameterized CML code block specification 140 are 3 copied into one aspect of the template record 136. This aspect is then 4 preferably stored in an organization level data-pod instance 142. 5 [0094] The dynamic objects, earlier selected as parameterization values 6 for use in the evaluation of the specifications 138, 140, are preferably stored 7 in another, separate aspect of the template record 136. This latter aspect is 8 preferably stored in the study data-pod 144 used for the source contract 122 9 corresponding clinical trial. Thus, the study specific parameterization values, 10 as tokens, are stored separate from the CML UI and code block specifications 11 138, 140. 12 [0095] By rendering the set of contract terms contained in the source 13 agreement 122 as a collected set of CML statements, automation of the source 14 agreement is functionally achieved. The source agreement 122 can be a 15 compilation of one or more agreements that, together, represent and define 16 the operational and procedural events necessary to implement a study 17 protocol. Amendments and other changes made are reflected by adding, 18 modifying, and removing altered contractterm corresponding CML statements. 19 Consequently, the impact of changing source agreement 122 terms is 20 minimal. The CML statements are, in effect, atomic. 21 [0096] As discussed above, the effective execution of CML statements 22 is performed in response to the transit of operational events, as conveyed by 23 messages, through an application server process 82 instance as executed on 24 the application servers 56. With reference to Figure 7, the initial generation 25 of an operational event will occur in response to any number of different 26 actions taken by sponsors, CROs, investigators and others, including other 27 automated systems, that interact with the distributed data processing system 28 10. An exemplary action by a user is the addition of new information, such as WO 2011/103523 PCT/US2011/025570 - 34 1 performed through a data-entry form. Upon submission of form entered data, 2 an operational event is generated 192. The event is associated with event 3 related data 194, particularly including the data associated with the event 4 generation, such as the data provided through the data-entry form, and 5 information identifying the clinical trial and sufficient to identify the associated 6 organization and study data-pods, the corresponding investigator and site, 7 and related details, as applicable. The message is prepared 196 and 8 transmitted 198 through a corresponding service requester 34. The message 9 is routed through the cluster 92 and to an application server process executed 10 by the servers 56. 11 [0097] Referring to Figure 8, a CML statement execution engine 210, 12 as implemented in a preferred embodiment of the present invention, is 13 embedded with an application server process 82 executed on the servers 56. 14 The engine 210 initially receives an operational event via the message inbox 15 of an associated study data-pod 60', 62'. As each operational event is 16 received 212, the event related data is saved to an event database 214 and 17 a notification is sent effectively to the CML engine 210 indicating that a new 18 operational event has been received and is awaiting review. 19 [0098] The initial step in processing a new operational event is to 20 validate 216 the event. Validation is performed to verify the source and data 21 integrity of the operational event. Additional validation and fraud detection 22 tests are preferably performed as a prerequisite to making the operational 23 event available for CML evaluation. 24 [0099] Operational events that fail validation must be subjected to 25 further review. Preferably, the event is passed to a review process 218, 26 typically involving some degree of human intervention. Within the review 27 process 218, the reviewer may accept, reject, or edit and resubmit the 28 operational event to retry validation 216.

WO 2011/103523 PCT/US2011/025570 - 35 1 [0100] Provided an operational event has passed all validation tests or 2 has otherwise been accepted on behalf of the CML engine 210, the 3 operational event is released 220 into a pending status awaiting CML 4 evaluation. 5 [0101] Preferably, the CML statement evaluator, as implemented within 6 the CML statement execution engine 210, can operate in several different 7 modes depending on, for example, the desired performance level of the CML 8 statement execution engine 210, typically as measured by event throughput 9 and a transaction latency limit. The presently available CML statement 10 evaluator modes include incremental, full, expected, and forecast. Incremental 11 mode is the preferred default mode. In incremental mode, only new valid 12 operational events 228, received within the last evaluation cycle, are 13 considered in determining the CML statements to be evaluated, preferably 14 defined as an evaluation set. The last evaluation cycle is defined as the period 15 of time after the CML statement execution engine 210 last finished the 16 complete evaluation of an event. If the evaluation set contains an "all sites" 17 or study-wide operational event 230, such as study status, then the evaluation 18 preferably switches immediately to full mode. 19 [0102] For full mode, all current, valid operational events are selected 20 232 in determining the evaluation set. In expected mode, the CML evaluation 21 runs largely consistent with full mode. An additional, expected set of 22 operational events are also included. Specifically, this expected set of events 23 are those events identified according to the relevant study protocol as expected 24 to already have occurred but have not yet been received by the CML statement 25 execution engine 210. In forecast mode, the CML evaluation again largely 26 runs consistent with the full mode of operation. The additional operational 27 events considered in determining the additional forecast set includes all of the WO 2011/103523 PCT/US2011/025570 - 36 1 operational events yet to be received, beginning from the current time point 2 through to the end of the clinical trial or study. 3 [0103] Once the evaluation set is established, the CML statement 4 evaluator determines 234 the distinct set of study locations referenced in the 5 evaluation set. Only CML statements associated with these study locations 6 need to be evaluated. A study location is typically the same as a site with a 7 persistent, physical address, such as a hospital, medical office, or clinic. 8 [0104] For each identified study location, only the CML statements 9 corresponding to the contract terms associated with a particular study location 10 need be selected for evaluation 236. In one embodiment, CML statements 11 can be further classified by operational event types so that upon import or 12 entry of operational event data, only CML statements for a chosen 13 classification will be evaluated, thereby improving the efficiency of the CML 14 statement evaluator. 15 [0105] If subject relative operational events exist 238 in the evaluation 16 set for a particular study location, the corresponding CML statements are 17 evaluated 240 for each referenced subject. Subjects that do not appear in the 18 evaluation set are not processed. If no subject related events are present in the 19 evaluation set for a particular study location, the CML statements are 20 evaluated 248 once with respect to the study location only. 21 [0106] CML statements are preferably defined by a 22 CMLStatementTemplate class. This class contains two significant properties. 23 A "CML" property contains the CML template UI specification that is parsed 24 and used to render UI controls to collect values for each dynamic object 25 property and variable defined in a given CML statement. The values collected 26 are preferably stored in the event database 214 as name/value pair "tokens". 27 The other property, denominated "Code", contains CML template code block 28 specification. This specification includes source statements that, when WO 2011/103523 PCT/US2011/025570 - 37 1 interpreted, compiled, or otherwise processed, produces machine readable 2 code executable by an application server 56 instance and capable of 3 producing a result value. In operation, the CML statement evaluator 4 determines the execution produced result value against the CML statements 5 against operational events to determine whether or not a transaction is 6 needed. In a preferred embodiment, the code fragment provided by the CML 7 template code block specification contains defined "markers" that identify a 8 particular token and property. Prior to execution of the code fragment, the 9 markers are identified and, by a dynamic revision of the code fragment, the 10 markers are replaced with the corresponding parameterized value for the 11 template token instance. 12 [0107] In a preferred embodiment of the present invention, a generic 13 CMLStatementEvaluator base class is defined. This class implements a virtual 14 "Evaluateo" method that accepts an arbitrary number of parameters to support 15 future enhancements and backwards compatibility. Execution of the Evaluate( 16 method will return an enumeration, called "CMLStatementResult". The virtual 17 evaluate method can be overridden by any CMLStatementEvaluator derived 18 class. The base class also provides a number of protected properties and 19 methods that can be used by derived classes. 20 [0108] As implemented in the preferred embodiments, to evaluate a 21 CML statement, the CML statement evaluator first checks to determine if a 22 CMLStatementEvaluator instance has already been compiled for the CML 23 statement. Since the code generated for a particular CML template code 24 block specification and parameterization list of tokens and variables is the 25 same, the source code fragment may be compiled once and cached for use 26 in subsequent evaluations. In the absence of a compiled instance, the 27 corresponding source code is dynamically modified and then an executable 28 code generator is invoked. Specifically, source code fragment is parsed to WO 2011/103523 PCT/US2011/025570 - 38 1 substitute markers for corresponding token property values and variable 2 values. The resulting source code is next wrapped in a class extending 3 CMLStatementEvaluator. The C# compiler is then invoked to produce a 4 compiled instance. This CMLStatementEvaluator object is used subsequently 5 by the CML statement evaluator to evaluate operational events for this unique 6 CML statement. 7 [0109] The CML statement evaluator implements the necessary 8 environment to execute the instantiated CMLStatementEvaluator object by 9 invoking the virtual "Evaluate(" method. Functionally, execution of the 10 compiled code fragment performs a logical condition testing of the values 11 defined in the compiled code fragment against each operational event in the 12 evaluation set of operational events. The order of the conditions evaluated 13 against an operational event is preferably not constrained to be sequential. 14 For example, the temporal order of evaluation of an operational event can 15 occur before, during, and after another operational event. 16 [0110] At execution completion, a CMLStatementResult object is 17 returned as a result 242. If this result 242 matches a defined value 18 corresponding to False, the evaluation of the CML statement terminates 250. 19 The evaluation result 242 will be False unless all operational events required 20 by the CML statement are present. 21 [0111] If the result 242 corresponds to a defined True value, then all 22 operational events associated with the transaction are satisfied, but a 23 frequency or quantity component of the CML statement has not been satisfied. 24 For example, where the CML statement specifies a counted requirement, such 25 as "For Every 2 Subjects", a corresponding transaction term will be saved 252 26 to maintain state in the ongoing evaluation of CML statements. 27 [011 2] An evaluation result 242 of TrueWithTransaction will occur when 28 all operational events associated with the CML statement are satisfied and all WO 2011/103523 PCT/US2011/025570 - 39 1 frequency or quantity components of the CML statement has also been 2 satisfied. In this case, a CMLTransaction object is created and initialized with 3 information identifying the study location (PI), contract owner, whether a 4 sponsor or CRO, a description of the operational events that satisfied the 5 transaction and the source of those events, and other information needed to 6 create a financial or non-financial transaction. This object is then sent to a 7 contractor organization data-pod inbox for processing. Notably, a CML 8 evaluation is only concerned with evaluating the conditions that determine if 9 and when a transaction should be generated. The CML evaluation is agnostic 10 concerning the details of the actual underlying transaction. 1] [0113] An exemplary transaction flow 260 illustrating an efficient 12 application of the Clinical Payment Network 50 is presented in Figure 9. The 13 transaction flow 260 will typically occur in clinical trial and other related 14 agreements, such as clinical research agreements, whenever sponsors and 15 CROs are required to issue reimbursements and other payments to or on 16 behalf of investigators in a manner specified by a clinical trial agreement. The 17 transaction flow 260 demonstrates the effective collection of reimbursement 18 information, an approval review, and completion resulting in the disbursement 19 of funds. 20 [0114] Investigators 262 include doctors, hospitals, other health care 21 providers who are involved in the performance and management of a 22 particular clinical trial. Subjects 264, as patient participants, are typically 23 associated with the investigators 262 who undertook the enrollment of the 24 subjects 264 as well as providing ongoing treatment and follow-up visits. 25 These subjects 264 are also identified as participating in the same clinical trial. 26 Affiliates 266 are also directly associated with the subjects 264 generally under 27 the direction of the investigator 262. Affiliates 266 are typically laboratories, 28 pharmacies, and other supporting product and service providers.

WO 2011/103523 PCT/US2011/025570 - 40 1 [0115] Preferably, on entry into a trial, the investigators, 262, subjects 2 264, and affiliates 266 are permitted access through an application server 56 3 instance to the trial corresponding organization and study data-pods 58, 60. 4 Access is constrained to reflect the specific roles of the investigators 262, 5 subjects 264, and affiliates 266. As potentially reimbursable expenses are 6 incurred including, for example, equipment purchase payments, the 7 investigators 262, subjects 264, and affiliates 266 may access the study 8 relevant organization and study data-pods 58, 60 as appropriate to submit 9 expense reports, expense support, and other information requested or required 10 for consideration of the underlying payment request. Access is typically 11 performed through use of the Web form-based interface provided by a Web 12 server 88 hosted on a corresponding application server 56 instance also 13 associated with the corresponding organization and study data-pods 58, 60. 14 [0116] The application server 56 instance associated with the trial 15 organization and study data-pods 58, 60 operates, in this example, as an 16 accounting engine 268. That is, the receipt of reimbursement requests results 17 in the selection and evaluation of CML statements that collectively implement 18 or relate to qualifying payment requests and related accounting business 19 operations. This selection of CML statements is implicit, arising from a 20 cascade of operational and procedural events deriving from the postings of 21 reimbursement requests and related information. The specifics of the business 22 operations carried out as a consequence are as defined in an applicable 23 source agreement 122 and as reduced to a corresponding collection of CML 24 statements. 25 [0117] Thus, for example, the collection of CML statements, upon 26 evaluation, progressively define a business processes of collecting and 27 organizing the provided reimbursement data and, at defined intervals, 28 sequencing the documentation through selected reviewers to obtain any WO 2011/103523 PCT/US2011/025570 -41 1 required pre-approvals. The reimbursement requests by subjects 264 and 2 affiliates 266 may run at different intervals and be examined by different 3 reviewers who may be categorically specialized for these different types of 4 requests. 5 [0118] To the extent that pre-approvals are received, the result may be 6 that the accounting engine 268 will typically generate invoices 170 or other 7 financial documents on behalf of the investigators 262, subjects 264, and 8 affiliates 266 at times applicable to the different organization roles as defined 9 through the CML statements and sufficiency of the reimbursement requests and 10 supporting information provided functionally as defined by the controlling 1] agreements. Generated invoices are again sequenced to the necessary 12 reviewers as necessary to gain invoice approval 272. The approved invoice 13 272 is then routed to a payment engine 274. Like the accounting engine, the 14 payment engine 274 is an application server 56 instance also associated with 15 the trial organization and study data-pods 58, 60. This application server 56 16 instance is functionally characterized as a payment engine 274, reflecting 17 execution of the payment business processes implemented by the cascade of 18 events initiated by the receipt of the approved invoice 270. 19 [0119] Again, depending on the specifics of the collected CML 20 statements upon evaluation, final approval request messages may be sent 21 from the payment engine 274 to the sponsor 276 and any CRO 278. These 22 organizations 276, 278 act to provide a final approval, realized as one or 23 more messages sent, as appropriate, to the organization and study data-pods 24 58, 60 associated with the application server 56 instance representing the 25 payment engine 274. These messages, as received, represent events to the 26 payment engine 274. Depending on the manner of payment specified 27 functionally by the trial controlling agreements, the business processes 28 controlling the manner and timing of disbursements are executed by the WO 2011/103523 PCT/US2011/025570 - 42 1 payment engine 274. As denoted by the dashed lines, funds are forwarded 2 from the sponsor 276, directly or through the CRO 278, as needed to 3 replenish the working account provided the sponsor 276 or the CRO 278 4 effectively managed by the payment engine 274. Appropriate payments are 5 separately directed to the investigators 262, subjects 264, and affiliates 266. 6 In addition, refunds can be similarly handed through execution of these 7 business operations. 8 [0120] Of note, clinical trials often provide payments to subjects of a 9 particular study using payment cards, such as credit, debit, prepaid including 10 reloadable cards that store electronic funds or link to corresponding deposit 11 accounts or the issuance of a check, ACH payment, or wire transfer. This 12 arrangement allows the investigator, CRO, or sponsor to issue payments to 13 subjects for travel and meals, completion of trial milestones, office visits, and 14 other payment events specified typically in the clinical trial agreement. The 15 timetables and requirements that trigger payment events to subjects and 16 organizations are therefore reducible to a set of CML statements as discussed 17 above. 18 [0121] The use of electronic payment systems has numerous 19 advantages, such by eliminating the need for investigators to pay subjects and 20 then seek reimbursement from the sponsor. The primary drawback is that 21 these systems create an additional opportunity for fraud and the potential for 22 processing errors. 23 [0122] In a preferred embodiment, fraud detection is carried out on a 24 trial site basis, and not necessarily on a trial subject basis. This is 25 accomplished, at least in part, by the system server 52 maintaining a 26 site-specific fraud score for each trial site. The fraud score is preferably based 27 on evaluating the subject payment requests received for trial subjects 28 associated with that trial site. In particular, the evaluation is advantageously WO 2011/103523 PCT/US2011/025570 - 43 1 based on the clinical trial agreement or other source document of operational 2 or performance event terms. Thus, assessing the likelihood that a given 3 payment request is fraudulent is driven by the underlying contractual 4 expectations. This vets payment requests against the terms of the protocol 5 itself and permits substantial if not complete automation of the fraud reduction 6 process. Alternatively or in addition, payment requests can be compared 7 against electronic data from various clinical management systems, such as 8 IVRS, IWRS, CTMS, EDC, DMS and other systems storing clinical data, to 9 identify deviations at the time of the payment request. Post analysis of prior 10 trials can be used to build anticipatory fraud scores and identify potentially 11 fraudulent or erroneous payment requests previously paid. 12 [0123] In a preferred embodiment, the payment engine 274 includes 13 a fraud detection engine that reports, for example, payment event identifiers, 14 payment event type information, required event data to the system server 52. 15 This information can be used to determine or otherwise implicitly define, a 16 permissible timing or sequence of payment events. Timing may be absolute 17 in calendar terms, or relative, such as days elapsed from the trial start or days 18 prior to and after a scheduled visit date. The trial protocol may define an 19 allowed payment window for a given payment event. A payment request 20 corresponding to that payment event may be evaluated by comparing the 21 actual timing to the permissible payment window. A request and frequency of 22 requests outside of the window may be flagged as fraudulent or otherwise 23 weighted to indicate the likelihood of fraud. 24 [0124] Each site submits or otherwise authorizes payment requests for 25 trial subjects concurrent with the processing of the subjects through the 26 ongoing payment events. In turn, the fraud engine receives and processes the 27 payment requests in view of the originating trial site. Thus, as each payment 28 request is evaluated against the payment requirements defined by the trial WO 2011/103523 PCT/US2011/025570 - 44 1 protocol, the fraud engine will update the corresponding fraud score 2 maintained for that trial site based on the weighted likelihood that the request 3 is fraudulent. 4 [0125] Combined with the described operation of the fraud engine, 5 fraud can be further reduced in clinical trials that use payment cards for 6 compensating trial subjects. Each payment card is associated within the 7 Clinical Payment Network 50 with a corresponding trial subject and the 8 primary trial site for that subject. During the trial, preferably in response to 9 payment requests, the fraud engine can retrieve the corresponding transaction 10 history. 11 [0126] Current and historical transactions are evaluated to identify 12 deviations from the expected sequence and amount of the transactions. If any 13 deviations are identified, the fraud score associated with that trial site is 14 updated as a weighted function of the identified deviations. Each fraud value 15 determined by the weighted function may be computed or otherwise 16 determined actuarially or empirically to reflect the likelihood of a fraud in the 17 context of the site payment transaction history. Preferably, payment requests 18 made by subjects associated with that trial site will be denied if the fraud score 19 exceeds a defined threshold. 20 [0127] Additionally, or alternatively, the overall fraud score of a site may 21 be considered in decision to approve, deny, or flag an individual subject's 22 payment transaction. For example, if the timing, amount, or other aspect of 23 the payment request for a particular subject deviates from a norm determined 24 from the events of other patient participants, that payment may still be allowed 25 if the overall fraud score of the site is low or denied if the site's fraud score is 26 high, though the score is still below the defined threshold for refusing all 27 payment requests.

WO 2011/103523 PCT/US2011/025570 - 45 1 [0128] Thus, an efficient a computer-implemented system and methods 2 for managing clinical trials, including payments made within the context of a 3 distributed clinical trial in accordance with the terms of a clinical trial 4 agreement, has been described. While the present invention has been 5 described particularly with reference to typically human oriented clinical trials, 6 the present invention is also applicable to other complex systems where 7 efficient and reliable communications are required, coupled with defining and 8 efficiently managing the security concerns for the data being routed through 9 the system. 10 [0129] In view of the above description of the preferred embodiments 1] of the present invention, many modifications and variations of the disclosed 12 embodiments will be readily appreciated by those of skill in the art. It is 13 therefore to be understood that, within the scope of the appended claims, the 14 invention may be practiced otherwise than as specifically described above.

Claims (1)

1. 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.