Translating Design Thinking Into Solutions

In the previous post, I described how Design Thinking was applied by the UX for Life Sciences working group at the Pistoia Alliance to design new software solutions. But once you’ve gone through the Design Thinking workshops, and produced the requisite reports, you still have to produce software. How do you cover that last mile and translate a paper-or PowerPoint prototype into a fully functional prototype with the least amount of effort?

There are three artifacts from the Design Thinking process that can help you get started. The design guide, the storyboard and the actual prototype itself. Let’s start with the design guide first because heretofore we haven’t really talked about it and it’s an important part of the process.

Design Guides

Design Guides typically provide developers with solutions to common design problems. How can I make a page layout that works for a mobile device, a tablet, and a desktop? Or how can I make a component that lets me invite users to a meeting? Should that component be a simple list of users, or should it be an autocomplete component that displays a “chip” containing the user’s picture and their name?

If you’re Google, you create the Material Design Guide to help developers solve these common problems. You spend years studying user interactions on a wide variety of devices. You use the Design Thinking methodology to develop software, and learn what differentiates a good user experience from a bad one. You then distill that research into the Material Design Guide.

And in order to make sure that developers start using it, you launch Material Design in front of thousands of developers at the annual Google IO developer conference. You teach developers how to implement material design concepts in their own software, and seed the development community with Material-compliant components for Android & web development.

The Material Design Guide itself is a specification that shows what a component should look like, and how the user expects to be able to interact with it. But the goal of the guide is to provide a developer with a road tested guide to creating user interfaces that will always appear consistent to a user. Why do this? Because developers are notoriously bad at creating user interfaces that are appealing to users. To be fair, a developers priorities are usually “make it work, first; make it pretty, second”.

And because “making it pretty” is always a lower priority, it sometimes falls off the To Do list. If you’re a user, this can leave you in a situation where you’re staring at the screen, unable figure out how to accomplish the task at hand. However, if the developer has followed the design guide, then everything you see on the screen should be familiar to you. You should have seen it a hundred times before in the applications on your phone or desktop.

How Does A Pharmaceutical Company’s Design Guide Differ From Material Design?

In pharmaceutical companies, marketing organizations have traditionally used Design Guides, similar to Material Design, to insure that external, customer-facing websites adhere to corporate graphic standards (i.e logos, icons, colors, and typography). In addition these guides often insure that drug information websites provide clear and consistent information to the customers and patients they serve. You might see guidance for representing drug label information, or usage recommendations (the types of patients this medicine is intended for), adverse event reporting, drug procurement assistance, etc. Since some of this information has regulatory requirements, and the guide must insure that a developer has all the information necessary to comply with the appropriate regulations. You can take a look at the Taltz website to get some idea of the types of information typically presented.

How can design guides help research organisations?

As we’ve seen previously, design guides can help research organizations minimize training requirements for software by insuring that internally developed software has a consistent look and feel to it. Design guides can be used to make developers aware of existing components that can address particular requirements, and specify CSS styling requirements. Moreover, as vendors begin adopting similar standards, the line between vendor supplied solutions, and internal software begins to blur.

All of these factors have a direct bearing on how the software is perceived by its users. Even at the prototyping stage, design guides can help insure that user interfaces are easy to understand and familiar. Design guides can include printable PDF templates for components which Design Thinking teams can use in their prototyping efforts. They can also include images of components that can be imported into Keynote or PowerPoint mockups.

Using Storyboards

Storyboards help us understand the flow of the application. They help us visualize what the user is trying to accomplish, and the steps that they go through to accomplish it. Since there may be a number of use cases that use the same screens, you may have multiple storyboards that describe these flows. Moreover, storyboards help us understand the upstream and downstream processes and the handoffs between them that have to be supported.

Let’s suppose for a moment that you’re implementing software that will help users analyze LC/MS data. You map out the process for how the data will be analyzed, how significant results are identified, how AUC calculations will be made, etc. You work with users to identify test cases, identify test data sets, and expected results. And you’re off to the races.

