Proposed information flow (app, annotation server, genomic data, guidelines)

[jannis-baum]

Proposed information flow (app, annotation server, genomic data, guidelines)

Prerequisites

• the app has genomic data that defines diplotypes, e.g. { "Gene": "CYP2D6", "ResultType": "Diplotype", "Genotype": "*5/*36-*10", ... }
• after the initial download of the genomic data we want to avoid ever sending it anywhere
• CPIC's API offers a mapping from diplotypes to so called lookupkeys that describe the resulting enzymes' function, e.g. 'Normal metabolizer'
• lookupkey-drug combinations can be used to query recommendations.
• Aniwaa plans on providing us with hand-written, patient-friendly recommendation texts that are also uniquely identifiable by their respective lookupkey-drug combination
• Jannis plans on processing CPIC recommendation data for machine readable information, e.g. to figure out when to display a warning icon or dosage recommendation chart

Proposed process for delivering suitable recommendations to the user

Preprocessing

App

The lookupkeys corresponding with the user's genomic data need to be known somewhere to filter for relevant recommendations. Since genomic data is intended to stay on the app, filtering has to happen here. To avoid querying lookupkeys by sending the user's personal diplotypes, the app could fetch all possible diplotype-lookupkey-combinations from CPIC and then match them locally, e.g. by querying https://api.cpicpgx.org/v1/diplotype with select: genesymbol,diplotype,lookupkey.

This can happen in advance to active use of the app, i.e. when first importing genomic data. Since new PGx findings are made frequently, lookupkeys should be updated in the described matter on a regular basis.

Annotation Server (Backend / PharMe Server?)

The server can request all level A, A/B and B guidelines by querying https://api.cpicpgx.org/v1/pair_view with

{
    cpiclevel: 'in.(A,A/B,B)',
    guidelinename: 'not.is.null',
    select: 'guidelinename'
}

and then fetch all related relevant recommendations for each <guidelinename> from https://api.cpicpgx.org/v1/recommendation_view with

{
    guidelinename: '<guidelinename>',
    classification: 'not.eq.No Recommendation'
}

These recommendations can be saved to a recommendation repository with a relation to the existing medication repository through RxNorm keys. Additionally, text processing can happen here, and, where applicable, a given CPIC recommendation can be replaced by one of Aniwaa's texts.

This data should, analogously to preprocessing in the app, be updated regularly.

Live use

Since all relevant and preprocessed data is now readily available on the server, the app can simply query the server for all recommendations for a drug at the user's request. Recommendations will come with their respective lookupkeys that the app can filter by locally to show the user only what's relevant to them.

Summary

The proposed process ensures that a user's genomic data is never sent anywhere from the app and makes for fast response times since no processing needs to happen on the go.

[knollengewaechs]

I have a few remaining questions / thoughts. I will stick to calling the backend "annotation server" for now. Obviously, please feel free to point out any flawed thoughts.

TL;DR

I propose the following:

