Workflow and access
The exam lifecycle within Laudos.AI, authentication, access roles and the per-institution segregation model.
RESOURCES · DOCUMENTATION
Technical documentation
The reference for the platform and the RadCommons API. Full access is granted to teams in evaluation or deployment.
OVERVIEW
What the documentation covers
HL7, DICOM and worklist
Supported messages, expected fields, the return path of the signed report and dedicated integration scenarios.
The corpus via API
Lookup by clinical term, responses with cited and versioned criteria, key-based authentication and usage limits.
For IT and DPO
Architecture, encryption, subprocessors, data flow and the rationale for compliance with the LGPD and CFM 2.454/2026.
EXAMPLE · RADCOMMONS API
GET /v1/sistemas/ti-rads?versao=vigente
Authorization: Bearer <your-key>
{
"sistema": "ACR TI-RADS",
"versao": "2017",
"vigente": true,
"categorias": [
{ "nivel": "TR1", "criterio": "0 pontos", "conduta": "sem PAAF" },
{ "nivel": "TR5", "criterio": "7+ pontos", "conduta": "PAAF se >= 1,0 cm" }
],
"fonte": { "citacao": "Tessler FN et al. J Am Coll Radiol 2017",
"localizador": "doi:10.1016/j.jacr.2017.01.046" }
}
Structured, cited and versioned response. The full API documentation lives at radcommons.laudos.ai.
Access
- EVALUATIONTeams in evaluation receive the full documentation with the proposal
- DEPLOYMENTSandbox and credentials are part of the integration plan
- RADCOMMONSPublic API documentation on the radcommons.laudos.ai subdomain
- REQUESToi@laudos.ai, subject "Documentation access"
FAQ
Direct questions
Why isn't the full documentation public?
Because half of it describes integrations and configurations specific to hospital environments. What is truly public (the corpus and the benchmark) is open on the subdomains.
Is there a sandbox for testing?
Yes, during the deployment or technical evaluation phase. IT receives credentials and an environment with sample data.
Documentation to implement, not to memorize
What a technical evaluation needs to receive
The platform documentation describes authentication, roles, per-institution segregation and the exam lifecycle. The integration documentation details the inbound and return path, messages, fields and environments applicable to the project. The security documentation presents the data flow, encryption, retention and subprocessors relevant to due diligence.
The public part explains the model and makes it possible to prepare questions. The team releases credentials, environment endpoints and specific integration conditions within an identified evaluation, because these details reveal operational architecture. This limit protects the platform, but it cannot prevent the institution from obtaining the information it needs before approving use.
From reading to sandbox
The path has five steps. Define the flow to evaluate. Receive the corresponding reference. Align authentication and test data. Run success and failure cases. Record the acceptance criteria.
Technical access without a use case produces a collection of endpoints; documentation tied to the workflow produces an integration decision.
The minimum tests are not just the happy path. They include an incomplete order, duplicates, an invalid credential, temporary unavailability, resending and result reconciliation. The expected behavior for each failure must be recorded before production, along with the owner of the fix and the escalation channel.
Four readings, four owners
Product and clinical leadership need to understand authorship, review and template governance. IT needs to map identity, events, messages, monitoring and contingency. The DPO needs to locate each piece of data, purpose, retention and subprocessor. Operations needs to know how to open an incident and how to keep the shift running when a dependency fails. The documentation is only complete when each owner finds the answer they need without relying on a meeting held from memory.
NEXT STEP
Technical team evaluating the platform?
The full documentation and the sandbox come into the deployment conversation.