But you’ve forgotten to ask what comes before and after this process. What format does the data arrive in? Is raw instrument data used or is it pre-processed? What about afterwards? Is the data stored in the database? Do you need to archive the raw results that you started with, or just the analyzed results? Are the analyzed results to be stored in a database, or in a report? How will the data be used? By whom, and for what purpose?

With a complete storyboard however, the answers to these questions are readily apparent.

Using Prototypes

Prototypes help us understand how the user will be using the components present on the screen. They help us understand everything from the data that needs to appear on the screen to the permissions needed to see or interact with the components. The real value of a prototype is that it delays developer’s immediate inclination to start creating software when they don’t fully understand the problem. Creating a functioning prototype with working code and sample data will often take longer than the average 5 day design sprint, but it gives us a really good idea of what has to be built. It gives us an idea of the complexity of the software, the use cases to be supported, the roles that need to be defined, and the data types that we need to work with.

The prototype also insures that both the user and the developer have a common understanding of what’s expected of the software.

You can use the prototype to estimate the effort required, plan development sprints, and identify test cases and test data, In the end, you minimize the risks that come from misunderstandings.

Tip 1 – Use A Template

During the sketching stage of the Design Thinking process, you’ll find the JoyTong template useful for sketching user interfaces. This stainless steel template has common icons and fields needed to create a professional looking user interface with a minimum amount of work.

Tip 2 – Use Paper Templates

The UXLS group has a number of paper templates and guides that can help you get started.

Tip 3 – Use Prototyping Tools

During the prototyping stage of the Design Thinking process, there are a number of tools that can help you with your prototyping efforts. If your company users Google Docs, try the Balsamiq plugin, Draw.io, Gliffy or LucidCharts. These tools make it easy to prototype user interfaces in a collaborative fashion. Multiple users can work on the same user interface at the same time.

Reusability – The Last Mile

At some point in the prototype-test iterations that you’re making, when both the developer and the user are confident that the paper prototype accurately represents the necessary solution, you’ll pull the trigger and start writing code. This is the most expensive part of the process but there are ways that you can minimize development costs and provide flexible, reusable solutions.

Web Components

Over the last 5 years a new W3C standard for reusable components has emerged. Championed initially by Google, the standard has been widely adopted by browser vendors. Web components are a combination of an HTML template, CSS and Javascript. Google’s implementation of the standard (known as Polymer) has evolved rapidly over the years, but with the latest release, we see increasing support for the new standard in frameworks like React, Vue, and Angular. You can see a sample component here.

Companies like BBVA, Comcast, Google, ING, USA Today and others are using web components. In the pharmaceutical industry,

Web components are Javascript based, and make use of ES6 standards like classes, template literals, and module imports. They also use the Node Package Manager (npm) to manage dependencies. This means that tooling support for web components is already available in popular text editors like Visual Studio Code, Atom and Sublime. So you have code navigation, intellisense, templating, unit testing and debugging support.

At their core, web components provide 3 key pieces of functionality: templating, data binding and shadow DOM. The first two are pretty self explanatory, but the shadow DOM is a means of insuring that the scope of CSS styling for a component begins and ends with the boundary of the component. This means that you can’t accidently apply a CSS style on your website that corrupts the look of your component. That said, there are some perfectly reasonable use cases for applying styles across multiple components (i.e. theming) and there is currently a spec underway at the W3C to support theming.

The Polymer includes a command-line interface application called polymer-cli which includes a Node.js Express server, support for building, linting, and minification. The build command can generate highly optimised code that targets specific generations of browsers. So if you’re targeting browsers that understand the ES6 Javascript standard, you can tell your build file to generate the appropriate files. The polymer server is also capable of identifying browser and serving a code bundle appropriate for that particular browser.

Google’s Paper components implement the Material Design 1.0 specification, and the new Material Components (currently in development) support Material Design 2.0. But Google isn’t the only purveyor of Material-compliant components. There are many components that follow the specification created by third parties. The webcomponents.org site contains thousands of components from Google, Vaadin and individual developers which you can easily add to your project.