• store mapping of diplotypes to lookup keys in annotation server
• check whether it's fair to leave out recommendations with strength 'no recommendation'
• (check whether it's okay to query a drug)
• make sure that data on smartphone is stored in a safe way

---

Preprocessing: Matching user's diplotypes to lookup-keys

• In order to know which diplotypes exist and so which one we should query for the respective lookupkeys, we would need to store them somewhere. I assume this would be in the annotation server. I we do that, I think we can save the app some resources by querying the matching lookupkeys for a diplotype in the annotation server. This information could be updated on a regular basis there aswell.
  • All the app would have to do is query the information from the annotation server with few queries from the annotation server. Maybe we send one for all lookup keys and one for the mappring of lookupkeys to diplotypes, or we only send the latter query (so only the mapping) and extract all possible lookupkeys in the app. But that's probably of lower importance and depends on what is more expensive – some in-app-processing or an additional query to the annotation server.

Annotation server

• Here I just wanted to point out that we only query guidelines that are classified either strong, moderate or optional. That makes a lot of sense to me but we should check with Aniwaa and/or others from the chair.

Live use

• Just to check in, we consider querying a drug safe, right? Even if the annotation server got attacked, the only information would be that some user requested a certain drug. I feel like that should be fine, but again, we chould check that with the chair.

Security of smartphones

• Our premise is that the data is safe on the mobile phone, as hacking smartphones seems to be rare. (At least that's what I took away from our discussions so far.) As we are storing highly sensitive health data, I think we should check again how true this is. I am not a security expert and maybe this is an unnenccesary question, but I think we should be asking it anyway and in the best case get a quick answer ensuring our procedure.
  • Doing some surface research, I was not immediately ensured that this is not a risk at all (e.g. https://en.wikipedia.org/wiki/Mobile_security).
  • As far as I know @kolioOtSofia et al. have thought quite a bit about how to store the star alleles in a secure way. I had trouble finding the right issue for this. Can you maybe link it or/our share your thoughts about this?
  • I know this is a large issue and you could probably write a whole thesis about it (*cough*).
  • Maybe we should, again, consider asking more knowledgeable people about this

General thoughts

I agree that this way of doing things is keeping us from sending the user's genetic data anywhere. I think we agree that this is a priority therefore I think that we should take this approch, maybe with some minor changes.

[jannis-baum]

Thanks for all the points you made!

Preprocessing: Matching user's diplotypes to lookup-keys

Regarding your thoughts on storing diplotype-lookupkey mappings on the annotation server I'm not entirely sure if I understood correctly. CPIC offers an endpoint that maps all genes & diplotypes CPIC has information on to their respective lookupkey. The app can fetch this mapping straight from CPIC, go through all of the user's gene/diplotype combinations and save the respective lookupkeys (where available). I don't see why we would need the annotation server for this at all since this one query to CPIC gives us all the information that's needed for the app's role in preprocessing.

Annotation server (recommendation classes)

Drug recommendation classified as the only other type, i.e. "No Recommendation", always have the recommendation text "No recommendation." and no further information which is why I assumed it was fair to omit them. Let's ask Aniwaa anyways; maybe there is something we should tell people about these that we don't know about yet. I started a list of talking points for our meeting with Aniwaa next week in our Google Drive.

Live use (querying recommendations by drug)

We have in fact considered querying drugs as safe thus far. Going with the live use described above, as far as I understand, the only information the annotation server ever gets is that some user has requested a specific drug without being able to identify the specific user. Maybe @tamslo can give her two cents on wether this is acceptable.

Security of smartphones

I think our premises on storing data on the phones were that

1. we have to store it somewhere and that
2. the user's phone is the safest option

rather than the data being safe (period) there. Beyond the inevitability of storing genomic data somewhere, I think storing it on the phone has been the plan from the very beginning and has been approved (or at least not criticized) by a lot of people. Nevertheless, I'm sure this is a topic someone could take a deep dive into if they are interested.

[knollengewaechs]

Preprocessing

• I agree with the procedure you propose. (I misunderstood your original idea, in that I thought we would query every diplotype's lookup key on its own, which you didn't say, but my brain heard. Sorry!)
• Storing all lookup keys should be within our capacities, right?

Smartphone security

• I agree with the points you made! I just wanted to make sure we put safety measures like an app password or local encryption (or other smart stuff) in place if needed, and that we are aware of possible risks.

[tamslo]

Thank you for the discussion and the good overview! Querying a medication, receiving all possible guidelines, and matching on the phone sounds fair to me! I also think that @kolioOtSofia will have at least a short look at data security on mobile devices 😊 but I like the assumption that it is the "safest" option and not entirely safe

[kolioOtSofia]

@tamslo indeed, I will be taking a look at this in my bachelor thesis. @jannis-baum @dieknolle3333 just for your information, storing the lookups is not trouble at all, we could even encrypt them.

[jannis-baum]

Resolution

After our follow-up meeting with Aniwaa, we have enough information to make a final decision on the topic which resolves this discussion. See below for detailed information.

App

The app-side of the discussion can be implemented as proposed.

Backend

Aniwaa and her team aim to keep all information directed at patients up to date and complete in a Google Sheet, roughly organized by medications and lookupkeys. CPIC data will only be used in the PDF export for doctors / professionals (and in case we want to show supplemental information such as diplotype frequency across population groups (as per Aniwaa's suggestion; meeting notes from 4/05) which are readily available from CPIC).

The backend needs infrastructure to

• import data from the Google Sheet (see corresponding API) and organize it by medications and lookupkeys
• import data from CPIC to
  1. verify the Google Sheet data is up-to-date & complete (if not, notify someone who can notify Aniwaa / log it)
  2. supply raw CPIC data for PDF export directed at professionals
  3. fetch supplemental data (we should discuss if and what we want to show here)
• regularly update database
• serve data to app

I will create issues accordingly.