Privacy Policy for the Dr. Drive app (Android)

1. In short

• Dr. Drive is a route planner for home visits. It has no accounts: you do not give a name, email address or password.
• The data of the people you visit (full name, phone number, address, notes) is only on your phone. I have no access to it.
• To look up an address and calculate a route, my server passes only the address or coordinates to TomTom, without names, phone numbers or notes. The server does not keep this data in a database or in logs.
• “Prowadź” (“Navigate”) opens the Google Maps app with the next visits, up to 9 at a time. Google receives the coordinates or, if there are none, the text from the address field.
• The server recognizes an installation by a random identifier and a subscription by an anonymous RevenueCat identifier. I do not know your name or email address unless you write to me.
• You pay for Premium in Google Play. I do not see your card details.
• The app has no ads or analytics tools and does not send me crash reports. However, the Google library that draws the map collects its own data for Google (section 5.3).
• You or your facility (as the controller) are responsible for patient data. In map requests I process it on your behalf, under the Data Processing Agreement.

I write “doctor,” but I mean anyone who uses Dr. Drive for home visits, such as a nurse or a physical therapist. I call the people visited “patients.” If you visit clients rather than patients, the same rules apply to their data.

2. Controller and contact

The controller of the data in section 4 is Marek Maks, a natural person. I provide the app as part of an unregistered business activity (Article 5(1) of the Polish Entrepreneurs' Law).

• Email, also for matters about data, breaches and security vulnerabilities: support@approject.dev
• Place of residence and address: Traugutta 15, 36-200 Brzozów, Poland
• Phone: +48 513 785 574

I do not appoint a data protection officer because, at the current scale, Article 37(1) GDPR does not require it.

3. My roles

4. Data I process as the controller

4.1. Installation identifier

• What it is: a random string of characters (UUID) created when you first use the app. It contains no information about you or your phone.
• Where it is: in the app's storage on the phone. The app attaches it to every request to my server. It does not go to TomTom or Google.
• What it is for: it limits the number of requests from one installation and protects the server from abuse. It is also used for the one-time 14 days of Premium and for limits when the app has no RevenueCat identifier (section 4.3).
• Storage on the server: the identifier itself is not in the database or in logs. Only its hash can end up in the database (section 4.3). The short-term limit counter uses the identifier within a 60-second window.
• A new identifier is created after you uninstall the app or clear its data.

4.2. Premium subscription: RevenueCat and Google Play

• RevenueCat identifier: an anonymous customer identifier created on the phone by the RevenueCat library. It does not contain a name or email address.
• What RevenueCat receives: this identifier, purchase data from Google Play (product and plan, dates of purchase, renewal and end, price and currency, store country, subscription status, purchase token), the device language and currency, and technical connection data. RevenueCat states that it does not store the IP address: it determines the country from it and deletes it.
• What it is for: buying and renewing the subscription, checking whether you have Premium, restoring a purchase after reinstalling or on another phone with the same Google account, and granting the 14 days of Premium.
• What my server does: it receives the RevenueCat identifier with map and Premium requests, asks RevenueCat whether you have Premium, and stores the result: the hash of the identifier (SHA-256), whether Premium is active, whether it is a Trial, the end date and the time of the check. The hash is a pseudonym, which means it is still personal data (Recital 26 GDPR).
• What I see in the RevenueCat dashboard: customers under anonymous identifiers, their purchases and sales summaries. I do not link this to anything that could identify you, unless you give me an order number.
• Google Play: Google handles the payment, the Google account and the card details. It gives me the order data needed for accounting, such as the order number, product, price, date and country.
• “Przywróć zakupy” (“Restore purchases”) assigns the purchase from your Google Play account to the RevenueCat identifier of this installation.
• Source of the data: the identifier is created in the app, and Google Play provides the purchase data (Article 14(2)(f) GDPR).

4.3. Limits and the Trial

• Free version: up to 60 address searches per day. Premium: up to 400 searches per day.
• The server counts searches separately for each customer. The key is the hash of the RevenueCat identifier or, when the app does not send it, the hash of the installation identifier.
• The server grants the 14 days of Premium without a card once per RevenueCat customer and once per installation. It stores the hashes of both identifiers, the grant date and the end date, and grants a promotional entitlement in RevenueCat. After 14 days the app returns to the Free version. Nothing is charged.
• Other than that, the server database has only aggregate counters for the whole service (for example, how many searches were made today), with no identifiers.

4.4. Connection data, logs and server error reports

• Connection data: every connection reveals the phone's IP address and technical headers (for example, the Android version and phone model). Cloudflare processes them to deliver the request and protect the network. My code does not store them.
• Server log: one line per request, with the method, the type of path (for example, /v1/maps/route), the response code, a random request number and the handling time and, on an error, also the error type. No IP address, identifiers, addresses or coordinates. Cloudflare's automatic logs with the full request URL are turned off.
• Cloudflare statistics: aggregate, for example the number of requests and errors and the run time.
• Error reports (Sentry): on a server error, the report contains the error type, the request number, the time and the server version. A filter removes the IP address, request content, headers, email addresses, tokens and route coordinates. When TomTom or RevenueCat returns an error or does not respond, the report may contain, respectively, the address used in that request or the anonymous RevenueCat identifier, because they are part of the web address of those services.

4.5. Your location and home address in map requests

When you turn on GPS in the app, your current location is used as the start of the day route and as a reference point for address search. It goes through my server to TomTom together with the request (section 5.2). The server does not store it. The app keeps only the last location in memory, does not store a location history and does not use location in the background.

Your home address, if you enter it, is stored on the phone and by default serves as the day's end point and, without GPS, also as the start. Its coordinates go through my server to TomTom in the same way as visit points.

4.6. Google Play: statistics, reviews, closed test

• Statistics and stability: Google Play shows me aggregate statistics (installs, countries, phone models, Android versions) and crash reports that Google collects from people who agree in Android to send diagnostic data. I do not link them to identifiers.
• Reviews: I see the display name, the rating, the content and the device data that Google shows. I can reply publicly.
• Closed test: I add the Google account email address you give me to the list of testers in the Google Play Console.

4.7. Correspondence

• When you write to me, I see your email address, the content and any attachments. I use them to reply or to handle a complaint or a report of a bug or security vulnerability.
• For matters about a purchase, give your Google Play order number (it starts with “GPA.”).
• Do not send me patient data: no screenshots of the list and no import files.

4.8. Purposes and legal bases

I do not base processing on consent. I do not make solely automated decisions that produce legal effects concerning you or similarly significantly affect you (Article 22 GDPR). Limits work automatically, but they only count requests.

5. Patient data

5.1. Data on the phone: the controller is the doctor or the facility

• What is on the phone: full name (the person's label), phone number, address, notes, date and estimated duration of the visit, status, arrival and finish times, coordinates, the day's visit order.
• Where: in the app's local database, in a folder excluded from backups. Backups are turned off for the app. There is no sync and no copy on my server. Coordinates from TomTom and route paths are only in memory, until the app is closed. Distances and times of route legs stay in the database.
• Import: CSV and XLSX files and pasted text are read on the phone. A photo taken for import stays briefly in the app's cache and is deleted after loading. Reading text from photos (OCR) is turned off.
• Deleting: “Ustawienia” (“Settings”) → “Usuń wszystkie osoby i wizyty” (“Delete all people and visits”) or uninstalling the app. The app does not delete finished visits on its own. The doctor does that.
• Protection: the app has no lock of its own (PIN, fingerprint). The data is protected by the phone's screen lock and encryption.
• Who decides: the doctor in their own practice or the facility (for an employee, a civil-law contractor and usually also under a B2B contract). The basis is the law on providing health care services: Article 6(1)(b), (c) or (e) and Article 9(2)(h) and 9(3) GDPR. The patient's consent is not needed.
• I have no access to this data and cannot read or recover it.

5.2. Map requests through my server: I process data on the doctor's behalf

Address search, the day route, visit order and traffic incidents work through my server on Cloudflare, which queries TomTom. The TomTom key is only on the server.

• What I pass to TomTom:
  • the address text to search for, without the street prefix “ul.” and without the apartment number in common notations (for example, “12/4”, “m. 4”, “lok. 3”); other additions from the address field also go there,
  • the reference point for the search (your location, 5 decimal places),
  • the coordinates of the route points: start, visits and end point (6 decimal places),
  • the rectangle of the area for which I fetch traffic incidents.
• What I do not pass on: first names, last names, phone numbers, notes, visit dates, statuses, identifiers or the phone's IP address. TomTom sees the request as coming from my server.
• The server: between the phone and the server, the data is in the body of the request, not in the URL. My code does not store requests or responses: they do not go to the database, a cache or logs. The exception is described in section 4.4 (a report of a TomTom error).
• TomTom: I use a server in the EU, and TomTom processes requests there. TomTom keeps request metadata, including the request path with the address or coordinates, for up to 90 days, for security and debugging. TomTom's terms allow it to use aggregated and anonymized data for analytics and to improve its services.
• Data Processing Agreement: I process this data under the Data Processing Agreement (Article 28(3) GDPR), which the doctor or facility enters into with me together with the Terms of Service. It describes my obligations and the sub-processors.
• After use ends, there is nothing on the server to delete or return, because I do not store map requests. Error reports disappear after 30 days, and the copies at TomTom expire on its schedule (up to 90 days).

5.3. Google: a separate controller

• The map in the app, on the “Trasa” (“Route”) tab: a Google library draws it. The phone draws the pins and lines. Google states that this library itself collects device data, crash reports, the IP address, location, actions on the map and a periodically changed identifier. It uses them, among other things, for traffic information and to improve its services.
• Google Maps (“Prowadź”): the app opens a link with at most 9 destinations. The destinations are given as coordinates or, if there are none, as text from the address field, including the apartment number. Google Maps then works under your Google account. With history turned on, routes may be saved to the account.
• This version has no turn-by-turn navigation in the app and no Android Auto support. When I add them, I will update this policy.
• Here Google acts under its own rules as a separate controller. I do not receive this data. Google Privacy Policy.

6. Data recipients

The providers use their own subcontractors, from lists published on their websites.

7. Transfers of data outside the European Economic Area

If you ask at support@approject.dev, I will send you a copy of the safeguards (Article 13(1)(f) GDPR).

8. How long I keep data

9. What I do not do

• I do not run accounts or logins.
• The app has no ads or analytics tools, does not read the advertising ID and does not send me crash reports.
• I do not store your location history.
• I do not sell data or use it for marketing or profiling.
• I do not send first names, last names, phone numbers or notes to the map service or to Google.

However, you need to know two things. The Google library that draws the map itself sends diagnostic and usage data to Google (section 5.3). RevenueCat and Google Play show me sales summaries and statistics (sections 4.2 and 4.6).

10. Your rights

You have the right to:

• access your data and get a copy of it (Article 15 GDPR),
• rectification (Article 16),
• erasure (Article 17), except for data I must keep, for example for taxes (Article 17(3)(b)),
• restriction of processing (Article 18),
• portability of data processed under a contract (Article 20),
• file a complaint with the President of the Personal Data Protection Office (UODO), ul. Stawki 2, 00-193 Warszawa, uodo.gov.pl (Article 77 GDPR).

Right to object (Article 21 GDPR). At any time you can object to the processing of your data based on my legitimate interest: limits, protection from abuse, logs, error reports, statistics and correspondence. I will stop processing it unless I demonstrate compelling legitimate grounds that override your interests, rights and freedoms, or grounds for establishing, exercising or defending legal claims.

How to exercise your rights. Write to support@approject.dev. There are no accounts, so I do not know which data is yours. For matters about purchases, give your Google Play order number. Without it I may be unable to identify you (Article 11(2) GDPR). I will reply within a month. In difficult cases the deadline may be extended by two months. If that happens, I will let you know in advance (Article 12(3) GDPR). Details: Your data.

What you can do yourself. Delete patient data in the app, clear the app's data or uninstall the app. The data on the phone and the identifiers then disappear. You cancel the subscription in Google Play: deleting the app or its data does not cancel it.

Do you have to provide data? No. The app creates the identifiers. Without them the server features (maps, Premium) do not work, and without a purchase in Google Play you will not get Premium. The list of people and visits works on the phone without the server.

For data processed by Google, you exercise your rights with Google.

11. Information stored on the phone

The app saves the following on the phone: the database of people and visits, settings, the map request counter, the installation identifier, the last configuration from the server and the RevenueCat library data (identifier, subscription status). The service you use does not work without this, so the app does not ask for consent (Article 399(3)(2) of the Polish Electronic Communications Law of July 12, 2024). Google libraries store their own data on the phone under Google's rules.

12. Security measures

• Connections to the server and to the providers are encrypted (HTTPS).
• The TomTom key and the secret RevenueCat key are only on the server. The Google key for the map has to be in the app (a Google requirement). It is restricted to the Dr. Drive app and its signature and has a daily limit.
• The server checks every request, limits the number of requests and filters error reports.
• The app's database is excluded from backups.

13. Information for patients

If the person who comes to you for a visit plans it in Dr. Drive, the controller of your data is that person (in their own practice) or the facility they work for. You exercise your right of access, rectification or erasure with them.

I have no access to the data on that person's phone. My server does not know whose address is in a request and does not store requests, so I cannot determine on my own whether your data is involved. If you write to me, I will explain how the app works and help the doctor or facility respond to your request (Article 28(3)(e) GDPR).

14. For doctors and facilities: obligations of the controller of patient data

A list of home visit patients is data concerning health (Article 4(15) and Recital 35 GDPR) covered by professional secrecy. Dr. Drive is only a tool. The obligations to patients belong to the controller, meaning you or your facility. Below is the minimum.

1. Determine who the controller is: you in your own practice or the facility (employment, civil-law contract, usually a B2B contract). If you work for a facility, use the app only with its consent and its authorization (Article 4(7) and Article 29 GDPR).
2. Process data on the basis of the law, not the patient's consent: Article 6(1)(b), (c) or (e) and Article 9(2)(h) in conjunction with Article 9(3) GDPR.
3. Enter into the Data Processing Agreement with me. It also includes authorization for the sub-processors (Article 28 GDPR).
4. Add the activity “planning and logistics of home visits” to your record of processing activities (Article 30(1) GDPR).
5. Add to your information notice for patients: a working copy on the phone, recipients (me as a processor, Cloudflare, TomTom, Sentry; Google in Google Maps), transfers outside the EEA, the retention period (Articles 13–14 GDPR).
6. Secure the phone: a screen lock, an up-to-date system, a device locator with remote wipe. Do not let household members use the phone (Article 32 GDPR).
7. Enter only what is needed for getting there and for the visit. Do not enter diagnoses or medications in the notes. Enter only the address in the address field, because any additions will go to TomTom (Article 5(1)(c) GDPR).
8. Delete finished visits and people with no further visits, because the app does not do this on its own. When you change phones or the cooperation ends, use “Usuń wszystkie osoby i wizyty” (Article 5(1)(e) GDPR).
9. Do not show the data to unauthorized people and do not take screenshots of the list (professional secrecy).
10. If the phone is lost or stolen, assess the risk. If needed, report the breach to the President of the Personal Data Protection Office (UODO) within 72 hours. Enter every incident in the breach register (Article 33 GDPR).
11. Assess whether a data protection impact assessment is needed (Article 35 GDPR).
12. Respond to patients' requests within a month. I will help with map requests (Article 12(3) and Articles 15–21 GDPR).
13. Do not send me patient data: no screenshots and no import files. Report bugs using made-up data.
14. Remember that in Google Maps, Google is a separate controller. On the Google account you use for work, consider turning off location history.

15. Changes to this policy

The date and version are at the top. I will announce a significant change (new data, a new recipient, a new purpose) in the app or in the update description in Google Play before it takes effect. I will notify doctors in advance, because a change of sub-processor gives them the right to object (Article 28(2) GDPR). I will send previous versions on request.

This version applies to the Android app. I will describe the iPhone version before it becomes available.