Mediforce now orchestrates your Databricks jobs with human-in-the-lead AI workflows, audit trails, and full control, while your clinical data never leaves your own Databricks environment.

Rhino 1.12.0 ships built-in code coverage with covr_r()/covr_report() and AGENTS.md scaffolding that teaches AI coding agents to write correct Rhino code.

Clinical data has two opposite jobs: immutable submission records and fast, flexible exploration. A three-layer S3 architecture with Object Lock, narrow IAM roles, and promotion manifests serves both, with the audit trail as a byproduct.

Running Posit Workbench on Kubernetes gives pharma teams per-session pod isolation, study-specific container images, and immutable 21 CFR Part 11 audit trails. The assurance is architectural, built into the infrastructure itself.

Learn how to use tests to develop Shiny modules efficiently, ensuring faster development cycles and better modularization.

Audit logs are snapshots. Lineage is the chain between them. How to build data lineage into a regulated SCE delivery layer using CloudTrail, a transformation ledger, and OpenTelemetry.

SFTP is the default, but vendors deliver clinical data many ways. Here's how to build a protocol-agnostic data delivery layer that preserves audit trails, immutability, and identity attribution across SFTP, API, direct S3, and managed file transfer.

Beyond "use smaller models" and "write concise prompts" — advanced patterns spanning the entire developer workflow that reduce both time and token costs when working with Claude Code, GitHub Copilot, or Codex.

Why standardising vendor onboarding — path conventions, access isolation, IaC credentialing — is what keeps event-driven ingestion pipelines clean as new CROs and studies get added over time.

Getting clinical data to your SFTP endpoint is the easy part. How the file is handled from the moment it lands is what determines whether the audit trail emerges from the system itself or has to be produced after the fact.

A short field note for teams getting ready to validate a Shiny app for GxP use — the patterns we keep seeing, and what we'd want someone to tell us before we started.

Adding acceptance tests first makes refactoring safer.

SFTP isn't going anywhere in pharma. Vendors expect it, SOPs reference it, switching costs dwarf the benefits. The real work is making the infrastructure around it compliant, automated, and boring enough that nobody has to think about it.

A practical reference to CDISC standards for clinical programming teams. Covers Define-XML structure, ADaM submission requirements, Dataset-JSON, ARS, and how to build define.html from define.xml.

Cloud-native is often discussed as a technical concept, but for pharma SCE leaders it has very practical implications. This article explains what cloud-native means in the context of a Statistical Computing Environment, how technologies like containers, Kubernetes, infrastructure as code, and CI/CD reduce manual work, and why they can make change management faster without weakening compliance. It also outlines key questions to ask when evaluating whether an SCE is built for reproducibility, auditability, and future modernization.

