U.S. patent application number 10/938756 was filed with the patent office on 2005-07-07 for clinical trial data management system and method.
This patent application is currently assigned to Phase Forward Inc.. Invention is credited to Bleicher, Paul A., Dale, Richard M., Klofft, Jeffrey P., Stamos, Nicholas.
Application Number | 20050149852 10/938756 |
Document ID | / |
Family ID | 22233230 |
Filed Date | 2005-07-07 |
United States Patent
Application |
20050149852 |
Kind Code |
A1 |
Bleicher, Paul A. ; et
al. |
July 7, 2005 |
Clinical trial data management system and method
Abstract
A system and method for managing clinical trial data includes
dynamically generating, at a server, a data entry form to be
displayed at a client. The data entry form is generated dynamically
in a SGML-derived language. Control elements within the form
comprise images which are used to construct the control elements
and larger controls. The form is generated from a protocol database
and a context received from the client, is populated from the data
database, and is published to the client. Templates based on the
protocol database comprise several frames including intermediate
frames for displaying frame borders which are non-horizontal and
non-vertical. If the trial protocol changes during a trial, the
generated form is based on the protocol version active at the time
data was entered into the form. Inadvertent use of the application
is discouraged requiring an authentication procedure and displaying
a picture of the authenticated user. Furthermore, help is provided
by creating a link between the text of each question and
information about the question. The source of help may be any or
all of a protocol document, an investigative brochure, and a study
guide. In addition, a user, upon logging in, is presented with a
dashboard screen which provides information or links to information
such as trial-related news, alerts, statistical information,
progress reports and a list of work to be completed.
Inventors: |
Bleicher, Paul A.; (Newton,
MA) ; Stamos, Nicholas; (Belmont, MA) ;
Klofft, Jeffrey P.; (Marlborough, MA) ; Dale, Richard
M.; (Newton, MA) |
Correspondence
Address: |
HAMILTON, BROOK, SMITH & REYNOLDS, P.C.
530 VIRGINIA ROAD
P.O. BOX 9133
CONCORD
MA
01742-9133
US
|
Assignee: |
Phase Forward Inc.
Waltham
MA
|
Family ID: |
22233230 |
Appl. No.: |
10/938756 |
Filed: |
September 10, 2004 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10938756 |
Sep 10, 2004 |
|
|
|
09092441 |
Jun 5, 1998 |
|
|
|
6820235 |
|
|
|
|
Current U.S.
Class: |
715/206 ;
715/205; 715/221 |
Current CPC
Class: |
G16H 70/40 20180101;
G16H 10/20 20180101 |
Class at
Publication: |
715/501.1 ;
715/513 |
International
Class: |
G06F 017/21 |
Claims
1-26. (canceled)
27. A clinical trial data entry method, comprising: displaying a
form on a computer screen, the form having at least one question to
which a user must respond to provide clinical data; creating links
between text of each question and detailed information related to
the question; and if the user clicks on text of the question,
displaying detailed information corresponding to the question.
28. The method of claim 27 wherein the detailed information
displayed is a help document defining the clinical trial.
29. The method of claim 28 wherein the help document is one of a
protocol document, an investigative brochure, and a study
guide.
30. The method of claim 28 wherein the help document comprises all
of a protocol document, an investigative brochure, and a study
guide.
31. A clinical trial data entry method, comprising: displaying a
form on a computer screen, the form having at least one question to
which a user must respond to provide clinical data; upon a user
request, displaying detailed information from any or all of a
protocol document, an investigative brochure, and a study
guide.
32. The method of claim 31 wherein the user can walk through each
of the protocol document, investigative brochure and study
guide.
33. The method of claim 32 wherein the detailed information
displayed is from a section of the protocol document, investigative
brochure, or study guide, which section pertains immediately to the
question to which the user must respond.
34-52. (canceled)
53. A computer system for entering clinical trial data, comprising:
a form displayed on a computer screen, the form having at least one
question to which a user must respond to provide clinical data; and
links between text of each question and detailed information
related to the question, the detailed information existing in at
least one on-line document, such that if the user clicks on text of
the question, displaying detailed information corresponding to the
question is displayed.
54-56. (canceled)
Description
RELATED APPLICATION
[0001] This application is a divisional of U.S. application Ser.
No. 09/092,441, filed Jun. 5, 1998. The entire teachings of the
above application are incorporated herein by reference.
COPYRIGHT NOTICE
[0002] A portion of the disclosure of this patent document contains
material which is subject to copyright protection. The copyright
owner has no objection to the facsimile reproduction by anyone of
the patent document or the patent disclosure, as it appears in the
Patent and Trademark Office patent file or records, but otherwise
reserves all copyright rights whatsoever.
BACKGROUND OF THE INVENTION
[0003] Once a pharmaceutical, medical device manufacture or
bio-technology company has developed a treatment, device or drug
therapy, approval from a regulatory authority, such as the FDA in
the US, must be obtained before it can be made available through
prescription. The submission to the regulatory authority consists
of a large volume of information, including clinical information
which focuses on the safety and efficacy of the therapy. Much of
that information is collected by conducting clinical trials.
[0004] A pharmaceutical, medical device manufacture or
biotechnology company sponsors a series of clinical trials. Either
an internal clinical group manages these trials or they are
out-sourced to a clinical research organization (CRO). The clinical
group or CRO contracts with investigation sites that in turn
recruit patients for the study and collect the clinical data.
[0005] The clinical trials are performed in a series of phases,
known as Phase I, Phase II, Phase III, and Phase IV. Each phase
varies in duration, the number of patients involved and purpose.
Failure at any stage of Phases I, II or III of the clinical trial
process effectively ends the therapy's chances for final
approval.
[0006] Before entering Phase I, the sponsor needs to obtain
regulatory approval. Phase I trials typically last six months and
involve tens of volunteer subjects usually all of whom are located
at a single investigative site. Phase I trials test the safety of
the therapy. Once Phase I trials are complete and the therapy has
been shown to be safe, the sponsor requests permission from the
regulatory authority to proceed with further clinical tests.
[0007] Phase II trials typically last six to twelve months, involve
tens to hundreds of patients and are conducted to test the
effectiveness of the treatment, device or drug. A sponsor may
conduct many Phase II trials, attempting to find as many uses of
the therapy as possible. If the therapy appears to be effective,
the sponsor requests permission from the regulatory authority to
proceed with large scale trials.
[0008] For each likely use of the therapy, the sponsor conducts at
least two Phase III trials. Phase III trials typically last 24 to
36 months and involve thousands of patients. Phase III trials are
blinded trials, that is, a portion of the patients receive the
therapy and the remaining patients receive a placebo or active
control, and the identities of patients taking the trial therapy
are not known to anyone until the trial is complete. Phase III
trials are conducted to test the safety and effectiveness of a
therapy in a large population. The Phase III trial is the first
opportunity to observe infrequent adverse effects in the general
population; each and every one is carefully recorded. Since the
effectiveness of the therapy is tested in a blinded environment,
the results are not known until after the study is complete.
[0009] Phase IV trials occur after approval and are generally held
to obtain approval to change a characteristic such as the delivery
system, e.g., from liquid to tablets, or to change the status,
e.g., from a prescription drug to an over-the-counter drug. Failure
at any stage of a Phase IV trial effectively ends the therapy's
chances of obtaining approval for such a change.
[0010] Every clinical trial has a protocol which specifies the
exact timing and nature of the measurements and interventions to be
performed on each patient. The protocol's time-line lists a series
of events, or visits, where the data are collected from the study
patient. The time-line of a typical study starts with the screening
and enrollment of a patient and typically ends with the last
patient visit.
[0011] FIG. 1 illustrates the preparation and processing of
paperwork in a typical clinical trial. There are a number of points
in the process where the data are audited and reviewed. A patient
401 visits the investigative site 413. For each visit, the protocol
instructs the investigator to collect certain information 403 about
the patient 401. After the information 403 is collected, it is
recorded on a Case Record Form (CRF) 405. Periodically, a Clinical
Research Associate (CRA) 417 visits the investigative site 413 and
compares the data in the original medical record 403 with the
information on the CRF 405. This process 406 is known as source
document validation, or SDV.
[0012] Once the CRF has been source document verified, CRF 405 is
delivered to the organization 407 running the trial (either a CRO
or an internal clinical group at the sponsor) as indicated by arrow
408. When the CRF 405 arrives at the sponsor/CRO 407, its data is
entered into a clinical database 409 twice to ensure that no errors
are introduced, as indicated by arrows 410A and 410B.
[0013] A medical monitor 415 and clinical data manager (CDM) 419 at
the sponsor/CRO 407 examine the CRF 405 to look for
inconsistencies. If any of the data are incomplete or appear
incorrect, the CRF is sent back to the investigative site 413 with
a query 411 for correction, a process known as cleaning. If someone
at the investigative site 413 makes a change as a result of a query
411, the data is again source document verified by the CRA 417, and
is sent back to the sponsor/CRO 407 for data entry, as identified
by arrow 412. When all of the data cleaning is complete, the
clinical database 409 is locked and data analysis begins.
[0014] As can be seen, a large volume of data is collected during
each clinical trial, and the collection and management of clinical
data is a large problem that requires many people performing a
number of different and unique roles. These roles fall into three
groups: the investigative site roles, the clinical data review
roles, and other central sponsor roles.
SUMMARY OF THE INVENTION
[0015] Implementing such a system or method on the Web has the
obvious advantage of ease--many people are now familiar with Web
technology and even those with computerphobia are becoming
comfortable accessing the Web. In addition, because browsers are so
inexpensive, while the personal computers on which they run can
typically be had for under $1,000, there are no major expenses
involved for other than the development of the clinical trial
database. No special software needs to be distributed.
[0016] On the other hand, one disadvantage is that access over the
Web can be considerably slower than a direct connection to a host
server. Another is that certain things that can be done easily in a
closed environment with custom software, such as curved boundaries
between frames, are not so readily done on the Web. The present
invention is aimed at overcoming these and other disadvantages.
[0017] Therefore, a method of implementing a graphical user
interface (GUI) control element within a client browser, comprising
creating several bitmaps which can be constructed to present the
GUI control element in a variety of different states. A Standard
Generalized Markup Language (SGML)-derived language such as HTML or
XML is used to specify placement of the bitmaps within a document.
Upon receipt of the document, a browser displays a desired GUI
control.
[0018] Preferably, placement of the bitmaps is specified by placing
indicators such as URLs corresponding to the bit maps in certain
locations, preferably table entries, within the document, such that
the browser will correctly display the control element.
[0019] Preferably, these bit maps are used by many similar GUI
controls.
[0020] Furthermore, a bitmap may be partitioned into multiple
sections, where each section is associated with a different
indicator.
[0021] In particular, in a preferred embodiment, one type of
control element is a button control which comprises left, right,
top and bottom pieces. A label is placed between the top and bottom
pieces.
[0022] Another type of control element is a file tab, or tab,
control, comprising left, right, top and bottom pieces. A label is
placed between the top and bottom pieces. Multiple tab controls can
be grouped together, sharing bitmaps which have a left or right
overlapping piece. Different bitmaps also provide different styles
such as color to portray a selected or non-selected tab.
[0023] Yet another type of control is a linear control which
comprises button control elements spaced at intervals along a line.
Each button control element has a corresponding bit map or
combination of bit maps. A pointer indicating a current value along
the line also has an associated bitmap.
[0024] In the preferred embodiment, the server is stateless with
respect to the GUI controls. That is, when a request is received,
the server has no knowledge of the states of the controls other
than what is sent in the request.
[0025] The present invention also provides a method of entering
clinical trial data from a client, where the data is maintained on
a server. A data entry form to be displayed at the client, is
generated at the server dynamically in a SGML-derived language,
from a library of code fragments. The form is generated according
to the user, the patient, the protocol version within a clinical
trial and data previously entered.
[0026] In a preferred embodiment, a protocol, or clinical, database
is created which is specific to an application. A data database is
created which is specific to a subject processed by the
application. Then the form is generated based on the protocol
database, preferably based on a clinical protocol, and a context
received from the client. Preferably this is done by generating a
template based on the protocol database and a context received from
the client. The form or template is populated with application data
from the data database, and published to the requesting client
browser.
[0027] Preferably, the template comprises several frames including
control frames with one or more control elements. An intermediate
frame presents a visual attribute shared by the control frames. The
appearance of the intermediate frame depends on the visual
appearance of the control frames.
[0028] In addition, in a preferred embodiment, protocols can be
changed during the trial. The generation of the template is then
further based on the protocol version which was active at time of
entering data to be displayed. Thus the form to be displayed is
itself based on the protocol version which was active at time data
was entered.
[0029] Furthermore, in a preferred embodiment, rules are associated
with the displayed form, and are based on the protocol version
which was active at the time of entering data to be displayed in
the form.
[0030] Yet another aspect of a preferred embodiment of the present
invention is the discouragement of inadvertent use of a computer
application, by requiring a log-on procedure for each user, and
displaying a picture of the currently logged-on user.
[0031] Still another aspect of a preferred embodiment of the
present invention is the provision of context-sensitive help.
Preferably, a displayed form has at least one question to which a
user must respond to provide clinical data. Links are created
between the text of each question and detailed information related
to the question. If the user clicks on text of the question,
detailed information corresponding to the question is retrieved
from the server is displayed.
[0032] Preferably, the detailed information is derived from any or
all of three source documents defining the clinical trial: a
protocol document, an investigative brochure, and a study guide.
Preferably, the user can walk through each of the documents.
[0033] Another aspect of the present invention is the dashboard
screen which provides information regarding the trial, customized
for the user and presented to the user upon logging in to the
system. Such information preferably includes but is not limited to
trial-related news, alerts, statistical information, progress
reports and a list of work to be completed
BRIEF DESCRIPTION OF THE DRAWINGS
[0034] The foregoing and other objects, features and advantages of
the invention will be apparent from the following more particular
description of preferred embodiments of the invention, as
illustrated in the accompanying drawings in which like reference
characters refer to the same parts throughout the different views.
The drawings are not necessarily to scale, emphasis instead being
placed upon illustrating the principles of the invention.
[0035] FIG. 1 is a block diagram illustrating current trial data
collection practice.
[0036] FIG. 2 is a block diagram illustrating the present
invention's implementation of a clinical trial data management
system operating over the Internet and the World Wide Web.
[0037] FIG. 3 is a block diagram illustrating the general flow of
operation and data in the present invention.
[0038] FIG. 4A is a diagram illustrating a Web page comprising a
typical clinical form created by the present invention.
[0039] FIGS. 4B and 4C are illustrations depicting the hierarchical
structure of a form such as that of FIG. 4A within the present
invention.
[0040] FIG. 4D is a schematic diagram illustrating the dynamic
construction of a form template and the resulting document within
the present invention.
[0041] FIG. 5 is a diagram illustrating how the form of FIG. 4A
might appear for a different user.
[0042] FIG. 6 is a diagram of a login screen.
[0043] FIG. 7 is a diagram illustrating the dashboard screen of the
present invention.
[0044] FIG. 8 is a diagram illustrating intermediate frames as used
by the present invention.
[0045] FIG. 9 is a diagram illustrating how a button control of the
present invention comprises bit maps laid out in a table.
[0046] FIG. 10A-10C are diagrams illustrating how the tab control
of the present invention comprises bit maps laid out in a
table.
[0047] Fig. 11A-11D are diagrams illustrating a linear control of
the present invention.
[0048] FIG. 12A is a flowchart illustrating the present invention's
use of study protocol version control.
[0049] FIGS. 12B and 12C are illustrations showing the same form
under two different protocol versions.
[0050] FIGS. 13A-13F are diagrams illustrating the use of context
sensitive help as employed by the present invention.
DETAILED DESCRIPTION OF THE INVENTION
[0051] The present invention provides a means of expediting the
process by collecting and managing trial data including
communications between sites over the Internet, using a World Wide
Web (Web) server in combination with Web browsers which run on most
personal computers. Such a system requires little to no investment.
Communication between parties is near-instantaneous, and can be
saved as part of the record. Checks can be performed automatically
and instantaneously. This allows faster processing of the data, and
faster availability of the data. A significant amount of time is
cut out the trial time, allowing the sponsor to get its product to
market sooner, saving millions of dollars, and potentially aiding
thousands or millions of potential recipients of the treatment much
sooner than the treatment might otherwise be available.
[0052] The Internet is a world-wide computer network which actually
comprises thousands of smaller networks connected to the Internet
backbone, thus linking millions of computer users around the world.
The Web is a technology which allows a user to format a document
according to some standard. The document is made accessible to a
Web server which transmits the document to another user upon
request. When the document is received by the requester running a
Web browser, the browser knows how to construct and display, or
render, the document.
[0053] Requests are made to a Web server using a Uniform Resource
Locator (URL) which identifies the Web server and the specific
document. These documents are often called Web "pages".
[0054] One common format for transmitting these documents is known
as Hypertext Markup Language (HTML). HTML allows the creator of a
document to specify the appearance and placement of a variety of
things such as font size, style, headers and so, including
placement of data or pictures within tables.
[0055] If a Web page is to contain pictures, these pictures or
images are often specified within the document by their respective
source locations, where they are stored as image files using
formats such as "gif" or "jpeg", for example. These image files can
be quite large and can consume an annoyingly large amount of time
as a requesting party waits for the image files to download. Of
course, this is compounded when there are several image files to be
downloaded.
[0056] One feature of most Web browsers is the ability to cache
information locally.
[0057] Thus image files can be stored in the browser's cache, so
that if the user requests the same page at a later time, the
browser uses the locally cached image files rather than downloading
the files again. While this saves much of the time that would
otherwise be wasted re-downloading the images, it does come with a
cost: image files can be large and caching many of them for
hundreds or thousands of Web pages can consume a significant
portion of local memory or disk space.
[0058] FIG. 2 illustrates the present invention operating over the
Internet. The Clinical Research Organization (CRO) or the sponsor's
own internal clinical group responsible for maintaining trial data
maintains an application server 103 which stores data about the
protocol, the forms to be used, the roles of various individuals
involved, etc., in a meta database 105. Actual clinical data
collected during a trial is maintained in a trial database 107. Of
course, while there are logically two databases, the actual data
can be maintained in just one or many databases.
[0059] The application server 103 receives requests via a network
109, such as the Internet, from users 111 at the investigative
sites 112, sponsor sites 113, and CRO sites 114, and responds to
the requests, presenting a consistent and secure interface through
a Web server 101. The Web server 101 transmits information to the
requesting site as a document formatted according to an
SGML-derived language, such as XML, or preferably, hypertext markup
language (HTML) document. The document can also include small
scripts in a language such as Javascript for implementing certain
rules at the user's site. Investigative sites 112 include, but are
not limited to, hospitals, clinics and independent doctors'
offices.
[0060] During a clinical trial, various individuals have certain
responsibilities which are accompanied by privileged access to
certain documents. In the present invention, these privileges are
rigidly defined. Roles are defined as a collection of privileges
such that assigning a particular individual to a defined role
bestows upon that individual the collection of corresponding
privileges.
[0061] For example, in the present invention, there are two primary
roles at the investigator site. The Clinical Investigator and the
Clinical Research Coordinator (CRC) gather the data for the trial
according the protocol, and record the data on CRFs which are sent
to the sponsor for review and acceptance.
[0062] The Clinical Investigator (CI) is responsible for treating
his patients and executing the study protocol. He has the ultimate
responsibility for all activities at his site.
[0063] The CRC is responsible for collecting all of the information
about the patients in the study who are being treated at the CRC's
site, and for returning the information to the clinical group. In
the US this individual is typically a nurse, while in Europe the
role of the CRC is typically performed directly by the Clinical
Investigator.
[0064] The people fulfilling these roles at the investigation site
must be able to see information about all of their patients who
have been screened or accepted into the study. This information
includes a patient's visit history, the contents of the CRF
associated with the patient, and the patient's lab results to name
a few.
[0065] As clinical reviewers at the CRO or sponsor examine the
answers to the CRF questions, they may have questions or comments
which require responses from the investigation site. These
questions and comments are referred to as queries. The CI or CRC
must be able to respond to a query, usually by attaching a comment
to a question or CRF, by adding new or additional information to a
CRF, or by changing information previously entered on the CRF. This
is a key component of data cleaning. Once the query is resolved,
the response is returned to the individual reviewer who issued the
query.
[0066] During the course of a trial, some patients may experience
adverse events. These events are noted by recording a text
description of the event, as well as a medical code for that event.
These codes are found in a number of coding dictionaries such as
COSTART. If the adverse event is serious, the sponsor is notified
immediately.
[0067] Some patients in the trials may take other medications
during the trial. These medications, whether taken regularly as for
allergy medication, or occasionally such as aspirin for a headache,
are `coded` and stored in the patient's record.
[0068] From time to time, the CI or CRC at the investigation site
must review some of the information about the study such as the
study protocol, the study reference manual, a study newsletter, and
a list of frequently asked questions. In addition, they must review
information about individual questions on the CRF such as getting a
list of all previous responses to a question and viewing the
discrepancy criteria for a question.
[0069] During a trial, a CI or CRC may need to communicate with a
representative of the sponsor. For example, initially the CI/CRC
needs to provide information about the site to the sponsor (Form
1571, lab normals, CVs of the investigator). As the study
progresses, the CRC may have a question or may notice something
that would interest the sponsor. Much of this communication is
included in the study files.
[0070] In addition to communication with the sponsor, the
investigation site may want to communicate with another site.
Perhaps an investigation site wants to ask someone at another site
a question. These communications are not part of the study
data.
[0071] In addition to written communication with the sponsor,
frequently the site will call someone at the sponsor. The content
of many of these conversions may need to be noted in the study
data.
[0072] The study protocol may require a CI/CRC to sign the CRF
pages either before the CRA performs the source document
verification, when the patient book is complete or both. The
signature task can be made easier for the investigator site by
telling them which CRFs are complete and need a signature, and when
data on a signed CRF has changed and needs another signature.
Additionally, the investigator sites need to know which CRFs they
have examined and which ones they have not examined.
[0073] The management of drug inventory during a study is critical.
A complete accounting of all study medication is required by the
regulatory agencies. The investigator site needs to dispense study
medication to their patients in the study and record this
transaction. Additionally, when the sponsor issues study medication
to the investigator site, this transaction and the receipt of the
study medication by the investigation site must also be
recorded.
[0074] Occasionally, the investigator site will need to break the
study blind for a particular patient (for example, when a study
patient becomes pregnant.) This is an important transaction and it
must be noted in the study data.
[0075] There are four clinical review roles to be performed at the
Clinical Research Organization (CRO) and/or sponsor. The Clinical
Research Associate (CRA), Clinical Data Manager, Medical Monitor,
and Clinical Project Manager review the data that is generated by
the investigator sites for completeness and consistency.
[0076] The Clinical Research Associate reviews all of the data
provided by the investigator sites, ensures that the sites are
following the protocol and that all of the information in the
medical record is completely and accurately represented in the
study data. Typically, a CRA is responsible for monitoring a number
of sites, and their audit role requires them to visit their sites.
The CRA needs to know exactly what is happening at all of their
sites so that they can effectively monitor the site's activities.
The CRA sends summary reports to the project manager and others at
the sponsor.
[0077] The Clinical Data Manager (CDM) prepares and maintains the
clinical study database. The CDM is involved in the design of the
study database, validation checks, and the design of the CRFs. The
CDM also reviews the data in the database ensuring that the data is
complete and consistent.
[0078] The Medical Monitor is often the designer of the study
protocol and may be responsible for making any of the necessary
changes to or deviations from the protocol once that study has
begun. The Medical Monitor also reviews the study data looking for
data anomalies and irregularities with respect to patient safety.
Like the CRA, the Medical Monitor reviews the data in the CRFs and
the communications with the sites. The Medical Monitor may respond
to a query from a CRA. Finally, the Medical Monitor is immediately
notified whenever a serious adverse event is recorded.
[0079] The Clinical Project Manager oversees the entire data
collection process. They directly manage the activities of the CRAs
and CDMs and at times they will examine the study data in detail.
Together with the Medical Monitor, the Clinical Project Manager
reviews the progress of the study and reports status to the senior
management at the sponsor.
[0080] To monitor a site effectively, a data reviewer periodically
reviews the data in the CRFs. If a value is missing, the validity
of a value is questionable, or there is some other cause for
concern, the data reviewer issues a query by attaching a question
or comment to a question on the CRF.
[0081] Before a clinical database can be locked, members of the
review team may be required to sign the patient CRF books. The
signature task is simplified by indicating which CRFs are complete
and need a signature, and which data on a signed CRF has changed
and requires another signature. In addition, the data reviewer
needs to know which CRFs have already been examined and which have
not been examined.
[0082] Just as the site must on occasion communicate with the
sponsor, the data reviewer must communicate with a site. These
communications may or may not be included in the study data. In
addition, some messages are critical and investigator site
personnel must see these messages before continuing.
[0083] Data reviewers need to communicate with each other. A CRA
may have a question for the medical monitor, or the medical monitor
may notice something that they would like the CRA to investigate.
Unlike queries, these communications are not part of the study
database.
[0084] Occasionally, one or more of the data reviewers will want to
lock some or all of the patient's records so that interim
statistical analysis can be performed. A preferred embodiment of
the present invention provides a mechanism for locking the data at
a patient level.
[0085] The Clinical Research Associate (CRA), has specific
additional functions, as well. The CRA can view an investigator
site's data and issue queries to the sites.
[0086] Periodically, the CRA visits a site, reviews all of the data
in the original medical records (the source documents) and compares
this with the information in the CRFs. This is known as source
document verification. The CRA monitors a CRF at the question
level, meaning that part of a CRF could be considered reviewed, but
the rest will still need monitoring at a later time. In a preferred
embodiment of the present invention, the CRA is automatically
notified when any CRF is ready for review.
[0087] The CRA often does not have access to the primary study
database and must work off-line. Therefore, during verification the
site cannot change the data being reviewed until after the review
is complete.
[0088] The CRA must manage the documents that are provided by the
site. These include any regulatory documents and any additional
documents that are generated by the site that must be included with
the study data. The CRA must notify the site when one of these
documents is about to expire.
[0089] From time to time, the CRA issues a report about a site. For
example, these reports are issued when a site has been qualified
for the study, when a site initiates a trial, after the CRA has
monitored some of the data at a site, and when a site finishes its
last study patient.
[0090] The Clinical Data Manager (CDM) also has specific additional
functions. During the course of a trial, the CDM may need to change
one or more of the discrepancy checks in the system.
[0091] Typically, codes are entered not by the study coordinator
(CRC) but rather by the CDM. If a CRC enters an adverse event or
concomitant medication without coding the data, the CDM supplies
the appropriate code in the database. In addition, the CDM
carefully reviews all coding of adverse events and concomitant
medications, making any changes that are necessary for
consistency.
[0092] The Medical Monitor is notified whenever a serious adverse
event is recorded. This notification occurs as quickly as possible
to ensure the safety of the affected patient and all other patients
in the study.
[0093] The sponsor will occasionally send information to all
members of the study team and/or to all of the sites.
[0094] In addition, it is occasionally necessary for the Medical
Monitor to change some part of the study protocol or CRFs. If the
change affects patient safety, the protocol change must be reviewed
by an Institutional Review Board at each site before it can be
implemented. This leads to the possibility that two or more
versions of the protocol could be active at different sites
simultaneously.
[0095] On rare occasions the Medical Monitor allows a site to
violate the study protocol. When this occurs, there must be a
documented record of the deviation with the Medical Monitor's
approval. Additionally, the Medical Monitor must note the
justification for the deviation in the study data.
[0096] Occasionally, the Medical Monitor will need to break the
study blind for a particular patient (for example, when a study
patient becomes pregnant). This is an important transaction and it
must be recorded in the study data.
[0097] The Clinical Project Manager will sometimes act as an
individual contributor CRA or CDM.
[0098] There are two other roles in the system which do not fit
into any of the other categories. They are the Pharmacist and the
Database Manager. Many investigator sites will have their own
pharmacy on site, or they will work with a local pharmacy. In
either case, the Pharmacist must have access to the clinical trial
data application.
[0099] The Database Manager is responsible for the security and
reliability of the clinical study database. During the design of
the trial, the Database Manager works with the CDM designing the
implementation of the data model for the trial. At the end of the
trial, the Database Manager is responsible for moving the data out
of the study database and into a statistical analysis database.
[0100] From time to time, a pharmacist must review information
about the study such as the study protocol, the study reference
manual, a study newsletter, and a list of frequently asked
questions. During the study, the pharmacist may need to communicate
with the sponsor personnel. As the study progresses, the pharmacist
may have a question or may notice something that would be of
interest to the sponsor. Some of these communications must be
included in the study data.
[0101] The management of drug inventory during a study is critical.
A complete accounting of all study medication is required by the
regulatory agencies. The site needs to dispense study medication to
their patients in the study and record this transaction. In
addition, when the sponsor issues study medication to the site,
this transaction must also be recorded.
[0102] When the study is complete and the database is locked, the
Database Manager must move the study data into a statistical
database. The database structures of the clinical database must
support this conversion.
[0103] FIG. 3 illustrates the general flow of operation and data in
the present invention. While any Standard Generalized Markup
Language (SGML)-derived language such as XML can be used, the
preferred embodiment of the present invention utilizes Hypertext
Markup Language (HTML). Rectangular boxes and solid bold lines
indicate process flow, while dotted lines indicate data flow.
[0104] First, at 201, a request is received from a user, i.e., an
investigative site, a sponsor site, a CRO site or a pharmacist. The
request 213 is saved for later processing by any or all of the
authentication process 203, the application layout process 205, or
the form creation process 207.
[0105] Upon receipt of a request from a client, the authentication
process 203 is invoked. A user database 215 is maintained, and the
authentication process 203 checks user information contained in the
request 213 against the user database 215. Such information may
contain user identification, password, session information, valid
time frame, etc., or other equivalent authentication means.
[0106] In addition to authenticating the user, the authentication
process 203 examines the user request 213 and checks with the user
database 215 that the user is authorized to make such a request.
The authentication process 203 can then establish which user rights
217 the user is to be given regarding the response to the
particular request.
[0107] Once the requesting user has been authenticated, an
application layout process 205 begins to construct the layout of
the HTML response 221 to the client. This is a top layer describing
what pieces are to be positioned within the HTML document and
where. For example, this layer determines what the various frames
should look like and what controls should appear therein. To make
these decisions, the application layout process 205 relies on the
original user request 213, the user rights 217 as determined
previously by the authentication process 203, and descriptors
maintained in a descriptor database 219.
[0108] Once the layout has been generated, the form creation
process 207 uses the user request 213 and descriptor database 219
to determine what questions, controls and other information should
go into the form in the HTML document 221 previously laid out by
the application layout process 205.
[0109] Next, the HTML document 221 is populated with clinical data
by a data population routine, which retrieves the data from a trial
database 223. The document 221 is now complete and ready for
transmission back to the client (block 211).
[0110] FIG. 4A illustrates a typical Web page 250 created by the
present invention, as constructed from the HTML document 221 (from
FIG. 3) when received and displayed by a client browser. Panels
251A-251C derive from the part of the HTML document 221 constructed
by the application layout process 205 (FIG. 3), and contain various
controls and other general information.
[0111] For example, panel 251A contains a photograph 257 of the
person whose user identifier and password were used to first gain
access to the system, or login. As discussed below, a preferred
embodiment of the present invention displays this photograph 257
for the purpose of discouraging inadvertent use of the system by
another person.
[0112] Other controls 261 are also provided in this panel 251A
which permit the user to navigate to and examine various related
documents and other information pages. Links 269 to recently
accessed documents or data are also provided.
[0113] Panel 251B holds two additional controls: a time line
control 263, and a file tab control 265. These are special types of
controls which were necessitated by the present invention, yet are
not easily implemented in a Web application. They are discussed
below. Note however, that the time line control 263 is used to
select a specific week (or some other unit of time) within the
study, and that the file tab control 265 is used to select a
particular form. Appearance of the form, of course, is dependent on
the user's role, the protocol version and the week selected, as
well as the actual form selected.
[0114] Finally, panel 251C holds controls 267 related to the form,
here a Submit button and a Cancel button.
[0115] Once the panels 251A-251C are laid out by the application
layout process 205, the selected form layout 253 is specified by
the form creation process 207 (FIG. 3). In FIG. 4A, the
"Demographics" form is displayed.
[0116] FIGS. 4B and 4C depict the hierarchical structure of an
electronic CRF 253, also referred to simply as a form, of the
present invention. The form 253 comprises one or more sections 551.
Two sections 551 of the Demographics form 253 are visible: a
Demographics section and a Smoking History section The remainder of
the form can be brought into view by scrolling the scroll bar
553.
[0117] Each section comprises one or more items in which the user
is typically asked to provide information about a patient, or if
the information has already been provided, the information is
displayed. For example, the Demographics section 551 has six items
554 numbered from 1 to 6, as well as a seventh item 555 in which a
calculation is automatically performed by the system.
[0118] Each item 554 in turn may comprise one or more control
groups 556. For example, item 2 ("Date of Birth") comprises control
group 556, which in turn comprises three controls 557A-557C
(generally 557 in FIG. 4C). Note that a control group may itself
comprise control groups.
[0119] Each control may have one or more elements. For example,
control 557A allows a user to select the patient's date of birth
month. The twelve months are available in a list which is made
visible by clicking on the arrow. Each month is an element 558 of
the control 557A.
[0120] The significance of this hierarchy is that each of these
hierarchical levels is treated as an object, with its own HTML
fragments. As illustrated in FIG. 4C, when a user sends a request
201 for a specific form, the associated form object 253 is called
up and passed user 559 and form 560 information. Form construction
is begun by selecting certain HTML fragments. The form object 253
then determines from the trial database including information about
the protocol version, and from user privileges and patient
information, which sections are to be included, and those section
objects are then called by the form object to render
themselves.
[0121] As with the form object, each section object has its own
HTML fragments, some of which are selected. This process continues,
each object in the hierarchy selecting HTML fragments according to
the user privileges, and calling its embedded objects.
[0122] FIG. 4D further illustrates how the HTML document 211 is
constructed dynamically from fragment templates and from data. A
trial database 220 stores structural information of the form object
hierarchies as previously discussed. A descriptor database 219 is
essentially a library of HTML code fragments. These two databases
together make up the meta database 105. A clinical database 223
stores data collected during the trial.
[0123] For example, the Demographics Form is described as having
two sections, Section 1 and Section 2. In the preferred embodiment,
pointers are used, such as the pointer 230 to Section 1. Each
section in turn has pointers to its items, and so on.
[0124] Each part of the hierarchy also points to corresponding code
fragments in the descriptor database 219. For example, the high
level Demographics form object comprises a pointer or identifier
231 which points to various code fragments 234. The object decides
which fragments to use and which to reject, depending on user
rights. The selected template fragment is copied (indicated by 238
) into the document 211.
[0125] Each object in the hierarchy behaves similarly. Section 1
object data in the trial database 220 has a pointer 232 to its own
corresponding code fragments in the descriptor database 219. Again,
those code fragments or templates selected, such as code fragment
235, are copied into the document 211, as indicated by arrow
239.
[0126] In addition, the object for Section 1 also has a pointer 233
to data 236 stored in the clinical database 223 which is combined,
in the output document 211, with the fragment template 235. That
is, the data 236 is copied, as indicated by arrow 241, into the
document 211, and replaces some placeholder from the original
fragment 235. The copied data is indicated by reference 242.
[0127] Finally, the output document 211 is sent, or published, to
the requester, whose browser renders the form. Arrow 243
demonstrates how one of the section fragments with trial data is
rendered into a section 204 of the form.
[0128] Of course, the clinical data is initially entered by the
CI/CRC and stored in the trial database when submitted. Upon later
retrieval for review or editing (assuming proper user rights), the
stored data is filled in under the data population process 209
(FIG. 3), wherein individual control or element objects retrieve
and display actual clinical data from the clinical database
223.
[0129] Note that while code fragments are generally in the form of
HTML statements, they can also contain small scripted statements
written in a language such as Javascript, which might be used to
implement certain rules. For example, a rule might allow patient
temperatures only within a certain range, to protect against the
entering of Celsius temperatures instead of Fahrenheit. Checking
with rules at the browser using a language such as Javascript
obviates the extra transmissions back and forth that would be
required if all checks were to be done at the server. Such rules
may be based on the protocol which was active at the time certain
data was entered.
[0130] In FIG. 4B, an inconsistency in the data has been found. The
user has indicated in Question 7 that the patient has never smoked,
yet in Question 9 has indicated that the patient smokes cigarettes.
Thus a query 271 has been entered by a CRA asking for further
verification and appears on the form for the user to respond
to.
[0131] Finally, note that the text of each question is a link to
additional information. For example, the text 271 of Question 5,
"Weight" is a link to one of several documents explaining weight in
the context of the protocol. This is discussed further below.
[0132] FIG. 5 illustrates how, in the preferred embodiment, the
same form can differ for a different user with a different role and
therefore different access rights. Here, User2 is a Clinical
Research Associate (CRA) with the Sponsor. The Sponsor is not
allowed to enter or alter data. Thus patient data at 275 is simply
displayed as text and is not editable. No controls are
available.
[0133] Note also that for User2, different controls 277 are
provided in the application layout panel 251A. Here, there are two
additional controls: Signatures and Monitor, because these are CRA
functions. Note also that because the form does not allow data
entry, the controls in pane 251C are also different from those of
FIGS. 4A and 4B.
[0134] Preventing Inadvertent Use
[0135] FIG. 6 illustrates a typical login screen of the present
invention as displayed on a client browser. A user is asked to
provide an account name 293 and a password 295. Upon clicking on
the Log In button 297, the account name and password are
transmitted over the Internet to the Web Server 101 (FIG. 2) where
they are then submitted to the Application Server 103 for
authentication. Alternatively, authentication could be performed
using alternative methods such as a secure identification card,
digital certificates or biometric characteristics.
[0136] A preferred embodiment of the present invention displays a
photograph 257 (FIG. 4A) for the purpose of discouraging
inadvertent use of the system by another person. For instance, if
the person logged in happens to walk away for a break, take a
telephone call, etc. and another user comes along and logs in using
his own login, and this second user takes a break, while the first
user returns, the first user will see instantly that she is no
longer logged in. A photograph catches the attention of the user
much more readily than would a text-only name.
[0137] In the preferred embodiment, the name and role 259 of the
logged-in user are provided under the photograph 257. Thus, if the
first user forgot to log out, a second user coming upon the system,
and unfamiliar with the first user, could visually identify the
first user, or, if unable to find the first user, because the name
is provided, could look the first user up in a directory if it were
necessary to contact the first user.
[0138] Integrated Dashboard
[0139] In a preferred embodiment, when the user has been
authenticated, a "dashboard" 301 customized to the user is returned
to the client browser and displayed.
[0140] FIG. 7 is a diagram illustrating the dashboard screen of the
present invention. The dashboard 301 contains various information
and links regarding the study. For example, it contains study news
303 which the user should read and alerts 305 which may be
critical. It also contains study progress graphs 307, a list of
work to be completed 309 with navigational links, and additional
information. It serves as a home base for the user.
[0141] Intermediate Frames
[0142] While frames with curved corners can be aesthetically
pleasing, HTML frames do not provide such curved borders. Thus one
aspect of the present invention is the use of intermediate frames
to provide the curves.
[0143] FIG. 8 is a diagram illustrating the use of an intermediate
frame by the present invention. Normally, a Web display may be
broken down into several independent frames. Here, Web page 400 is
divided functionally into three independent frames: a control panel
frame 403, a content action panel frame 405 and a content panel
frame 407.
[0144] The developer of the Web site wishes to use a curved line
401 to visually differentiate the panels from each other. However,
in HTML, frame borders are limited to horizontal and vertical
lines.
[0145] A preferred embodiment of the present invention simulates
curved or irregular shapes between frames by using an intermediate
frame 409 between frames 403, 405 and 407 in which the curves and
other frame borders are drawn. Thus, it appears to the user that
the various panels actually have curved borders.
[0146] Bit Mapped Controls
[0147] As discussed earlier, in a preferred embodiment of the
present invention, typical GUI controls which are normally executed
in a stateful machine are implemented in a client browser. This is
done in the preferred embodiment of the present invention by
creating several bitmapped images which can be selectively placed
such that the browser properly constructs the desired control.
Bitmapped images may be formatted as gif, jpeg or other formats.
Because browsers cache images locally, reuse of most of the bitmaps
in multiple control elements results in rapid construction of the
control element and thus the Web page.
[0148] One advantage of this approach is that because many of the
images are reused, only one copy of each needs to be downloaded
from the server. Second, labels are simple text and do not have
associated images to be downloaded. The text is small and thus
takes only a short time to transfer. Finally, because the image
files corresponding to the bitmaps are locally cached by a browser,
and because the image files are small, they consume only a small
portion of memory.
[0149] FIG. 9 illustrates this concept with a button control 501
containing the text label "ABC" 503. Ordinarily this entire button
501 is a single image. If many buttons are used, say having labels
"DEF", "GHI" and so on, each must have a completely different
image, each requiring its own initial transfer time and its own
cache storage.
[0150] Instead, the present invention breaks the button image into
several images 505A-505D. References or indications such as URLs to
these images (which, in the preferred embodiment are generally
"gif" files) are placed into a TABLE structure in an HTML document.
Such a table 506 has five data entries, labeled 506A-506E.
References to images 505A-505D are placed in four of the table
entries 506A-506D, resulting in the placement by a browser, of the
images in the table 506, as indicated by arrows 509A-509D
respectively. The label text "ABC" is placed, with a background
color matching the images 505A-505D, into the remaining table entry
506E.
[0151] Thus, while the application may use many different buttons,
only the labels are different--the same images are reused by all of
the buttons. No additional image files need to be transferred over
the Internet. Only the text needs to be transferred and text takes
but a fraction of the time an image takes to transfer. Since the
images are reused, storage in the cache is much smaller as
well.
[0152] Note also that an HTML-compatible browser automatically
extends bitmapped images to fit a required space. Since a table
adjusts itself to contain its data entries, a button 501A having a
long label 503A (say the entire alphabet) would be drawn having a
label space 506E long enough to contain the entire label. Table
entries 506B and 506C would be lengthened accordingly, and
therefore bitmapped images 505B and 505C would be extended to fill
these lengthened entries, even though only minimal descriptions of
the bitmaps is provided.
[0153] Below is sample HTML code to produce a button from several
gif files. Bitmap images 505A-505D (FIG. 9) correspond to files
named respectively "but_bot_left.gif", "but_bot_top.gif",
"but_bot_right.gif", and "but_bot_bot.gif". The label of this
particular button is "Go". Note also that each of the table entries
has the text: HREF="tabs.htm". Thus clicking anywhere on the button
will cause the browser to request a Web page identified as
"tabs.htm".
1 <HTML> <!--//////////////////////////////-
//////////////////// --> <!--// Copyright (c) 1997-1998 Phase
Forward Inc. --> <!--// 51 Winchester Street, Newton MA 02161
--> <!--// All Rights Reserved -->
<!--////////////////////////////////////////////////// -->
<HEAD> <STYLE> TD { font-size: 8pt; font-family:
Arial,"Sans Serif"; text-align: center; vertical-align: middle;
font-weight: bold; color:#CCCCCC; } TD.menu { line-height: 10px;
height: 8px; } TD.TDLeft { text-align: left; vertical-align:
middle; } TD.TDRight { text-align: right; vertical-align: middle; }
A:link { color: #CCCCCC; font-size: 8pt; font-family: Arial,"Sans
Serif"; font-weight: bold; text-align: center; text-decoration:
none; } </STYLE> </HEAD> <BODY> <TD NOWRAP
TITLE="Click here to go to the patient visit"> <TABLE
BORDER="0" CELLSPACING="0" CELLPADDING="0" VALIGN="middle"
ALIGN="left"> <TR> <TD ROWSPAN="3" NOWRAP><A
HREF="tabs.htm"><IMG SRC="./images/but_bot_left.gif"
BORDER="0"> </A></TD> <TD NOWRAP><A
HREF="tabs.htm"><IMG SRC="./images/but_bot_top.gif"
WIDTH="34" HEIGHT="4" BORDER="0"></A><- ;/TD>
<TD ROWSPAN="3" NOWRAP><A HREF="tabs.htm"><IMG
SRC="./images/but_bot_right.gif" BORDER="0">
</A></TD> </TR> <TR> <TD CLASS="menu"
BGCOLOR="#336699" NOWRAP><A
HREF="tabs.htm">Go</A></TD> </TR> <TR>
<TD NOWRAP><A HREF="tabs.htm"><IMG
SRC="./images/but_bot_bot.gif" WIDTH="34" HEIGHT="5"
BORDER="0"></A><- ;/TD> </TR>
</TABLE> </TD> </BODY>
[0154] Note that in HTML, a table structure is delimited by the
<TABLE> and </TABLE> tags. Each row begins with the tag
<TR> and optionally ends with </TR>. Within each row,
each column, or table data, begins with <TD> and optionally
ends with </TD>. A COLSPAN=X or ROWSPAN=Y specification
within a <TD> tag indicates that the corresponding entry is
to span X columns or Y rows respectively.
[0155] FIGS. 10A, 10B and 10C illustrate a file tab, or tab,
control used by the present invention. FIG. 10A shows a tab control
421 having three tabs, although a tab control with any number of
tabs can be implemented with this technique. As shown, the first
tab element, labeled "ABC" is selected.
[0156] The tab control 421 is subdivided into many small sections,
shown individually in FIG. 10C, each of which, except for label
sections, has a corresponding image. As with the button control,
many of the images are reused. Each image has a shaded version and
an unshaded version. A tab is shaded if it has been selected. For
example, a right piece bitmap 437, a top piece bitmap 425, and a
bottom piece bitmap 429 define most of the third "GHI" tab. The
label 435 is not a bitmap but rather, as with button labels
described above, is simply text with a background color to match
the surrounding bitmaps. Bitmap 431 is shared by the "GHI" tab and
the adjacent "DEF" tab.
[0157] The "DEF" tab uses the same top and bottom piece bitmaps
425, 429. Therefore, these bitmaps will not have to be transferred
again since they were just transferred in order to draw them into
the "GHI" tab. Of course, the "DEF" tab here uses a unique label
("DEF"), but since that is simple text, it is placed directly in
the table structure and as a result there is no significant
overhead in its transmittal. Another overlapping piece bitmap 431A
is shared between the "DEF" tab and the selected "ABC" tab.
[0158] The "ABC" tab uses shaded left, top and bottom piece bitmaps
423A, 425A, 429A respectively, to show that the "ABC" tab is
selected. The label "ABC" 427 is data embedded directly in the
table data definition.
[0159] Each of these small bitmap images has a HREF element
assigned to it, i.e. a reference to send to the server if the user
clicks the mouse button on the bitmap. Although the same top bitmap
425 is used for multiple tabs, each realization of the bitmap may
have a different HREF assignment. Thus, for example, when the user
clicks anywhere within any of the top 425 or bottom 429 bitmaps or
the label 427 associated with the "DEF" tab, information regarding
"DEF" may be retrieved from the server and displayed on the
browser. In addition, the tab control appearance must change to
indicate that "DEF" has been selected.
[0160] Thus, the tab control now appears as shown in FIG. 10B. Only
two new images are required: the shared bitmap 431A between the
"ABC" and "DEF" tabs has been replaced by a bitmap 439A with a
different overlapping appearance, and the leftmost piece 423A is no
longer shaded and must be replaced with piece 423. These are the
only piece of the tab control that need to be provided by the
server.
[0161] As with the button discussed above, without this technique,
it is necessary to download and cache the entire tab control in
each of its three possible states, i.e. three bitmap of the entire
tab control, each with a different tab selected. This requires much
more cache memory than the present invention, as well as much more
transmission time when the maps have not been cached (and each
transmission is a transmission of the entire tab control bitmap.)
The present invention, on the other hand, uses one small top bitmap
425 for each tab, as well as a bottom 429, left 423, and right 437
pieces, or their shaded versions 425A, 429A, 423A, 437A
respectively, and right overlap 431A and left overlap 439A pieces
all of which are significantly smaller than the whole. This
difference becomes even more significant where the number of tabs
is larger. As with the button control, the top and bottom tab
bitmaps 425, 429 respectively can be extended and therefore the
actual bitmaps are extremely small, just a few pixels wide and
therefore consume a very small amount of cache memory.
[0162] Another advantage to the present invention is that if the
form changes so that the tab control has additional tabs, no
further bitmaps need to be transferred. All of the necessary
bitmaps will have been cached. Only the table structure with text
labels, tab selection information, and references to the bitmap
files needs to be transferred.
[0163] Yet another advantage is that the present invention
alleviates the need to create more images when a form changes. For
example, in the prior art, if a tab control comprises seven
individual tab control elements, seven different images must have
been created--each one having a different tab selected. If it
becomes necessary to add an eighth tab control element, eight new
images must be created. In the present invention, no further images
need to be created.
[0164] Preferably, these bitmaps are arranged by placing them in a
table structure. For example, the code below defines an HTML table
in which the positions and files containing the bitmaps are
specified.
[0165] Also, in a preferred embodiment, the selected tab (whose
associated form is displayed) is colored differently and rendered
differently than the non-selected tabs. Thus there are different
images for selected and non-selected tab parts. However, since a
label is simply text and no image is used, a label's background
color is specified within the corresponding table entry to match
the tab. There is no image file to be transferred.
[0166] The following sample code produces a file tab control with
five tabs labeled "VS", "LAB", "AE", "CM", and "CMP" respectively,
with "VS" indicated as the selected form.
2 <HTML> <!--//////////////////////////////-
//////////////////// --> <!--// Copyright (c) 1997-1998 Phase
Forward Inc. --> <!--// 51 Winchester Street, Newton MA 02161
--> <!--// All Rights Reserved -->
<!--////////////////////////////////////////////////// -->
<HEAD> <META HTTP-EQUIV="Content-Type" content="text/html;
charset=iso-8859-1"> <TITLE>Phase Forward Demo CRF
Navigation Bar</TITLE> <STYLE> BODY { margin-top: 0px;
margin-left: 0px; margin-right: 0px; margin-bottom: 0px; } TD {
vertical-align: bottom; } TD.tabselect { color: #FFFF00; font-size:
10pt; font-family: Arial,"Sans Serif"; font-weight: bold;
text-align: center; vertical-align: center; line-height: 8pt;
height: 11pt; } TD.tabnotselect { color: #CCCCCC; font-size: 10pt;
font-family: Arial,"Sans Serif"; font-weight: bold; text-align:
center; vertical-align: center; line-height: 8pt; height: 11pt; }
A:link { color: #CCCCCC; font-size: 10pt; font-family: Arial,"Sans
Serif"; font-weight: bold; text-decoration: none; text-align:
center; } A:visited { color: #CCCCCC; font-size: 10pt; font-family:
Arial,"Sans Serif"; font-weight: bold; text-decoration: none;
text-align: center; } A:hover { color: #FFFFCC; } </STYLE>
</HEAD> <BODY BGCOLOR="#666666"> <MAP
NAME="OffMidMap1"> <AREA SHAPE="poly" HREF="tab_vsbp.htm"
COORDS="0,1,4,1,10,6,15,20,15,24,0,24" TITLE="Vital Signs/Blood
Pressure"> <AREA SHAPE="poly" HREF="tab_lab.htm"
COORDS="27,1,22,1,17,6,14,10,17- ,20,17,24,27,24,"
TITLE="Laboratory"> </MAP> <MAP NAME="OnMidLMap2">
<AREA SHAPE="poly" HREF="tab_lab.htm"
COORDS="0,1,4,1,10,6,15,20,15,24,0,24" TITLE="Laboratory">
</MAP> <MAP NAME="OnMidRMap3"> <AREA SHAPE="poly"
HREF="tab_cm.htm" COORDS="27,1,22,1,17,6,14,10,17,20,17,24,27,24,"
TITLE="Concomitant Medications"> </MAP> <MAP
NAME="OffMidMap4"> <AREA SHAPE="poly" HREF="tab_cm.htm"
COORDS="0,1,4,1,10,6,15,20,15,24,0,24" TITLE="Concomitant
Medications"> <AREA SHAPE="poly" HREF="tab_cmp.htm"
COORDS="27,1,22,1,17,6,14,10,17- ,20,17,24,27,24," TITLE="Study
Compliance"> </MAP> <TABLE BORDER="0" CELLPADDING="0"
CELLSPACING="0" HEIGHT="100%"> <TR> <TD
VALIGN="bottom"><TABLE BORDER="0" CELLPADDING="0"
CELLSPACING="0" ALIGN="left"> <TR> <TD ROWSPAN="3"
NOWRAP><A HREF="tab_vsbp.htm"><IMG
SRC="./images/tab_off_1.gif" BORDER="0" ALT="Vital Signs/Blood
Pressure"></A></TD> <TD NOWRAP><A
HREF="tab_vsbp.htm"><IMG SRC="./images/tab_off_top.gif"
BORDER="0" WIDTH="52px" HEIGHT="5" ALT="Vital Signs/Blood
Pressure"></A></TD> <TD ROWSPAN="3"
NOWRAP><IMG SRC="./images/tab_off_mid.gif" BORDER="0"
USEMAP="#OffMidMap1"></TD> <TD NOWRAP><A
HREF="tab_lab.htm"><IMG SRC="./images/tab_off_top.gif"
BORDER="0" WIDTH="40px" HEIGHT="5" ALT="Laboratory"></A-
></TD> <TD ROWSPAN="3" NOWRAP><IMG
SRC="./images/tab_on_midl.gif" BORDER="0"
USEMAP="#OnMidLMap2"></TD> <TD NOWRAP><IMG
SRC="./images/tab_on_top.gif" BORDER="0" WIDTH="32px" HEIGHT="5"
ALT="Adverse Experiences"></TD> <TD ROWSPAN="3"
NOWRAP><IMG SRC="./images/tab_on_midr.gif" BORDER="0"
USEMAP="#OnMidRMap3"></TD> <TD NOWRAP><A
HREF="tab_cm.htm"><IMG SRC="./images/tab_off_top.gif"
BORDER="0" WIDTH="34px" HEIGHT="5" ALT="Concomitant
Medications"></A></TD> <TD ROWSPAN="3"
NOWRAP><IMG SRC="./images/tab_off_mid.gif" BORDER="0"
USEMAP="#OffMidMap4"></TD> <TD NOWRAP><A
HREF="tab_cmp.htm"><IMG SRC="./images/tab_off_top.gif"
BORDER="0" WIDTH="43px" HEIGHT="5" ALT="Study
Compliance"></A></TD> <TD ROWSPAN="3"
NOWRAP><A HREF="tab_cmp.htm"><IMG
SRC="./images/tab_off_r.gif" BORDER="0" ALT="Study
Compliance"></A></TD> </TR> <TR> <TD
CLASS="tabnotselect" BGCOLOR="#336699" NOWRAP><A
HREF="tab_vsbp.htm" TITLE="Vital Signs/Blood
Pressure">VS/BP</A></TD> <TD CLASS="tabnotselect"
BGCOLOR="#336699" NOWRAP><A HREF="tab_lab.htm"
TITLE="Laboratory">LAB</A></TD> <TD
CLASS="tabselect" BGCOLOR="#003366" TITLE="Adverse Experiences"
NOWRAP>AE</TD> <TD CLASS="tabnotselect"
BGCOLOR="#336699" NOWRAP><A HREF="tab_cm.htm"
TITLE="Concomitant Medications">CM</A- ></TD> <TD
CLASS="tabnotselect" BGCOLOR="#336699" NOWRAP><A
HREF="tab_cmp.htm" TITLE="Study
Compliance">CMP</A></TD> </TR> <TR>
<TD BGCOLOR="#336699" NOWRAP><A
HREF="tab_vsbp.htm"><IMG SRC="./images/tab_off_bot.gif"
BORDER="0" WIDTH="52px" HEIGHT="5" ALT="Vital Signs/Blood
Pressure"></A></TD> <TD BGCOLOR="#336699"
NOWRAP><A HREF="tab_lab.htm"><IMG
SRC="./images/tab_off_bot.gif" BORDER="0" WIDTH="40px" HEIGHT="5"
ALT="Laboratory"></A></TD> <TD BGCOLOR="#003366"
NOWRAP><IMG SRC="./images/tab_on_bot.gif" BORDER="0"
WIDTH="32px" HEIGHT="5" ALT="Adverse Experiences"></TD>
<TD BGCOLOR="#336699" NOWRAP><A
HREF="tab_cm.htm"><IM- G SRC="./images/tab_off_bot.gif"
BORDER="0" WIDTH="34px" HEIGHT="5" ALT="Concomitant
Medications"></A></TD- > <TD BGCOLOR="#336699"
NOWRAP><A HREF="tab_cmp.htm"><IMG
SRC="./images/tab_off_bot.gif" BORDER="0" WIDTH="43px" HEIGHT="5"
ALT="Study Compliance"></A ></TD> <TD
VALIGN="bottom" COLSPAN="3" NOWRAP><IMG
SRC="./images/tab_off_bot.gif" WIDTH="1000" HEIGHT="5"
BORDER="0"></TD> </TR> </TABLE></TD>
</TR> </TABLE> </BODY> </HTML>
[0167] The correlation between bitmaps from Fig. 10C and their
corresponding file names is given in the table below:
3 FIG. 10C ref. number Filename in HTML code 423A/423
tab_on_l.gif/tab_off_l.gif 425A/425 tab_on_top.gif/tab_off_top.gif
429A/429 tab_on_bot.gif/tab_off_bo- t.gif 431A tab_on_midr.gif 439A
tab_on_midl.gif 437A/437 tab_on_r.gif/tab_off_r.gif
[0168] Similarly, FIGS. 11A, 11B and 11C illustrate a linear
control, preferably a time-line control, of the present invention
using the same technique. FIG. 11C shows the various bitmaps that
are placed in a table structure to compose a linear control. The
dashed lines show the outline of the bitmap, while the solid lines
represent what is actually seen. Of course, color and shading can
be used to produce a more dramatic effect, and in fact are used in
the preferred embodiment.
[0169] Bitmap 481 defines the left end of the control and shows the
left end of a frame which encloses the control. Similarly bitmaps
482, 483 and 489 define top, bottom and right frame pieces
respectively of the control enclosure. Note that by defining a
bitmap to span multiple rows or columns within a table entry does
not change the appearance of the bitmap except to extend it in the
vertical or horizontal direction respectively.
[0170] Bitmaps 483, and 485-488 define the various parts of the
linear control itself. Bitmaps 483 and 488 are the left and right
pieces respectively of the control and in the preferred embodiment
are only used once per control. Bitmap 485 is the line part of the
control and is used simultaneously in several places. Bitmap 486
has a continuation of the control line, plus a vertical tick.
Bitmap 487 is used to show which value has been selected.
[0171] These bitmaps 481-489 can be assembled in various
combinations to create linear controls of any size, and to show any
control in any particular state. For example, in FIG. 11A, bitmaps
481-489 (from FIG. 11C) have been assembled into a table 451 to
create a linear control with four stops. In addition, labels have
been placed in the table below each stop. These labels are merely
text entries with a background color matching the control, so that
there is negligible overhead in obtaining the labels.
[0172] The following HTML code produces the linear control of FIG.
11A.
4 <HTML> <!--//////////////////////////////-
//////////////////// --> <!--// Copyright (c) 1997-1998 Phase
Forward Inc. --> <!--// 51 Winchester Street, Newton MA 02161
--> <!--// All Rights Reserved -->
<!--////////////////////////////////////////////////// -->
<HEAD> <META HTTP-EQUIV="Content-Type" content="text/html;
charset=iso-8859-1"> <TITLE>Phase Forward Demo Visit
Bar</TITLE> <STYLE> BODY { margin-left: 0px;
margin-top: 0px; } TD { font-size: 8pt; font-family: Arial,"Sans
Serif"; font-weight: bold; text-align: center; vertical-align:
middle; } TD.tdselect { color: #FFFF00; } A:link { color: #CCCCCC;
font-size: 8pt; font-family: Arial,"Sans Serif"; font-weight: bold;
text-decoration: none; text-align: center; vertical-align: middle;
line-height: 11px; height: 8px; } A:visited { color: #CCCCCC;
font-size: 8pt; font-family: Arial,"Sans Serif"; font-weight: bold;
text-decoration: none; text-align: center; vertical-align: middle;
line-height: 11px; height: 8px; } A:hover { color: #FFFFCC; }
TD.tickmark { vertical-align: middle; /*line-height: 12px; height:
12px;*/ } </STYLE> </HEAD> <BODY
BGCOLOR="#336699"> <TABLE BORDER="0" CELLPADDING="0"
CELLSPACING="0" HEIGHT="100%" ALIGN="left" VALIGN="top">
<TR> <TD ROWSPAN="3"><IMG
SRC="./images/tick_indent_l.gif" BORDER="0"></TD> <TD
COLSPAN="2"><IMG SRC="./images/tick_indent_top.gif"
BORDER="0" WIDTH="53" HEIGHT="5"></TD> <TD
COLSPAN="3"><IMG SRC="./images/tick_indent_top.gif"
BORDER="0" WIDTH="70" HEIGHT="5"></TD> <TD
COLSPAN="3"><IMG SRC="./images/tick_indent_top.gif"
BORDER="0" WIDTH="70" HEIGHT="5"></TD> <TD
COLSPAN="3"><IMG SRC="./images/tick_indent_top.gif"
BORDER="0" WIDTH="70" HEIGHT="5"></TD> <TD
COLSPAN="3"><IMG SRC="./images/tick_indent_top.gif"
BORDER="0" WIDTH="70" HEIGHT="5"></TD> <TD
COLSPAN="3"><IMG SRC="./images/tick_indent_top.gif"
BORDER="0" WIDTH="70" HEIGHT="5"></TD> <TD
COLSPAN="3"><IMG SRC="./images/tick_indent_top.gif"
BORDER="0" WIDTH="70" HEIGHT="5"></TD> <TD
COLSPAN="2"><IMG SRC="./images/tick_indent_top.gif"
BORDER="0" WIDTH="46" HEIGHT="5"></TD> <TD
ROWSPAN="3"><IMG SRC="./images/tick_indent_r.gif"
BORDER="0"></TD> </TR> <TR> <TD
CLASS="tickmark"><- ;A HREF="tl_wk-4.htm"
TITLE=""><IMG SRC="./images/tick_left.gif"
BORDER="0"></A></TD> <TD
CLASS="tickmark"><IMG SRC="./images/tick_line.gif" BORDER="0"
WIDTH="35" HEIGHT="3"></TD> <TD
CLASS="tickmark"><IMG SRC="./images/tick_line.gif" BORDER="0"
WIDTH="26" HEIGHT="3"></TD> <TD
CLASS="tickmark"><A HREF="tl_wk-2.htm" TITLE=""><IMG
SRC="./images/tick_middle.gif" BORDER="0"></A></TD>
<TD CLASS="tickmark"><IMG SRC="./images/tick_line.gif"
BORDER="0" WIDTH="26" HEIGHT="3"></TD> <TD
CLASS="tickmark"><IMG SRC="./images/tick_line.gif" BORDER="0"
WIDTH="26" HEIGHT="3"></TD> <TD
CLASS="tickmark"><A HREF="tl_wk0.htm" TITLE=""><IMG
SRC="./images/tick_middle.gif" BORDER="0"></A></TD>
<TD CLASS="tickmark"><IMG SRC="./images/tick_line.gif"
BORDER="0" WIDTH="26" HEIGHT="3"></TD> <TD
CLASS="tickmark"><IMG SRC="./images/tick_line.gif" BORDER="0"
WIDTH="26" HEIGHT="3"></TD> <TD
CLASS="tickmark"><A HREF="tl_wk1.htm" TITLE=""><IMG
SRC="./images/tick_middle.gif" BORDER="0"></A></TD>
<TD CLASS="tickmark"><IMG SRC="./images/tick_line.gif"
BORDER="0" WIDTH="26" HEIGHT="3"></TD> <TD
CLASS="tickmark"><IMG SRC="./images/tick_line.gif" BORDER="0"
WIDTH="26" HEIGHT="3"></TD> <TD
CLASS="tickmark"><IMG SRC="./images/tick_middle_selected.gif"
BORDER="0"></TD> <TD CLASS="tickmark"><IMG
SRC="./images/tick_line.gif" BORDER="0" WIDTH="26"
HEIGHT="3"></TD> <TD CLASS="tickmark"><IMG
SRC="./images/tick_line.gif" BORDER="0" WIDTH="26"
HEIGHT="3"></TD> <TD CLASS="tickmark"><A
HREF="tl_wk4.htm" TITLE =""><IMG SRC="./images/tick_middl-
e.gif" BORDER="0"></A></TD> <TD
CLASS="tickmark"><IMG SRC="./images/tick_line.gif" BORDER="0"
WIDTH="26" HEIGHT="3"></TD> <TD
CLASS="tickmark"><IMG SRC="./images/tick_line.gif" BORDER="0"
WIDTH="26" HEIGHT="3"></TD> <TD
CLASS="tickmark"><A HREF="tl_wk5.htm" TITLE=""><IMG
SRC="./images/tick_middle.gif" BORDER="0"></A></TD>
<TD CLASS="tickmark"><IMG SRC="./images/tick_line.gif"
BORDER="0" WIDTH="26" HEIGHT="3"></TD> <TD
CLASS="tickmark"><IMG SRC="./images/tick_line.gif" BORDER="0"
WIDTH="28" HEIGHT="3"></TD> <TD
CLASS="tickmark"><A HREF="tl_wk8.htm" TITLE=""><IMG
SRC="./images/tick_right.gif" BORDER="0"></A></TD>
</TR> <TR> <TD COLSPAN="2"><IMG
SRC="./images/tick_indent_bot.gif" BORDER="0" WIDTH="53"
HEIGHT="5"></TD> <TD COLSPAN="3"><IMG
SRC="./images/tick_indent_bot.gif" BORDER="0" WIDTH="70"
HEIGHT="5"></TD> <TD COLSPAN="3"><IMG
SRC="./images/tick_indent_bot.gif" BORDER="0" WIDTH="70"
HEIGHT="5"></TD> <TD COLSPAN="3"><IMG
SRC="./images/tick_indent_bot.gif" BORDER="0" WIDTH="70"
HEIGHT="5"></TD> <TD COLSPAN="3"><IMG
SRC="./images/tick_indent_bot.gif" BORDER="0" WIDTH="70"
HEIGHT="5"></TD> <TD COLSPAN="3"><IMG
SRC="./images/tick_indent_bot.gif" BORDER="0" WIDTH="70"
HEIGHT="5"></TD> <TD COLSPAN="3"><IMG
SRC="./images/tick_indent_bot.gif" BORDER="0" WIDTH="70"
HEIGHT="5"></TD> <TD COLSPAN="2"><IMG
SRC="./images/tick_indent_bot.gif" BORDER="0" WIDTH="46"
HEIGHT="5"></TD> </TR> <TR> <TD COLSPAN="3"
STYLE=`text-align:left` BGCOLOR="#336699" NOWRAP><A
HREF="tl_wk-4.htm" TITLE="Placebo Run-In Visit 1"> Week
–4</A></TD> <TD COLSPAN="3" BGCOLOR="#336699"
NOWRAP><A HREF="tl_wk-2.htm" TITLE="Placebo Run-In Visit
2">Week –2</A></TD> <TD COLSPAN="3"
BGCOLOR="#336699" NOWRAP><A HREF="tl_wk0.htm" TITLE="Baseline
Visit">Week 0</A></TD> <TD COLSPAN="3"
BGCOLOR="#336699" NOWRAP><A HREF="tl_wk1.htm"
TITLE="Treatment Visit 1">Week 1</A></TD> <TD
COLSPAN="3" CLASS="tdselect" BGCOLOR="#336699" TITLE="Treatment
Visit 2" NOWRAP>Week 2</TD> <TD COLSPAN="3"
BGCOLOR="#336699" NOWRAP><A HREF="tl_wk4.htm"
TITLE="Treatment Visit 3">Week 4</A></TD> <TD
COLSPAN="3" BGCOLOR="#336699" NOWRAP><A HREF="tl_wk5.htm"
TITLE="Treatment Visit 4 (Optional)">Week 5</A></TD>
<TD COLSPAN="3" STYLE=`text-align:right` BGCOLOR="#336699"
NOWRAP><A HREF="tl_wk8.htm" TITLE="Final Visit">Week
8</A></TD> </TR> </TABLE> </BODY>
</HTML>
[0173] Note in addition that certain table entries have anchors,
denoted by the <A></A> element pair. An HREF
specification within an <A> element specifies the source of a
document of image file. Those parts of the control corresponding to
table entries having anchors with HREF specifications will cause a
message to be sent to the server when a user clicks in the entry
area, requesting the specified document. The server processes that
request, returning pertinent information about the selected week in
the form, and at the same time, resending the table with the
references to the image files reordered so that the control will
appear with the user's selection selected and with a form
appropriate for a particular visit. Thus the control appears to
work as the user would normally expect, yet all of the work is done
at the server. In addition, none (or at most one) of the bitmaps
need to be downloaded because they have already been used and
should be cached at the browser. Thus the transmission from server
to client will not be hampered by a need to download many
bitmaps.
[0174] Without the present invention, it is necessary to download
from the server a very large bitmap comprising the entire control
in a particular state, say with the first tab selected. For each
state having a different tab selected, a separate, large bitmap of
the entire tab control must be sent from the server if not already
cached, and when these large bitmaps are cached, each consumes a
very large amount of available cache memory.
[0175] FIG. 11D illustrates a variation of the time-line control
490 in which the time-line is further subdivided with small ticks
491 which do not have their own associated labels, yet each is
associated with a different copy of a bitmap and a HREF. For
example, the ticks 491 may represent weeks within a month. Because
each tick 491 has its own bitmap, the user can click on one to move
the pointer 492 to a particular week.
[0176] Finally, in a further embodiment of the present invention,
an individual bitmap may itself be sectioned, each section being
mapped to a different indicator or URL, or no URL at all. For
example, the file tab HTML code above uses HTML tags
<USEMAP>, <MAP> and <AREA> to specify two
different URLs corresponding to the left tab and right tab within
the tab_off_r bitmap. That part of the bitmap not corresponding to
any tab is not mapped to an URL.
[0177] Protocol-Version Dependent Forms
[0178] For various reasons, it is common during a trial for the
protocol to undergo changes. Related forms must be changed to fit
the new protocol when this happens. However, data entered before
the change, i.e. in the old protocol, must be presented in a form
corresponding to the old protocol under which it was entered.
[0179] In addition, as stated earlier, a protocol change may need
to be reviewed by an Institutional Review Board at each site before
it can be implemented. This can result in there being two or more
active protocols at the same time. Again, the data must be
presented in the form corresponding to the protocol in which the
data was entered.
[0180] FIG. 12A is a flowchart illustrating the process at the
server in deciding how to deliver a form to the browser depending
on the study protocol version control. At block 601, a request is
received from a client. The server determines what the correct
study protocol version should be for the request based on date and
time by looking up the protocol version of the CRF when data was
first entered in the CRF. At block 605, the server determines
whether the necessary form (CRF) already exists. If so the form is
loaded and populated with the correct data (block 607). Otherwise,
the form is created (block 609). Finally, in block 611, the correct
populated form is returned to the requesting client.
[0181] FIGS. 12B and 12C illustrate a CRF as it might appear in a
first protocol (ref. 620 in FIG. 12B) and as it might appear in a
second protocol (ref. 622 in FIG. 12C). In FIG. 12B, the CRF 620
has three items 621, 623, 625. Perhaps at the beginning of the
trial, it was established that blood pressure would be measured
twice and entered into items 623 and 625.
[0182] At some point during the trial, it is decided to change the
protocol so that blood pressure is to be measured three times. The
CRF would then appear as in ref. 622 in FIG. 12C, having an
additional item 627 corresponding to the new third measurement.
[0183] Of course, for visits occurring prior to the protocol
version change, there would only be two blood pressure measurements
on file, and so the CRF as portrayed in FIG. 12B (ref. 620) is
retrieved and displayed when a user examines those visits.
[0184] Integrated Help
[0185] In prior art applications, help is often available in the
form of a help button, or a help link. Typically, the user clicks
on the help button or link, and a general help page, often
accompanied with a table of contents and/or a topic index, is
retrieved from the server and displayed, replacing the original
page. To find help, the user must search through the table of
contents or the index, sometimes through several layers. To return
to the original page, the user must either go back by clicking on a
"Back" button in the browser, or optionally by clicking on a "Back
to Document"--type link or button that is typically available on
the help page. Several steps are thus required to obtain help about
a specific topic and then return to the original page for which
help was needed.
[0186] An innovative aspect of the present invention is the use of
context sensitive help in a Web document. As seen in FIG. 13A, the
text of each question comprises a link to one of several
trial-related documents. For instance, the text 801 "Height" for
item 4 is such a link. When the user clicks on the text 801, a
separate help window 803 pops open, as in FIG. 13B, and context
sensitive help 804 is transferred from the server and displayed in
the help window 803. This context sensitive help 804 has
information specific to the text 801 clicked on--here there are
specific instructions as to how to measure height, e.g. shoes off.
Thus the user does not have to look for the subject in an index or
table of contents, and the original page is still available--the
user can close the help window at any time and the original page
has not been affected.
[0187] Preferably, help comes from one of three standard sources
defining the clinical trial: a protocol document, an investigative
brochure, or a study guide. Note that the help window 803 comprises
additional button controls 805 which enable the user to go directly
to related information in any of the three documents.
[0188] In addition, a help button 807 is always available in the
main panel 251A. Clicking on this button 807 brings up a general
help window 809, from which a user can browse through a table of
contents 810 or an index 811 for the clinical trial documents.
Again, additional buttons 805 allow the user to choose a specific
document. FIGS. 13E and 13F show sample help screens for the
protocol document 811 and study guide 812 respectively.
[0189] Equivalents
[0190] While this invention has been particularly shown and
described with references to preferred embodiments thereof, it will
be understood by those skilled in the art that various changes in
form and details may be made therein without departing from the
spirit and scope of the invention as defined by the appended
claims. Those skilled in the art will recognize or be able to
ascertain using no more than routine experimentation, many
equivalents to the specific embodiments of the invention described
specifically herein. Such equivalents are intended to be
encompassed in the scope of the claims.
* * * * *