Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
CA 02790472 2012-08-20
WO 2011/103523 PCT/US2011/025570
1 [0001] CLINICAL PAYMENT
2 NETWORK SYSTEM AND METHODS
3
4 [0002]
6
7
8
9 [0003] This application claims the benefit of U.S. Provisional Application
No. 61/306,425, filed February 19, 2010, and which is expressly incorporated
1 1 by reference.
12
13
14 [0004] Background of the Invention
[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
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:
[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
CA 02790472 2012-08-20
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
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,
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.
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
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
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
CA 02790472 2012-08-20
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
an invoice can be submitted for payment, further delay is incurred due to this
6 additional review and approval process.
7 [00111 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
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
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-
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
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
CA 02790472 2012-08-20
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,
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
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
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.
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
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
CA 02790472 2012-08-20
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
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,
this also creates regulatory reporting challenges at the local levels. With
the
11 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.
[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
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
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.
CA 02790472 2012-08-20
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
[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
agreement, master services agreement, research agreements, and other
11 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
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
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
defined data set, to the distributed computer system. An accounting engine
26 may then distribute corresponding documents and transactions to appropriate
27 organizations.
CA 02790472 2012-08-20
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
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
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.
[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
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,
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.
CA 02790472 2012-08-20
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
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
distributed in a variety of manners, including using reloadable or
11 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
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
[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
a distributed data processing operating environment within which preferred
26 embodiments of the present invention can be effectively utilized.
CA 02790472 2012-08-20
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 [00311 Figure 3B provides a block diagram of an application server
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.
[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
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.
[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
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
CA 02790472 2012-08-20
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
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
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
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
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,
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
CA 02790472 2012-08-20
WO 2011/103523 PCT/US2011/025570
-11 -
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
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
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
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
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
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.
CA 02790472 2012-08-20
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.
[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 responsiblefor maintaining defaults, configuration of workflows, data,
security,
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
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
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
exchanges, and similar entities.
26 [00511 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,_N and service providers
36,_M.
CA 02790472 2012-08-20
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.
Distributed service requesters 34,_N and providers 36,_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.
[0052] The function of the ESB 32 is to route messages, representing
11 network protocol specific requests and responses, between service
requesters
12 341_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,
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.
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
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
CA 02790472 2012-08-20
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
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
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
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.
[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.
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
CA 02790472 2012-08-20
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
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
organizations may grant access to non-custodial organizations, typically by
11 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.
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
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
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
CA 02790472 2012-08-20
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
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
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
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
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
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.
CA 02790472 2012-08-20
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
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.
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
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.
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
typically identify a completion procedure to be performed. If false, execution
26 of the CML statement is simply terminated.
27 [00611 To execute the completion procedure, the result object
28 representation of the message is transferred to a messages engine 87 that
CA 02790472 2012-08-20
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
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.
[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
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
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 ofthe 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-
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
CA 02790472 2012-08-20
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
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 1001_N
9 present in the MSMQ cluster 92. Preferably, each of the input queues 1001_N
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 1001_N.
13 [0065] The input queues 1001_N are progressively read by one or more
14 queue dispatchers 1021_M. These queue dispatchers 1021_M inspect and
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
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 1021_M.
[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
CA 02790472 2012-08-20
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 1001 _N typically for return to
the
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.
[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,
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
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
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.
CA 02790472 2012-08-20
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
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
constrained natural language representation of this exemplary template
11 instance is:
12
13 When INPUT subjects have a subject status of SELECT, pay $AMOUNT.
14
[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:
21 When 3 subjects have a subject status of On Study, pay $5000.
22
23 [00711 Figure 1 1 provides a representation of the corresponding UI
24 form presented template 300 with these parameterization values entered. The
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 1 1 is preferably
represented
28 by a CML template UI specification:
CA 02790472 2012-08-20
WO 2011/103523 PCT/US2011/025570
-22-
2 When {Integerl :integer} Subjects Have Subject Status of {Strl :string}
3 Pay {Amtl :decimal}
4
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
maintained separate from the parameterization values.
11 [0072] The corresponding CML template code block specification is:
12
13 When {Integerel :integer} [[Subjects]] Have [[[Subject Status]]]
14 of {Strl :string}
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
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
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}" ).Count(=={integer}
ExecuteTransaction( {decimal}
31
CA 02790472 2012-08-20
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]
Template (as retrieved from CML library):
6
7 (1) For Every INPUT Subject(s) with Visit SELECT Status of SELECT
8 - Record Transaction
9
(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
are Status SELECT
16 and Procedure SELECT
17 at Visit SELECT
18 is Status SELECT
19 - Record Transaction
21 (4) When Local IRB Status is SELECT or Drug Status is SELECT
22 - Record Transaction
23
24 (5) When CTA Status is SELECT
- 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
31 Parameterized Template (clinical trial agreement specific):
32
33 (1) For Every 3 Subject(s) with Visit Screening Status of Complete
34 - Record Transaction
36 (2) For Every 1 Subject(s) when All CRFs for Visit Randomization
37 are Status Monitored
38 - Record Transaction
39
CA 02790472 2012-08-20
WO 2011/103523 PCT/US2011/025570
-24-
1 (3) For Every 1 Subject(s) when All CRFs for Visit Week 1
2 are Status Frozen
3 and Procedure Colonoscopy
4 at Visit Screening
is Status Complete
6 - Record Transaction
7
8 (4) When Local IRB Status is Approved or Drug Status is Shipped
9 - Record Transaction
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
are Greater Than 0
16 - Decrease Screen Fail Credits by 1 and Record Transaction
17
18
19 CML Template UI Specification
21 (1) For Every {Integerl :Integer} Subject(s) with Visit {Visitl :Visit}
22 Status of {VisitStatusl :Visit Status}
23 - Record Transaction
24
(2) For Every {Integerl :Integer} Subject(s) when All CRFs
26 for Visit {Visitl :Visit}
27 are Status {CRFStatusl :CRF Status}
28 - Record Transaction
29
(3) For Every {Integerl :Integer} Subject(s) when All CRFs
31 for Visit {Visitl :Visit}
32 are Status {CRFStatusl :CRF Status}
33 and Procedure {Procedure) :Procedure}
34 at Visit {Visit2:Visit}
is Status {ProcedureStatusl :Procedure Status}
36 - Record Transaction
37
38 (4) When Local IRB Status is {IRBStatusl :Local IRB Status}
39 or Drug Status is {DrugStatusl :Drug Status}
- Record Transaction
41
CA 02790472 2012-08-20
WO 2011/103523 PCT/US2011/025570
-25-
1 (5) When CTA Status is {CTAStatusl :CTA Status}
2 - Set {CMLVariablel :CML Variable} to {Integerl :Integer}
3
4 (6) When Subject Status is {SubjectStatusl :Subject Status}
and {CMLVariablel :CML Variable}
6 are Greater Than {Integerl :Integer}
7 - Decrease {CMLVariable2:CMLVariable} by {Integer2:Integer}
8 and Record Transaction
9
11 CML Template Code Block Specification
12
13 (1) For Every {Integerl :Integer} [[Subject(s)]] with [[[Visit]]] {Visitl
:Visit}
14 [[[Status]]] of {VisitStatusl :Visit Status}
- Record Transaction
16
17 (2) For Every {Integerl :Integer} [[Subject(s)]] when All CRFs
18 for [[[Visit]]] {Visitl :Visit}
19 are [[[Status]]] {CRFStatusl :CRF Status}
- Record Transaction
21
22 (3) For Every {Integerl :Integer} [[Subject(s)]] when All CRFs
23 for [[[Visit]]] {Visitl :Visit}
24 are [[[Status]]] {CRFStatusl :CRF Status}
and [[[Procedure]]] {Procedurel:Procedure}
26 at [[[Visit]]] {Visit2:Visit}
27 is [[[Status]]] {ProcedureStatusl :Procedure Status}
28 - Record Transaction
29
(4) When [[Local IRB]] [[[Status]]] is {IRBStatusl :Local IRB Status}
31 or [[Drug]] [[[Status]]] is {DrugStatusl :Drug Status}
32 - Record Transaction
33
34 (5) When [[CTA]] [[[[Status]]] is {CTAStatusl :CTA Status}
- Set {CMLVariablel :CML Variable} to {Integerl :Integer}
36
37 (6) When [[Subject]] [[[Status]]] is {SubjectStatusl :Subject Status}
38 and {CMLVariablel :CML Variable}
39 are Greater Than {Integerl :Integer}
- Decrease {CMLVariable2:CMLVariable} by {Integer2:Integer}
41 and Record Transaction
CA 02790472 2012-08-20
WO 2011/103523 PCT/US2011/025570
-26-
2 Source Code Fragments
3
4 (1) if (And Event(EligibleStudyEvents.WithStatus({VisitStatus1 })
.ForVisit({Visitl })))
6 {
7 return RecordTransaction(ForEvery({Integerl }));
8 }
9 return base. Evaluate(args);
11
12 (2) if (AndEvent(AIICRFsForVisit({Visitl }),
13 EligibleStudyEvents.AtVisit({Visitl })
14 .With Status ({CRFStatusl })))
{
16 return RecordTransaction(ForEvery({Integerl }));
17 }
18 return base. Evaluate(args);
19
(3) if (AndEvent(AIICRFsForVisit({Visitl }),
21 EligibleStudyEvents.AtVisit({Visitl }).WithStatus({CRFStatusl })))
22 {
23 if (AndEvent(EligibleStudyEvents
24 .ForProcedure({Procedure 1 })
.AtVisit({Visit2})
26 .WithStatus({ProcedureStatusl })))
27 {
28 return RecordTransaction(ForEvery({Integerl }));
29 }
}
31 return base. Evaluate(args);
32
33 (4) if (OrEvent(EligibleStudyEvents.WithStatus({IRBStatus1 }),
34 EligibleStudyEvents.WithStatus({DrugStatusl })))
{
36 return RecordTransaction(First());
37 }
38 return base. Evaluate(args);
39
CA 02790472 2012-08-20
WO 2011/103523 PCT/US2011/025570
-27-
1 (5) if (And Event(EIigibleStudyEvents.WithStatus({CTAStatus1 })))
2 {
3 return SetVariable(FirstO, {CMLVariablel }, {Integerl });
4 }
return base. Evaluate(args);
6
7 (6) if (And Event(EIigibleStudyEvents.WithStatus({SubjectStatusl })))
8 {
9 if (AndVariable({CMLVariablel }, {Integerl }))
{
11 return RecordTransaction(DecrementVariable(Always(),
12 {CMLVariable2}, {Integer2}));
13 }
14 }
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
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
Object Properties
26 Subject Status, ID
27 Visit Name, Status
28 CaseReportForm Name, Status
29 Procedure Name, Status
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
CA 02790472 2012-08-20
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
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.
[0079] Exemplary simple and defined variable types 170 are listed in
11 Table 2:
12 [0080]
13 Table 2
14 Simple Variable Types Defined Variable Types
{integer} {Cohort}
16 {string} {Visit Type}
17 {decimal} {Visit}
18 {date} {Procedure}
19 {decimal percentage} {CRF}
{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
CA 02790472 2012-08-20
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
{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
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",
"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
[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
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
particular CML statement. Since CML statements are relatively concise, the
31 semantic analysis is neither too ambiguous nor too burdensome.
CA 02790472 2012-08-20
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
When All Set Record
6 If Issue Increase Transaction
7 Of First Decrease Release
8 Have Last Return Holdback
9 Pay Less Not Claim
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
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
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
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
CA 02790472 2012-08-20
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
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
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 {list}.
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
'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".
[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
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
CA 02790472 2012-08-20
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
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
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
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.
[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
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
CA 02790472 2012-08-20
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.
[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,
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
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
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
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
CA 02790472 2012-08-20
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
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
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
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
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
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.
CA 02790472 2012-08-20
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.
[01011 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
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
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
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
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
CA 02790472 2012-08-20
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
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
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.
[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
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
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
CA 02790472 2012-08-20
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
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
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 "Evaluate()" method that accepts an arbitrary number of parameters to
support
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.
[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
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
CA 02790472 2012-08-20
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
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
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
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
by the CML statement are present.
21 [01 1 1 ] 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
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 [01 12] An evaluation result 242 of TrueWithTransaction will occurwhen
28 all operational events associated with the CML statement are satisfied and
all
CA 02790472 2012-08-20
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
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
concerning the details of the actual underlying transaction.
11 [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
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.
[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.
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.
CA 02790472 2012-08-20
WO 2011/103523 PCT/US2011/025570
-40-
1 [01151 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,
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
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
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
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.
[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
CA 02790472 2012-08-20
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.
[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
supporting information provided functionally as defined by the controlling
11 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
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
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
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
CA 02790472 2012-08-20
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
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
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
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
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
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
CA 02790472 2012-08-20
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
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
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.
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
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
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
CA 02790472 2012-08-20
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,
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
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
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.
[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
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.
CA 02790472 2012-08-20
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
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.
[0129] In view of the above description of the preferred embodiments
11 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.
