Blockchain Phase 2 Kick Off Meeting 14/08/18

From PHUSE Wiki
Revision as of 09:53, 12 September 2018 by Laurenwhite (talk | contribs) (Created page with "'''Attendees''': Disa, Aji, Adama, Sven, Will, Jim, Natalie, Todd, Anders, Richard, Anders, Marek, Rajan, Skip, Andrew, Aimee, Andrew, Scott, Selina, Peter, Brigid, Ravi, Eric...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Attendees: Disa, Aji, Adama, Sven, Will, Jim, Natalie, Todd, Anders, Richard, Anders, Marek, Rajan, Skip, Andrew, Aimee, Andrew, Scott, Selina, Peter, Brigid, Ravi, Eric, Karin, Mark, Rajesh, Kala, Michael, Marrco, Maria

Apologies: Scott, Xavier, Abdullah, Robert, Lucy


  • Welcome (from PhUSE/Co-Leads)
    • Disa Lee Choun - UCB
    • Adama Ibrahim- Biogen
    • Aji Barot- HealthUnlocked


  • Welcome new and existing members
  • Scott Bhalavonni - Working Groups co director
    • World's largest Healthcare focused biometric society
    • PhUSE promotes collaboration and see each other as equals
    • PhUSE is a neutral platform
    • We welcome participation from vendors and software developers but on a neural basis and not for a marketing purposes
    • PhUSE has 6 different Working Groups Blockchain falls under Emerging Trends and Technologies
    • Please do not share an confidential information as this is an open forum

Phase 2 Proposal

  • Open source proof of concept on patient data
  • Proposed in this project we will implement a way to identify patients using the permission access and abolish the Siloed element
  • Why patient data
    • One of the most complex and has many players in the industry
    • We need to have an open source for all the data and establish trust
    • Patients should own their data not by the government or hospitals
    • Look at the patient ecosystem and look to give access to the care givers (doctors/nurses)

  • Patient Data Flow
    • Through our previous research we found that close to 90% of the patients would like to participate in clinical trials and are willing to share the data freely
    • If the patient was interest in participating in a clinical trial they would have to be referred by the GP to a specialist for further tests
    • If the patient qualifies they then have to sign a Consent with that they would start their clinical trial visits
    • This is complex and complicated as we have to rely on data coming from different labs and different systems

Expect to have five leads one for each sub team

  • Patient ID
    • We need to identify the problem we are going to focus on
    • How to track they have consented the different versions of ICF to start clinical trial
    • Defining the data, data standard, what the limitations are, the benefits and results
    • Deliverables - User interface and provide a written protocole to support that

  • ICF (eConsent)
    • This is compatible with IEE standards activity - they are looking at defining pre standards definitions
    • We will take this forward forward to this group for PhUSE to understand as a problem statement on how do we track different versions of scientists for example, using blockchain
    • Make sure patients match the correct ICF
    • Deliverable - User interface and provide a written protocol to support that
    • Patient Data Sharing (Day 1 Trials)
    • How to track data after consent has been provided
    • Defining the data, what standards exist
    • Tracking and setting of data permissions
    • Deliverable -User interface and provide a written protocol to support that

  • Labs/Genomics
    • We want to go into the data bases that are supporting either the lab will genomics data and we want to start seeing how we can track and aggregate to differentiate these lab results by patients
    • We need to make sure how the data types are defined and how they're compatible with standards
    • Deliverables User interface (APP/Website) and a written protocol

  • Architecture alignment
    • Across all the problems we highlighted we want to understand how to handle and manage them across different databases
    • We want to look at how the data flows and interacts - if we introduce blockchain we want to see how it interacts and how we can share this information
    • We want to see how we can link the data we will be using for the pilots
    • Deliverables - Harmonising patient ID in other DBs and other blockchain system - developing API and Data Mapping

  • Deliverables
    • Produce meaningful outputs to help industry stakeholders understand the usage for adoption purposes
    • Establish a working group charter and protocol
    • We want to make sure we're learning from other groups- please share any consortiums you're working on


  • Total of 6 months
  • We then want to share this with the wider community

  • Process/Criteria for IT Selection
    • Looking to send the development questionnaire out next week that will give us an ability to build a target list
    • It will be a case who best fits out agenda
    • We will look to collate this and score by the end of September

  • Roles and Expectations SWG Leads
    • Size history and type of organisation
    • What relevant work you've done and the patient data you've worked with
    • Typically 10% a week - please do not be discouraged by this guideline

  • Communication/Awareness campaign - Promote the work
    • PhUSe Conferences
    • DIA
    • IEE
    • Raise awareness
    • PhUSE workshop in Basel

  • Risk Mitigation
    • Team membership and commitment
    • Competing IT solution and providers

  • Next Steps
    • Vendor Demos on the PoCs
    • How would you ensure vendor neutrality during that review process?
    • This will be in the charter (still being developed) - having a clear vision of what this will look like and considering all the potential influences of impartiality on the project

AOB /Questions

  • If there's a need to have a QA element a validation elements thats over seeing all the different sub-work groups to make sure that we're building this in a best practice in alignment within all the guidelines
    • How can we be sure that this is validated and how can you provide us with relevant documentation
  • Who is the customer for this proof of concept and then a product?
    • There are two topics we focused on within the proof of concept, patient identification and data portability
    • These two challenges are experienced by regulators, by patients themselves and are two very broad issues
    • We are not looking to create a product that is applicable for a particular customer group more about actually collaborating to solve challenges

  • Demo day
    • These will all be non confidential as we will look to share and choose the best solution which caters to the proof of concept
  • Concerns around timeline to have a demonstration day in a month
    • If we're doing scoring we are boarding on things that are not appropriate for PhUSE as we do not want to see endorsing a vendor
    • We have aimed to make sure we remain vendor agnostic - we want to identify the right protocol to fit the right work group, it doesn't matter which vendor it is
  • How can we provide a demo that is still useful but non proprietary and also shares the same concerns with the demo timeline
    • What do the demos look like? how do they balance imperative of not sharing proprietary information with how we're intending to communicate?
    • It's not about looking at your application
    • We're testing we're not building a solution to sell
    • Maybe we could have more than one vendor working together
    • We need to focus on we are creating something brand new here and look to see where we are going to be able to contribute as technology grows
    • We have to get to the first step before we finalise what direction and what protocol otherwise

  • Vendor agnostic
    • Blockchain in it's algorithmic nature it shouldn't be vendor or computation dependent
    • Blockchain is about trust and removing the middle man
    • Being open source is the way to move things forward
    • We need to be conscious of what we are asking from the vendors
  • We need to define whether is it a demo or a proof of concept that we are trying to achieve
    • What we want to achieve from this demo is give our stakeholders within pharma a tangible experience of this technology and how it can interact with different systems
    • We need to understand what it will take to achieve that using the resources and capabilities in front of us.