In addition, the biojs project has a catalogue of web components specifically designed for bioinformatics projects. These open source components developed by academic research institutions include PDB viewers, Cytoscape viewers, sequence annotation viewers and more. There are a couple of caveats with this project: (1) that the components aren’t guaranteed to be material compliant, and (2) the components aren’t necessarily compliant and interoperable with the latest version of Polymer.

The Polymer Starter Kit (which comes as part of the polymer-cli tool) provides you with starter projects that you can quickly adapt to suit your purposes. These templates include a store application, and a Progressive Web App (PWA). PWAs are a set of technologies that allow web applications to be installed on mobile devices and desktops. These technologies include ServiceWorker (an API for caching network requests), and the web manifest (which determines how an application will appear on a mobile device).

Since web components are a Javascript/HTML based standard, this means that you can incorporate them within your existing applications. Moreover, you can create a web application and serve it using any web server. The advantage to this is that the front-end of your web application can be served by an Apache server running in your data center or an NGINX server in the cloud. By separating the front and back-end of your application to create a microservices based architecture, you’re no longer tied to a specific monolithic stack, and thus no longer tied to the long upgrade cycles often imposed on research informatics teams.

REST Services

REST Services are a standard for invoking and communicating with backend services. REST stands for REpresentational State Transfer. These services can persist and query data, and are widely supported in 3rd party LIMS/ELN applications from vendors like Dotmatics, Benchling, Core Informatics and others. This makes it possible for you to combine internal functionality with functionality in vendor-based solutions to better support the needs of your scientists.

You can implement REST services in almost any stack/language: PHP, Java, Grails, Rails, Micronaut, Javascript (Node.js), and Python to name but a few. You can combine web components with REST services to create compelling user experiences.

Tools like Swagger allow you to expose REST service metadata in a manner that can be catalogued in order to improve re-use. There are Swagger annotations for Java, PHP, Rails and Grails that let you annotate a REST service to expose it’s metadata.

Microservices Architecture

With these two pieces in place, your organization can take advantage of a flexible microservices-based architecture that maximises re-use, minimises development time and provides scientists within your research organisation with the best user experience.

Need Help Getting Started?
Contact us to learn how we can help you translate your Design Sprints into working software.

Advertisements
Posted in Bioinformatics, Informatics | Tagged , , , , , | Leave a comment

Design Thinking In Drug Discovery

In the previous blog post, I showed the importance of good UX design to research organizations; and how the Design Thinking process created at Google Ventures helps users, designers and developers quickly narrow down a list of potential solutions, and focus on the best solutions. In this post, we’ll take a look at how the Pistoia Alliance’s UX for Life Science (UXLS) working group is applying these methodologies to solve research-related problems.

The UXLS working group draws its members from pharmaceutical companies like AstraZeneca, Amgen, Bayer and GSK in addition to numerous technology vendors. And these members have contributed case studies, templates and best practices from their own projects to create the UX for Life Sciences Toolkit. The toolkit was a finalist for this year’s Bio IT World Innovation Best Practice award.

 

UX for Life Sciences
At the heart of the Design Thinking methodology (and UX for Life Sciences for that matter) is this iterative three-step approach for problem solving that in many ways resembles agile and lean development (albeit without the code). Define the problem (via user research), prototype a solution, evaluate the solution with users and repeat. With each iteration you narrow your focus on the problem and get closer to achieving an optimal solution.

Within each of these activities the toolkit provides a host of best practices and templates geared towards helping life science companies apply Design Thinking principles in their projects.

User Research

Task Modeling – a process for understanding the tasks that the user is trying to accomplish. Similar to Alistair Cockburn’s Use Case modeling methodology.

Personas – a process for identifying different types of users, and identifying differences or similarities with the way in which they interact with a system/execute a process. For example, you might look at how a biologist performs a literature search during target selection and compare that to how a chemist performs a literature search to better understand the chemistry space for the target.

Contextual Inquiry – using direct observation of scientists as they work to better understand the business process and identify needs and opportunities for improvement.

User Interviews – using conversations with scientists to better understand the goals, process, and needs of scientists.

Jobs To Be Done – an approach to identifying high priority opportunities for improvement.

