-
-___
+---
## Agenda
-| Time | -Chair | -Description | -
|---|---|---|
| 8.50am | -Katie Igartua (Tempus AI) | -Intro to day | -
| 9-10am | -Aaron Clark (Arcus) and Doug Kelkhoff (Roche) | -Driving Consensus Through Repositories Following last year's open dialogue about shaping an industry standard repository, we're excited to share what's on the horizon. Through collaborations across the industry and the ecosystem of R repository tools, we're settling on a means of delivering consistent, reproducible quality assessments of packages. |
-
| 10-11am | -Natalia Andriychuk (Pfizer) and Nicole Jones (Denali) | -Defining Good Practices and Tracking risk in Interactive Data Products (30 mins context setting, 30 mins panel): Crafting Impactful Interactive Data Products: A Guide to Success by Nicole Jones Assessing and mitigating risk while developing Shiny apps by Natalia Andriychuk Panel discussion: Internalizing/productionalizing shiny apps within organizations with Eric Nantz (Eli Lilly), Becca Krouse (GSK), Sam Parmar (Pfizer) |
-
| 11-11.15am | -- | -Bio-break | -
| 11.15-12.30pm | -Katie Igartua (Tempus AI) | -One Year Later - Reflection on Progress and New Developments A year has passed since our last in person meeting where we discussed regulatory validation workflows for R Shiny, integrating LLMS advancements and real-world into drug discovery, challenges of approval for open source workflows within industry and talent recruitment and training. This session aims to get new attendees up to speed while reflecting on conversations from last year's round tables with user stories. |
-
| 12.30-1.30pm | -- | -Lunch | -
| 1.30-4pm | -James Black (Roche) | -Round tables Split into 2 sessions of 1hr with short break between sessions. People are welcome, but do not need to stay at a round table for the full 1 hour. A list of the roundtable topics can be found at this link. |
-
| 4-4.45pm | -Round table chairs | -Chairs report back notes, and any planned follow up | -
| 4.45-5pm | -Phil Bowsher (Posit) | -Wrap up | -
| 6:30pm-9.00pm | -Tempus sponsored apero | --RSVP to the R /Pharma Summit Meetup @ The Pine Box -Sunday, August 11th, 2024 @ 6:30PM-9:30PM -Join other Posit enthusiasts in BioPharma for a social event following the R/Pharma Summit. We'll be meeting at the Pine Box, which is only a 10 minute walk away from the Seattle Hyatt Regency hotel where POSIT::CONF(2024) is taking place. -Attendance to the R/Pharma Summit not required. - |
-
+---
+
+### Roundtables
+
+#### 1. AI in Pharma
+##### Chair: Jeremy Wildfire
+- Best Practices for AI-Assisted R Coding
+- What would an "AI-friendly" submission look like?
+- Reimagine open-label trial deliverables with interactive display/AI
+- Best Practices for AI Integration in Data Workflows
+- *Create more tables if needed for GenAI*
+
+#### 2. Validation in 2025
+- Validating Open Source Tools with Stochastic Components
+- Architectures to provision validated R packages
+
+#### 3. Python for Clinical Study Reports and Submission
+- Medical Devices
+
+#### 4. SCEs in 2025
+- Open-source infrastructure to complement **openstatsware** and the **pharmaverse**
+- Expanding the Pharmaverse beyond Clinical Reporting
+
+#### 5. Open-Source Change Management
+- From Hacks to Habits — Tools & Tricks That Changed the Game
+
+#### 6. Implementation / Perspectives of CROs
+- Expanding the Pharmaverse beyond Clinical Reporting
## Audience
These round tables are for you if:
-- You are an active contributor to the adoption of data science best practices across drug development
-- You are a sponsor of data science codebases
-- You are an informatics professional designing and implementing GxP conforming data science platforms
-- You are interested in cross-pharma collaboration
-
-___
-
-## Round table advisory board:
+- You are an active contributor to the adoption of data science best practices across drug development
+- You sponsor data science codebases
+- You are an informatics professional designing and implementing **GxP-conforming** data science platforms
+- You are interested in cross-pharma collaboration
-Ordered alphabetically by company;
+---
-___
+## Round Table Advisory Board
-## Organising committee
+A mix of 50 people from various pharmaceutical companies, CRO and organization supporting the advancement of open source for drug development and clinical reporting.
-- Phil Bowsher, Posit
-- James Black, Roche
-- Harvey Lieberman, Novartis
-- Katie Igartua, Tempus
+---
+## Organising Committee
+- Phil Bowsher — *Posit*
+- James Black — *Roche*
+- Harvey Lieberman — *Novartis*
+- Katie Igartua — *Tempus*
+This summit is run by [Open Source in Pharma](https://opensourceinpharma.com/), a non-profit aiming to support the use of open source languages in Pharma.
diff --git a/_quarto.yml b/_quarto.yml
new file mode 100644
index 0000000..25817e7
--- /dev/null
+++ b/_quarto.yml
@@ -0,0 +1,17 @@
+project:
+ type: website
+
+website:
+ title: "R/Pharma Summit 2025"
+ navbar:
+ left:
+ - text: "Home"
+ href: index.qmd
+ page-navigation: true
+
+format:
+ html:
+ theme: cosmo
+ css: styles.css
+ toc: true
+ toc-depth: 3
diff --git a/_site/hyatt_regency.png b/_site/hyatt_regency.png
new file mode 100644
index 0000000..78cc287
Binary files /dev/null and b/_site/hyatt_regency.png differ
diff --git a/_site/index.html b/_site/index.html
new file mode 100644
index 0000000..720c5da
--- /dev/null
+++ b/_site/index.html
@@ -0,0 +1,1368 @@
+
+
+
+
+
+
+
+
+
+In-person event • Monday, September 15, 2025 • Atlanta, GA
+In 2018 and 2019, R in Pharma was in-person at Harvard University and focused on opportunities for direct interaction with speakers and guests.
+These relationships and connections have grown into many exciting areas of Open Source drug development.
Over the last five years we’ve seen an explosive growth in the use of R and other open source technologies across drug development, with an increasing focus on pan-company collaboration.
+The R/Pharma Roundtable Summit provides an open, collaborative, and inclusive environment to:
+The focus is to foster in-person discussions about key items such as reproducibility and submissions, much like the original Harvard events.
+++🔗 Review the 2023–2024 roundtable summaries here:
+
+rinpharma.github.io/roundtables
You can contribute to the discussion about the final agenda!
+Join the GitHub discussions here:
+👉 rinpharma-summit-2025 Discussions
Hyatt Regency Atlanta
+265 Peachtree St NE
+Atlanta, GA 30303, USA
+Meeting Room: Regency VII
| Time | +Chair | +Description | +
|---|---|---|
| 9.15am | ++ | Intro to day | +
| 9.30–10am | +James Black / Orla Doyle / Phil Bowsher | +ROI on Open Source | +
| 10–10.45am | +Eric Nantz / Paulo Bargo | +Navigating Quality | +
| 10.45–11.05am | ++ | Bio-break | +
| 11:05–12:15pm | +Devin Pastoor / Jeremy Wilfire, Joe Cheng, Eric Nantz | +GenAI Discussion Panel | +
| 12:15–1:30pm | ++ | Lunch 🍴 Lunch & Learn sessions: • Postitron (Thomas Mock) • Validation (R Validation Hub, Doug Kelkhoff) |
+
| 1:30–4pm | +James + other chairs | +Round tables Split into 2 × 1hr sessions with short break between. Attendance is flexible. |
+
| 4–4:45pm | +Round table chairs | +Chairs report back notes, and any planned follow up | +
| 4:45–5pm | +Phil Bowsher (Posit) | +Wrap up | +
| 6–8pm | +Social Event supported by Wu Consulting | +at White Oak - Barrel Bar Room 270 Peachtree St NW Altanta, GA 30303  |
+
These round tables are for you if:
+A mix of 50 people from various pharmaceutical companies, CRO and organization supporting the advancement of open source for drug development and clinical reporting.
+This summit is run by Open Source in Pharma, a non-profit aiming to support the use of open source languages in Pharma.
+During the R/Pharma summit, each roundtable session chair shared a summary of their group’s discussion at the conclusion of the event. This year, we recorded the audio of these summaries to local mp3 audio files, and leveraged the OpenAI whisper audio transcription LLM run entirely locally on a computer to generate transcripts of the audio summaries. Lastly, these transcripts were summarized using the Anthropic model within Positron Assistant to create summaries of these transcripts. You can view the summaries and source transcripts of the roundtable sessions below.
Okay, so we discussed a couple of topics in this. One of them, I’ll go one by one, the usability where we are currently using. We talked about using it for chatbots, for ADM, Adam TLF coding standards, general coding support and automation. I think there was somebody who also asked if we could even generate specifications from SAPs and study documents so that you could complete the loop like, you know, specs as well as code generation. We talked about where we are using it in clinical operations. One, I think there’s somebody who is using it to improve operational efficiency and another person also indicated that they are using it for signal detection for safety monitoring. In terms of implementation strategy, we wanted to break these problems into manageable pipelines, start with POCs and leverage domain knowledge as a key asset. You want to take the next one? Thank you. And some of the issues and other barriers that were discussed, in terms of the technicality, like data privacy came up a lot and how do you handle sensitive clinical data from not, you know, falling off? And there was also traceability, repeatability, and how do you control the quality? And hallucination of the AI itself was also mentioned. And this other aspect of, I guess, in terms of implementation, people trying to wipe code into producing a manageable solution which doesn’t seem to work. So these are some of the technical implementation issues that were discussed. In terms of the organizational hurdles, broader implementation like management not being on board just because of the habits they are used to and the return of investment challenge, validation, repeatability as well. And there is also a need for comprehensive user training when especially when trying to implement a process change using AI. There’s also concerns about job displacement due to AI that were mentioned. And finally regulatory and compliance like maintaining an audit as well as ensuring complete documentation and transparency of pathways. And how do you ensure it’s meeting the industry quality standards? And finally implementing proper guardrails and controls on sensitive data in terms of the regulatory where some of the other issues discussed.
+very much a Shiny-centric kind of spin to our validation discussion, where we had some interesting use cases about how Shiny, of course, you can set a lot of inputs and make dynamic changes in your UI of whatever table or plot you’re making. But then when you want to actually validate the results of those selections, there were some interesting cases where you might use a different even language in and of itself to do that, such as SAS, to look at how those outputs are being generated. So that was an interesting idea I never really thought about. But it also underscored the importance of, it’s one thing just to do the business logic kind of validation. I talked about my morning session. But you do need that kind of user-centric, dynamic look at what outputs you’re generating and making sure you’re on track with validating those. So I think there’s some opportunity to learn from each other on that side of it, too. And then, actually, you, Phil, you had a great comment about the number of conferences, some of the stigma that R has is a, quote unquote, lack of backward compatibility, which I personally wonder where that’s coming from, especially what BASE are, because they are very rigid to changing. But there are, obviously, things you need to consider with how you manage, say, your package versioning and documenting whenever big changes are occurring there, too. And then trying to think back on whatever parts we talked about. I think we talked about ShinyTest. Oh, yeah. And we also talked about ways to do testing in Shiny, specifically with ShinyTest, too. And there was some interesting new tooling that’s coming out from our friends at the Taurus, it sounds like, coming up very soon with augmenting that with automated reporting and screenshots that we’re going to be eager to see as we go forward with that side of it, too. One last thing, we talked about ShinyMeta and Teal. Yep. And then, yeah, exactly. So then Teal came up quite a bit, as we often see, that’s a great use case to get buy-in from an organization to leverage Shiny in the clinical area. But then you think about how they are approaching creating those reproducible scripts that you can get to, in essence, carry out what you did in the Teal app. And they went away from the ShinyMeta route that, Rosie, who had been at our farm before, that package from Posit actually was born from conversations with some of us with the Shiny team back then. But it never really got as much adoption as I think maybe it was anticipated. So we are interested to see the way Teal conducts this, if that’s a pattern that ends up being more standard in the future, always learning from what’s working well there and maybe where that can go in the validation discussion when you think about teams that say, oh, you did that great analysis in that app, but I need to be able to run that in a month from now or even a year from now, maybe to answer a question. So we do see some intriguing ideas that Teal has pioneered with getting those scripts out there. And last, but certainly not least, there were some questions about how to handle larger data in apps. And myself and others were quick to literally mouth off. DuckDB is a very promising approach so that you can have that within that environment database feature, but yet you’re not overhead of a Postgres or even NoSQL database that often came up, too. But we think DuckDB and Shiny is a great combination for big data analytics that I think will play nicely in Noveltoon in the future.
+So we were talking mostly about package validation during both validation roundtables, and there are companies that they already built both the exploratory and the validated GXP environments, and there are a lot of companies that are just building the GXP environments, and the cycles and the processes vary, and there could be an approach where the validation cycle takes, that happens every six or even every 12 months. However, there is one company that takes more agile and fluid approach where the package validation can be completed in just a few hours, and I think that demonstrates that both speed and compliance can coexist in a proper process. And we discussed that managing the infrastructure actually is a challenge with a lot of packages and a lot of images being created, and that a good approach that can be taken in the future is to create a base image that can be specific per project or specific for a therapeutic area, and this is a container, and Kubernetes seem to be the standard for managing those. And however, container sizing continues to present a technical challenge. What else? We also discussed that the transparency for our packages packs, that this is actually a positive thing, because with SAS you don’t really know, you only know about your own bag that you submitted, but you don’t know about the other bags, and they for sure exist, and with the open source you get access, you see what happens, and you see how those bags are resolved, so we thought that this is actually a good thing. And we also agreed that internal packages, they should follow the same process as external packages, so there needs to be testing, and that actually testing, the tester should be a separate person than the developer. And we also covered a bit the topic of testing, thank you, testing the GenAI outputs, and we concluded that basically there needs to be a code that is reproducible, and this needs to be tested, and this needs to be validated as well. And I think one more thing that was quite interesting is that we don’t have a standard what the validated package means, and that every company basically defines their own way what it means that the package is validated. And regarding also the GenAI principles and validating the outputs, we thought that right now, basically we have to decide on principles regarding the GenAI, because right now we don’t state that, for example, the documentation was generated by the GenAI, and we thought that this would be valuable, because this gives additional context, and it can mean that you also would pay additional extra attention to that part, because you know that this was not generated by the human. And last but not least, we discussed whether AI bot to help evaluate if the test is good, it can be something useful, and it can be used as an extra pair of eyes. There were mixed opinions that yes, this could be useful, however, this can also make the reviewers a bit mindless, because they would rely too much on the advice and the output from the bot. Thank you.
+So a couple of things, I’m going to start with a question that we had more towards the end because what is seen from the table that we were is that there is some heterogeneity on the usage of it. Some people are actually in the medical device space, some people are in the pharma space and for medical devices, a lot of the people that have used Python are engineers and they are more familiar to this, which end up becoming very much their standard language for them to use, which created an interesting thing. It becomes very difficult to manage multiple languages sometimes and in this particular case, this company has decided that they are just using Python even though there are some challenges in that space. We have a couple of different topics that we were discussing. One of them is regarding the use cases. So of course for medical devices, the use cases are very different than what’s in pharma. The kind of data that is coming from devices, large data sets, kind of forces the use of Python in a different way. There is also a little bit of a medical device space. You’re also thinking not only about the data analysis but an actual product that’s going to be created in the end after the data analysis, which is more difficult to be developed in R, in that space. But I think that one of the things that drives some of the use cases, especially for pharma, is speed, and because of that, a lot of ETLs, maybe machine learning, data engineering is really the space where pharma is looking into the usage of Python. Of course, another team was validation, that James already mentioned a little bit about this. What do we do about validation of Python? I think when the R validation hub created the white paper, even though it’s an R paper, it was meant to be language agnostic. We did put a lot of stuff that was there because that’s what we were working on, but we talked about it. Should we just make this language agnostic at the time? We decided not, but I think the principles are the same. Of course, it does raise a lot of different questions because there are assumptions in the R validation white paper that we do for R that are a little maybe easier to get from evidence perspective. For example, what’s a trusted source? And what is a trusted source in Python? I think that we heard in the table that things coming from Anaconda or maybe PyPy with maybe some RSPM may be reasonable, but also that you have to put some scrutiny around this because it’s not, again, Python is more of a wide west in comparison to R. There’s just so much more stuff going on and we have to have all that in consideration. An interesting comment, the statistics in Python, I mean, packages or libraries that are doing statistics, I think that what we heard from one person, one company, is that the groundwork to make sure that those statistical analysis is being vetted, it’s still a little early. It’s like R was like eight years back maybe, so there’s a little bit of that going on and that’s in the space for Python. There’s some discussion in the validation about the use of containers and a couple of other questions that you have that we posed in the end was Python and GenAI, so as you see, there’s a lot of GenAI, when I talk about GenAI, there’s a lot of stuff that’s going on in Python just because it’s a more used language and that may be driven or driving some of the, where the languages are going. There is some conversation about Python versus R and one thing that R is definitely ahead is the fact that submission and regulatory acceptance is already being developed, so no one has really got a Python submission yet, as far as I know, and that is groundwork that has to be done. Submission, pilot number 10, pilot 15, Eric, pilot 15, Eric, for you, and I guess the other thing is really in regards to the limitations that may be in R for certain types of data sets, gene data sets, genetic data sets and so forth because of the size of the data. Did I, is there something else that I, okay, so that’s it. Thank you.
+and David’s. So we start off saying there’s three components to an SCE, and then we listed out five different components. So the first one was the IDE, there’s file and version management, data and access, the governance, and then the actual compute. In terms of scope, I don’t think we had an agreed scope for what actually is in an SCE. Historically, that might be defined by department structure, and it seemed it was kind of a common theme that in the legacy world, you had an SCE for GXP work and an SCE for everything else. And it seemed most companies want to have a single SCE going forwards. We talked a little bit about vendors and how some vendors kind of promise to package everything together into an ecosystem. But people tend to be quite a little bit afraid of that because of vendor lock-in. And also, there’s often missing integrations. And I think we were hypothesizing some of those are strategic to kind of force you to stay within the ecosystem. We, yeah, there are a couple of platforms specifically called out for that. And I think one comment that was made is there’s also that kind of concern around the total cost of ownership. So if you have to string together a whole bunch of different vendors to build your SCE, you kind of start ballooning the costs. And there’s overlap between the different vendor products. And at least in the modern SCEs, there’s often really diverse users in there, like PK, Biostat, Stats Programming, and other groups all on the same platform. Validation takes a long time. I think my own company seemed to be longest at three months to validate the SCE. But it seemed it was always a kind of a slow process. And the test suites themselves add a lot of burden just to maintain those because you have to update the test suites whenever something changes in the platform. There’s a bit of a debate whether the IDE should be part of the validation environment or should it be kept outside. So the IDE is kind of repeated across as a layer on top of your validated containers. And there was a discussion also on, do we validate a system or a process? And I think the best practice was to qualify the systems and focus validation just on the process. A few companies mentioned Python was coming in. So this is in the clinical reporting space, usually for transformations. How to validate Python is a challenge, though, because it doesn’t have a standardized documentation and testing framework like R. I think one company mentioned that they have an opinionated list of R packages. So you can’t just get any package validated. They tried to put some governance on what are the packages they’re validating. Parquet seems to have replaced SAS7bdat as the data format within modern SCEs. For environment management, either three or six months seems to be a common window to update the base environments. A couple of companies decoupled the R package from the environment, but that doesn’t seem to be the norm. One company mentioned that they have a tool. So if the users are kind of interactively modifying their environments, it can flag whether that environment is one of the managed ones for a production run and could also tell if it was an upcoming planned environment, which I thought was a cool thing to open source if that company was interested. And it was really important to think about consistency of environments. So if you have a container in the SCE, the Shiny app should also be able to access that container. The HPC should be able to access that container and the like. And the last two topics, one of them was Git for version control. It seemed that was the direction most companies are going in, but we really had to acknowledge there was a change management issue there with the learning curve. And we discussed some of the complications around data access, particularly in Shiny. So kind of passing through the viewer of the application’s data access. And there was mention of a couple of technologies to help. One was Denodo, and also AWS’s data zone as a way of kind of putting a middle layer to help manage that. Thank you.
+open source change management: I think the first thing when it comes to change management is the why before we actually talk about the how. And I think it’s important to keep the perspective of change management is about risk. And there’s a saying that I did not make up even though no one at my table had heard about it. You can’t get, no one has ever gotten fired for buying IBM. And that saying means that like, if everyone does things a certain way, no one’s gonna get in trouble if something happens with like that way. And so you’re asking people to change the way they do analysis. And so management and people who aren’t like in this room basically see the downsides pretty obviously, but then your job as sort of thought leaders is to show them the upsides. And I think a big one is mentioned stuff like collaboration, AI, like I think AI is like oregano, everyone wants to sprinkle AI on everything. So mission AI and those things, and that’ll help to make the conversation a little bit about like, yes, you see the downsides, but moving more towards the upsides. I think the R-validation hub is a big, big benefit. I think you can show that there is a process, you can show stuff like risk metric, and that’ll sort of help to ameliorate some of the concerns about change, but it won’t eliminate them. When it comes to actually making the change, I think we talked a little bit about training, either buying it or doing it yourself. I think one thing to keep in mind is that when it comes to training, the best training is the training that you do yourself. So I think you need to find the right people to help make that change. I think a big thing about, especially open source change management, is environment, and I’m talking about like SCE stuff, James already solved that, so you’re fine, but work on your environment, make sure that people feel comfortable in that environment, especially if there are ways to sort of, before you make a big investment, do some kind of trials with that. For change management, communication is key. Make sure you have the right people, give the right message. I think a lot of people push back if you’re like, you have to change, you have to do it this way now. Expect some pushback. And then one of the biggest things that is a change from closed source analysis to open source is a lot of stuff about package issues. A lot of companies, they just have like one, one single sort of package that gets updated every couple of years. Obviously, this open source is much more dynamic, and so you need to maybe explain a little bit more how like software works, because if there’s an error, it could be that your code is fine, but maybe you have a, maybe the version needs to be updated, and explaining stuff like packaging, and I think a big part of that is containerization, either RAM for Docker or something, I think that’ll make that change process a lot easier.
+So we have the, for our roundtable, we’re talking about open source change management, and then we try to tackle that problem from the three pillars of change management, people, technology, and process. And for the people side, we talk about to get the momentum started, oftentimes we need very specific use cases showing that by using our Python, we can generate this very complicated tables and the graph is very easily. And then we talk about that, actually grassroot effort can only get us to a certain level and at the end of the day, we really need kind of top down decisions and then those incentives coming from the leadership team and also having those messages repeatedly like from the leadership team. And we see a trend that from mid-size and large companies, like there are creation of independent innovation groups. So we acknowledge that if like change management is a side job of someone’s, like in complimentary to someone’s day job of filing, et cetera, it’s always getting deprioritized. So we see a trend of creating those innovation teams. And we talk a little bit about hiring versus training. And we talk about for internal training, we want to have those just in time training. We see many cases that we train people, they go back to SAS work and they forgot about the training. And it seems like there is a trend that for many companies, they start to remove SAS in their job description. And we see that people are, for younger generation, we are hiring our Python programmers from day zero. And then in terms of another thing I found very interesting that in terms of people influence, we also have some discussion about this is also a good time to influence our internal standard group because there are many trivial decisions in internal standard or limitations or historical reasons from like legacy tools or legacy technology limitations. So it’s a good timing to influence them and then to kind of like reset the baseline a little bit. In terms of technology, we spend quite some time talking about Git, kind of double click on the conversation this morning. Like it’s absolutely the foundation of adoption of open source languages and also the AI tools. In terms of process, we talk about Git again, and we also talk about there are also unique opportunity for us to rethink about our clinical trial reporting process. For example, we see that in some companies, like by using Shiny, actually we can reduce number of TLGs or even get rid of the generation of static TLF for a certain reporting event. So I think that there is an opportunity to rethink what really makes sense for clinical trial reporting.
+So yeah, we had a good discussion. I’m going to differentiate probably between the more innovative CROs that I think are here versus the more traditional groups that tend to dominate the industry a lot but are obviously a big part of what’s going on. So the consensus view is that there’s a big challenge in the CRO space because one, SAS is still a big part of the workflow and the process that everybody is working through and dealing with. And so the requirements to upskill people and to change that paradigm, it falls a bit on the CRO. And it’s a decision that they have to make in terms of how they’re looking at the market. And so I think a lot of these groups are looking for maybe more guidance from the sponsor side or perhaps sponsors that are more set on a certain path as opposed to expecting them to manage both. And in that sense, they’ve become a bit of a bottleneck because they’re trying to figure it out on their own but they don’t always know where to go in some of these strategies. I think the other thing is though that we did talk about on the other side of that, CROs also can be a really great resource for organizations that are looking to make this transition because they have a lot of internal experience working on a lot of different studies and projects across a lot of different clients. So they’re not often set up to be consultants. They’re really more kind of order takers or process-focused organizations. But they’re pivoting a bit to try to support more of those activities as clients are demanding it of them. Yeah, I mean, there was a lot of discussion around do sponsors understand that the upskilling and the change is taking time and that there are certain requirements that need to be dealt with? And I think there’s a question there as to whether a lot of sponsors understand that. But it also just kind of fits in with the business model and the expectations. The other big, I guess the other big topic everybody discussed is the importance of being part of an organization like this because there’s a lot of information available to people as they’re trying to work through some of these topics. And perhaps an emphasis of getting more CROs involved in this discussion could be pretty useful because they are a pretty big player in the overall kind of ecosystem that we all work in. Thank you.
+${missingFields[0]} field.`,
+ message: `The items being returned for this search do not include all the required fields. Please ensure that your index items include the ${missingFields[0]} field or use index-fields in your _quarto.yml file to specify the field names.`,
+ };
+ } else if (missingFields.length > 1) {
+ const missingFieldList = missingFields
+ .map((field) => {
+ return `${field}`;
+ })
+ .join(", ");
+
+ throw {
+ name: `Error: Search index is missing the following fields: ${missingFieldList}.`,
+ message: `The items being returned for this search do not include all the required fields. Please ensure that your index items includes the following fields: ${missingFieldList}, or use index-fields in your _quarto.yml file to specify the field names.`,
+ };
+ }
+ }
+}
+
+let lastQuery = null;
+function showCopyLink(query, options) {
+ const language = options.language;
+ lastQuery = query;
+ // Insert share icon
+ const inputSuffixEl = window.document.body.querySelector(
+ ".aa-Form .aa-InputWrapperSuffix"
+ );
+
+ if (inputSuffixEl) {
+ let copyButtonEl = window.document.body.querySelector(
+ ".aa-Form .aa-InputWrapperSuffix .aa-CopyButton"
+ );
+
+ if (copyButtonEl === null) {
+ copyButtonEl = window.document.createElement("button");
+ copyButtonEl.setAttribute("class", "aa-CopyButton");
+ copyButtonEl.setAttribute("type", "button");
+ copyButtonEl.setAttribute("title", language["search-copy-link-title"]);
+ copyButtonEl.onmousedown = (e) => {
+ e.preventDefault();
+ e.stopPropagation();
+ };
+
+ const linkIcon = "bi-clipboard";
+ const checkIcon = "bi-check2";
+
+ const shareIconEl = window.document.createElement("i");
+ shareIconEl.setAttribute("class", `bi ${linkIcon}`);
+ copyButtonEl.appendChild(shareIconEl);
+ inputSuffixEl.prepend(copyButtonEl);
+
+ const clipboard = new window.ClipboardJS(".aa-CopyButton", {
+ text: function (_trigger) {
+ const copyUrl = new URL(window.location);
+ copyUrl.searchParams.set(kQueryArg, lastQuery);
+ copyUrl.searchParams.set(kResultsArg, "1");
+ return copyUrl.toString();
+ },
+ });
+ clipboard.on("success", function (e) {
+ // Focus the input
+
+ // button target
+ const button = e.trigger;
+ const icon = button.querySelector("i.bi");
+
+ // flash "checked"
+ icon.classList.add(checkIcon);
+ icon.classList.remove(linkIcon);
+ setTimeout(function () {
+ icon.classList.remove(checkIcon);
+ icon.classList.add(linkIcon);
+ }, 1000);
+ });
+ }
+
+ // If there is a query, show the link icon
+ if (copyButtonEl) {
+ if (lastQuery && options["copy-button"]) {
+ copyButtonEl.style.display = "flex";
+ } else {
+ copyButtonEl.style.display = "none";
+ }
+ }
+ }
+}
+
+/* Search Index Handling */
+// create the index
+var fuseIndex = undefined;
+var shownWarning = false;
+
+// fuse index options
+const kFuseIndexOptions = {
+ keys: [
+ { name: "title", weight: 20 },
+ { name: "section", weight: 20 },
+ { name: "text", weight: 10 },
+ ],
+ ignoreLocation: true,
+ threshold: 0.1,
+};
+
+async function readSearchData() {
+ // Initialize the search index on demand
+ if (fuseIndex === undefined) {
+ if (window.location.protocol === "file:" && !shownWarning) {
+ window.alert(
+ "Search requires JavaScript features disabled when running in file://... URLs. In order to use search, please run this document in a web server."
+ );
+ shownWarning = true;
+ return;
+ }
+ const fuse = new window.Fuse([], kFuseIndexOptions);
+
+ // fetch the main search.json
+ const response = await fetch(offsetURL("search.json"));
+ if (response.status == 200) {
+ return response.json().then(function (searchDocs) {
+ searchDocs.forEach(function (searchDoc) {
+ fuse.add(searchDoc);
+ });
+ fuseIndex = fuse;
+ return fuseIndex;
+ });
+ } else {
+ return Promise.reject(
+ new Error(
+ "Unexpected status from search index request: " + response.status
+ )
+ );
+ }
+ }
+
+ return fuseIndex;
+}
+
+function inputElement() {
+ return window.document.body.querySelector(".aa-Form .aa-Input");
+}
+
+function focusSearchInput() {
+ setTimeout(() => {
+ const inputEl = inputElement();
+ if (inputEl) {
+ inputEl.focus();
+ }
+ }, 50);
+}
+
+/* Panels */
+const kItemTypeDoc = "document";
+const kItemTypeMore = "document-more";
+const kItemTypeItem = "document-item";
+const kItemTypeError = "error";
+
+function renderItem(
+ item,
+ createElement,
+ state,
+ setActiveItemId,
+ setContext,
+ refresh,
+ quartoSearchOptions
+) {
+ switch (item.type) {
+ case kItemTypeDoc:
+ return createDocumentCard(
+ createElement,
+ "file-richtext",
+ item.title,
+ item.section,
+ item.text,
+ item.href,
+ item.crumbs,
+ quartoSearchOptions
+ );
+ case kItemTypeMore:
+ return createMoreCard(
+ createElement,
+ item,
+ state,
+ setActiveItemId,
+ setContext,
+ refresh
+ );
+ case kItemTypeItem:
+ return createSectionCard(
+ createElement,
+ item.section,
+ item.text,
+ item.href
+ );
+ case kItemTypeError:
+ return createErrorCard(createElement, item.title, item.text);
+ default:
+ return undefined;
+ }
+}
+
+function createDocumentCard(
+ createElement,
+ icon,
+ title,
+ section,
+ text,
+ href,
+ crumbs,
+ quartoSearchOptions
+) {
+ const iconEl = createElement("i", {
+ class: `bi bi-${icon} search-result-icon`,
+ });
+ const titleEl = createElement("p", { class: "search-result-title" }, title);
+ const titleContents = [iconEl, titleEl];
+ const showParent = quartoSearchOptions["show-item-context"];
+ if (crumbs && showParent) {
+ let crumbsOut = undefined;
+ const crumbClz = ["search-result-crumbs"];
+ if (showParent === "root") {
+ crumbsOut = crumbs.length > 1 ? crumbs[0] : undefined;
+ } else if (showParent === "parent") {
+ crumbsOut = crumbs.length > 1 ? crumbs[crumbs.length - 2] : undefined;
+ } else {
+ crumbsOut = crumbs.length > 1 ? crumbs.join(" > ") : undefined;
+ crumbClz.push("search-result-crumbs-wrap");
+ }
+
+ const crumbEl = createElement(
+ "p",
+ { class: crumbClz.join(" ") },
+ crumbsOut
+ );
+ titleContents.push(crumbEl);
+ }
+
+ const titleContainerEl = createElement(
+ "div",
+ { class: "search-result-title-container" },
+ titleContents
+ );
+
+ const textEls = [];
+ if (section) {
+ const sectionEl = createElement(
+ "p",
+ { class: "search-result-section" },
+ section
+ );
+ textEls.push(sectionEl);
+ }
+ const descEl = createElement("p", {
+ class: "search-result-text",
+ dangerouslySetInnerHTML: {
+ __html: text,
+ },
+ });
+ textEls.push(descEl);
+
+ const textContainerEl = createElement(
+ "div",
+ { class: "search-result-text-container" },
+ textEls
+ );
+
+ const containerEl = createElement(
+ "div",
+ {
+ class: "search-result-container",
+ },
+ [titleContainerEl, textContainerEl]
+ );
+
+ const linkEl = createElement(
+ "a",
+ {
+ href: offsetURL(href),
+ class: "search-result-link",
+ },
+ containerEl
+ );
+
+ const classes = ["search-result-doc", "search-item"];
+ if (!section) {
+ classes.push("document-selectable");
+ }
+
+ return createElement(
+ "div",
+ {
+ class: classes.join(" "),
+ },
+ linkEl
+ );
+}
+
+function createMoreCard(
+ createElement,
+ item,
+ state,
+ setActiveItemId,
+ setContext,
+ refresh
+) {
+ const moreCardEl = createElement(
+ "div",
+ {
+ class: "search-result-more search-item",
+ onClick: (e) => {
+ // Handle expanding the sections by adding the expanded
+ // section to the list of expanded sections
+ toggleExpanded(item, state, setContext, setActiveItemId, refresh);
+ e.stopPropagation();
+ },
+ },
+ item.title
+ );
+
+ return moreCardEl;
+}
+
+function toggleExpanded(item, state, setContext, setActiveItemId, refresh) {
+ const expanded = state.context.expanded || [];
+ if (expanded.includes(item.target)) {
+ setContext({
+ expanded: expanded.filter((target) => target !== item.target),
+ });
+ } else {
+ setContext({ expanded: [...expanded, item.target] });
+ }
+
+ refresh();
+ setActiveItemId(item.__autocomplete_id);
+}
+
+function createSectionCard(createElement, section, text, href) {
+ const sectionEl = createSection(createElement, section, text, href);
+ return createElement(
+ "div",
+ {
+ class: "search-result-doc-section search-item",
+ },
+ sectionEl
+ );
+}
+
+function createSection(createElement, title, text, href) {
+ const descEl = createElement("p", {
+ class: "search-result-text",
+ dangerouslySetInnerHTML: {
+ __html: text,
+ },
+ });
+
+ const titleEl = createElement("p", { class: "search-result-section" }, title);
+ const linkEl = createElement(
+ "a",
+ {
+ href: offsetURL(href),
+ class: "search-result-link",
+ },
+ [titleEl, descEl]
+ );
+ return linkEl;
+}
+
+function createErrorCard(createElement, title, text) {
+ const descEl = createElement("p", {
+ class: "search-error-text",
+ dangerouslySetInnerHTML: {
+ __html: text,
+ },
+ });
+
+ const titleEl = createElement("p", {
+ class: "search-error-title",
+ dangerouslySetInnerHTML: {
+ __html: ` ${title}`,
+ },
+ });
+ const errorEl = createElement("div", { class: "search-error" }, [
+ titleEl,
+ descEl,
+ ]);
+ return errorEl;
+}
+
+function positionPanel(pos) {
+ const panelEl = window.document.querySelector(
+ "#quarto-search-results .aa-Panel"
+ );
+ const inputEl = window.document.querySelector(
+ "#quarto-search .aa-Autocomplete"
+ );
+
+ if (panelEl && inputEl) {
+ panelEl.style.top = `${Math.round(panelEl.offsetTop)}px`;
+ if (pos === "start") {
+ panelEl.style.left = `${Math.round(inputEl.left)}px`;
+ } else {
+ panelEl.style.right = `${Math.round(inputEl.offsetRight)}px`;
+ }
+ }
+}
+
+/* Highlighting */
+// highlighting functions
+function highlightMatch(query, text) {
+ if (text) {
+ const start = text.toLowerCase().indexOf(query.toLowerCase());
+ if (start !== -1) {
+ const startMark = "";
+ const endMark = "";
+
+ const end = start + query.length;
+ text =
+ text.slice(0, start) +
+ startMark +
+ text.slice(start, end) +
+ endMark +
+ text.slice(end);
+ const startInfo = clipStart(text, start);
+ const endInfo = clipEnd(
+ text,
+ startInfo.position + startMark.length + endMark.length
+ );
+ text =
+ startInfo.prefix +
+ text.slice(startInfo.position, endInfo.position) +
+ endInfo.suffix;
+
+ return text;
+ } else {
+ return text;
+ }
+ } else {
+ return text;
+ }
+}
+
+function clipStart(text, pos) {
+ const clipStart = pos - 50;
+ if (clipStart < 0) {
+ // This will just return the start of the string
+ return {
+ position: 0,
+ prefix: "",
+ };
+ } else {
+ // We're clipping before the start of the string, walk backwards to the first space.
+ const spacePos = findSpace(text, pos, -1);
+ return {
+ position: spacePos.position,
+ prefix: "",
+ };
+ }
+}
+
+function clipEnd(text, pos) {
+ const clipEnd = pos + 200;
+ if (clipEnd > text.length) {
+ return {
+ position: text.length,
+ suffix: "",
+ };
+ } else {
+ const spacePos = findSpace(text, clipEnd, 1);
+ return {
+ position: spacePos.position,
+ suffix: spacePos.clipped ? "…" : "",
+ };
+ }
+}
+
+function findSpace(text, start, step) {
+ let stepPos = start;
+ while (stepPos > -1 && stepPos < text.length) {
+ const char = text[stepPos];
+ if (char === " " || char === "," || char === ":") {
+ return {
+ position: step === 1 ? stepPos : stepPos - step,
+ clipped: stepPos > 1 && stepPos < text.length,
+ };
+ }
+ stepPos = stepPos + step;
+ }
+
+ return {
+ position: stepPos - step,
+ clipped: false,
+ };
+}
+
+// removes highlighting as implemented by the mark tag
+function clearHighlight(searchterm, el) {
+ const childNodes = el.childNodes;
+ for (let i = childNodes.length - 1; i >= 0; i--) {
+ const node = childNodes[i];
+ if (node.nodeType === Node.ELEMENT_NODE) {
+ if (
+ node.tagName === "MARK" &&
+ node.innerText.toLowerCase() === searchterm.toLowerCase()
+ ) {
+ el.replaceChild(document.createTextNode(node.innerText), node);
+ } else {
+ clearHighlight(searchterm, node);
+ }
+ }
+ }
+}
+
+function escapeRegExp(string) {
+ return string.replace(/[.*+?^${}()|[\]\\]/g, "\\$&"); // $& means the whole matched string
+}
+
+// highlight matches
+function highlight(term, el) {
+ const termRegex = new RegExp(term, "ig");
+ const childNodes = el.childNodes;
+
+ // walk back to front avoid mutating elements in front of us
+ for (let i = childNodes.length - 1; i >= 0; i--) {
+ const node = childNodes[i];
+
+ if (node.nodeType === Node.TEXT_NODE) {
+ // Search text nodes for text to highlight
+ const text = node.nodeValue;
+
+ let startIndex = 0;
+ let matchIndex = text.search(termRegex);
+ if (matchIndex > -1) {
+ const markFragment = document.createDocumentFragment();
+ while (matchIndex > -1) {
+ const prefix = text.slice(startIndex, matchIndex);
+ markFragment.appendChild(document.createTextNode(prefix));
+
+ const mark = document.createElement("mark");
+ mark.appendChild(
+ document.createTextNode(
+ text.slice(matchIndex, matchIndex + term.length)
+ )
+ );
+ markFragment.appendChild(mark);
+
+ startIndex = matchIndex + term.length;
+ matchIndex = text.slice(startIndex).search(new RegExp(term, "ig"));
+ if (matchIndex > -1) {
+ matchIndex = startIndex + matchIndex;
+ }
+ }
+ if (startIndex < text.length) {
+ markFragment.appendChild(
+ document.createTextNode(text.slice(startIndex, text.length))
+ );
+ }
+
+ el.replaceChild(markFragment, node);
+ }
+ } else if (node.nodeType === Node.ELEMENT_NODE) {
+ // recurse through elements
+ highlight(term, node);
+ }
+ }
+}
+
+/* Link Handling */
+// get the offset from this page for a given site root relative url
+function offsetURL(url) {
+ var offset = getMeta("quarto:offset");
+ return offset ? offset + url : url;
+}
+
+// read a meta tag value
+function getMeta(metaName) {
+ var metas = window.document.getElementsByTagName("meta");
+ for (let i = 0; i < metas.length; i++) {
+ if (metas[i].getAttribute("name") === metaName) {
+ return metas[i].getAttribute("content");
+ }
+ }
+ return "";
+}
+
+function algoliaSearch(query, limit, algoliaOptions) {
+ const { getAlgoliaResults } = window["@algolia/autocomplete-preset-algolia"];
+
+ const applicationId = algoliaOptions["application-id"];
+ const searchOnlyApiKey = algoliaOptions["search-only-api-key"];
+ const indexName = algoliaOptions["index-name"];
+ const indexFields = algoliaOptions["index-fields"];
+ const searchClient = window.algoliasearch(applicationId, searchOnlyApiKey);
+ const searchParams = algoliaOptions["params"];
+ const searchAnalytics = !!algoliaOptions["analytics-events"];
+
+ return getAlgoliaResults({
+ searchClient,
+ queries: [
+ {
+ indexName: indexName,
+ query,
+ params: {
+ hitsPerPage: limit,
+ clickAnalytics: searchAnalytics,
+ ...searchParams,
+ },
+ },
+ ],
+ transformResponse: (response) => {
+ if (!indexFields) {
+ return response.hits.map((hit) => {
+ return hit.map((item) => {
+ return {
+ ...item,
+ text: highlightMatch(query, item.text),
+ };
+ });
+ });
+ } else {
+ const remappedHits = response.hits.map((hit) => {
+ return hit.map((item) => {
+ const newItem = { ...item };
+ ["href", "section", "title", "text", "crumbs"].forEach(
+ (keyName) => {
+ const mappedName = indexFields[keyName];
+ if (
+ mappedName &&
+ item[mappedName] !== undefined &&
+ mappedName !== keyName
+ ) {
+ newItem[keyName] = item[mappedName];
+ delete newItem[mappedName];
+ }
+ }
+ );
+ newItem.text = highlightMatch(query, newItem.text);
+ return newItem;
+ });
+ });
+ return remappedHits;
+ }
+ },
+ });
+}
+
+let subSearchTerm = undefined;
+let subSearchFuse = undefined;
+const kFuseMaxWait = 125;
+
+async function fuseSearch(query, fuse, fuseOptions) {
+ let index = fuse;
+ // Fuse.js using the Bitap algorithm for text matching which runs in
+ // O(nm) time (no matter the structure of the text). In our case this
+ // means that long search terms mixed with large index gets very slow
+ //
+ // This injects a subIndex that will be used once the terms get long enough
+ // Usually making this subindex is cheap since there will typically be
+ // a subset of results matching the existing query
+ if (subSearchFuse !== undefined && query.startsWith(subSearchTerm)) {
+ // Use the existing subSearchFuse
+ index = subSearchFuse;
+ } else if (subSearchFuse !== undefined) {
+ // The term changed, discard the existing fuse
+ subSearchFuse = undefined;
+ subSearchTerm = undefined;
+ }
+
+ // Search using the active fuse
+ const then = performance.now();
+ const resultsRaw = await index.search(query, fuseOptions);
+ const now = performance.now();
+
+ const results = resultsRaw.map((result) => {
+ const addParam = (url, name, value) => {
+ const anchorParts = url.split("#");
+ const baseUrl = anchorParts[0];
+ const sep = baseUrl.search("\\?") > 0 ? "&" : "?";
+ anchorParts[0] = baseUrl + sep + name + "=" + value;
+ return anchorParts.join("#");
+ };
+
+ return {
+ title: result.item.title,
+ section: result.item.section,
+ href: addParam(result.item.href, kQueryArg, query),
+ text: highlightMatch(query, result.item.text),
+ crumbs: result.item.crumbs,
+ };
+ });
+
+ // If we don't have a subfuse and the query is long enough, go ahead
+ // and create a subfuse to use for subsequent queries
+ if (
+ now - then > kFuseMaxWait &&
+ subSearchFuse === undefined &&
+ resultsRaw.length < fuseOptions.limit
+ ) {
+ subSearchTerm = query;
+ subSearchFuse = new window.Fuse([], kFuseIndexOptions);
+ resultsRaw.forEach((rr) => {
+ subSearchFuse.add(rr.item);
+ });
+ }
+ return results;
+}
diff --git a/_site/styles.css b/_site/styles.css
new file mode 100644
index 0000000..14a986e
--- /dev/null
+++ b/_site/styles.css
@@ -0,0 +1,127 @@
+/* styles.css — Custom styling for R/Pharma Summit Quarto page */
+
+/* General page style */
+body {
+ font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
+ line-height: 1.6;
+ color: #2a2a2a;
+}
+
+/* Headings */
+h1, h2, h3, h4 {
+ font-weight: 700;
+ letter-spacing: 0.5px;
+ margin-top: 1.2em;
+ margin-bottom: 0.6em;
+ color: #1c3f95; /* Deep pharma blue */
+}
+
+h1 {
+ font-size: 2.2rem;
+ border-bottom: 3px solid #1c3f95;
+ padding-bottom: 0.3rem;
+}
+
+h2 {
+ font-size: 1.8rem;
+ border-left: 6px solid #1c3f95;
+ padding-left: 0.5rem;
+}
+
+h3 {
+ font-size: 1.4rem;
+ color: #333333;
+}
+
+/* Links */
+a {
+ color: #0077b6;
+ text-decoration: none;
+ font-weight: 500;
+}
+a:hover {
+ text-decoration: underline;
+ color: #023e8a;
+}
+
+/* Callouts (Quarto built-in) */
+.callout {
+ border-radius: 10px;
+ box-shadow: 0 2px 6px rgba(0,0,0,0.08);
+ padding: 0.8em 1em;
+}
+.callout-note {
+ border-left: 6px solid #0077b6;
+}
+.callout-important {
+ border-left: 6px solid #d62828;
+}
+
+/* Agenda table */
+table {
+ width: 100%;
+ margin: 1em 0;
+ border-collapse: collapse;
+ font-size: 0.95rem;
+}
+table thead {
+ background-color: #1c3f95;
+ color: white;
+}
+table th, table td {
+ padding: 0.6em 0.8em;
+ border: 1px solid #ddd;
+ text-align: left;
+}
+table tbody tr:nth-child(even) {
+ background-color: #f7f9fc;
+}
+
+/* Lists */
+ul {
+ margin-top: 0.5em;
+ margin-bottom: 1em;
+}
+ul li {
+ margin-bottom: 0.3em;
+}
+
+/* Horizontal rules */
+hr {
+ border: 0;
+ height: 2px;
+ background: linear-gradient(to right, #1c3f95, #0077b6, #90e0ef);
+ margin: 2em 0;
+}
+
+/* Images */
+img {
+ display: block;
+ margin: 1.5em auto;
+ border-radius: 12px;
+ box-shadow: 0 4px 12px rgba(0,0,0,0.12);
+ max-width: 100%;
+ height: auto;
+}
+
+/* Agenda table column control */
+.agenda-table table {
+ width: 100%;
+ border-collapse: collapse;
+}
+
+.agenda-table table th:nth-child(1),
+.agenda-table table td:nth-child(1) {
+ white-space: nowrap; /* stop wrapping */
+ min-width: 80px; /* enough room for long times like "11:15–12:30pm" */
+}
+
+.agenda-table table th:nth-child(2),
+.agenda-table table td:nth-child(2) {
+ width: 25%; /* chair column gets a reasonable share */
+}
+
+.agenda-table table th:nth-child(3),
+.agenda-table table td:nth-child(3) {
+ width: auto; /* description takes the rest */
+}
diff --git a/_site/white_oak.png b/_site/white_oak.png
new file mode 100644
index 0000000..6165912
Binary files /dev/null and b/_site/white_oak.png differ
diff --git a/_summit_transcripts/ai/summary.md b/_summit_transcripts/ai/summary.md
new file mode 100644
index 0000000..e064fec
--- /dev/null
+++ b/_summit_transcripts/ai/summary.md
@@ -0,0 +1,30 @@
+### Current Use Cases
+* **Development Support**: Chatbots, ADM, Adam TLF coding standards, general coding support and automation
+* **Specification Generation**: Potential for generating specifications from SAPs and study documents to complete the code generation loop
+* **Clinical Operations**:
+ - Improving operational efficiency
+ - Signal detection for safety monitoring
+
+### Implementation Strategy
+* Break problems into manageable pipelines
+* Start with proof-of-concepts (POCs)
+* Leverage domain knowledge as a key asset
+
+### Technical Challenges
+* **Data Privacy**: Major concern with handling sensitive clinical data securely
+* **Quality Control**: Issues with traceability, repeatability, and quality control
+* **AI Limitations**: Hallucination problems with AI outputs
+* **Implementation Issues**: Tendency to over-engineer solutions rather than creating manageable ones
+
+### Organizational Barriers
+* **Management Resistance**: Leadership not being on board due to established habits
+* **ROI Challenges**: Difficulty demonstrating return on investment
+* **Validation Requirements**: Need for repeatability and validation processes
+* **Training Needs**: Comprehensive user training required for process changes
+* **Job Security Concerns**: Worries about AI-related job displacement
+
+### Regulatory and Compliance Issues
+* **Audit Trail**: Maintaining proper audit trails
+* **Documentation**: Ensuring complete documentation and transparency of AI pathways
+* **Quality Standards**: Meeting industry quality standards
+* **Data Governance**: Implementing proper guardrails and controls on sensitive data
diff --git a/_summit_transcripts/ai/transcript.txt b/_summit_transcripts/ai/transcript.txt
new file mode 100644
index 0000000..5135944
--- /dev/null
+++ b/_summit_transcripts/ai/transcript.txt
@@ -0,0 +1,30 @@
+Okay, so we discussed a couple of topics in this. One of them, I'll go one by one,
+the usability where we are currently using. We talked about using it for
+chatbots, for ADM, Adam TLF coding standards, general coding support and
+automation. I think there was somebody who also asked if we could even generate
+specifications from SAPs and study documents so that you could complete
+the loop like, you know, specs as well as code generation. We talked about where we
+are using it in clinical operations. One, I think there's somebody who is using it
+to improve operational efficiency and another person also indicated that they
+are using it for signal detection for safety monitoring. In terms of
+implementation strategy, we wanted to break these problems into manageable
+pipelines, start with POCs and leverage domain knowledge as a key asset.
+You want to take the next one? Thank you. And some of the issues and other barriers
+that were discussed, in terms of the technicality, like data privacy came up a
+lot and how do you handle sensitive clinical data from not, you know, falling
+off? And there was also traceability, repeatability, and how do you control the
+quality? And hallucination of the AI itself was also mentioned. And this other
+aspect of, I guess, in terms of implementation, people trying to wipe
+code into producing a manageable solution which doesn't seem to work. So
+these are some of the technical implementation issues that were
+discussed. In terms of the organizational hurdles, broader implementation like
+management not being on board just because of the habits they are used to
+and the return of investment challenge, validation, repeatability as well. And
+there is also a need for comprehensive user training when especially when
+trying to implement a process change using AI. There's also concerns about job
+displacement due to AI that were mentioned. And finally regulatory and
+compliance like maintaining an audit as well as ensuring complete documentation
+and transparency of pathways. And how do you ensure it's meeting the industry
+quality standards? And finally implementing proper guardrails and
+controls on sensitive data in terms of the regulatory where some of the other
+issues discussed.
diff --git a/_summit_transcripts/change_management/summary.md b/_summit_transcripts/change_management/summary.md
new file mode 100644
index 0000000..64b93b3
--- /dev/null
+++ b/_summit_transcripts/change_management/summary.md
@@ -0,0 +1,32 @@
+### The Foundation: Why Before How
+* **Risk Management**: Change management is fundamentally about managing risk
+* **Breaking the IBM Rule**: "No one gets fired for buying IBM" - need to show upsides of change to overcome conservative mindset
+* **Value Proposition**: Emphasize collaboration benefits, AI integration opportunities, and modern capabilities
+
+### Three Pillars of Change Management
+
+#### People
+* **Grassroots vs. Top-Down**: Grassroots efforts have limits; executive support and repeated messaging from leadership essential
+* **Innovation Teams**: Trend toward creating dedicated innovation groups rather than making change management a side job
+* **Hiring vs. Training**:
+ - Just-in-time training more effective than advance training
+ - Trend toward hiring R/Python programmers from day one
+ - Removing SAS requirements from job descriptions
+* **Standards Influence**: Good opportunity to influence internal standards and reset limitations from legacy tools
+
+#### Technology
+* **Git Foundation**: Essential foundation for open source adoption and AI tool integration
+* **Environment Management**: Focus on Statistical Computing Environment (SCE) setup
+* **Containerization**: Important for managing package versioning issues (R+ENV, Docker)
+
+#### Process
+* **Version Control**: Git as key process improvement
+* **Reporting Innovation**: Opportunities to rethink clinical trial reporting (e.g., using Shiny to reduce static TLFs)
+* **Communication Strategy**: Right people delivering right messages, expect pushback, avoid mandate-style approaches
+
+### Key Success Factors
+* **R Validation Hub**: Valuable resource for demonstrating process and risk metrics
+* **Specific Use Cases**: Show concrete examples of complex tables/graphs generated easily
+* **Environment Comfort**: Ensure users feel comfortable in the new environment
+* **Package Management**: Education about dynamic nature of open source vs. traditional single-package updates
+* **Trial Periods**: Implement trials before major investments
diff --git a/_summit_transcripts/change_management/transcript.txt b/_summit_transcripts/change_management/transcript.txt
new file mode 100644
index 0000000..b7ada7c
--- /dev/null
+++ b/_summit_transcripts/change_management/transcript.txt
@@ -0,0 +1,129 @@
+open source change management:
+I think the first thing when it comes to change management
+is the why before we actually talk about the how.
+And I think it's important to keep the perspective
+of change management is about risk.
+And there's a saying that I did not make up
+even though no one at my table had heard about it.
+You can't get, no one has ever gotten fired for buying IBM.
+And that saying means that like,
+if everyone does things a certain way,
+no one's gonna get in trouble if something happens
+with like that way.
+And so you're asking people to change the way
+they do analysis.
+And so management and people who aren't like
+in this room basically see the downsides pretty obviously,
+but then your job as sort of thought leaders
+is to show them the upsides.
+And I think a big one is mentioned stuff
+like collaboration, AI, like I think AI is like oregano,
+everyone wants to sprinkle AI on everything.
+So mission AI and those things,
+and that'll help to make the conversation
+a little bit about like, yes, you see the downsides,
+but moving more towards the upsides.
+I think the R-validation hub is a big, big benefit.
+I think you can show that there is a process,
+you can show stuff like risk metric,
+and that'll sort of help to ameliorate
+some of the concerns about change,
+but it won't eliminate them.
+When it comes to actually making the change,
+I think we talked a little bit about training,
+either buying it or doing it yourself.
+I think one thing to keep in mind
+is that when it comes to training,
+the best training is the training that you do yourself.
+So I think you need to find the right people
+to help make that change.
+I think a big thing about,
+especially open source change management,
+is environment, and I'm talking about like SCE stuff,
+James already solved that, so you're fine,
+but work on your environment,
+make sure that people feel comfortable in that environment,
+especially if there are ways to sort of,
+before you make a big investment,
+do some kind of trials with that.
+For change management, communication is key.
+Make sure you have the right people,
+give the right message.
+I think a lot of people push back
+if you're like, you have to change,
+you have to do it this way now.
+Expect some pushback.
+And then one of the biggest things
+that is a change from closed source analysis to open source
+is a lot of stuff about package issues.
+A lot of companies, they just have like one,
+one single sort of package
+that gets updated every couple of years.
+Obviously, this open source is much more dynamic,
+and so you need to maybe explain a little bit more
+how like software works, because if there's an error,
+it could be that your code is fine,
+but maybe you have a, maybe the version needs to be updated,
+and explaining stuff like packaging,
+and I think a big part of that is containerization,
+either RAM for Docker or something,
+I think that'll make that change process a lot easier.
+
+So we have the, for our roundtable,
+we're talking about open source change management,
+and then we try to tackle that problem
+from the three pillars of change management,
+people, technology, and process.
+And for the people side, we talk about
+to get the momentum started,
+oftentimes we need very specific use cases
+showing that by using our Python,
+we can generate this very complicated tables
+and the graph is very easily.
+And then we talk about that,
+actually grassroot effort can only get us
+to a certain level and at the end of the day,
+we really need kind of top down decisions
+and then those incentives coming from the leadership team
+and also having those messages repeatedly
+like from the leadership team.
+And we see a trend that from mid-size and large companies,
+like there are creation of independent innovation groups.
+So we acknowledge that if like change management
+is a side job of someone's,
+like in complimentary to someone's day job of filing,
+et cetera, it's always getting deprioritized.
+So we see a trend of creating those innovation teams.
+And we talk a little bit about hiring versus training.
+And we talk about for internal training,
+we want to have those just in time training.
+We see many cases that we train people,
+they go back to SAS work and they forgot about the training.
+And it seems like there is a trend that for many companies,
+they start to remove SAS in their job description.
+And we see that people are, for younger generation,
+we are hiring our Python programmers from day zero.
+And then in terms of another thing
+I found very interesting that in terms of people influence,
+we also have some discussion about this is also a good time
+to influence our internal standard group
+because there are many trivial decisions
+in internal standard or limitations
+or historical reasons from like legacy tools
+or legacy technology limitations.
+So it's a good timing to influence them
+and then to kind of like reset the baseline a little bit.
+In terms of technology,
+we spend quite some time talking about Git,
+kind of double click on the conversation this morning.
+Like it's absolutely the foundation of adoption
+of open source languages and also the AI tools.
+In terms of process, we talk about Git again,
+and we also talk about there are also unique opportunity
+for us to rethink about our clinical trial reporting process.
+For example, we see that in some companies,
+like by using Shiny, actually we can reduce number of TLGs
+or even get rid of the generation of static TLF
+for a certain reporting event.
+So I think that there is an opportunity to rethink
+what really makes sense for clinical trial reporting.
diff --git a/_summit_transcripts/cro/summary.md b/_summit_transcripts/cro/summary.md
new file mode 100644
index 0000000..2c5b896
--- /dev/null
+++ b/_summit_transcripts/cro/summary.md
@@ -0,0 +1,24 @@
+### Current Industry Landscape
+* **SAS Dominance**: SAS remains a major part of CRO workflows and processes
+* **Innovation Gap**: Differentiation between innovative CROs (smaller, forward-thinking) and traditional CROs (larger, dominant market players)
+
+### Key Challenges for CROs
+* **Upskilling Requirements**: Need to invest in training staff on new technologies while maintaining SAS capabilities
+* **Dual Technology Management**: Challenge of managing both traditional and modern toolchains
+* **Guidance Dependency**: Many CROs seeking more direction from sponsor companies rather than self-directing change
+* **Business Model Constraints**: Traditional "order taker" model doesn't align well with consulting-style technology guidance
+
+### CRO as Resource vs. Bottleneck
+* **Bottleneck Risk**: CROs can become bottlenecks when trying to figure out technology transitions independently
+* **Valuable Resource Potential**: CROs have extensive cross-client experience that could be leveraged for best practices
+* **Service Evolution**: Pivoting from process-focused to more consultative roles as clients demand technology expertise
+
+### Sponsor-CRO Relationship Dynamics
+* **Timeline Expectations**: Question whether sponsors understand the time required for upskilling and technology changes
+* **Communication Gap**: Need for better understanding between sponsors and CROs regarding transition requirements
+* **Business Model Evolution**: Traditional expectations may need adjustment for new technology paradigms
+
+### Community Engagement
+* **Information Access**: Importance of CROs participating in organizations like R/Pharma for knowledge sharing
+* **Ecosystem Integration**: CROs are significant players in the overall life sciences technology ecosystem
+* **Increased Participation**: Need for more CRO involvement in industry technology discussions
diff --git a/_summit_transcripts/cro/transcript.txt b/_summit_transcripts/cro/transcript.txt
new file mode 100644
index 0000000..d9d40ab
--- /dev/null
+++ b/_summit_transcripts/cro/transcript.txt
@@ -0,0 +1,52 @@
+So yeah, we had a good discussion.
+I'm going to differentiate probably between the more
+innovative CROs that I think are here versus the more
+traditional groups that tend to dominate the industry a lot
+but are obviously a big part of what's going on.
+So the consensus view is that there's
+a big challenge in the CRO space because one,
+SAS is still a big part of the workflow and the process
+that everybody is working through and dealing with.
+And so the requirements to upskill people
+and to change that paradigm, it falls a bit on the CRO.
+And it's a decision that they have to make in terms of how
+they're looking at the market.
+And so I think a lot of these groups
+are looking for maybe more guidance from the sponsor side
+or perhaps sponsors that are more set on a certain path
+as opposed to expecting them to manage both.
+And in that sense, they've become a bit of a bottleneck
+because they're trying to figure it out on their own
+but they don't always know where
+to go in some of these strategies.
+I think the other thing is though
+that we did talk about on the other side of that,
+CROs also can be a really great resource for organizations
+that are looking to make this transition
+because they have a lot of internal experience working
+on a lot of different studies and projects
+across a lot of different clients.
+So they're not often set up to be consultants.
+They're really more kind of order takers
+or process-focused organizations.
+But they're pivoting a bit to try
+to support more of those activities
+as clients are demanding it of them.
+Yeah, I mean, there was a lot of discussion around
+do sponsors understand that the upskilling and the change
+is taking time and that there are certain requirements
+that need to be dealt with?
+And I think there's a question there
+as to whether a lot of sponsors understand that.
+But it also just kind of fits in
+with the business model and the expectations.
+The other big, I guess the other big topic
+everybody discussed is the importance
+of being part of an organization like this
+because there's a lot of information available to people
+as they're trying to work through some of these topics.
+And perhaps an emphasis of getting more CROs involved
+in this discussion could be pretty useful
+because they are a pretty big player
+in the overall kind of ecosystem that we all work in.
+Thank you.
diff --git a/_summit_transcripts/python/summary.md b/_summit_transcripts/python/summary.md
new file mode 100644
index 0000000..5725484
--- /dev/null
+++ b/_summit_transcripts/python/summary.md
@@ -0,0 +1,38 @@
+### Industry Heterogeneity
+* **Medical Devices vs. Pharma**: Different use cases and adoption patterns
+ - Medical device engineers more familiar with Python as standard language
+ - Creates challenges managing multiple languages within organizations
+ - Some companies choosing Python-only approach despite challenges
+
+### Primary Use Cases
+* **Medical Devices**:
+ - Large datasets from device data
+ - Product development beyond just data analysis
+ - Engineering-driven adoption
+* **Pharma Applications**:
+ - ETL processes for speed advantages
+ - Machine learning implementations
+ - Data engineering tasks
+
+### Validation Challenges
+* **R Validation Hub Principles**: White paper was meant to be language-agnostic, principles apply to Python
+* **Trusted Sources**: Questions about what constitutes trusted sources in Python ecosystem
+ - Anaconda, PyPI with RSPM scrutiny mentioned as possibilities
+ - Python ecosystem seen as "wild west" compared to R
+* **Statistical Packages**: Python statistical libraries still developing; roughly 8 years behind R in maturity
+* **Containers**: Discussion of containerization for validation approaches
+
+### Regulatory and Submission Status
+* **Submission Gap**: No Python submissions to regulators yet (unlike R which has established precedent)
+* **Regulatory Acceptance**: Need for groundwork similar to what was done for R submissions
+* **Pilot Programs**: Reference to submission pilots (pilot 15) for future development
+
+### Python vs. R Considerations
+* **GenAI Integration**: Python more prevalent in generative AI development, potentially driving adoption
+* **Large Dataset Handling**: Python advantages for genetic datasets and other large-scale data due to memory limitations in R
+* **Statistical Maturity**: R still ahead in statistical package validation and regulatory acceptance
+
+### Future Directions
+* Need for Python-specific validation frameworks
+* Development of regulatory submission pathways
+* Balancing language choice with organizational capabilities
diff --git a/_summit_transcripts/python/transcript.txt b/_summit_transcripts/python/transcript.txt
new file mode 100644
index 0000000..7a6e087
--- /dev/null
+++ b/_summit_transcripts/python/transcript.txt
@@ -0,0 +1,50 @@
+So a couple of things, I'm going to start with a question that we had more towards the
+end because what is seen from the table that we were is that there is some heterogeneity
+on the usage of it.
+Some people are actually in the medical device space, some people are in the pharma space
+and for medical devices, a lot of the people that have used Python are engineers and they
+are more familiar to this, which end up becoming very much their standard language for them
+to use, which created an interesting thing.
+It becomes very difficult to manage multiple languages sometimes and in this particular
+case, this company has decided that they are just using Python even though there are some
+challenges in that space.
+We have a couple of different topics that we were discussing. One of them is regarding
+the use cases. So of course for medical devices, the use cases are very different than what's
+in pharma. The kind of data that is coming from devices, large data sets, kind of forces
+the use of Python in a different way. There is also a little bit of a medical device space.
+You're also thinking not only about the data analysis but an actual product that's going
+to be created in the end after the data analysis, which is more difficult to be developed in
+R, in that space.
+But I think that one of the things that drives some of the use cases, especially for pharma,
+is speed, and because of that, a lot of ETLs, maybe machine learning, data engineering is
+really the space where pharma is looking into the usage of Python.
+Of course, another team was validation, that James already mentioned a little bit about
+this. What do we do about validation of Python?
+I think when the R validation hub created the white paper, even though it's an R paper,
+it was meant to be language agnostic. We did put a lot of stuff that was there because
+that's what we were working on, but we talked about it. Should we just make this language
+agnostic at the time? We decided not, but I think the principles are the same.
+Of course, it does raise a lot of different questions because there are assumptions in
+the R validation white paper that we do for R that are a little maybe easier to get from
+evidence perspective. For example, what's a trusted source? And what is a trusted source
+in Python?
+I think that we heard in the table that things coming from Anaconda or maybe PyPy with maybe
+some RSPM may be reasonable, but also that you have to put some scrutiny around this
+because it's not, again, Python is more of a wide west in comparison to R. There's just
+so much more stuff going on and we have to have all that in consideration.
+An interesting comment, the statistics in Python, I mean, packages or libraries that
+are doing statistics, I think that what we heard from one person, one company, is that
+the groundwork to make sure that those statistical analysis is being vetted, it's still a little
+early. It's like R was like eight years back maybe, so there's a little bit of that going
+on and that's in the space for Python. There's some discussion in the validation about the
+use of containers and a couple of other questions that you have that we posed in the end was
+Python and GenAI, so as you see, there's a lot of GenAI, when I talk about GenAI, there's
+a lot of stuff that's going on in Python just because it's a more used language and that
+may be driven or driving some of the, where the languages are going. There is some conversation
+about Python versus R and one thing that R is definitely ahead is the fact that submission
+and regulatory acceptance is already being developed, so no one has really got a Python
+submission yet, as far as I know, and that is groundwork that has to be done. Submission,
+pilot number 10, pilot 15, Eric, pilot 15, Eric, for you, and I guess the other thing
+is really in regards to the limitations that may be in R for certain types of data sets,
+gene data sets, genetic data sets and so forth because of the size of the data. Did
+I, is there something else that I, okay, so that's it. Thank you.
diff --git a/_summit_transcripts/quality/summary.md b/_summit_transcripts/quality/summary.md
new file mode 100644
index 0000000..06a33b6
--- /dev/null
+++ b/_summit_transcripts/quality/summary.md
@@ -0,0 +1,42 @@
+### Shiny-Centric Validation Discussion
+* **Dynamic Validation**: Challenges validating Shiny apps with multiple inputs and dynamic UI changes
+* **Cross-Language Validation**: Interesting approach using different languages (e.g., SAS) to validate Shiny outputs
+* **User-Centric Testing**: Need for dynamic validation of user interactions beyond business logic validation
+
+### Package Validation Approaches
+* **Environment Types**: Companies building both exploratory and validated GXP environments
+* **Validation Cycles**: Range from every 6-12 months to agile approaches completing validation in hours
+* **Speed vs. Compliance**: Demonstration that speed and compliance can coexist with proper processes
+
+### Infrastructure Management
+* **Container Strategy**:
+ - Managing multiple packages and images is challenging
+ - Base images specific to projects or therapeutic areas recommended
+ - Kubernetes as standard for container management
+ - Container sizing remains technical challenge
+* **Image Management**: Need for structured approach to container proliferation
+
+### Package Transparency Benefits
+* **Open Source Advantage**: Unlike SAS, can see how bugs are identified and resolved
+* **Visibility**: Access to bug reports and fixes provides better understanding than closed-source alternatives
+* **Internal Package Standards**: Internal packages should follow same validation processes as external packages
+
+### Testing Standards and Practices
+* **Separation of Roles**: Testers should be different from developers
+* **Validation Definitions**: No industry standard for what "validated package" means - companies define their own criteria
+* **Reproducibility**: Focus on reproducible code as foundation for validation
+
+### GenAI Integration Challenges
+* **Output Validation**: GenAI outputs need reproducible code that can be tested and validated
+* **Documentation Transparency**: Suggestion to identify AI-generated documentation for additional scrutiny
+* **AI-Assisted Review**: Mixed opinions on using AI bots to evaluate tests - could be useful but may reduce human vigilance
+
+### Emerging Tools and Technologies
+* **Testing Innovation**: New automated testing tools with reporting and screenshots coming from vendors
+* **ShinyTest Evolution**: Improvements in Shiny testing capabilities
+* **Teal vs. ShinyMeta**: Teal's approach to reproducible scripts gaining more adoption than ShinyMeta
+* **DuckDB Integration**: Promising for handling large data in Shiny applications without full database overhead
+
+### Backward Compatibility
+* **R Perception vs. Reality**: Addressing misconceptions about R's backward compatibility
+* **Documentation Needs**: Importance of documenting package versioning and major changes
diff --git a/_summit_transcripts/quality/transcript.txt b/_summit_transcripts/quality/transcript.txt
new file mode 100644
index 0000000..431413e
--- /dev/null
+++ b/_summit_transcripts/quality/transcript.txt
@@ -0,0 +1,115 @@
+very much a Shiny-centric kind of spin to our validation
+discussion, where we had some interesting use cases about how
+Shiny, of course, you can set a lot of inputs
+and make dynamic changes in your UI of whatever
+table or plot you're making.
+But then when you want to actually validate
+the results of those selections, there
+were some interesting cases where
+you might use a different even language in and of itself
+to do that, such as SAS, to look at how those outputs are
+being generated.
+So that was an interesting idea I never really thought about.
+But it also underscored the importance of,
+it's one thing just to do the business logic
+kind of validation.
+I talked about my morning session.
+But you do need that kind of user-centric, dynamic look
+at what outputs you're generating
+and making sure you're on track with validating those.
+So I think there's some opportunity
+to learn from each other on that side of it, too.
+And then, actually, you, Phil, you
+had a great comment about the number of conferences,
+some of the stigma that R has is a, quote unquote,
+lack of backward compatibility, which I personally
+wonder where that's coming from, especially
+what BASE are, because they are very rigid to changing.
+But there are, obviously, things you
+need to consider with how you manage,
+say, your package versioning and documenting
+whenever big changes are occurring there, too.
+And then trying to think back on whatever parts we talked about.
+I think we talked about ShinyTest.
+Oh, yeah.
+And we also talked about ways to do testing in Shiny,
+specifically with ShinyTest, too.
+And there was some interesting new tooling
+that's coming out from our friends at the Taurus,
+it sounds like, coming up very soon with augmenting
+that with automated reporting and screenshots
+that we're going to be eager to see as we go forward
+with that side of it, too.
+One last thing, we talked about ShinyMeta and Teal.
+Yep.
+And then, yeah, exactly.
+So then Teal came up quite a bit, as we often
+see, that's a great use case to get buy-in from an organization
+to leverage Shiny in the clinical area.
+But then you think about how they
+are approaching creating those reproducible scripts
+that you can get to, in essence, carry out
+what you did in the Teal app.
+And they went away from the ShinyMeta route
+that, Rosie, who had been at our farm before,
+that package from Posit actually was
+born from conversations with some of us
+with the Shiny team back then.
+But it never really got as much adoption
+as I think maybe it was anticipated.
+So we are interested to see the way Teal conducts this,
+if that's a pattern that ends up being
+more standard in the future, always
+learning from what's working well there
+and maybe where that can go in the validation discussion
+when you think about teams that say, oh, you
+did that great analysis in that app,
+but I need to be able to run that in a month from now
+or even a year from now, maybe to answer a question.
+So we do see some intriguing ideas
+that Teal has pioneered with getting those scripts out there.
+And last, but certainly not least,
+there were some questions about how to handle larger data
+in apps.
+And myself and others were quick to literally mouth off.
+DuckDB is a very promising approach
+so that you can have that within that environment database
+feature, but yet you're not overhead of a Postgres
+or even NoSQL database that often came up, too.
+But we think DuckDB and Shiny is a great combination
+for big data analytics that I think
+will play nicely in Noveltoon in the future.
+
+So we were talking mostly about package validation during both validation roundtables, and there
+are companies that they already built both the exploratory and the validated GXP environments,
+and there are a lot of companies that are just building the GXP environments, and the cycles and
+the processes vary, and there could be an approach where the validation cycle takes,
+that happens every six or even every 12 months. However, there is one company that takes more
+agile and fluid approach where the package validation can be completed in just a few hours,
+and I think that demonstrates that both speed and compliance can coexist in a proper process.
+And we discussed that managing the infrastructure actually is a challenge with a lot of packages
+and a lot of images being created, and that a good approach that can be taken in the future is to
+create a base image that can be specific per project or specific for a therapeutic area,
+and this is a container, and Kubernetes seem to be the standard for managing those.
+And however, container sizing continues to present a technical challenge.
+What else? We also discussed that the transparency for our packages packs,
+that this is actually a positive thing, because with SAS you don't really know,
+you only know about your own bag that you submitted, but you don't know about the other
+bags, and they for sure exist, and with the open source you get access, you see what happens,
+and you see how those bags are resolved, so we thought that this is actually a good thing.
+And we also agreed that internal packages, they should follow the same process as external packages,
+so there needs to be testing, and that actually testing, the tester should be a separate person
+than the developer. And we also covered a bit the topic of testing, thank you, testing the GenAI
+outputs, and we concluded that basically there needs to be a code that is reproducible,
+and this needs to be tested, and this needs to be validated as well. And I think one more thing
+that was quite interesting is that we don't have a standard what the validated package means,
+and that every company basically defines their own way what it means that the package is validated.
+And regarding also the GenAI principles and validating the outputs, we thought that right
+now, basically we have to decide on principles regarding the GenAI, because right now we don't
+state that, for example, the documentation was generated by the GenAI, and we thought that this
+would be valuable, because this gives additional context, and it can mean that you also would pay
+additional extra attention to that part, because you know that this was not generated by the human.
+And last but not least, we discussed whether AI bot to help evaluate if the test is good,
+it can be something useful, and it can be used as an extra pair of eyes. There were mixed opinions
+that yes, this could be useful, however, this can also make the reviewers a bit mindless,
+because they would rely too much on the advice and the output from the bot. Thank you.
diff --git a/_summit_transcripts/sce/summary.md b/_summit_transcripts/sce/summary.md
new file mode 100644
index 0000000..c33b8bd
--- /dev/null
+++ b/_summit_transcripts/sce/summary.md
@@ -0,0 +1,41 @@
+### SCE Components (5 Core Elements)
+1. **IDE**: Development environment interface
+2. **File and Version Management**: Source control and file handling
+3. **Data and Access**: Data storage and access management
+4. **Governance**: Policies and compliance frameworks
+5. **Compute**: Processing and computational resources
+
+### Scope and Architecture Challenges
+* **Historical Separation**: Legacy approach had separate SCEs for GXP work vs. everything else
+* **Unified Direction**: Most companies moving toward single SCE for all work
+* **User Diversity**: Modern SCEs serve PK, Biostatistics, Stats Programming, and other groups on same platform
+
+### Vendor Considerations
+* **Ecosystem Promises**: Vendors offer packaged solutions but create vendor lock-in concerns
+* **Missing Integrations**: Gaps in vendor offerings, sometimes strategically maintained
+* **Cost Management**: Total cost of ownership concerns when using multiple vendors
+* **Integration Overlap**: Redundancy between different vendor products increases costs
+
+### Validation Challenges
+* **Timeline**: Validation processes take months (up to 3 months reported)
+* **Test Suite Maintenance**: Significant burden maintaining test suites as platforms change
+* **IDE Validation Debate**: Whether to validate IDE as part of environment or keep separate
+* **System vs. Process**: Best practice is qualifying systems while validating processes
+
+### Technology Evolution
+* **Python Integration**: Coming into clinical reporting, mainly for transformations
+* **Python Validation Gap**: Lacks standardized documentation and testing frameworks compared to R
+* **Data Format Shift**: Parquet replacing SAS7bdat as standard data format
+* **Package Governance**: Some companies using opinionated lists of approved R packages
+
+### Environment Management
+* **Update Cycles**: 3-6 months common window for base environment updates
+* **Package Coupling**: Most companies couple R packages with environments (some decouple)
+* **Environment Tracking**: Tools to flag whether environments are managed/production-ready
+* **Consistency Requirements**: Containers must be accessible across SCE, Shiny apps, HPC, etc.
+
+### Version Control and Data Access
+* **Git Adoption**: Standard direction but significant change management challenges
+* **Learning Curve**: Git presents training challenges for traditional SAS users
+* **Data Access Complexity**: Challenges with data access in Shiny applications
+* **Technology Solutions**: Denodo and AWS Data Zone mentioned for data access management
diff --git a/_summit_transcripts/sce/transcript.txt b/_summit_transcripts/sce/transcript.txt
new file mode 100644
index 0000000..f6d7de9
--- /dev/null
+++ b/_summit_transcripts/sce/transcript.txt
@@ -0,0 +1,97 @@
+and David's.
+So we start off saying there's three components to an SCE,
+and then we listed out five different components.
+So the first one was the IDE, there's
+file and version management, data and access, the governance,
+and then the actual compute.
+In terms of scope, I don't think we had an agreed scope for what
+actually is in an SCE.
+Historically, that might be defined
+by department structure, and it seemed
+it was kind of a common theme that in the legacy world,
+you had an SCE for GXP work and an SCE for everything else.
+And it seemed most companies want to have
+a single SCE going forwards.
+We talked a little bit about vendors
+and how some vendors kind of promise to package everything
+together into an ecosystem.
+But people tend to be quite a little bit afraid of that
+because of vendor lock-in.
+And also, there's often missing integrations.
+And I think we were hypothesizing
+some of those are strategic to kind of force
+you to stay within the ecosystem.
+We, yeah, there are a couple of platforms specifically
+called out for that.
+And I think one comment that was made
+is there's also that kind of concern
+around the total cost of ownership.
+So if you have to string together
+a whole bunch of different vendors to build your SCE,
+you kind of start ballooning the costs.
+And there's overlap between the different vendor products.
+And at least in the modern SCEs, there's
+often really diverse users in there,
+like PK, Biostat, Stats Programming, and other groups
+all on the same platform.
+Validation takes a long time.
+I think my own company seemed to be longest at three months
+to validate the SCE.
+But it seemed it was always a kind of a slow process.
+And the test suites themselves add a lot of burden
+just to maintain those because you
+have to update the test suites whenever something
+changes in the platform.
+There's a bit of a debate whether the IDE should
+be part of the validation environment
+or should it be kept outside.
+So the IDE is kind of repeated across
+as a layer on top of your validated containers.
+And there was a discussion also on,
+do we validate a system or a process?
+And I think the best practice was to qualify the systems
+and focus validation just on the process.
+A few companies mentioned Python was coming in.
+So this is in the clinical reporting space,
+usually for transformations.
+How to validate Python is a challenge, though,
+because it doesn't have a standardized documentation
+and testing framework like R. I think one company mentioned
+that they have an opinionated list of R packages.
+So you can't just get any package validated.
+They tried to put some governance on what
+are the packages they're validating.
+Parquet seems to have replaced SAS7bdat
+as the data format within modern SCEs.
+For environment management, either three or six months
+seems to be a common window to update the base environments.
+A couple of companies decoupled the R package
+from the environment, but that doesn't seem to be the norm.
+One company mentioned that they have a tool.
+So if the users are kind of interactively
+modifying their environments, it can flag whether that
+environment is one of the managed ones
+for a production run and could also
+tell if it was an upcoming planned environment,
+which I thought was a cool thing to open source
+if that company was interested.
+And it was really important to think about
+consistency of environments.
+So if you have a container in the SCE,
+the Shiny app should also be able to access that container.
+The HPC should be able to access that container and the like.
+And the last two topics, one of them was
+Git for version control.
+It seemed that was the direction most companies are going in,
+but we really had to acknowledge
+there was a change management issue there
+with the learning curve.
+And we discussed some of the complications
+around data access, particularly in Shiny.
+So kind of passing through the viewer
+of the application's data access.
+And there was mention of a couple of technologies to help.
+One was Denodo, and also AWS's data zone
+as a way of kind of putting a middle layer
+to help manage that.
+Thank you.
diff --git a/build_nixconfig.R b/build_nixconfig.R
new file mode 100644
index 0000000..e1fdbab
--- /dev/null
+++ b/build_nixconfig.R
@@ -0,0 +1,14 @@
+library(rix)
+
+rix(
+ r_ver = "4.5.1",
+ r_pkgs = c(
+ "quarto",
+ "knitr"
+ ),
+ system_pkgs = c("quarto"),
+ ide = "none",
+ project_path = ".",
+ overwrite = TRUE,
+ print = TRUE
+)
diff --git a/default.nix b/default.nix
new file mode 100644
index 0000000..187ac11
--- /dev/null
+++ b/default.nix
@@ -0,0 +1,49 @@
+# This file was generated by the {rix} R package v0.17.2 on 2025-09-19
+# with following call:
+# >rix(r_ver = "4.5.1",
+# > r_pkgs = c("quarto",
+# > "knitr"),
+# > system_pkgs = c("quarto"),
+# > ide = "none",
+# > project_path = ".",
+# > overwrite = TRUE,
+# > print = TRUE)
+# It uses the `rstats-on-nix` fork of `nixpkgs` which provides improved
+# compatibility with older R versions and R packages for Linux/WSL and
+# Apple Silicon computers.
+# Report any issues to https://github.com/ropensci/rix
+let
+ pkgs = import (fetchTarball "https://github.com/rstats-on-nix/nixpkgs/archive/2025-09-16.tar.gz") {};
+
+ rpkgs = builtins.attrValues {
+ inherit (pkgs.rPackages)
+ knitr
+ quarto;
+ };
+
+ system_packages = builtins.attrValues {
+ inherit (pkgs)
+ glibcLocales
+ nix
+ quarto
+ R
+ which
+ pandoc;
+ };
+
+ shell = pkgs.mkShell {
+ LOCALE_ARCHIVE = if pkgs.system == "x86_64-linux" then "${pkgs.glibcLocales}/lib/locale/locale-archive" else "";
+ LANG = "en_US.UTF-8";
+ LC_ALL = "en_US.UTF-8";
+ LC_TIME = "en_US.UTF-8";
+ LC_MONETARY = "en_US.UTF-8";
+ LC_PAPER = "en_US.UTF-8";
+ LC_MEASUREMENT = "en_US.UTF-8";
+
+ buildInputs = [ rpkgs system_packages ];
+
+ };
+in
+ {
+ inherit pkgs shell;
+ }
diff --git a/hyatt_regency.png b/hyatt_regency.png
new file mode 100644
index 0000000..78cc287
Binary files /dev/null and b/hyatt_regency.png differ
diff --git a/index.qmd b/index.qmd
new file mode 100644
index 0000000..501779a
--- /dev/null
+++ b/index.qmd
@@ -0,0 +1,202 @@
+---
+title: "R/Pharma Summit"
+subtitle: "In-person event • Monday, September 15, 2025 • Atlanta, GA"
+format:
+ html:
+ toc: true
+ toc-depth: 3
+ theme: cosmo
+ number-sections: false
+ css: styles.css
+---
+
+# Background
+
+In 2018 and 2019, **R in Pharma** was in-person at Harvard University and focused on opportunities for direct interaction with speakers and guests.
+These relationships and connections have grown into many exciting areas of Open Source drug development.
+
+- In **2023** we partnered with *Posit*, hosting an in-person session at posit::conf(2023) in Chicago.
+- In **2024**, the session continued at posit::conf(2024) in Seattle.
+- We’re thrilled to bring this back at **posit::conf(2025)** in Atlanta! 🎉
+
+---
+
+Over the last five years we’ve seen an explosive growth in the use of R and other open source technologies across drug development, with an increasing focus on **pan-company collaboration**.
+
+The R/Pharma Roundtable Summit provides an **open, collaborative, and inclusive environment** to:
+
+- Share learnings
+- Understand common themes across our industry
+- Establish collaboration opportunities
+
+The focus is to foster **in-person discussions** about key items such as *reproducibility* and *submissions*, much like the original Harvard events.
+
+> 🔗 Review the 2023–2024 roundtable summaries here:
+> [rinpharma.github.io/roundtables](https://rinpharma.github.io/roundtables/)
+
+---
+
+## Call for Input
+
+::: callout-note
+**You can contribute to the discussion about the final agenda!**
+Join the GitHub discussions here:
+👉 [rinpharma-summit-2025 Discussions](https://github.com/rinpharma/rinpharma-summit-2025/discussions)
+:::
+
+---
+
+# Location
+
+::: callout-important
+**Hyatt Regency Atlanta**
+265 Peachtree St NE
+Atlanta, GA 30303, USA
+Meeting Room: **Regency VII**
+
+{fig-align="center" width="80%"}
+
+
+:::
+
+---
+
+# Agenda
+
+::: {.agenda-table}
+| Time | Chair | Description |
+|---------------|------------------------|-----------------------|
+| **9.15am** | | Intro to day |
+| **9.30–10am** | James Black / Orla Doyle / Phil Bowsher | ROI on Open Source |
+| **10–10.45am** | Eric Nantz / Paulo Bargo | Navigating Quality |
+| **10.45–11.05am**| | Bio-break |
+| **11:05–12:15pm** | Devin Pastoor / Jeremy Wilfire, Joe Cheng, Eric Nantz | GenAI Discussion Panel |
+| **12:15–1:30pm** | | Lunch
+:::
+---
+
+## Roundtables
+
+### 1. AI in Pharma
+##### Chairs: Jeremy Wildfire, Sri Pavan Vemuri, Satish Murthy
+- Best Practices for AI-Assisted R Coding
+- What would an "AI-friendly" submission look like?
+- Reimagine open-label trial deliverables with interactive display/AI
+- Best Practices for AI Integration in Data Workflows
+- *Create more tables if needed for GenAI*
+
+### 2. Validation in 2025
+##### Chairs: Olga Mierzwa-Sulima, Eric Nantz, Paulo Bargo
+- Validating Open Source Tools with Stochastic Components
+- Architectures to provision validated R packages
+
+### 3. Python for Clinical Study Reports and Submission
+##### Chairs: Yilong Zhang, Jonathan Tisack
+- Medical Devices
+
+### 4. SCEs in 2025
+##### Chairs: David Thiriot, Phil Bowsher, James Black
+- Open-source infrastructure to complement **openstatsware** and the **pharmaverse**
+- Expanding the Pharmaverse beyond Clinical Reporting
+
+### 5. Open-Source Change Management
+##### Chairs: Ning Leng, Nate Mockler
+- From Hacks to Habits — Tools & Tricks That Changed the Game
+
+### 6. Implementation / Perspectives of CROs
+##### Chairs: Douglas Henry, Steven Tan
+- Expanding the Pharmaverse beyond Clinical Reporting
+
+# Audience
+
+These round tables are for you if:
+
+- You are an active contributor to the adoption of data science best practices across drug development
+- You sponsor data science codebases
+- You are an informatics professional designing and implementing **GxP-conforming** data science platforms
+- You are interested in cross-pharma collaboration
+
+---
+
+# Round Table Advisory Board
+
+A mix of 50 people from various pharmaceutical companies, CRO and organization supporting the advancement of open source for drug development and clinical reporting.
+
+---
+
+# Organising Committee
+
+- Phil Bowsher — *Posit*
+- James Black — *Roche*
+- Harvey Lieberman — *Novartis*
+- Katie Igartua — *Tempus*
+
+This summit is run by [Open Source in Pharma](https://opensourceinpharma.com/), a non-profit aiming to support the use of open source languages in Pharma.
+
+# Roundtable Summaries
+
+During the R/Pharma summit, each roundtable session chair shared a summary of their group's discussion at the conclusion of the event. This year, we recorded the audio of these summaries to local `mp3` audio files, and leveraged the OpenAI `whisper` audio transcription LLM run entirely locally on a computer to generate transcripts of the audio summaries. Lastly, these transcripts were summarized using the Anthropic model within Positron Assistant to create summaries of these transcripts. You can view the summaries and source transcripts of the roundtable sessions below.
+
+## AI in Pharma
+
+::: {.callout-note title="Summary" collapse="false"}
+{{< include _summit_transcripts/ai/summary.md >}}
+:::
+
+::: {.callout-note title="Source Transcript" collapse="true"}
+{{< include _summit_transcripts/ai/transcript.txt >}}
+:::
+
+## Quality & Validation in 2025
+
+::: {.callout-note title="Summary" collapse="false"}
+{{< include _summit_transcripts/quality/summary.md >}}
+:::
+
+::: {.callout-note title="Source Transcript" collapse="true"}
+{{< include _summit_transcripts/quality/transcript.txt >}}
+:::
+
+## Python for Clinical Study Reports and Submission
+
+::: {.callout-note title="Summary" collapse="false"}
+{{< include _summit_transcripts/python/summary.md >}}
+:::
+
+::: {.callout-note title="Source Transcript" collapse="true"}
+{{< include _summit_transcripts/python/transcript.txt >}}
+:::
+
+## SCEs in 2025
+
+::: {.callout-note title="Summary" collapse="false"}
+{{< include _summit_transcripts/sce/summary.md >}}
+:::
+
+::: {.callout-note title="Source Transcript" collapse="true"}
+{{< include _summit_transcripts/sce/transcript.txt >}}
+:::
+
+## Open-Source Change Management
+
+::: {.callout-note title="Summary" collapse="false"}
+{{< include _summit_transcripts/change_management/summary.md >}}
+:::
+
+::: {.callout-note title="Source Transcript" collapse="true"}
+{{< include _summit_transcripts/change_management/transcript.txt >}}
+:::
+
+## Implementation / Perspectives of CROs
+
+::: {.callout-note title="Summary" collapse="false"}
+{{< include _summit_transcripts/cro/summary.md >}}
+:::
+
+::: {.callout-note title="Source Transcript" collapse="true"}
+{{< include _summit_transcripts/cro/transcript.txt >}}
+:::
\ No newline at end of file
diff --git a/max_lagers_wood_fired_grill.png b/max_lagers_wood_fired_grill.png
new file mode 100644
index 0000000..aabddc9
Binary files /dev/null and b/max_lagers_wood_fired_grill.png differ
diff --git a/.github/DISCUSSION_TEMPLATE/deliverable.yml b/old_files/.github/DISCUSSION_TEMPLATE/deliverable.yml
similarity index 100%
rename from .github/DISCUSSION_TEMPLATE/deliverable.yml
rename to old_files/.github/DISCUSSION_TEMPLATE/deliverable.yml
diff --git a/.github/DISCUSSION_TEMPLATE/roundtable.yml b/old_files/.github/DISCUSSION_TEMPLATE/roundtable.yml
similarity index 100%
rename from .github/DISCUSSION_TEMPLATE/roundtable.yml
rename to old_files/.github/DISCUSSION_TEMPLATE/roundtable.yml
diff --git a/.github/workflows/contrib.yml b/old_files/.github/workflows/contrib.yml
similarity index 100%
rename from .github/workflows/contrib.yml
rename to old_files/.github/workflows/contrib.yml
diff --git a/.github/workflows/jekyll-gh-pages.yml b/old_files/.github/workflows/jekyll-gh-pages.yml
similarity index 100%
rename from .github/workflows/jekyll-gh-pages.yml
rename to old_files/.github/workflows/jekyll-gh-pages.yml
diff --git a/LICENSE b/old_files/LICENSE
similarity index 100%
rename from LICENSE
rename to old_files/LICENSE
diff --git a/old_files/README.md b/old_files/README.md
new file mode 100644
index 0000000..6a41320
--- /dev/null
+++ b/old_files/README.md
@@ -0,0 +1,120 @@
+# R/Pharma Summit (in-person event Monday, September 15)
+
+## Background
+
+In 2018 and 2019, R in Pharma was in-person at Harvard University and focused on opportunities for direct interaction with speakers and guests. These relationships and connections have grown into many exciting areas of Open Source drug development. In 2023 we partnered with Posit, hosting an in-person session at posit::conf 2023 in Chicago and 2024 in Seattle. We're thrilled to bring this back at posit::conf 2025.
+
+Over the last 5 years we’ve seen an explosive growth in the use of R and other open source technologies across drug development, with an increasing focus on open source projects and pan-company collaboration. In this 1-day series of roundtables we aim to provide an open, collaborative, and inclusive environment to share learnings, understand common themes across our industry, and establish collaboration opportunities. The focus of the R/Pharma Roundtable Summit is to foster in-person discussions and conversations about key items (reproducibility, submissions etc.) as we did at Harvard.
+
+Posit and R/Pharma are excited to announce that the R/Pharma Roundtable Summit is returning for posit::conf(2025). Over the last few years, representatives from ~40 companies met in-person to discuss some of the most pressing topics pharma is tackling to bring data science to late stage development. We are excited to continue the conversations this year on September 15th in Atlanta. The in-person R/Pharma program at posit::conf(2025) will focus on the future of drug development using open source and tailoredfor program leaders and people leading Open Source initiatives. The 2023/4 review of the Summit (then called 'round-tables') is here: https://rinpharma.github.io/roundtables/
+
+During the 2025 R/Pharma Summit, facilitators will foster in-person discussions and conversations about key items (reproducibility, interactivity, submissions, scalability, etc.) with industry leaders about open-source tools for next-generation submissions.The 2024 advisory board, shaping the agenda and planned actions for the event, spans >10 pharma companies, as well as CROs and academic research centers.
+
+**You can contribute to the discussion about the final agenda via this collection of github discussions**: https://github.com/rinpharma/rinpharma-summit-2025/discussions
+
+___
+
+## Location
+
+> HYATT REGENCY ATLANTA
+>
+> Room TBD
+>
+> 265 Peachtree St NE
+>
+> Atlanta, GA 30303, USA
+
+
+___
+
+## Agenda
+
+| Time | +Chair | +Description | +
|---|---|---|
| 8.50am | ++ | Intro to day | +
| 9-10am | +James / Orla / Phil | +ROI on Open Source | +
| 10-11am | +Eric / Paulo | +Navigating Quality | +
| 11-11.15am | ++ | Bio-break | +
| 11.15-12.30pm | +Devin / Jeremy | +GenAI | +
| 12.30-1.30pm | ++ | Lunch | +
| 1.30-4pm | +James + other chairs | +Round tables Split into 2 sessions of 1hr with short break between sessions. People are welcome, but do not need to stay at a round table for the full 1 hour. |
+
| 4-4.45pm | +Round table chairs | +Chairs report back notes, and any planned follow up | +
| 4.45-5pm | +Phil Bowsher (Posit) | +Wrap up | +
| 6:30pm-9.00pm | +Social event | ++ |