SDTM, ADaM, and TFL in 2 days

Astraea is software for clinical data and biometrics teams. It connects study inputs, SDTM mapping, ADaM derivations, tables, listings, figures, and review in one workflow. Your team reviews the specifications and accepts the outputs.

Astraea provides software that your team operates alongside its existing study systems and service providers. You can use it with an internal programming team or a CRO; it does not take over their study responsibilities.

Yes. Start with the workflow you need, such as SDTM mapping or data visualization. The evaluation and proposal define the modules, deliverables, and integrations included, so you can assess a focused use case before expanding.

Typical inputs include study data, the protocol, eCRF or annotated CRF, and the statistical analysis plan. ADaM and TFL work also uses reviewed SDTM data, specifications, and output shells where available. Include transfer specifications for external data and any sponsor conventions the workflow should follow.

Yes. Prior specifications, study conventions, and TFL templates can be included as study context. Your team reviews how they are applied to the new study. Existing ADaM specifications can also be supplied rather than generated from scratch.

Astraea proposes SDTM domains and source-to-target mappings, then generates specifications and transformation programs. For ADaM, it uses SDTM and the analysis documents to propose derivations or work from an existing specification. Reviewers resolve study-specific questions before approving the results.

No. Astraea can generate ADaM specifications from your SDTM data, SAP, protocol, and TFL shells. Your team can then review and edit them before approval. If you already have specifications, you can upload those too.

Yes. The workflows support R and SAS programs. SAS execution connects to your licensed SAS environment; it is not a substitute for a SAS license. The execution environment and required packages are agreed during technical setup.

Supply your existing TFL shells, formatting conventions, and reference figures or code. Astraea can use these to configure outputs, and your team can review and refine the result. Confirm required footnotes, file formats, and delivery conventions in the pilot.

Yes. The visualization workflow can work from raw study data as well as standardized or analysis datasets. Teams can review patient profiles, safety data, and study trends, then ask follow-up questions with the relevant data and code available for inspection.

No. Your statisticians and programmers review analysis intent, mappings, derivations, and outputs. Astraea supports execution, while qualified reviewers make study-specific decisions and approve the work.

The workflow flags the gap or unresolved interpretation for review. Your team supplies the missing context or documents the decision before accepting the affected mapping or output. A missing value should not be silently replaced with an invented result.

Yes. Reviewers can inspect the specification, generated program, source references, and available change history behind a result. TFL outputs can be traced to their generating code, so a reviewer can investigate the calculation and its study context.

No. Conformance checks and independent QC answer different questions. Astraea surfaces Pinnacle 21 findings, while your team still checks source-to-target accuracy, clinical meaning, and analysis rules. Keep the agreed study QC process and compare pilot outputs with known results.

No. In the demonstrated review workflow, issues are surfaced for review and data management approves escalation before an issue becomes an EDC query. EDC write-back is a separate integration to scope with your team.

Astraea puts study documents, standards, specifications, generated programs, conformance findings, and review history into a connected workflow. The specification guides downstream generation, and study-specific decisions stay visible for review. Evaluate the resulting deliverables against your own study requirements.

Astraea can be deployed in the client environment. Technical evaluation establishes the hosting setup, network boundaries, access controls, and operational responsibilities. Cloud, on-premise, and pilot arrangements are scoped with your IT team.

That depends on the approved deployment and model configuration. Technical review should document which schemas, documents, or prompts reach a model provider, and which data stays within your environment. Client-owned API keys, provider retention terms, and self-hosted model options are part of that discussion.

Clinical data is not used to train shared models. The deployment must use the agreed data-handling controls and model-provider terms. Your security review should confirm retention, access, and any external service configuration before study data is processed.

Yes. SSO and role-based access can be configured during setup, with permissions scoped to users, roles, and studies. Your team defines who can review, edit, and approve work as part of the deployment.

Choose a representative study or workflow with known outputs. Agree the inputs, deliverables, acceptance criteria, and review responsibilities, then compare Astraea's outputs with the reference results. Involve IT and QA early so infrastructure and qualification requirements are addressed before testing.

Timing depends on infrastructure approvals, the selected workflow, and how much sponsor-specific configuration is needed. Historical specifications and templates help establish your conventions. Agree the deployment milestones and pilot schedule after reviewing those inputs with the team.

Pricing is scoped around the modules, study workload, deployment, and support required. Per-study and broader license arrangements have been discussed for different needs. Request a proposal for your intended scope, including pilot terms and what is included.