UI Design

Card Sorting – A process for getting direct feedback from users, designing user interfaces, prioritising opportunities, and understanding the user’s perspective.

Prototyping – a process for rapidly and economically turning ideas into prototype user interfaces.

Evaluation

System Usability Scale – metrics used to measure the usability of a product or service based on user feedback.

UX Metrics Using HEART – a set of metrics developed by Google for evaluating the usability of prototypes.

Need Help Getting Started?
Contact us to learn more about getting started with Design Thinking and UX for Life Sciences.

Posted in Bioinformatics, Informatics | Tagged , , , | Leave a comment

Why UX Matters In Drug Discovery

In commercial software development, the most successful applications are often the ones where the vendor has invested the time and effort to design an engaging user experience. That user experience transcends the widgets you put on the screen, and encompasses critical success factors like:

  • Reduced cycle time – reducing the amount of time required to advance a discovery project from target identification through to pre-clinical testing.
  • Fit-to-function – how well does the application fit the requirement
  • Fit-to-flow – how well does the application fit the workflow that we use. Do we need to spend time entering data into multiple systems?
  • Ease-of-use – how easy is it for scientists to start using the application
  • Reduced training time – how much time is required to be fully conversant with the application, keeping in mind that the lab may have GLP training requirements for software.
  • Reduced rework – reduce the number of times that an internally developed application must be reworked to suit the needs of the scientists.
  • User satisfaction – increase user satisfaction and decrease frustration
  • Increased bench time – decrease the amount of time spent entering data, and increase the amount of time spent at the bench.
  • Aesthetics – studies of computer-human interaction have found that an aesthetically pleasing user interface can reduce work-place stress. Sometimes the user experience can be so compelling that scientists are willing to overlook the fact that the application doesn’t actually cover a significant portion of their workflow.
  • User interface consistency – by making the user interfaces for internal applications consistent with one-another, you can reduce training time.

The flip-side of these metrics reflect the ways in which a poorly designed UX can affect productivity and even retention. The applications that scientists use every day are often seen are a reflection of how seriously the company values science and scientists. A poorly designed user experience can result in duplicate work, lots of manual entry work, or manual transformation of data from one form into another in order to get the data into another system.

The 1990s Called And They Want Their UI Back
Millennials have certain expectations about the software they use, based in part on the social media and mobile applications they use every day.

  • They expect it to be easy to use.
  • They expect it to be as familiar to them as the other mobile applications they use.
  • They expect to be able to use it on a range of devices (known as responsive design).
  • They expect to be performant. They want interact with it without having to go through multiple page loads.
  • They expect it to notify them when a lab process has completed (a robot has finished replating samples, or a sequencer has finished its run).
  • And they expect to be able to interact with the system while wearing having personal-protective equipment like goggles and gloves.

UX In Pharmaceutical Companies
In pharmaceutical companies, we have traditionally seen User Experience (UX) practices applied in customer-facing web applications not internally developed research applications. The traditional business rationale for putting additional effort into UX is that a well-designed web or mobile patient-engagement application can result in increased patient compliance with medications, improved customer satisfaction, and increased sales, in addition to simply making patients aware that new treatments for their indication exist. Taken as a whole, these metrics constitute measures of “customer-solution fit”. And while they have a direct bearing on profitability, but also have an important bearing on how the company is perceived by both patients and potential future employees.

Beyond web applications though, we’re now seeing UX and Design Thinking practices applied in everything from clinical trial design to manufacturing and packaging. The ultimate goal of these practices though is to provide a more patient-centric focus.

As we’ll see later on in the article, these UX practices are beginning to filter down to pharmaceutical research organizations in some new and interesting ways. We’re translating the expectations of research communities into applications that fit the way they work.

How seriously do pharmaceutical companies take UX Design?
Seriously enough that companies likes GSK, Novartis, Amgen, Roche, Merck and AstraZeneca all have Centers of Excellence or Communities of Practice for UX Design. In addition, these companies are working together through the Pistoia Alliance to develop a common pre-competitive toolkit for UX design through a program called UX for Life Sciences.

