Computerized Systems

Keep the technical stack visible

flowchart LR
    Unknown[Untracked platforms] --> CS[Computerized system record]
    CS --> Identity[System identity]
    CS --> DataFlow[Data flow]
    CS --> Connections[Data-exchange connections]
    CS --> Trials[Trial links]

Teams rarely fail because they lack software. They fail because the software landscape is invisible, so no one can tell which systems participate in a trial, what direction data flows, or whether a new integration will break a validated workflow.

A computerized system record gives the team one governed place to answer questions such as:

• what is this system and what category does it belong to
• which vendor or organization provides it
• does data flow inbound, outbound, bidirectional, or not at all
• what integration connections exist and how are they secured
• which trials depend on this system

That matters because validation, monitoring, and traceability decisions all depend on knowing the technical stack.

Describe the system and the exchange

flowchart LR
    CS[Computerized system] --> Trials[Trials]
    CS --> Media[Media]

TrialStack treats computerized systems as governed records because system changes can affect monitoring, validation, and operational traceability. The page keeps both identity and integration detail visible so reviewers can assess what the system does and how it participates.

Use it when the system matters operationally

flowchart LR
    CS[Computerized system] --> Describe[Describe the system]
    CS --> Classify[Classify data flow]
    CS --> Connect[Document integrations]
    CS --> Review[Review connections]

Track a computerized system when the team needs ongoing visibility into:

• what the system does and who provides it
• how data moves through it — inbound, outbound, or bidirectional
• what authentication and encryption methods protect each integration
• which trials or assets depend on this system

On the page

The computerized system page has two main sections: system details and data-exchange connections.

Surface	Purpose	What users do there
Details	Define the system identity and category	Capture title, category, vendor, data-flow direction, description
Connections	Document data-exchange integrations	Add connection rows with type, authentication, encryption, rationale
Relationship tabs	Show where the system matters	Review linked trials and media

classDiagram
    class ComputerizedSystemPage {
        +Summary
        +RelationshipTabs
    }

    class Summary {
        +Details
        +Connections
    }

    class RelationshipTabs {
        +Trials
        +Media
    }

    ComputerizedSystemPage *-- Summary
    ComputerizedSystemPage *-- RelationshipTabs

What to capture

mindmap
  root((Strong system records))
    Clear system identity
    Meaningful category
    Known vendor
    Data-flow direction
    Documented connections
    Secured integrations

A strong computerized system record is not just a name in a list. It makes clear what the system does, who provides it, and how data moves through it.

Good system records usually do three things well:

• they describe the system clearly with title, category, and description
• they identify the vendor or provider and the direction of data flow
• they document each data-exchange connection with security and rationale

Only Title is required. The point is to build up operational context incrementally as integration patterns emerge.

Details

mindmap
  root((Details))
    Title
    Category
    Vendor
    Data flow
    Description

This section captures what the system is and how data moves through it.

Label	Description	Type
Title	Display name for the computerized system	Text
Category	System classification such as EDC, CTMS, IRT, ePRO, or other	Select
Vendor	Organization that provides the system	Select (organization lookup)
Data Flow	Direction of data exchange — inbound, outbound, bidirectional, or none	Select
Description	Plain-language explanation of what the system does and why it matters	Rich text

Connections

mindmap
  root((Connections))
    Name
    Connection type
    Auth method
    Encryption
    Rationale

This section holds an array-table of data-exchange connections. Each row describes one integration channel.

Label	Description	Type
Name	Display name for the connection	Text
Connection Type	Protocol or integration type — API, sFTP, database link, manual, or other	Select (badge)
Authentication Method	How the connection authenticates — OAuth, API key, certificate, or other	Select (badge)
Data Encryption Method	How data is protected in transit — TLS, SSH, VPN, or other	Select (badge)
Rationale	Why this connection exists and what data it carries	Rich text

Connection type, authentication method, and data encryption method are required for each row so that security posture is always visible.