Effective Date: 23 August 2026
Last Updated: 23 August 2026
Application: MySievert — Medical Radiation Tracker
Company: Apex Technology Group, Inc. (“Apex,” “we,” “us,” “our”)
Washington residents, and anyone who wants the health-data specifics: consumer health data is also covered by our separate Consumer Health Data Privacy Policy, which is a distinct document as required by the Washington My Health My Data Act. Where that policy addresses consumer health data, it controls.
Your medical procedure records are encrypted on your device, with a key we do not have and cannot obtain. We cannot read your radiation history. We cannot list it, count it, or describe it. Not with database access, not with server access, not under legal compulsion, and not at your own request.
MySievert is a personal record-keeping tool. You log medical procedures that involved radiation; the app attaches published reference dose values and keeps a running history for you. It does not assess those values, and it does not tell you what they mean. Everything about those procedures is encrypted before it ever leaves your device.
What we actually hold on our servers, for each account, is:
That is the complete list. There is no procedure table, no record count, no activity log, no analytics database, and no advertising identifier anywhere in this product.
We do not sell your personal data. We do not share it for advertising. We serve no ads. We run no analytics SDK. We never request location permission, for any reason, ever.
This policy applies to the MySievert mobile applications, the MySievert API operated by Apex, and any MySievert web client we may publish. It does not apply to your healthcare providers, your imaging facility, your insurer, or any third-party service you separately choose to use.
Apex Technology Group, Inc. is the controller of the personal data described here.
Most privacy policies describe a promise. This one describes an architecture, because the promise is a consequence of the architecture and not the other way round.
The local store on your phone is the source of truth for your history. The app works fully offline, including logging. Server synchronisation is backup, never a dependency.
A 256-bit data encryption key (the “DEK”) is generated on your device, by your device, at the moment you log your first record — not when you create an account. An account with no records has no key material anywhere.
Every record — the exposure type, the date, the dose values, the associated catalog entry, any note you write, and the derived totals — is serialised into a single document, padded, encrypted on your device, and transmitted to us as an opaque byte array.
The server stores that array. It has no schema for its contents, no index over it, and no code path that parses it. We hold a second opaque array containing wrapped copies of your key, each wrapped under a key we do not possess.
Signing in proves who you are. It does not unlock anything. Possessing a valid credential for your account grants access to your ciphertext, and nothing more. Your sign-in provider never holds and cannot derive your encryption key.
The cost of this design, stated plainly. There is no key escrow, no administrative override, no support escalation, and no recovery path that does not run through your own device or your recovery code. If you lose both your device and your recovery code, your history is permanently unreadable — by you and by us. We accept that cost deliberately, because it is the direct source of every protection described in this policy. See Section 8.
You sign in through Firebase Authentication, operated by Google. We receive and store a
single value: an opaque user identifier (a Firebase uid). Our servers handle
no name, no email address, and no device identifier in connection with your account.
Your chosen sign-in provider — for example, a Google account — will itself process the identity information required to authenticate you, under that provider’s own privacy policy. Where the provider makes an email address or display name available to the app on your device, the app uses it locally to show you which account you are signed into. That information is not stored in the MySievert account record on our servers.
One opaque byte array containing your entire encrypted history. We cannot decrypt it and we cannot parse it.
One opaque byte array containing wrapped copies of your data encryption key. It is held as a single undifferentiated blob rather than a structured list, deliberately, so that we cannot even determine which kinds of wraps your account holds — whether you have set up a recovery code, for instance.
One boolean recording whether your account holds a paid entitlement, and, where a purchase has been made, a one-way hash of the store purchase token. The hash exists solely to prevent one purchase from entitling many accounts. The raw token is never stored.
A policy claiming “nothing” would be untrue and would undermine everything else in this document. The following is the complete list of what our storage layer necessarily reveals, and what we do about each item:
| What exists | What it could reveal | What we do about it |
|---|---|---|
| Account identifier | That an account exists | Opaque. Not linked by us to a name, email, or device. |
| Stored blob length | Roughly how much data you have | Padded to power-of-two buckets starting at 4 KiB, so length indicates a coarse magnitude and not a record count. |
| Version counter on each blob | That a write occurred | Required for safe concurrent writes. It counts writes, not records; a single write may carry any number of changes. |
| Time a write is received | When you used the app | Clients batch writes and add jitter, so arrival time does not correspond to the moment you logged a record. |
| Entitlement boolean | Whether you have paid | One bit. Carries no health information. |
We maintain anonymous aggregate counts of which procedures are most commonly logged across the platform, so we know which entries in our reference catalog deserve verification effort and refinement. These counts are population totals. They are not, and by construction cannot be, associated with any individual account.
That claim does not rest on a schema. It rests on four constraints, each of which is enforced rather than merely intended, and each of which is load-bearing:
If a future change would make any one of these four constraints untrue, this policy changes in the same release, or the change does not ship.
If you email us, we hold your message and your email address so we can reply. Please do not include details of your medical procedures in a support email — we do not need them, we cannot use them to help you, and an email is not protected by the encryption described above.
The only permitted uses of the information in Section 4 are:
We cannot use your health records for any purpose whatsoever, including our own, because we cannot read them. We do not profile you, score you, or evaluate your records — we could not do so even if we wanted to.
Stated specifically, so that it can be evaluated rather than taken on faith. These parameters are implemented, verified against byte-for-byte conformance vectors in continuous integration on every client platform, and amended in the same commit as any change to the cryptography.
| Property | Value |
|---|---|
| Content encryption | AES-256-GCM (NIST SP 800-38D) |
| Key length | 256 bits |
| Nonce | 96 bits, from a cryptographically secure RNG, unique per encryption |
| Authentication tag | 128 bits |
| Additional authenticated data | The envelope header (version, key id, nonce) |
| Key derivation | HKDF-SHA256 (RFC 5869), extract-then-expand |
| Key wrapping | AES-256-GCM |
| Reference catalog signing | Ed25519, public key pinned in each app binary |
| Recovery code | 128 bits of system-generated entropy, with a checksum |
| Transport | TLS 1.2 or higher |
Implementations use platform-native cryptographic providers only — no bundled third-party crypto library. Negative conformance vectors covering tampered tags, tampered ciphertext, rewritten key identifiers, version downgrade, and wrong keys must all be rejected for a build to pass.
Because payloads are already ciphertext before transmission, TLS is a second layer rather than the only one: a transport failure would expose ciphertext, not records. Data at rest on our servers is ciphertext in a database that has never seen the key. Data at rest on your device is additionally protected by platform facilities — encrypted local storage keyed through the Android Keystore or the iOS Keychain with file protection.
Apex Technology Group, Inc. cannot decrypt a user’s health records. There is no key escrow, no administrative override, and no recovery path that does not run through the user’s own device or their recovery code.
Read this before you rely on the app to keep your history.
Your records are recoverable to a new device in two ways: through your platform key store, if the platform successfully migrates it, or through your recovery code. If neither is available, your history cannot be recovered by anyone, including us. There is no exception, no escalation, and no support ticket that changes this.
Please set up your recovery code when the app offers it, store it somewhere you will still have it in two years, and export a PDF copy of your history periodically. A recovery code is a passphrase; treat it as one. Anyone who obtains both your recovery code and access to your account can read your history.
We detect the state in which your account holds server-side data that your device cannot open, and we tell you so directly rather than showing you an empty history. We also give you practical routes to rebuild it — a prior PDF export, your own paperwork, or a list of studies with dates from your imaging facility.
Each of the following operates under its own privacy policy, which governs how it handles anything it receives. None of them receives readable health information from us, because we do not have any to give.
| Service | Role | What it receives | Policy |
|---|---|---|---|
| Firebase Authentication (Google) | Sign-in and session management | The identity information required to authenticate you, per your chosen sign-in method. No health data. No encryption key, ever. | Link |
| Amazon Web Services (Lightsail) | Hosting for the MySievert API and database | Ciphertext, account identifiers, entitlement booleans. Nothing readable. | Link |
| Google Play Services — Block Store | Device-to-device transfer of your wrapped key on Android | An encrypted 32-byte key wrap, end-to-end encrypted. Not enabled where the platform cannot provide end-to-end encryption. | Link |
| Apple iCloud Keychain | Device-to-device transfer of your wrapped key on iOS | An encrypted key wrap, under Apple’s end-to-end encrypted keychain sync. | Link |
| Google Play / Apple App Store | App distribution and, if offered, in-app purchases | A product identifier and a transaction identifier. We never receive your card number, billing address, or store account password. | Link |
Not present in this product: advertising networks, analytics providers, data brokers, attribution SDKs, tag managers, session-replay tools, customer data platforms, and third-party crash reporters.
We disclose personal data only in these circumstances:
What we can produce in response to a subpoena, warrant, or court order. An account identifier, an entitlement boolean, and two arrays of bytes that neither we nor the requesting party can decrypt. We will not build a mechanism to defeat this, and we would contest an order requiring us to do so. We cannot, however, promise to defeat an order directed at your device or your sign-in provider — that is outside our control.
We have never sold personal data, we do not sell it, and we do not share it for cross-context behavioural advertising.
We retain your encrypted blobs, account identifier, and entitlement boolean for as long as your account exists. There is nothing else to retain.
You can delete your account from within the app, or by emailing us. Deletion removes your account record, your encrypted vault, and your encrypted key wraps from our production systems. Because we hold no derived data, no analytics rows, and no activity table, there is no second copy of your information anywhere for us to miss.
Deletion propagates to our processors within thirty (30) days, including expiry from routine encrypted backups. Aggregate counts described in Section 4(F) are not deleted, because they are population totals that were never associated with you and cannot be traced back to you.
Deletion is permanent. Once deleted, your history cannot be restored by us under any circumstances.
Deleting the app from your device does not delete your account. Deleting your account does not cancel a store subscription; manage that through Google Play or the App Store.
Subject to applicable law, you have the right to:
Email apex@apextechnologygroup.io to exercise any of these. We will verify your request by requiring you to act from the account in question, and we will respond within 45 days, extendable once by a further 45 days where the law permits and we tell you why.
Apex Technology Group, Inc. is not a covered entity and, in operating MySievert, is not a business associate. HIPAA does not govern this app, and we do not claim that it does. Information you enter here is not protected health information under HIPAA merely because it is medical in nature.
We say this plainly because “HIPAA compliant” is a claim that is frequently made and rarely true of consumer apps. Your protection here comes from the architecture in Sections 3 and 7 — which is, for this narrow purpose, a stronger guarantee than a regulatory one, because it does not depend on our good behaviour.
The FTC Health Breach Notification Rule does apply to us. See Section 14.
We are subject to the FTC Health Breach Notification Rule, including its 2024 amendments, under which an unauthorised disclosure — not only an intrusion — is a reportable breach.
If we discover a breach of security involving personal data we hold, we will notify affected users and the Federal Trade Commission within the timeframes the Rule requires, and any other regulator entitled to notice under applicable state or foreign law. Where the law sets a 60-day individual notification clock, we will meet it.
The Rule’s notification duties attach to unsecured health information. Records encrypted on the user’s device under keys our servers never hold are a strong case for falling outside that definition, and our encryption standard is documented and dated for exactly that reason. We will not, however, use that position as a reason to stay silent: if our systems are breached, we will tell affected users what happened, whether or not a notification duty is triggered.
No system can guarantee absolute security. What we can guarantee is that an attacker who obtains our database obtains ciphertext, and that we have not kept a key anywhere for them to find.
To report a vulnerability, email apex@apextechnologygroup.io. We will not pursue legal action against good-faith security research that respects user privacy, avoids service degradation, and gives us reasonable time to remediate before disclosure.
Consumer health data is addressed in our separate Consumer Health Data Privacy Policy, provided as a distinct document with its own link as the Washington My Health My Data Act requires. It also covers Nevada SB 370, the health-data provisions of Connecticut’s and New York’s laws, and equivalent requirements elsewhere.
We do not sell consumer health data, and we do not operate or permit any geofence around any healthcare facility. The app never requests location permission, so we have no means to.
In the twelve months preceding the effective date of this policy, we collected the categories of personal information described in Section 4: identifiers (an opaque account identifier), commercial information (an entitlement boolean), and sensitive personal information in the form of health information — which we hold only as ciphertext we cannot read. We collected it for the purposes in Section 6, from you.
Residents of states with comprehensive consumer privacy laws — including Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, and others — have rights of access, correction, deletion, portability, and opt-out of targeted advertising, sale, and profiling with legal or similarly significant effects. We conduct none of those three activities. Where health information is treated as sensitive data requiring opt-in consent, we obtain that consent in the app before any collection.
Appeals. If we decline a rights request, we will tell you why, and you may appeal by replying to our response or emailing apex@apextechnologygroup.io with “Appeal” in the subject line. We will decide the appeal within 60 days and, if we deny it, tell you how to contact your state Attorney General.
Where MySievert is offered in these jurisdictions, Apex Technology Group, Inc. is the controller. Our legal bases are:
You have the rights of access, rectification, erasure, restriction, portability, and objection, and the right to lodge a complaint with your local supervisory authority. Personal data is processed on servers in the United States; transfers rely on the Standard Contractual Clauses or another valid mechanism. Because the data transferred is ciphertext under a key held only on your device, the supplementary-measures analysis is unusually simple: an authority compelling our host obtains bytes nobody can read.
We do not carry out automated decision-making producing legal or similarly significant effects. In particular, the app performs no assessment, scoring, classification, or interpretation of your health records.
Where PIPEDA or a comparable law applies, we obtain express consent for health information, limit collection to the purposes identified in Section 6, and honour access and correction requests through the process in Section 12.
MySievert is intended for adults. It is not directed to children, and we do not knowingly collect personal information from anyone under 18. If you believe a child has created an account, contact us and we will delete it.
An adult may log procedures relating to a child or another person in their care within their own account. Those records are the adult’s account data, encrypted like any other, and the adult is responsible for the authority to record them.
We may update this policy. If a change is material — and in particular if it would affect any statement in Sections 1, 3, 4, 5, or 7 — we will update the effective date, describe the change in the app, and, where the change concerns consumer health data or special category data, obtain your consent before it takes effect for data already collected.
We will not retroactively apply a weaker policy to data collected under a stronger one.
Email: apex@apextechnologygroup.io
Company: Apex Technology Group, Inc.
Subject line for privacy requests: “Privacy Request — MySievert”
Related documents: Terms of Service · Consumer Health Data Privacy Policy