The toolkit contains processes, templates, case studies, and best practices for creating new compelling user experiences, and improving the user experience in existing scientific software. And although we might use this in the context of software development, the same processes have been used by the group to solve problems in logistics, laboratory design, material handling/inventory, and lab operations.

The group borrows from the Design Thinking practices first developed at Google Ventures and taught at Stanford’s d.School (one of the country’s most prestigious design schools).

Design Thinking
The Design Thinking process in use at Google, Adobe, Mayo Clinic, Kaiser Permanente, Pfizer, Novartis, Roche/Genentech and many other companies follow is a 5-step exercise which brings together subject matter experts, UX design, and development experts into a single room to focus on solving a challenging business problems. And although there are a number of implementations of Design Thinking practices, these companies have chosen Stanford’s d.School approach in-part because it’s so well documented, and training videos are available on YouTube.

Design Thinking helps us use what we know about our customers and business processes to design new and compelling solutions that fit their needs. The 5 steps of the process are:

Empathise – Learn about your business process and participants to the point that you understand their priorities, biases and problems.

Define – Define the problem to be solved.

Ideate – Identify as many potential solutions as possible that solve the problem. Sketch what those solutions might look like, and storyboard how a user might interact with them.

Prototype – Create a crude prototype solution using simple tools like Keynote or PowerPoint.

Test – Have the users evaluate the prototypes and provide feedback

Then continue to iterate on the last two steps until you have a prototype that best fits the need. At some point during these iterations, you’ll transition from a Keynote/PowerPoint prototype to code.

The explainer videos below gives you a brief/long overview of the process.

Design Sprints
One of the most common implementations of Design Thinking is a process called the Design Sprint. Similar to development sprints that you see in agile software development organizations, a Design Sprint is a 5-day, time-boxed process for quickly developing and evaluating prototypes that resonate with the end-user. A typical Design Sprint looks like this:

Day 1

  • Start At The End – Identify the business goal(s) that you’re trying to achieve.
  • Map – map the process. For example, if your goal is to develop a more efficient process to create antibodies (and the software needed to achieve it), then your map would include the people, process steps and technologies currently in use to make that happen. This map provides a common reference point and vocabulary for all of the participants in the process. You can also use this part of the exercise to identify the parts of the process that are slow, user intensive, or just plain broken.
  • User Interviews – At this point, subject-matter experts help you flesh out the details behind the steps in the process. Everyone in the meeting will be focused on taking notes, and asking questions.
  • Choosing A Design Target – After mapping out the process, the team selects a single target user and event that will become the focus for the rest of the design sprint.

Day 2

  • Remix and improve – identify features in existing solutions that you like, and demo them for the rest of the team, and collect the best features on a whiteboard.
  • Sketch – Using the some of the previously demonstrated features as “grist for the mill”, the team members begin sketching new solution ideas.

Day 3

  • Decide – Review the sketches and select the solution(s) that best solve the problem.
  • Rumble – If you have multiple solutions, then the best way to compare them is to prototype both of them during Day 4, and review the results on Day 5.
  • Storyboard – Storyboard each of the solutions. Each storyboard walks the user through the business process/scientific process that you want to support.

Day 4

  • Prototype – prototype the storyboards using Keynote or PowerPoint.

Day 5

  • Evaluation – review the resulting solutions with subject-matter experts.

You’ll also find this podcast (entitled “Design Thinking For Clinical Trials“) useful for seeing how Design Thinking has been applied to design more patient-centric clinical trials.

 

More Reading

 

Need Help Getting Started?
Contact us to learn more about how you can apply Design Thinking in your research organization.

Posted in Bioinformatics, Drug Development, Informatics | Tagged , , , | Leave a comment

Pharma Webcasts

In the previous blog posting I listed some of the podcasts that make it easier to stay on top of the changes that drive the pharmaceutical industry.

