| Oracle® Clinical Application Programming Interface Guide Release 5.1 E53565-02 |
|
|
PDF · Mobi · ePub |
| Oracle® Clinical Application Programming Interface Guide Release 5.1 E53565-02 |
|
|
PDF · Mobi · ePub |
The term API, or Application Programming Interface, refers to the mechanisms that form a software interface to link an application program to the services and functions of another application, operating system, network operating system, driver, or software program.
The Data Capture API (DCAPI) provides API functions to update data in Oracle Clinical. In addition to the API, Oracle Clinical provides a stable interface for programmers. The combination of the Data Capture API and the stable interface provides the tools to integrate Oracle Clinical with other systems. For information about the stable interface contact Support or see the Oracle Clinical Stable Interface Technical Reference Manual.
The API can be used with programs that you develop with Oracle Pro*C and Microsoft Visual C++. See the requirements section of the Oracle Clinical Installation Guide for the supported version Oracle Pro*C and Microsoft Visual C++. The following files are provided to use in your development, and are available on the Oracle Clinical Web Server in the opa_home/oc/dcapi folder. Please note that DCAPI binaries are compiled for 64-bit. This means that the bin folder contains all the 64-bit libraries and calling application need to be in 64-bit.
dcapi.h: Include this header file in your C files and set the header file path in your Microsoft Visual C++ project definition to the directory that contains dcapi.h.
dcapi.lib: Include this library file in the list of files used to link your program and set the library path of your Microsoft Visual C++ project definition to the directory that contains dcapi.lib.
dcapi.dll: Include this file in your system path during runtime.
The Oracle Clinical Installer automatically loads the DCAPI files onto the Oracle Clinical Web Server during the Front End installation. The DCAPI files are available in the oracle_home/oc/dcapi folder, and are required by Oracle Clinical. To link to these files in a different location, copy the DCAPI files to that location instead of moving them.
To build an application using DCAPI, the C++ compiler must know where the header and library files are, and what libraries to link against. The following section describes how to do this in Visual Studio 2010.
To use the header file and library file in your Microsoft Visual C++ projects, within Visual Studio, right click on your project in the Solution Explorer and bring up the project's Properties dialog. You need to change the settings for both Debug and Release versions, so under the Configuration field, select ”All Configurations”. The following example shows how to do so in Microsoft Visual C++ 10.0; the steps may differ if you use another version.
Select the C/C++ category of properties, and pick the General options under that. In the Additional Include Directories property, add the semicolon-separated directory where dcapi.h is available
To change the settings for both Debug and Release versions, go to the Properties dialog under the Configuration field and select All Configurations.
Select the Linker category of properties then pick the Input option. In the Additional Dependencies property, add the DCAPI library dcapi.lib.
OPA provides a selection of sample programs that illustrate the use of DCAPI functions in the following tasks for a document:
Initial Log-in
Key Changes
First-pass data entry
Update
Browse
Soft Delete
This document is available on My Oracle Support. Search for article ID 315201.1 and click the dcapi_samples.pc link from that note; see "Finding Information on My Oracle Support".
Many DCAPI functions use two new data elements that provide auditing information: the audit change reason and a reason for the change. These data elements are part of the new AuditInfo structure, which is a direct parameter for the DCAPI functions SetResponseData, SetDataComment, and DeleteRepeat and an indirect parameter for the functions SetRdci and SetRdcm.
AuditInfo is also a new component of other existing data structures in the DCAPI, adding audit capabilities to these structures. All DCAPI functions that use these structures are affected by the change.
RdciKeysRecord: The external system will use AuditInfo to provide the audit change reason and an optional comment, in addition to the new set of keys or comment definition, in the RdciKeysRecord. The RdciKeysRecord structure will also include another boolean called audit_only_flag to indicate whether only an audit reason and no key or comment changes is provided. If an audit reason is required and it is not provided and the system is unable to derive or default one, the API call will fail. This change affects the DCAPI functions CreateRdci and SetRdci.
RdciRecord: The external system uses AuditInfo to retrieve the audit reason and comment (if any) provided earlier during an RDCI key or comment change or a soft delete, in addition to the full set of RDCI elements, in the RdciRecord. Adding AuditInfo to this structure affects the functions CreateRdci, GetRdci, ProcessRdci, SetRdci and FetchRdci.
RdcmKeysRecord: This structure will be updated to include the AuditInfo structure. AuditInfo is the structure that the external system will use to provide audit reason and an optional comment, in addition to the new set of keys or comment definition, in the RdciKeysRecord. If an audit reason is required and it is not provided, and the system is unable to derive or default one, the API call will fail. This change affects the SetRdcm function.
RdcmRecord: This structure will be updated to include the AuditInfo structure. This is the structure that the external system will use to retrieve the audit reason and comment (if any) provided earlier during an RDCM key or comment change, in addition to the full set of RDCM elements, in the RdcmRecord. This change affects the functions GetRdcm and SetRdcm.
RepeatId: This structure will be updated to include the AuditInfo structure. The boolean needs_audit will be set to TRUE to indicate if a audit reason is needed and is missing. The external system uses this structure to provide the audit reason and an optional comment when deleting a repeat.
DataComment: This structure will be updated to include the AuditInfo structure. The external system uses AuditInfo to provide the audit reason and an optional comment, in addition to the investigator comment definition, in the DataComment. This change affects the following DCAPI functions: CreateRdci, SetRdci, GetRdci, FetchRdci, ProcessRdci, SetRdcm, GetRdcm, DeleteRepeat and SetDataComment.
The values to these new parameters will be initialized to NULL and will be cleared upon saving of a transaction.
DCAPI functions require an audit change reason each time you make a change to a document. To enable backward compatibility with programs you have written to interface with earlier Oracle Clinical releases, this release includes two new reference codelists that you can supply with default values for the audit change reason.
To enable backward compatibility for pre-4.5 interfacing programs, perform these steps:
Re-compile and re-link your existing interfacing programs with the Release 4.5 version of the header file (dcapi.h) and library file (dcapi.lib).
Populate the new reference codelists with the default values you want to use for the audit change reason. You can Because the audit change reason supplied depends on the change you make, you can provide separate default values for:
To find the default audit reason for Header changes (RDCI or RDCM Key change, RDCI or RDCM Comment change and when Soft-Deleting a document), the system refers to the reference code list 'RDCI CHANGE REASON TYPE CODE' as the primary and to 'RDCI CHANGE REASON2 TYPE CODE' as the secondary reference codelist. The system attempts to find a default audit reason by looking for "DCAPI" as a comma-separated string in the long value of either one of the reference codelists.
To find a default audit reason for Investigator Comment changes (a change to responses), the system refers to the reference code list 'DATA CHANGE REASON TYPE CODE' as the primary and to 'DATA CHANGE REASON2 TYPE CODE' as the secondary reference codelist. The system attempts to find a default audit reason by looking for ”DCAPIINV” in the long value of either one of the reference codelists.
To find a default audit reason for Delete Repeat (a change to responses), the system refers to the reference code list 'DATA CHANGE REASON TYPE CODE' as the primary and to 'DATA CHANGE REASON2 TYPE CODE' as the secondary reference codelist. The system attempts to find a default audit reason by looking for "DCAPIDEL" in the long value of the either one of the reference codelists.
This documentation provides information about the syntax and functionality of the API functions for creating or updating the following information in Oracle Clinical:
received DCI and DCM Log-In information
actual events
patient enrollment
data responses
data discrepancies
comment information
This chapter is an introduction to Chapter 7, which describes the functions themselves.
Review the following rules before you begin to develop your application. Instructions are written for someone with a working knowledge of Microsoft Visual C++ 6.0.
The documentation includes several references to the term accessible documents. Every Oracle Clinical study has properties indicating if first and second pass Data Entry are necessary. A RDCI is considered accessible when any of its RDCMs become accessible.
An RDCM is considered accessible if it meets any of the following criteria:
The RDCM was batch loaded
Pass 1 has been completed for the RDCM and Pass 2 is not required
Pass 2 is required for the RDCM and has been completed
All date, time and date-time arguments to the API function calls are of type character array. This information is translated to Oracle dates internally by the API functions, so to remove ambiguity during translation, the dates, times, and date-times must be input in the following formats: YYYYMMDD, HH24MISS, and YYYYMMDDHH24MISS. The hours, HH, are specified in military time (values from 00 to 23 inclusively). These formats are referred to as the API date, time, and date-time formats respectively.
API functions will return a SUCCESS, FAILURE, or WARNING, defined as "short int" in the header file (SUCCESS = 0, FAILURE = 1, WARNING = 2). In the case of FAILURE or WARNING, the external application can use the GetError API function to get the message ID, text, and type from the error message stack. The external application can also use GetErrorStackSize to assess the depth of the stack and then call GetError repeatedly until no errors remain. If GetError returns SUCCESS your application should process the errors. For a complete list of error messages, see Appendix A, "Error Messages". If GetError returns the message ID -1, an internal Oracle Clinical error has occurred.
Warning:
An internal Oracle Clinical error can corrupt data. If you encounter this kind of error, immediately roll back your data. The external application should continue retrieving the errors and ignoring them until the error stack is empty.
Your application should put -1 in numeric (double, short, int) fields to indicate a null value to Oracle Clinical. Similarly, Oracle Clinical returns -1 for these fields to indicate a null value in the database. The Visit Number field can have a valid negative value. If the visit number has a value of -1, your application must check for a visit name. When the visit name is null and the visit number is -1, the visit number is null in the database as well.
The API functions described manage allocation and deallocation of memory for the internal data structures they use. Your application must manage allocation and deallocation of memory for arguments to API calls that accept pointers to variables. For example, in a call to GetRdci, your program must allocate the memory for the argument of type RdciRecord.
InitializeRdcmResponses handles memory allocation. If you attempt to set or get response values for a question in a particular repeat in a question group without creating a repeat first, you receive an error message.
For a document with existing responses, InitializeRdcmResponses allocates memory to hold response values for all questions in all existing repeats in all question groups in the RDCM. The user can then retrieve or set values for these responses. However, for repeating groups, if the user wants to retrieve or set the response of a new repeat that does not exist in the database, the user must begin by inserting a repeat.
For repeating groups with n > 1 repeats, InsertRepeat needs to be called. This function allocates memory to hold response values for all questions in the i-th repeat for the group (where 1 < i <= n).
It is not necessary to enter response values immediately after inserting the repeat; the user of the API functions can first insert the necessary repeats in all question groups and then set the values for the responses. However, response values for at least one question should be entered for all inserted repeats in all question groups, otherwise WriteResponses will return FAILURE.
To delete an existing repeat, use the DeleteRepeat call. This does not free the memory allocated for holding the responses in the API Responses buffer; it simply marks the corresponding responses as deleted. They will be processed at commit time and marked accordingly in the database. The deleted repeats are archived in the database. Users can run either an Oracle Clinical audit report or their own audit report to view the deleted repeats.
Before you can use the ExecuteMultivariate function, Validation and Derivation Procedures must be categorized in Oracle Clinical. This step lets the function, ExecuteMultivariate identify the Procedures to execute in different circumstances.
Procedures are classified by the Execution Context attribute. A field for the attribute is displayed in the Oracle Clinical Procedures forms. Although this attribute can be entered for both pre-V3.1- and V3.1-style Procedures, only V3.1-style Procedures can be called by ExecuteMultivariate. The Execution Context does not affect batch validation processing.
This attribute's value should be chosen based on the Procedure's purpose and its usefulness in raising multivariate discrepancies for timely feedback during data entry. While the value defaults to OFF-LINE, V3.1-style Procedures can change it to either ON-LINE/DCM or ON-LINE.
These sections describe the values for the Execution Context attribute. An API-only argument, SINGLE, is also described because it affects Procedure classification.
Procedures should be classified as ON-LINE/DCM when they are suitable for DCM-targeted types of validation to be invoked— for instance, at the completion of data entry for a given patient's DCM. Procedures with aggregate-only question groups, which have no primary reference DCM, cannot be classified as ON-LINE/DCM.
Calling ExecuteMultivariate with an ON-LINE/DCM Execution Context causes a specific DCM to be supplied in the API call. Procedures are then targeted for execution on the basis of a match on:
Execution Context
The Procedure primary reference question group DCM
Note:
When ExecuteMultivariate is called with an ON-LINE Execution Context, Procedures classified as ON-LINE/DCM are automatically executed, regardless of their primary reference question group DCM.An ON-LINE classification indicates the Procedure is suited to being invoked after a larger unit of work (two or more DCMs) is completed for the patient — regardless of the Procedure primary reference question group DCM. Procedures classified as ON-LINE or ON-LINE/DCM are automatically executed when ExecuteMultivariate is called with an ON-LINE Execution Context.
Procedures classified as OFF-LINE (the default) are not executed when the API Execution Context argument is either ON-LINE or ON-LINE/DCM. They are typically appropriate for the following circumstances:
batch processing
execution in batch validation
execution via the Execute Single Procedure menu option
An API-only argument, SINGLE, signifies that a specific Procedure is to be executed; the Procedure ID and version are supplied as API arguments in this case. When ExecuteMultivariate is called with the Execution Context of SINGLE, the match on Procedure classification is bypassed and the requested Procedure executed.
Procedures can have dependencies, such as using the results of derivation for subsequent validation. The Procedure Definition form enforces the restriction that a Procedure can only be flagged for a particular Execution Context if all Procedures upon which it is dependent are also in the same context or in a "lesser" context. This means that "related" Procedures must be guaranteed to execute in tandem.
The following tables shows, for six sample Procedures, whether the Procedure will be selected for execution in each context.
| Procedure Definition | Procedure Execution — On-Line Processing API Execution Context | Procedure Execution — On-Line Processing API Execution Context | Procedure Execution — On-Line Processing API Execution Context | Procedure Execution — Off-Line Processing | Procedure Execution — Off-Line Processing |
|---|---|---|---|---|---|
| ON-LINE/ DCM DEMOG |
ON-LINE | Single Procedure B |
Batch Validation |
Execute Single Procedure B |
|
| Proc: A,
Primary Ref DCM: DEMOG, Execution Context: ON-LINE/DCM |
Selected | Selected | Not selected | Selected | Not selected |
| Proc: B,
Primary Ref DCM: DCM48, Execution Context: ON-LINE/ |
Not selected | Selected | Selected | Selected | Selected |
| Proc: C,
Primary Ref DCM: DCM48, Execution Context: OFF-LINE/ |
Not selected | Not selected | Not selected | Selected | Not selected |
| Proc: D,
Primary Ref DCM: DEMOG, Execution Context: ON-LINE/DCM |
Selected | Selected | Not selected | Selected | Not selected |
| Proc: E,
Primary Ref DCM: VITAL_SIGNS, Execution Context: OFF-LINE |
Not selected | Not selected | Not selected | Selected | Not selected |
| Proc: F ,
Primary Ref DCM: VITAL_SIGNS, Execution Context: ON-LINE |
Not selected | Selected | Not selected | Selected | Not selected |
For instance, if Procedure X uses derived values from Procedure Y the possible classification combinations between the two Procedures are shown below.
| Validation Procedure X Definition | |||
|---|---|---|---|
| Derivation Procedure Y Definition | ON-LINE/ DCM |
ON-LINE | OFF-LINE |
| on-line/DCM | Selected | Selected | Selected |
| on-line | Not selected | Selected | Selected |
| off-line | Not selected | Not selected | Selected |
Oracle Clinical provides a mechanism for controlling the tasks that certain users can perform. Each user with access to Oracle Clinical is given a set of roles that ensures that only certain tasks can be performed by that user. A user's assigned roles are the same for each clinical study to which he or she has access.
The Data Capture API provides similar security mechanisms for assigning roles to users to determine the tasks they can perform. This assignment is also accomplished through database roles. The roles necessary to perform tasks through the API are different from the roles in Oracle Clinical. Therefore, a particular user may be granted permission to perform data entry through an application built with the API but not through the Oracle Clinical client, or vice versa.
The following list shows the names of the database roles and what each role is called in Oracle Clinical user materials.
| Database Role Name | OC Manual Name |
|---|---|
| OCLAPI_INITIAL_LOGIN | Initial Log-In |
| OCLAPI_KEY_CHANGES | Key Changes |
| OCLAPI_FIRST_PASS_ENTRY | First-Pass Entry |
| OCLAPI_UPDATE | Update |
| OCLAPI_BROWSE | Browse |
| OCLAPI_PATIENT_ENROLLMENT | Patient Enrollment |
| OCLAPI_EXECUTE_MULTIVARIATE | Execute Multivariate |
This section shows which of the database roles for the Data Capture API a user must have to act on production data. The column headers indicate different DCAPI roles. The rows indicate different DCAPI calls under different conditions. An ”X” in a column signifies that the call in the selected row requires one of the roles indicated. Privileges are cumulative and require that the user have only one intersecting role/call combination for the call to succeed.
Note:
So that these actions are performed on test data, the letter T is appended to the database role name — for example, OCLAPI_BROWSE becomes OCLAPI_BROWSET.Each role maps to a specific action that you can take within Oracle Clinical. This action is referred to as a mode. There are two types of modes:
Standalone - Patient Enrollment and Multivariate Execution are standalone roles.
Data Entry - Initial Log-In, Key Changes, First-Pass Entry, Update, and Browse are data entry modes.
CreateRdci (INITIAL_LOGIN)
Requires: Initial Log-In only
CreateRdci (KEY_CHANGES)
Requires: Key Changes
FetchRdci (Locking) (INITIAL_LOGIN)
Requires: Initial Log-In for documents that are inaccessible, or accessible documents whose only updateable field is the comment field
FetchRdci (Locking) (KEY_CHANGES)
Requires: Key Changes
FetchRdci (Locking) (FIRST_PASS_ENTRY)
Requires: First-Pass Entry for inaccessible documents only.
FetchRdci (Locking) (UPDATE)
Requires: Update
FetchRdci (Locking) (BROWSE)
Requires: Browse, but only if the operator comment in Browse mode is enabled
FetchRdci (Non-Locking)
Requires: Initial Log-In, Key Changes, First-Pass Entry, Update, and Browse.
Requires: Initial Log-In (Update of the comment fields only), Key Changes, First-Pass Entry (Update of the comment fields and Blank Flag only), and Update (Update of the comment fields only).
Requires: Initial Log-In (Update of the comment fields only), Key Changes, First-Pass Entry (Update of the comment fields and Blank Flag only), and Update (Update of the comment fields only).
Requires: Initial Log-In (Update of the comment fields only), Key Changes, First-Pass Entry (Update of the comment fields and Blank Flag only), and Update (Update of the comment fields only).
Requires: Initial Log-In (Inaccessible documents only)
InitializeRdcmResponses (FIRST_PASS_ENTRY)
Requires: First-Pass Entry
InitializeRdcmResponses (UPDATE)
Requires: Update
InitializeRdcmResponses (BROWSE)
Requires: Browse
Requires: Initial Log-In and Key Changes
Requires: Initial Log-In, Key Changes, First-Pass Entry, and Update
Requires: Patient Enrollment
Requires: Multivariate Validation
The FetchRdci function retrieves data from the Oracle Clinical database. To call FetchRdci, program must know the RDCI_ID in the Oracle Clinical database for the RDCI it wants to fetch. You can obtain this information through the stable interface.
The Data Capture API buffers the RDCI, RDCM, and response data so that your program can pass data to the API and validate it without committing the data to the database. When program is ready to commit the RDCI and RDCM data to the database, it calls WriteRdciRdcm. To commit response data to the database call WriteResponses.
CreateRdci, ProcessRdci, SetRdci, SetRdcm and SetResponseData perform one or more of the following:
validation checks
defaulting of fields
setting of timestamps
Your program should refresh any data structures it created to store RDCI and RDCM information with the modified data structures passed back from these API functions. This keeps the data structures in your program consistent with the API buffered data.
The Data Capture API enforces rules about when you can call an API function. These rules are associated with the state of the data. The API considers the data to be in one of the following states.
This state occurs when the your application is running but not connected to the Oracle Clinical database. The API function ConnectOCL connects you to the Oracle Clinical database. All other Data Capture API functions require a connection to the Oracle Clinical database.
If you call a Data Capture API function, and you are not connected to the database, you receive an error message. Once connected to the Oracle Clinical database, you can disconnect or set study context from any of the remaining four states.
This state occurs immediately after your program connects to the Oracle Clinical database and means that the study for which you are planning to enter data is unknown to the API. The SetStudyContext API function provides this context information. Any of the API functions that attempt to retrieve or set data require the study context and return an error if called in this state. Because SetExternalContext does not affect Oracle Clinical data, it can be called in this state.
In-Study with Empty RDCI/RDCM Buffer
This state occurs when the program has set the study context but has not called any API functions that update RDCI/RDCM data. RDCI/RDCM data must always be entered before response data because responses are associated with RDCMs that belong to RDCIs.
To proceed with entering RDCI/RDCM and responses data, you must either create a new RDCI by calling CreateRdci or fetch an existing RDCI to browse or update by calling FetchRdci. Either of these two functions will switch you into the RDCIRDCMWork state. There are no pending changes to RDCI/RDCM data or responses data in this state, so APIs that commit data to the database — EnrollPatient, SetActualEvent, SetPageStatus, and ExecuteMultivariate — can be called. You can call SetExternalContext from this state as well.
This state occurs when the program is retrieving or updating RDCI/RDCM data; while in this state, you cannot call functions that retrieve or update RDCI/RDCM data. The function SetExternalContext does not commit data or retrieve/update responses data, so it can be called in this state.
Pending changes must be saved to the database, using WriteRdciRdcm; otherwise they must be discarded using FlushRdciRdcm before more response data can be entered. InitializeRdcmResponses then brings you to the ResponsesWork state.
Once all pending changes have been saved or discarded, the program can call EnrollPatient, SetActualEvent, SetPageStatus, and ExecuteMultivariate to commit data. These API functions do not commit data if there are pending changes, because incomplete RDCI/RDCM information would cause data corruption.
This state occurs when your program is retrieving or updating response data. The API functions that update the RDCI/RDCM data cannot be called in this state.
Once all pending changes have been saved (using WriteResponses) or discarded (using FlushResponses), the program can commit data by calling EnrollPatient, SetActualEvent, SetPageStatus, and ExecuteMultivariate. These functions cannot be called if there are pending changes, because the functions would commit incomplete responses information to the Oracle Clinical database which would cause data corruption. The program can return to either the RDCIRDCMWork state or In-Study with Empty RDCIRDCM Buffer state by calling, saving, or discarding any pending changes.
This section describes the functional states in which you can call each of the DCAPI functions. Because ConnectOCL is associated with only one state, the Pre-Connection state, this function is not listed.
Can be called in:
In-Study with Empty RDCI/RDCM Buffer.
RDCI/RDCM Work, but only if there are no changes pending. If an audit comment is required and has not been provided before you call CreateRdci in this state, it returns an error.
Can be called in RDCI/RDCM Work, but only if there are no changes pending. If an audit comment is required and has not been provided before you call DeleteRdci in this state, it returns an error.
Can be called in Responses Work. If an audit comment is required and has not been provided before you call DeleteRepeat in this state, it returns an error.
Can be called in:
Pre-Study
In-Study with Empty RDCI/RDCM Buffer
RDCI/RDCM Work, but only if there are no changes pending
Responses Work, but only if there are no changes pending
Can be called in:
In-Study with Empty RDCI/RDCM Buffer
RDCI/RDCM Work, but only if there are no changes pending. Even if there are no changes pending, EnrollPatient cannot be called in this state if the RDCI was fetched for update until the database lock is released.
Responses Work, but only if there are no changes pending. Even if there are no changes pending, EnrollPatient cannot be called in this state if the RDCI was fetched for update until the database lock is released.
Can be called in:
Pre-Study
In-Study with Empty RDCI/RDCM Buffer
RDCI/RDCM Work, but only if there are no changes pending
Responses Work, but only if there are no changes pending
Can be called in:
In-Study with Empty RDCI/RDCM Buffer
RDCI/RDCM Work, but only if there are no changes pending. If an audit comment is required and has not been provided before you call FetchRdci, the system returns an error.
Can be called in RDCI/RDCM Work
Can be called in Responses Work. If an audit comment is required and has not been provided before you call FlushResponses, the system returns an error.
Can be called in Responses Work. If an audit comment is required and has not been provided before you call GetManualDiscrepancy, the system returns an error.
Can be called in Responses Work. If an audit comment is required and has not been provided before you call GetNumRows, the system returns an error.
Can be called in Responses Work. If an audit comment is required and has not been provided before you call GetQuestGroupId, the system returns an error.
Can be called in Responses Work. If an audit comment is required and has not been provided before you call GetQuestionId, the system returns an error.
Can be called in RDCI/RDCM Work.
Can be called in RDCI/RDCM Work, but only if there are no pending RDCI changes. If pending RDCI changes exist, process them by calling ProcessRdci.
Can be called in RDCI/RDCM Work, but only if there are no pending RDCI changes. If pending RDCI changes exist, process them by calling ProcessRdci.
Can be called in Responses Work. If an audit comment is required and has not been provided before you call GetResponse, the system returns an error.
Can be called in Responses Work. If an audit comment is required and has not been provided before you call GetUnivDiscrepancy, the system returns an error.
Can be called in RDCI/RDCM Work
Can be called in Responses Work. If an audit comment is required and has not been provided before you call InsertRepeat, the system returns an error.
Can be called in RDCI/RDCM Work
Can be called in RDCI/RDCM Work, but only if there are no pending RDCI changes. If pending RDCI changes exist, process them by calling ProcessRdci.
Can be called in:
Pre-Study
In-Study with Empty RDCI/RDCM Buffer
RDCI/RDCM Work, but only if there are no changes pending. Even if there are no changes pending, this API function cannot be called in this state if the RDCI was fetched for update until the database lock is released.
Responses Work, but only if there are no changes pending. Even if there are no changes pending, this API function cannot be called in this state if the RDCI was fetched for update until the database lock is released.
Can be called in Responses Work. If an audit comment is required and has not been provided before you call this API function, the function will return an error.
Can be called in:
Pre-Study
In-Study with Empty RDCI/RDCM Buffer
RDCI/RDCM Work, but only if there are no changes pending.
Can be called from Responses Work. If an audit comment is required and has not been provided before you call this API function, the function will return an error.
Can be called from Responses Work. If an audit comment is required and has not been provided before you call this API function, the function will return an error.
Can be called from:
Pre-Study
In-Study with Empty RDCI/RDCM Buffer
RDCI/RDCM Work, but only if there are no changes pending. Even if there are no changes pending, this API function cannot be called in this state if the RDCI was fetched for update until the database lock is released.
Responses Work, but only if there are no changes pending. Even if there are no changes pending, this API function cannot be called in this state if the RDCI was fetched for update until the database lock is released.
Can be called from RDCI/RDCM Work
Can be called from RDCI/RDCM Work, but only if there are no pending RDCI changes. You can process these pending changes by calling ProcessRdci.
Can be called from Responses Work
Can be called from:
Pre-Study
In-Study with Empty RDCI/RDCM Buffer
RDCI/RDCM Work, but only if there are no changes pending.
Responses Work, but only if there are no changes pending.
Can be called from Responses Work. If an audit comment is required and has not been provided before you call SetUnivDiscrepancy, it returns an error.
Can be called from RDCI/RDCM Work, but only if there are no pending RDCI changes. You can process these pending changes by calling ProcessRdci.
Can be called from Responses Work. If an audit comment is required and has not been provided before you call this API function, the function will return an error.
The following diagram illustrates the required transitions to move from one state to another in the API.
Description of the illustration func_st_trans_diag.gif
* If called with preserve lock, otherwise brings you to In-Study with Empty RDCIRDCM Buffer state.
The majority of the Oracle Clinical data management rules are built into the functionality of the API. Nonetheless, there are a few data management rules that you must be aware of as you design your front-end application; otherwise, you may generate one or more error messages.
Five data entry modes are valid within the API. The following table describes the appropriate document status for each Log-In and Data Entry mode that the API supports.
| Mode | Status |
|---|---|
| Initial Log-In | RECEIVED |
| Key Changes | RECEIVED, P1 STARTED, P1 COMPLETE |
| Update/Browse | P1 STARTED, P1 COMPLETE |
| P1 (First Pass) | RECEIVED, P1 STARTED, P1 COMPLETE only if document is not accessible and the operator is the person who created the document |
Note that the Data Capture API does not support Pass 2. However, in some cases the status does change:
If you update an RDCM in status PASS 2 STARTED or PASS 2 COMPLETE, the document is opened in UPDATE mode and after a save, the status of the document (RDCM and RDCI) remains unchanged.
However, if you update an RDCM in status PASS 2 PENDING, then after a save, the RDCM status changes to PASS 2 COMPLETE. If all RDCMs in the RDCI are PASS 2 COMPLETE, then the RDCI status is also updated to PASS 2 COMPLETE.
|
 Copyright © 1998, 2015, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