A practical guide for pharma leaders deciding whether to build their statistical computing environment (SCE) on-premise or in the cloud. The piece argues that while on-prem still suits stable, predictable workloads and large legacy datasets, modern SCEs are no longer stable workloads — they need elastic compute, multi-language support, and AI/ML-ready hardware that cloud delivers natively. It addresses the security objection head-on (citing Gartner's finding that 99% of cloud security failures are customer misconfigurations, not platform weaknesses), highlights how cloud democratizes access to the same infrastructure powering Novo Nordisk and Eli Lilly's NVIDIA partnerships, and lands on a pragmatic recommendation: build on cloud-native patterns (containers, IaC, automated deployments) regardless of where you deploy today, so a future migration is incremental rather than a rewrite. Hybrid is positioned as the enterprise default, with 90% of organizations expected to adopt it by 2027.

Where R, Python, and SAS each fit in a modern pharma SCE, and why the AI era turns this from a language choice into an architecture decision.

Pharma teams don't choose between SAS and open source, they live with both. How Altair SLC on Positron Pro runs SAS, R, and Python in one IDE.

If you work in clinical development, you probably hear “SCE” in every other meeting about infrastructure, compliance, or moving off SAS. The acronym gets used loosely. Sometimes it means one specific tool. Sometimes it means an entire ecosystem. Sometimes it’s shorthand for “the thing our statisticians open every morning.”

A step-by-step guide to stronger R Shiny testing with stable selectors and reusable actions. Most shinytest2 tests break too easily. They expose fragile details of your app that break your tests as your implementation changes. It’s either by doing snapshots or by using raw input IDs. But you can take back control: make tests describe behavior, not wiring.

In this article, we'll cover why R package validation is harder than most teams expect, the two main ways pharma organizations go about it today, and what we built at Appsilon to solve it.

Most statistical computing environments in pharma were designed when SAS was the default language, studies were simpler, timelines were longer, and "open source in regulated settings" was still a controversial idea.

A practical guide to building focused AI assistants inside Shiny applications using shinychat, ellmer, and vitals — covering UI setup, streaming responses, prompt design, and benchmarking.

Posit has been shipping AI packages recently. If you've tried to keep up but ended up more confused than when you started, you’re not alone.

New drugs do not reach patients quickly. The drug development process usually takes 10 to 15 years, and most programs fail before approval. That long path is not only a science challenge. It is also a data, reporting, and compliance challenge.

Follow each step as I develop a form with Shiny and Behavior-Driven Development. Learn practical techniques for better software design through automated tests. Testing your Shiny applications shouldn’t be an afterthought. Many developers write tests after building features, missing the core benefit of test-first development: tests as design tools. I’ll walk you through how I built a small content submission form using Behavior-Driven Development (BDD), starting from absolutely nothing. Whether you’re building a new app or adding a feature, the steps are the same. Follow along and see how tests drive design decisions, keep business value visible, and make refactoring safe.

If your statistical computing environment was designed before R became a viable language for submissions, before cloud infrastructure had the prominent position it has today, and before "data engineering bottleneck" entered everyone's vocabulary you're probably already feeling the pressure. It's obvious that to overcome some of these challenges, a serious modernization effort needs to ensue. The questions that remain are how, how fast, and whether to build, buy, or partner. To answer those questions, Appsilon interviewed statistical computing leaders at top pharmaceutical companies. We coupled this with internal expertise and released a comprehensive report last year: The Anatomy of Modern Statistical Computing Environments in Pharma.

If you're a Statistical Programming Manager, you're familiar with Monday mornings that start with three urgent requests from different Biostatistics leads. All of them need analytical applications for studies with regulatory deadlines this quarter—and your team's sprint backlog is already jammed. Executives push for delivering more while cutting costs and reducing teams. Talk about being between a rock and a hard place.

Learn how to write reliable R tests by wrapping external dependencies and using `testthat::local_mocked_bindings`. Make your tests fast, clean, and predictable.

Your team pitched building a clinical dashboard in-house with a $300K budget and 6-month timeline. Read this article if you don't want to be patching bugs and spending $600K more than anticipated two years from today.

You’ve requested development support for a survival analysis application aligned with your SAP, but the team’s capacity means it’ll be at least three weeks before they can start.

The conversation around AI readiness typically centers on data quality, talent acquisition, and executive buy-in. While these factors matter, they overlook a more fundamental question: does the organization have the technical and cultural infrastructure to operationalize AI at scale? 

Imagine your team needs evidence-based answers to clinical questions like "Which medications can be combined with ibuprofen to help treat back pain?" The traditional approach means weeks of work. We built a working conversational AI assistant that queries this data in hours.

Global pharma leaders have proven open source is FDA-ready, which allows mid-sized companies to cut costs, avoid vendor lock-in, and compete on innovation with the same validated tools.

AI-powered rapid prototyping turns vague dashboard ideas into interactive prototypes in hours, which cuts requirements iteration by up to 90% and prevents costly misalignment.

What if you could go from concept to working clinical dashboard prototype in 48 hours instead of 4-6 weeks?