plenaryThere are a number of conferences and societies that provide webcasts of their sessions, in addition to podcast content. These are really useful when you can’t make it to a conference, or can’t make it to 3 sessions scheduled at the same time, or can’t make it to the conference at all. The webcasts are also useful for Lunch and Learn sessions. You can book a conference room, and get together with a number of colleagues at lunch to watch the sessions over a period of several weeks. This has the added benefit of stimulating some interesting conversations and creating a sense of teamwork.

AACR

The AACR provides an extensive library of the sessions given at it’s conferences. Many of the sessions are free and don’t require membership in the organization. In addition, the organization’s YouTube channel has interviews with selected speakers from their conferences.

ASCO

Similarly, the ASCO YouTube channel has a number of interviews with selected speaker as well as previews of the upcoming annual meeting, and brief explainers of some of the major programs like CancerLinQ.

ASH

ASH provides a library of audio and video content from their conference.

Bio IT World

Bio IT World provides a selection of talks from their annual conference on their YouTube Channel. In addition to these talks, there are short interviews with Best In Show winners in a variety of categories.

Cambridge Healthtech Institute

The Cambridge Healthtech Institute (CHI) puts on a number of conferences (including Bio IT World, PEGS, Peptalk, Oligonucleotide and Peptide Therapeutics, Biomarkers and Immuno-Oncology World, Next Generation Dx and more. The CHI YouTube channel has many of their talks as well as interviews some of the key speakers from each of their conferences

ESMO

ESMO’s YouTube channel contains a series of short interviews with leading oncologists in addition to conference highlights.

Posted in Uncategorized | Leave a comment

Pharma Podcasts

In 1996, Nicholas Negroponte (founder of MIT’s Media Lab) wrote in his book “Being Digital”, that the information about us (our personal metadata), could one day be used to “narrowcast” information to us. As prophetic as that vision may have been over 20 years ago, the reality of narrowcasting has had both benefits and drawbacks that were wholly unanticipated.

One of the key benefits of narrowcasting though has been the emergence of podcasting over the last 5 years as increasingly popular approach to finding personalised content that turns the time-suck that is the average daily commute, into a valuable opportunity to recharge and learn.

That need for personalised content goes beyond just the latest episode of The Guardian’s Science podcast, TEDTalk Radio, or The BBC’s “In Our Time”. Podcast topics are becoming increasingly specialised and range from general science podcasts to podcasts geared towards industry professionals. There are even CME podcasts for clinicians.

In addition, journals such as Nature, Science, Gut, OncoTarget, JAMA and NEJM produce podcasts, as do media outlets like the Guardian, the BBC and NPR. Major conferences such as ESMO and ASCO have their own podcasts, some of which include recordings of panel discussions and conference presentations

Here are a few of my favourites:

General Science Podcasts

  • Engines of our Ingenuity – The University of Houston’s Daily Science Program which features stories from the history of science and technology.
  • The Guardian Science Weekly – The Guardian’s Weekly Science program
  • Quirks and Quarks – The CBC’s Weekly Science Program
  • Science Friday – NPR’s Weekly Science Program
  • Science In Action – The BBC’s Weekly Science Program
  • Science On Top – An Australian weekly program on science
  • TED Talk Radio – NPR’s interviews & summations of key TED Talks.

Journal Podcasts

  • Lancet Oncology
  • Nature Biotech Podcast
  • Nature Podcast
  • OncoTarget
  • Science Magazine Podcast

Industry-Related Podcasts

  • Base Pairs – stories on genetics from Cold Spring Harbor Laboratory
  • BioFlash – stories from the San Francisco Business Times on biotech companies in the Bay Area
  • The Bio Report – The Bio Report podcast, hosted by veteran journalist Daniel Levine, focuses on the intersection of biotechnology with business, science, and policy.
  • Drug Discovery World – stories from the pages of Drug Discovery World
  • FierceBiotech – stories from the pages of FierceBiotech
  • GEN Sounds of Science Podcast – stories from the pages of Genetic Engineering News
  • The Pharmcast – stories from the Life Science industry
  • Quicksand Pharma/Biotech Weekly News – A weekly audio digest of the most important news in drug development affecting the pharmaceutical and biotech industry.
  • Regenerate – Regenerative Medicine podcast
  • The Stemcell Podcast – interviews with researchers in stem
  • This Week In Virology – a weekly podcast about viruses
  • This Week in Microbiology – a weekly podcast about microbes
  • Novel Targets – A podcast about cancer drug targets produced by the folks at Blue Ice Publishing (Pieter Droppert and Sally Church) who also publish the highly-respected Pharma Strategy Blog and Biotech Strategy Blog.

Conference/Society Podcasts

  • ASCO – ASCO provides a collection of 9 different podcasts on topics ranging from research to advocacy. You’ll find all of the podcasts here.
  • ACS
  • ASH
  • CHI Podcasts – previews and highlights from some of the numerous conferences that Cambridge Healthtech Institute organizes.
  • ESMO Open – ESMO Open is the open journal of the European Society for Medical Oncology and this podcast highlights research from the journal and their conference.

 

Scientist Conversations

  • Illumina Genomics Podcast – conversations with leading scientists on genomics-related topics.
  • Pharma & Biotech Thought Leadership – Shanna Landolt, leading executive recruiter interviews top thought leaders from the pharmaceutical and biotechnology industry to share their expertise with the pharma and biotechnology community.
  • Scientist The Human Podcast – conversations with researchers on topics from biology, medicine, pharmacology and more.
  • Two Scientists Walk Into A Bar – conversations with scientists from Genentech on a range of drug discovery and development topics. It’s an interesting peek behind the curtain at one of the most successful biotech companies.

Drug Development

  • Clinical Trial Podcast – what does it take to be a clinical trials professional? Listen to interviews with those in the field.
  • The Clinical Trials Guru – the challenges of clinical trials from the perspective of professionals operating in the field.

 

Medical Podcasts

  • Imedex – a Continuing Medical Education (CME) series
  • PeerView Oncology & Hematology – a CME series for oncology/hematology practitioners
  • Project Oncology – “focuses on a wide array of oncology topics designed to educate and enlighten practitioners on late-breaking discoveries, novel treatment options, evolving methods of patient management, and more. This series provides cutting-edge updates on the biology, diagnosis, and multidisciplinary management, as well as new understandings of evidence-based recommendations to achieve optimal patient outcomes”.

Podcasting tools like Stitcher, iTunes, Soundcloud, and Google Play can be used to find and subscribe to podcasts. To subscribe to any of these podcasts simply search for them in your podcasting app of choice, and tap the “Subscribe” button.

What are your favourite podcasts?

Posted in Cancer Research, Drug Development, genomics, Informatics, Science Blogging, Social Media | Tagged , , , | Leave a comment

Pancreatic Cancer and the Microbiome

microbiome_-_spl_image_-_coloured_sem_of_bacteria_cultured_from_a_fingertip_2x1

Beyond the genomic complexity of the disease, we’ve begun to examine the effect of the microbiome on pancreatic cancer. In a recent paper in Science, “Potential role of intratumor bacteria in mediating tumor resistance to the chemotherapeutic drug gemcitabine” [Geller et al] reported that 76% of pancreatic cancer patients in their study (n=113) had gammaproteobacteria in their pancreas tumors. These bacteria were shown to metabolize the chemotherapeutic drug gemcitabine, which is commonly prescribed to pancreatic cancer patients. The bacteria effectively converted the drug into an inactive form, thus explaining in part why gemcitabine has such a limited effect on patients.

In addition, a growing body of evidence is accumulating around a role for oral bacteria contributing to the progression of pancreatic cancer. In 2008, Meyer, et al, identified a potential relationship between periodontal disease, and pancreatic cancer. In 2013, a European study conducted by Michaud, et al,  revealed that patients with Porphyromonas gingivalis an oral pathogen, had a more than 2-fold risk of pancreatic cancer.

A prospective risk study was also performed at NYU Langone to help confirm the earlier results, the results of which were published in a paper by Fan, et al. This study was able to add additional data points to the growing body of knowledge on the subject, including a potential role for Aggregatibacter actinomycetemcomitans.

 

References

Fan X, Alekseyenko AV, Wu J, Peters BA, Jacobs EJ, Gapstur SM, Purdue MP, Abnet CC, Stolzenberg-Solomon R, Miller G, Ravel J, Hayes RB, Ahn J. (2018) Human oral microbiome and prospective risk for pancreatic cancer: a population-based nested case-control study. Gut. 2018 Jan;67(1):120-127. doi: 10.1136/gutjnl-2016-312580. Epub 2016 Oct 14.

 

Meyer MS, Joshipura K, Giovannucci E, Michaud DS (2008) A review of the
relationship between tooth loss, periodontal disease, and cancer. Cancer
Causes Control 19(9): 895–907.
Michaud DS, Izard J, Wilhelm-Benartzi CS, You DH, Grote VA, Tjonneland A,Dahm CC, Overvad K, Jenab M, Fedirko V, Boutron-Ruault MC, Clavel-
Chapelon F, Racine A, Kaaks R, Boeing H, Foerster J, Trichopoulou A,Lagiou P, Trichopoulos D, Sacerdote C, Sieri S, Palli D, Tumino R, Panico S,Siersema PD, Peeters PH, Lund E, Barricarte A, Huerta JM, Molina-Montes E, Dorronsoro M, Quiros JR, Duell EJ, Ye W, Sund M, Lindkvist B, Johansen D, Khaw KT, Wareham N, Travis RC, Vineis P, Bueno-de-
Mesquita HB, Riboli E (2013) Plasma antibodies to oral bacteria and risk of pancreatic cancer in a large European prospective cohort study. Gut 62(12):
1764–1770.

 

Posted in Cancer Research, microbiome, pancreatic cancer | Tagged , | Leave a comment

Subtypes of Pancreatic Cancer

In the third part of this series on pancreatic cancer, we’ll take a look at recent developments in identifying subtypes of pancreatic cancer and its potential impact on the lives of pancreatic cancer patients.

Twenty-one years ago, we had identified some of the histologically distinct types of pancreatic cancer. These neoplastic tissue types included: PanINs (pancreatic inter-epithelial neoplasms), IPMN (intraductal papillary mucinous neoplasms, MCN (mucinous cystic neoplasms). Wu et al established cancer-associated genes in the cyst fluids of IPMNs, and discovered that IPMNs harbored GNA and KRAS mutations.

In 2016, Andrew Biankin of the Wolfson Wohl Cancer Research Center in Glasgow, identified 4 distinct subtypes of pancreatic cancer in his paper “Genomic analyses identify molecular subtypes of pancreatic cancer”. These subtypes included:

  • Squamous – enriched for TP53 & KDM6A mutations, upregulation of the TP63∂N transcriptional network, hypermethylation of pancreatic endodermal cell-fate determining genes and have a poor prognosis
  • Pancreatic progenitor – differentially expressed genes involved in early pancreatic development including (FOXA2/3, PDX1, and MNX1)
  • Immunogenic – contained upregulated immune networks including pathways involved in acquired immune suppression
  • Aberrantly differentiated endocrine exocrine (ADEX) – displayed upregulation of genes that regulate networks involved in KRAS activation, exocrine (NR5A2 and RBPJL), and endocrine differentiation (NEUROD1 and NKX2-2)

With these subtypes, the hope is that clinicians can segment patient populations into groups that respond better to specific, targeted therapies. Already we’ve seen that patients with BRCA2 mutations are more likely to respond to PARP inhibitors, and researchers are currently investigating if patients in the Immunogenic subtype are more likely to respond to the latest immunotherapies.

Just recently, the Precision-Panc organization announced the first of three PRIMUS (Pancreatic cancer Individualized Multi-arm Umbrella Study) trials. PRIMUS-001 is an adaptive Phase II/III study with an integrated biomarker evaluation in patients with metastatic disease. PRIMUS-002 will aim to define biomarkers of therapeutic responsiveness in the neoadjuvant setting and is set to open in 2018. PRIMUS-003, supported by AstraZeneca, is using an immunotherapy approach and is also currently recruiting patients with metastatic disease.

Posted in Cancer Research, pancreatic cancer | Tagged | Leave a comment