1. REST API for Clinical One Platform
  2. Tasks
  3. Data Integration
  4. Visits Status
  5. Get list of visits status for subjects

v1.0

post

/ec-dataintegration-svc/rest/v1.0/studies/{studyId}/{mode}/visitstatus/subjects

Retrieves a list of visits status for subjects, as well as the study version associated with each visit status. This API request also lists unscheduled event details.

Request

Path Parameters
Query Parameters
  • If true, returns only the next scheduled visit for each subject
    Example:
    false
  • If true, filters for subjects with visits not yet started
    Example:
    false
  • Status of Sign / Verify.Values can be ALL, OPENQUERIES, NOOPENQUERIES, SIGNED, FROZEN, VERIFIED, SIGNEDANDVERIFIED, READYTOSIGN, READYTOVERIFY, LOCKED, UNLOCKED or ALLVISITSCOMPLETE
    Example:
    VERIFIED
  • Unique identifier (UUID, 32-character uppercase hexadecimal string) representing the clinical site.
    Example:
    0C50E26E482246B2BB9646C739E97CAA
  • String representing the version of the study configuration or protocol. Helps track changes in form or study design.
    Example:
    1.0.0.3
Supported Media Types
Request Body - application/json ()
Root Schema : schema
Type: object
Request payload containing a list of subject identifiers.
Show Source
Nested Schema : subjects
Type: array
List of subject identifiers in UUID, 32-character uppercase hexadecimal string
Show Source
Example:
[
    "1BC29B36F5D64B1B95F4BDBBCEA481BE",
    "2ABC8A2C11045A584ADEA8760F72B114"
]
Examples

Back to Top

Response

Supported Media Types

200 Response

Success
Body ()
Root Schema : SubjectVisitsStatusResponse70
Type: object
Show Source
Nested Schema : subjects
Type: array
Show Source
Nested Schema : SubjectVisitsDto70
Type: object
Subject visits and schedule along with current study version and sign/verify/freeze statuses
Show Source
Nested Schema : ScheduledVisitsDto
Type: object
Base scheduled visit details including scheduling windows and identifiers
Show Source
Nested Schema : VisitsStatusDto9
Type: object
Visit status details including associated study version
Show Source
  • Study version with which the visit status is associated
    Example: 3.0.0.1
  • Minimum Length: 0
    Maximum Length: 2048
    Additional comment for the visit status
    Example: All data verified
  • Unique identifier(UUID, 32-character uppercase hexadecimal string) representing the clinical event like Screening, Visit 1 etc.
    Example: ABCDEF1234567890ABCDEF1234567890
  • Numeric value representing the instance number of the event. Used for repeated or unscheduled visits. It is null for scheduled events.
    Example: 1
  • Event type corresponding to the visit. The acceptable values are: Visit_Not_Started, Visit_Started, Visit_Complete, Visit_Skipped, Visit_Skip_Undone, Visit_Date_Changed, Visit_Inserted, Visit_Show, Visit_Hide, VisitDateEntered and VisitDateCleared.
    Example: Visit_Not_Started
  • Frozen status of the record can have values NOT_APPLICABLE, FROZEN.
    Example: FROZEN
  • Unique identifier (UUID, 32-character uppercase hexadecimal string) representing the record
    Example: 1BC29B36F5D64B1B95F4BDBBCEA481BE
  • Minimum Length: 0
    Maximum Length: 255
    Reason associated with the visit status
    Example: Subject completed the visit successfully
  • Number of repeating form instances for the visit.
    Example: 2
  • Scheduled window end date for the visit
    Example: 2025-10-16T14:30:31.892Z
  • Scheduled window start date for the visit
    Example: 2025-10-16T14:30:31.892Z
  • Signed status for workflow, the acceptable values are: NEVER_SIGNED, SIGNED, UNSIGNED, NEVER_SIGNED.
    Example: SIGNED
  • Unique identifier (UUID, 32-character uppercase hexadecimal string) representing the clinical site.
    Example: ABCDEF1234567890ABCDEF1234567890
  • Minimum Length: 0
    Maximum Length: 100
    String representing the version of the study configuration or protocol. Helps track changes in form or study design.
    Example: 3.0.0.1
  • Unique subject identifier (UUID, 32-character uppercase hexadecimal string) representing the patient/participant enrolled in the study.
    Example: ABCDEF1234567890ABCDEF1234567890
  • Verified status for review workflow,the acceptable values are: NEVER_VEIFIED, VERIFIED, UNVERIFIED, NOT_APPLICABLE.
    Example: VERIFIED
  • Start timestamp of the version record
    Example: 2025-10-16T14:30:31.892Z
  • Visit start date timestamp
    Example: 2025-10-16T14:30:31.892Z
  • Status of the visit. The Value of the status can be NEW, COMPLETE, COMPLETE_ERR, INPROGRESS, INCOMPLETE, INCOMPLETE_ERR, SKIPPED, UNDO_SKIP and NOT_STARTED.
    Example: COMPLETE
  • Type of visit as per the visit type enumeration. The acceptable values are: SCREENING, RANDOMIZATION, DISPENSATION, NON_DISPENSATION, OPTIONAL, OPTIONAL_DISPENSATION, WITHDRAW, SCREENDISP, SCREENRAND, SUBJECT_COMPLETE, UNSCHEDULED, UNSCHEDULED_DISPENSATION, ADVERSE_EVENT, SCREENFAILURE, RESCREENING and RESCREENDISP.
    Example: SCREENING
Examples

400 Response

Bad request.
Body ()
Root Schema : RestResponse
Type: object
Show Source
Nested Schema : ErrorResponseData
Type: object
Structure representing an error response from the reporting service. Contains an error code, human-readable message, and details.
Show Source
  • details
    Detailed error context or debugging information such as validation error, stack trace, or field/parameter cause.
  • Application or business-specific error code representing the error type.
    Example: REPT_401
  • Human-readable error message describing the failure or issue.
    Example: Unauthorized: User does not have access to the requested resource
Nested Schema : result
Type: object
Nested Schema : details
Type: object
Detailed error context or debugging information such as validation error, stack trace, or field/parameter cause.
Example:
User role is missing required permission REPORTING_VIEW. Field: userId
Back to Top