Privacy, explained
with precision.

1. Summary

AMD is a working tool for healthcare professionals. Its architecture starts from a deliberate decision: the developer has no infrastructure capable of reading your clinical information. The clinical record never passes through a developer server: there is no remote database holding your records and no admin console. The only exception is an optional service, patient intake by link (§16). That service receives, encrypted, the intake details your patients send. It receives no clinical data, and the developer cannot read what it receives either.

• Everything lives on your device, stored locally with iOS file protection.
• If you enable iCloud, data is mirrored to your own private CloudKit zone, tied to your Apple Account. The developer cannot read its contents: there are no credentials, console, or API that would allow it. Encryption is managed by Apple, and how far end-to-end encryption reaches depends on your account settings.
• The clinical function works offline. AMD neither sends nor receives clinical data from any server, its own or a third party's. ICD-11 diagnosis search runs entirely offline, against a catalogue bundled with the app. In addition to the public-data queries described in §6, these optional features are started by you and carry no clinical data: Weather, which queries Apple Weather using the device's approximate location (§8); signing in with your Apple Account, which asks Apple whether the credential is still valid (§10); dictation, for which the system downloads the speech model from Apple if the device does not have it yet (§7); and patient intake by link, which queries a developer server to fetch the encrypted intake details your patients send (§16).
• Zero third-party dependencies. Not a single external library is integrated: no analytics, advertising, crash-reporting, or attribution SDK.
• No tracking. AMD does not track you across apps or websites, does not use the advertising identifier, and does not build usage profiles.
• Data leaves the device only when you decide it should, through an explicit action: exporting a PDF, exporting a backup or a spreadsheet, sharing an attachment, sending an appointment reminder, sharing a Library handout, or creating a patient intake invitation, which carries your professional card (§16).
• Patient intake by link is optional and off by default. If you turn it on, your patients enter their intake details in a web form. Those details travel encrypted with a key only you hold. They are deleted from the server when you add them to AMD or discard them, or after 30 days at most. Available from AMD 1.2. Until then, AMD sends no invitations and receives no data through this service.
• AI is the system's, and it runs on-device. Session summaries use local Apple Intelligence; clinical notes are not sent to any AI service to generate them.

2. Who is responsible for what

This distinction underpins everything else, so it is worth stating plainly.

You, the professional

You are the data controller for your patients' data under Law 25.326. You decide what to record, for what purpose, how long to keep it, to whom it may be disclosed, and when to erase it. The clinical record you build with AMD is your record and your professional responsibility, exactly as it would be on paper.

That includes obtaining your patients' informed consent where required, safeguarding professional confidentiality, and answering any access, rectification, or erasure request addressed to you. AMD gives you the tools — export, correct, deactivate; the duty is yours.

The developer

Juan Ignacio Antolini is the controller only for the data the app handles about you as a user: your name, license number, specialty, and professional contact details. In practice he does not access it, except for the details shown on the patient intake card. If you use that feature, your name, title, license number, contact email and, if you added it, your address are stored unencrypted on the server with each invitation, so your patient can see who will receive their details before entering them. For those details, the developer is the data controller. The card is deleted when the invitation closes (when you add the submission to AMD, discard it, or revoke the invitation). If no one closes it, it is deleted along with the invitation, at most about 32 days after it was created.

As a rule, the developer is not a "data processor" for your patients' data: he does not host your clinical records, does not process them on your behalf, and cannot recover them if you lose them.

The exception is patient intake by link (§16). If you use that feature, the developer receives on your behalf the forms your patients send. He keeps them encrypted until you add them to AMD or discard them, and then deletes them. For that purpose he acts as a data processor (Article 25, Law 25.326), under the addendum you accept in the app before your first invitation.

DonWeb

If you use patient intake by link, DonWeb (Dattatec.com S.R.L.) hosts the form's server and its backups in Argentina, as a sub-processor bound by the same obligations as the developer. It cannot read the content of submissions.

Apple

If you enable sync, Apple provides the storage infrastructure (iCloud / CloudKit) under your account and its own privacy framework. That relationship is between you and Apple; the developer is not part of it and has no visibility into your records.

3. What data the app handles

AMD stores what you enter to run your practice and, if you use patient intake by link, what your patients send you through that form. Nothing is collected in the background or inferred from your behavior.

All of it is used exclusively for the app's clinical function. There is no analytics, advertising, profiling, or any secondary purpose.

4. Where it is stored

AMD splits storage into four separate databases on the device, and only one of them syncs:

The split is not cosmetic: the catalogues are derived from the app bundle and never travel to iCloud, so they cannot be duplicated or contaminate your data when syncing across devices.

Some files live outside the database, in the app's private container: document attachments (stored with file protection and random names, with no clinical data in the filename), your avatar, and the PDFs you export. So do the PDF copies of the handouts you prepare in the Library: they are stored with iOS's strictest file protection — they cannot be read while the device is locked —, are excluded from iCloud Backup, do not sync, and expire after 24 hours and are deleted as soon as the app can do so safely. Attachment files sync as well: they travel to your private iCloud zone along with their record (name, type, date, and any title you give them), and each device also keeps a local copy to open them. Attachments added before this feature are uploaded from the device where they were added, if it still has the file.

5. iCloud sync

Sync is optional and depends on your Apple Account. When enabled, your clinical data is mirrored into the app container's private CloudKit zone, inside your own iCloud space.

• That zone is inaccessible to the developer: there are no credentials, console, or API that would allow reading it.
• It lets you see the same data on your iPhone and iPad, and acts as a backup tied to your account.
• The app cannot confirm that a write actually reached iCloud. The platform does not expose that guarantee, and AMD prefers to tell you a copy is "unconfirmed" rather than claim a success it cannot prove. That is why, for patient intake by link, the server copy is deleted when the app detects that iCloud completed a sync after the patient was added, even though it cannot verify that a specific card arrived. If iCloud is off, the copy is deleted 30 days after it was sent.
• If you turn iCloud off for AMD, the data keeps working on the device, without syncing.
• The Library history (§3) syncs along with the clinical database. The handout PDFs do not sync.

6. What AMD does not do

• There are no developer servers for the clinical record. No remote database holds your records. The developer's only server is the one for patient intake by link, which remote consent also uses (§16): it keeps encrypted submissions and consents for 30 days at most, plus up to 7 days in the provider's weekly backup (§16), and cannot read them.
• No network requests for the clinical function. No external API is involved in the clinical record. In particular, ICD-11 search is fully offline: the term you type when looking up a diagnosis never leaves the device. In addition to the public-data queries described below, optional features use the network without sending clinical data: the weather query (§8), checking your Apple Account if you enable that sign-in (§10), the download of the system speech model for dictation (§7), and patient intake by link (§16).
• No third-party libraries. The app is built without a single external dependency, which eliminates the most common risk category in mobile apps: the SDK that collects on its own.
• No product analytics or telemetry. The developer does not know which screens you open, how many patients you have, or how often you use the app.
• No advertising and no advertising identifier.
• No sale or disclosure of data. There is no one to disclose it to.
• No HealthKit access. AMD neither reads from nor writes to the Health app. The microphone is used only while you dictate a note, with the scope described in §7: audio is never recorded or saved. Location is used only if you enable Weather, with the scope described in §8; outside that feature, AMD neither requests nor uses it.
• Your contact list is never read. When you import a patient from Contacts, the system shows the picker and hands AMD only the single card you chose. The app never enumerates your address book and never writes to it.
• Nothing is written to your photo library. The photo picker also runs outside the app.
• No clinical data in system logs. Technical logs contain counts, error codes, and categories — never names, notes, diagnoses, or patient identifiers.

Public data: CPI and public holidays

From version 48, when remote updates are enabled, AMD uses HTTPS to query the Argentine CPI published by ArgentinaDatos and public holidays published by Argentina.gob.ar. Queries may run automatically or when you refresh these data. They request public information: they do not send patient or professional data, clinical notes, fees, amounts, appointment dates, or the device's location. A public-holiday query specifies only the year of the public calendar being requested.

The receiving sites and the infrastructure serving those requests may see your IP address and technical connection metadata, such as HTTP/TLS metadata and the user agent. This does not make a request anonymous. The developer does not control how those data are retained. ArgentinaDatos states that its origin server records the full IP address and metadata to operate and secure the service and produce traffic statistics. Access logs remain until rotation, with no published maximum; hourly statistics are retained for 30 days and daily statistics for 395 days. Cloudflare and the hosting provider also process data under their policies. We do not know every intermediary’s retention period or those of Argentina.gob.ar.

AMD keeps public data locally so they can be consulted offline. If a refresh fails, the last available valid information is preserved. Downloading CPI data does not automatically change your fees, and downloading public holidays does not create, change, or cancel appointments.

For stability diagnostics, AMD receives MetricKit reports from the system (crashes, hangs, CPU usage). That processing happens entirely on the device, is never transmitted anywhere, and never includes clinical content: only technical categories and counts.

Patient intake server

AMD connects over HTTPS to ingreso.jia.ar when you create or renew an invitation, when you check your invitations, when you add, revoke, or discard a submission, and when the app confirms, without you having to do anything, that iCloud completed the sync of an added patient; that confirmation carries only identifiers, no patient data. Those requests carry opaque technical identifiers for the invitation, the submission, the device, and the record about to be created: they contain no personal data, but they are linked to one another and to your signing key. The record's identifier is the same one the patient will have in your clinical record. Your patients connect to the same server when they open and send the form. As with any connection, the server sees the IP address and technical connection metadata, such as HTTP/TLS metadata and the user agent, for both you and your patients. The service keeps no logs of its own for those connections, except a fingerprint of the IP address, never the address itself, which it uses to limit attempts and deletes after 2 hours. The hosting provider keeps its technical logs for up to one month and then deletes them automatically. None of those logs contain the content of submissions.

If you send a consent to be signed remotely, the app uploads the encrypted text to the same server and later downloads the encrypted response. The person signing opens the link in their browser and connects to that server to read the text and send their response. That text may include the patient's health data, such as the diagnosis, medication, indication, or other clinical data you enter when preparing the consent. That is why it travels and is stored encrypted, in layers that can be verified: the key to read it is only in the link's fragment (what follows “#”), which the browser does not send to the server, and the server keeps only a fingerprint (hash) of that key, which lets it check that whoever responds has the link but cannot decrypt the text. As with any connection, when someone opens the link the server sees their IP address, the time of the connection, and their browser and their device's operating system (user agent). The hosting provider keeps those technical logs for up to one month. The encrypted text is deleted from the server as described in §16 and may remain for up to 7 more days in the provider's weekly backup.

If you create an appointment pass for Apple Wallet, the app sends the same server only what is printed on the pass: your name and specialty, the appointment time, the modality, whether it is scheduled or cancelled and, if you enter it, the office address. It sends nothing about the patient. The server signs the pass and does not keep it.

If you send the “Next appointment” pass instead, which AMD keeps up to date, the server does store data, because it has to send Wallet the new version every time the appointment changes: your name and specialty, and the time, time zone and modality of the next scheduled appointment, or the fact that there is none. It does not store the office address or the video call link, nor data that identifies the patient (not their name, ID number or the identifier of their record); it does store an identifier of their device, as explained below. The pass is recognized by an identifier that AMD computes and that cannot be traced back to the record. The appointment is stored encrypted with a server key, which decrypts it only to build the pass. When your patient adds the pass, their device registers with the server: the server stores a fingerprint (hash) of the identifier Wallet assigns to that device and the notification address (push token) Apple gives it, which identifies that device. With it, the server tells the device, through Apple's notification service, that a new version is available; the notice carries no appointment or patient data, and the device downloads the updated pass. AMD cannot confirm that the pass was updated on your patient's device: Apple does not guarantee delivery of those notices, and Wallet also updates the pass when it is opened. As with any connection, the server sees your patient's device IP address and technical metadata when Wallet connects. How long each item is kept is in §16.

The form your patients open uses no analytics, third-party cookies, or trackers.

7. Artificial intelligence

Session summary

When you request a session summary, AMD uses the Apple Intelligence language model that runs on the device. The input is that session's clinical notes and treatment plan; the output is a summary you can then edit or discard.

• Processing is local: no external AI service is used, neither the developer's nor a third party's, and the notes are not transmitted to generate it.
• Each request opens a fresh model session, so one consultation's content cannot bleed into another's.
• If the device is not eligible or Apple Intelligence is off, the feature is unavailable. There is no cloud fallback.

Generated avatar

You can generate a professional avatar with Image Playground, Apple Intelligence's image service. The input is a style description you write plus a fixed concept from the app. No patient data takes part in that generation, which is performed by the operating system, not by AMD.

Note dictation

You can dictate a session's notes and plan instead of typing them. AMD turns your voice into text with Apple's speech recognition, running on the device.

• It is meant for you to dictate, not to record the appointment or what the patient says.
• Audio lives only in memory while you dictate: it is never recorded, never saved to any file, and never leaves the device. Only the text remains; it is inserted into the field and you can edit it before saving the session.
• Transcription is local. If the device does not have the speech model for the language yet, the system downloads it from Apple before starting; that download carries none of your audio or text.
• It requires two system permissions: microphone and speech recognition (§8). If you deny them, you can keep typing as usual.

System writing tools

iOS offers its own writing tools (rewrite, proofread, summarize) in text fields across any app, and AMD does not disable them. If you use them on a clinical notes field, that text is processed under Apple Intelligence's privacy framework, which for some operations may use Private Cloud Compute. This is a system feature, not an AMD one, and you can turn it off in iOS settings.

8. System permissions

All of them are optional, requested at the moment you need them, and off by default. Denying them does not prevent you from using the app: it only disables the corresponding feature.

What gets written to your calendar

If you enable the integration, the event AMD creates carries a fixed, neutral title — "Session" — identical for every session, and the event notes are left empty. No name, initials, diagnosis, clinical status, location, or attendees are written. The event includes an internal link to the session, which is an opaque identifier with no meaning outside the app.

This matters because a calendar event propagates to iCloud Calendar, the lock screen, widgets, and every device signed into that account. That is why it carries nothing that could identify the patient. AMD also only modifies or deletes events it created itself.

What notifications say

They are local, scheduled by the device, and their text is fixed: they tell you there are incomplete sessions, or that some patients have exceeded a number of days without care. The only variable value is a number. No name, identifier, or clinical data appears — neither in the notification nor in its internal payload.

Weather and Apple Weather

Weather is optional and off by default. You turn it on from the "Today" screen with a button; only then does the system ask for "while using the app" location permission. If you don't turn it on, AMD neither requests location nor queries the weather.

When it is on:

• It uses the device's approximate location, as a single reading per query. There is no continuous or background tracking.
• The query goes straight to Apple Weather (WeatherKit) through the system API, with no developer server in between, and asks only for current conditions. There is no forecast, no saved city, and no address search.
• AMD does not store that location: it is not written to the database, to preferences, to technical logs, or to the audit log.
• The weather response stays in memory until the earlier of two limits — whatever Apple indicates, or 30 minutes — and is discarded when you turn Weather off.
• The location is not associated with patients, sessions, or your professional profile, and no clinical data is sent with the query.
• The official "Apple Weather" mark is shown alongside the data. The weather detail additionally shows a legal link provided by Apple. Loading that mark and opening that link are requests to Apple servers; AMD attaches no coordinates to them.
• You can turn Weather off at any time, from the weather detail.

Apple's processing of that query is governed by Apple's terms and privacy policy, not by this policy.

Siri & Shortcuts

Siri & Shortcuts is optional and off by default. You turn it on in Settings → Security → Siri & Shortcuts, after a screen that explains what changes, and it stays on across all your devices with the same profile.

With it on, Siri and the Shortcuts app can:

• open the "Today" screen and start a new session. Both actions open AMD and ask you to unlock the device;
• say out loud how many patients you have today. Siri receives only the number. It asks you to unlock the device, but it answers even if AMD's Face ID, Touch ID, or Optic ID lock is on: anyone who unlocks the device can ask. If you turned on sign-in with your Apple Account (§10), however, it waits until you sign in.

Siri, Shortcuts, and Apple Intelligence never receive patient names, diagnoses, notes, or any other clinical data. AMD adds nothing to the Spotlight index. Each use is recorded in the audit log as a read, without the result.

Your voice request is processed by Siri under Apple's terms and privacy policy. AMD cannot delete the shortcuts you build in the Shortcuts app or anything Siri or iOS keeps on its own. When you turn the option off, and when you delete your account, AMD removes from the device the record the system keeps of these actions.

ICD-11 lookup. With or without that option, you can ask Siri to look up a code or diagnosis in the ICD-11 catalogue bundled with the app ("Look up ICD-11 in AMD"). The lookup answers without opening the app, reads only the catalogue, and does not touch your patients or clinical records. AMD neither stores nor audits the term you dictate, and it deletes the record the system keeps of each lookup. Opening the result in AMD asks you to unlock the device.

9. Data you send out yourself

AMD never transmits data on its own. These are the only paths by which clinical information can leave the device, and every one requires an explicit action from you. Two more paths that are not clinical information are described below: Library handouts, which are prepared for a patient, and patient intake invitations, which carry your professional card.

Clinical record summary PDF

The patient's identity is always included: name, medical record number, age, date of birth, biological sex, and gender. You choose the rest, and optionally a date range for sessions:

• on by default: additional personal details (ID document, nationality, residence, occupation, education level, and marital status), clinical history and diagnoses, session notes, and your signature, if you have one on file;
• off by default: patient contact details, emergency contact, and health coverage.

It is therefore a configurable summary, not the complete copy of the clinical record. It is the app's most sensitive output: it can contain contact details, diagnoses, and complete session notes.

• The file is generated in the app container with file protection, is excluded from iCloud Backup, and expires after 24 hours, then is deleted as soon as the app can do so safely.
• The filename uses the medical record number, not the patient's name. Even so, that number is visible to whoever receives the file.
• Generation is recorded in the audit log at critical severity, noting which categories you included — never the content.
• The PDF is only shown, shared, or saved after the export has been recorded in the audit log. If that record fails, the file is withdrawn without being shown.
• You can share it or save it to Files. A copy saved to Files stays where you chose, outside the automatic 24-hour deletion. Every page carries the notice "Confidential document — contains protected health information".
• From the moment you share it, the file is outside AMD's control and under your professional responsibility.

Backup and spreadsheet

From Settings → Backup you can export all your information to an .amdbackup file, or export a spreadsheet with the administrative data. It is the broadest export in the app: the backup carries the clinical records of all your patients, notes included.

Before exporting. Every export warns you that you are taking out sensitive data about all your patients and asks you to confirm your identity with Face ID, Touch ID, Optic ID or the device passcode. If the device has no passcode, you can't export or import.

What the backup contains. Patients, sessions and their notes, diagnoses, history, anthropometrics, medication, scales, payments, your session types and pricing policy, issued certificates, Library history and the audit log. It also includes what you hid and what you deactivated. It doesn't carry the catalogues bundled with the app (ICD-11, drug reference and reference data) or your device preferences. If AMD can't attribute a record to your profile with certainty, because another profile on the same device has a patient or session with the same identifier, that record is left out and the backup counts it.

With a password (the default). You choose a password of at least 10 characters. AMD derives the key from it with PBKDF2-HMAC-SHA256 and encrypts the content with AES-256-GCM, which also detects any tampering. AMD doesn't store the password: if you lose it, nobody can open the backup, not even the developer. It is the only backup that carries attachments (PDFs and images), up to 192 MB; those that don't fit are not included, and when you import it AMD tells you how many are missing.

Without a password. This is optional, and the app warns you that anyone who opens the file will see your patients' clinical records, notes included. So as not to strip the protection from what iCloud stores with end-to-end encryption, a backup without a password leaves out your signature and practice address, video call links, report templates and copies of issued certificates, the Library, attachments, your base appointment type settings, the private titles of your reservations, and absence confirmations in habits and family history. The app shows you that list before exporting, and the file declares what was left out.

The spreadsheet. Four CSV files to read in Excel or Numbers: patients (medical record number, name, national ID, date of birth, contact details and status), sessions (date, format, status, duration and fee), diagnoses (ICD-11 code, title, type and date) and payments (date, amount, currency and method). It has no clinical notes and can't be used to restore. It has no password, and the app warns you that it contains identifying data and diagnoses for all your patients. It follows what the app hides: it doesn't include deleted patients, hidden sessions or voided payments.

Where it goes. You choose where to save it in the system's Files panel: on the device, in iCloud Drive or with another provider you have installed. AMD doesn't upload or share it on its own. The file is named AMD-copia- followed by the date and time, without your name or any patient's. Once you save it, the file is outside AMD's control: its safekeeping depends on the place you chose and is your professional responsibility. Save the backup only where you alone have access.

Logging. Exporting a backup or a spreadsheet is recorded in the audit log with the protection type and the number of records of each kind, never the content. The file is offered for saving only after that entry is stored; if logging fails, the file is deleted without leaving the device.

Importing a backup. Importing only adds what you don't already have: it never replaces or deletes anything. Before applying anything, AMD shows you what it will add, what is already there and what it won't import. A record that differs from yours is not imported, and yours is kept. If something fails midway, nothing changes. Imported data joins your clinical database and, if you use iCloud, syncs like the rest. The backup's audit log is added with its original dates, and the import itself is recorded.

• Damaged or modified backup. A password-protected backup that can't be verified is not imported. The same goes for a wrong password.
• Backup without a password. AMD can tell whether it was damaged, but not whether someone modified it, so it warns you and asks you to confirm before importing. Import it only if you know where it came from.
• Backup from another profile. If another professional profile exported the backup, AMD warns you before importing: its patients are assigned to you, together with the appointment types their sessions use. Its schedule, report templates and settings are not imported, and issued certificates stay only in the backup. A patient or session that already belongs to another profile on this device is not imported or merged with yours.

To move your data to another device with the same iCloud account you don't need to import: it syncs on its own (§5).

Attendance certificate

Designed to be handed to a third party, so its filename is deliberately neutral: it does not include the medical record number. When you issue it, AMD keeps a copy of what was issued — the patient's name and national ID, the session date, your professional details, and your signature, if you included it — so you can share it again exactly as it was issued, from "Issued certificates" on the patient's card. That copy syncs to your iCloud along with the clinical database and cannot be edited or deleted in the app. Issuing it and each time you share a copy are recorded in the audit log, without the content. If you delete your account, the copy is deleted (§12).

Care and work leave certificates

Designed to be handed to a third party, such as an employer. The care certificate states that the patient received care on a given date; the work leave certificate, that they require leave for a number of days. Both carry the patient's name and national ID, your professional details, and your signature, if you include it.

• By default, the work leave certificate says "por razones de salud" ("for health reasons"; the certificate is printed in Spanish), a text you can edit for that certificate. It only prints a diagnosis, with its ICD-11 code, if you choose one for that document.
• The filename is neutral: it does not include the patient's name or medical record number.
• The PDF gets the same treatment as the clinical record summary: file protection, exclusion from iCloud Backup, and expiry after 24 hours. AMD keeps no copy of its content.
• Each issuance is recorded in the audit log with the document type, whether it was signed, and, for work leave, whether it included a diagnosis — never the content.

Consent copy

You can give the patient a PDF copy of a signed consent. It includes the text, the signatures, who signed and in what capacity, your device's date and time, and a short fingerprint that makes changes detectable. It states "Signed electronically on screen. This is not a digital signature (Law 25.506).". The file is created with file protection and a neutral name, is excluded from iCloud backup, and the export is recorded in the audit log, without the content. Once you share it, it is outside AMD's control.

Remote consent

You can send the patient or their representative a link to read a consent and respond from their phone, signing on screen. The link carries the key to read the text, and the response travels encrypted: the server sees neither the text, which may include health data, nor the signature. The signer's IP address and browser are not stored with the response; the hosting provider's technical logs do record the IP address, time, and browser of whoever opens the link (§6). The server adds the time it received the response, signed. The link expires after 48 hours. Names and national ID numbers never leave your device: AMD adds them when it saves the response. Share the link only with the person who has to sign. Anyone who cannot sign responds in person, with witnesses.

Appointment reminders

You can send a reminder by email, SMS, or WhatsApp. AMD prepares the message and hands it to the channel you pick after you review it and tap send.

• AMD's templates include only the patient's first name — never the surname — your signature name, and the appointment logistics (date, time, duration, modality, address or video link). Never diagnoses or clinical notes.
• If you write the message yourself, it carries exactly what you write: there, the content is your decision.
• When using WhatsApp, the patient's phone number and the message text pass through a WhatsApp URL and become subject to that service's policy. That is the unavoidable trade-off of using a third-party channel.
• AMD does not store the message or the recipient: it records the channel, the outcome, and an opaque cryptographic fingerprint whose only purpose is to distinguish one send from another. If you change the patient's phone or email, a prior authorization stops matching and is invalidated.
• Requiring a recorded authorization from the patient before sending reminders is optional and off by default. It is set on each device and does not sync. With or without that requirement, each message goes out only after you review and confirm it.

Sharing an attachment

Document preview uses the system viewer, which has its own share button. AMD records every opening of a clinical document, but cannot intercept or suppress that system action: if you share an attachment from there, it leaves the device through the channel you choose.

Sharing a Library handout

The Library contains psychoeducational handouts bundled with the app. They are educational material, not confidential, and are not part of the clinical record. When you prepare a handout for a patient, AMD generates a PDF copy on the device; if you choose Share, that copy leaves through the system share sheet.

• The PDF contains no patient data. It includes the handout, its authorship and, only if you turned them on when preparing it, your professional details: name, profession, license number, or email. They are off by default.
• Before every share — including sharing the same copy again — AMD asks you to confirm on its own screen, which shows the handout, the patient it was prepared for, and which of your details are printed. The patient's name is shown only there, inside the app; never in the file.
• The file is named "AMD Document.pdf", or "Documento AMD.pdf" if the handout is in Spanish. Its metadata identifies the app and the authorship of the material; never the handout's title or any patient data.
• Only a current copy can be shared: it expires 24 hours after it was prepared, and it cannot be shared while the device is locked or if the patient has been deactivated.
• The sheet offers the system destinations — such as Mail, Messages, AirDrop, Print, or "Save to Files" — and the third-party apps you have installed. AMD excludes copying to the clipboard, assigning to a contact, adding to the Reading List, and saving to Photos.
• You choose the destination and the recipient in the other app: AMD cannot see who receives it and does not store the recipient. In the patient's history it records the date, what the sheet reported ("Share sheet opened", "Shared", "Cancelled", "The destination app reported an error", or "No response from the share sheet"), and, when the system reports it, the channel category. "Shared" means the destination app reported that it finished; not that the patient received or read it.
• After you share it, the file is outside AMD's control and subject to the destination's privacy policy.

Direct contact

The call, WhatsApp, and email buttons on a patient's card open the corresponding app with the contact detail prefilled and no message body. From there, the app you chose governs.

Patient intake invitations

When you invite a patient, AMD generates a single-use link, valid for 48 hours, and you send it through whatever channel you choose. The link carries no patient data: it contains a random code and your public encryption key.

When the page opens, the browser does not send that part of the link to the server. The form then presents the code so the server can recognize the invitation, and the server stores only a fingerprint of the code. Your public encryption key never reaches it. So that you can see your invitations from your other devices, the server also stores an encrypted copy of the link, which only your keys can open, and records your public signing key, which it uses to check that requests come from your app and which cannot be used to read anything.

If you send the link by WhatsApp, email, or SMS, that channel is governed by its own terms, just like appointment reminders.

The form shows your patient your name, title, license number, contact email and, if you added it, your address, so they know who will receive their details. Only someone with the link can see them.

10. Security

• iOS file protection applied to the clinical database, attachments, avatar, exported PDFs, and backups and spreadsheets while AMD holds them. The effective at-rest protection level depends on the data type and how the system manages each file; in all cases the data is covered by device encryption, which requires your passcode.
• App lock with Face ID, Touch ID, or Optic ID, optional. With the lock on, you choose in Settings when it is required again: immediately when the app goes to the background (the default on iPhone and iPad) or after 5, 10, 15, 30, 45, 60, or 90 minutes away from the app. Locking the iPhone or iPad also locks AMD, even if that period has not ended. If biometrics are unavailable, the device passcode is offered. If the lock preference or the chosen period cannot be read, the app does not assume they are off: it blocks access and uses the shortest period. Exception: with Siri & Shortcuts on, today's patient count can be requested on an unlocked device even while this lock is on (§8). The same does not apply to sign-in with your Apple Account.
  On the Mac, AMD asks for Touch ID or your Mac password when it opens, and asks again after the time you choose without using the app (30 minutes by default; from 5 to 90 minutes). Sync and notifications do not count as use. You can also choose “Never”: in that case AMD does not lock after a period of time, and protection is left to your Mac’s own lock. Even so, AMD always locks when the Mac sleeps, when the screen locks, or when the user is switched.
• Sign in with your Apple Account (Sign in with Apple), optional, from Settings → Security. Once on, AMD asks for it at every launch, before the biometric lock, and only the same Apple Account that turned it on opens it. It is not an AMD account and there is no developer server: AMD does not request your name or email, and from Apple it receives only an opaque identifier, specific to this app, which it stores in the device keychain. At launch and when you return to the app, it asks Apple whether that credential is still valid; if Apple says it is not, it asks you to sign in again. Offline, and for up to 7 days after the last validation with Apple, you can get in with Face ID, Touch ID, or the device passcode. Signing out deletes no data.
• App switcher shield: leaving the app covers the screen so the multitasking thumbnail cannot expose clinical data.
• Isolation between profiles: if a single device holds more than one professional profile, each can reach only its own patients and sessions. Verification is strict: on any identity ambiguity the app denies access rather than guessing. The isolation is logical, not cryptographic — anyone with your passcode and biometrics reaches the device.
• Keychain: technical preferences and records — the lock preference and its period, the professional account chosen at launch, a technical marker of the synced account, and, if you turn on Apple sign-in, its opaque identifier and the date of the last validation — with no passwords or clinical data. They are bound to this device: they do not sync and are not restored onto another one. They can be read only while the device is unlocked, except the synced-account marker, which can also be read after the first unlock following a restart.
• The exception is the patient intake keys. If you use that feature, AMD generates two private keys, one for encryption and one for signing, and stores them in iCloud Keychain. iCloud Keychain syncs them across your devices signed into the same Apple Account (iPhone, iPad, and Mac), so you can add submissions to AMD from any of them. They can be read after the first unlock following a restart, and they never pass through the developer's server. Only each device's identifier stays bound to that device.
• No custom cryptography: AMD uses standard algorithms from the system and the browser and invents none of its own. It employs SHA-256 for integrity fingerprints and derived identities, which is hashing, not encryption. Two features encrypt. Patient intake by link: your patient's browser encrypts the form with ECDH P-256, HKDF-SHA256, and AES-256-GCM, and only your private encryption key can decrypt it. Patient intake also uses a private signing key. And the password-protected backup: AMD derives the key from your password with PBKDF2-HMAC-SHA256 and encrypts the backup with AES-256-GCM. Neither the password nor the key is stored anywhere (§9).
• The app container is not exposed in the Files app, and regenerable catalogues are excluded from backup.
• Process hardening enabled in the app (iOS memory and code-loading protections).

11. Traceability and audit log

AMD keeps an audit log of clinically relevant operations: creation, modification, deactivation, restoration, reading of clinical data, export, and permanent deletion. It exists to support the traceability a clinical record demands.

• Each entry records the action, the entity type, its identifier, who performed it, the date, and a severity. It is append-only: never edited or deleted.
• The detail field is structural — which categories were touched, what options an export had — and contains no clinical notes, names, or contact details. It may, however, contain the ICD-11 diagnostic code of the recorded operation, which is health data.
• The log syncs along with the rest of the clinical database to your private iCloud zone.
• It is retained for 15 years and purged automatically by age. The period was set above the legal minimum for clinical record retention, adopting the most demanding of the applicable frameworks.
• The Library is not part of this log: its handouts are not part of the clinical record. What you prepared and shared is kept in its own history (§3), which is deleted entirely when you delete your account (§12).
• When you add a patient through patient intake by link, the creation of their card is recorded with the origin "patient intake by link". Inviting, revoking, or discarding are not recorded, because they do not touch the clinical record.
• Exporting a backup or a spreadsheet is recorded with its protection type and the number of records, without the content. When you import a backup, its audit log is added to yours as it was, with its original dates, and the import itself is recorded.

12. Retention and deletion

Since the clinical record does not pass through developer servers, you control retention: data remains on your device and in your iCloud for as long as you keep it there. You can export each patient's information as a PDF, or everyone's in a backup, at any time. Keep in mind that clinical records carry a legal retention period — Law 26.529 requires ten years from the last recorded encounter — and that their custody is yours: deleting a record inside the app does not release you from that period. The only exception is patient intake submissions. The server deletes each submission when you add it to AMD or discard it, or 30 days after it was sent, whichever comes first. Unfinished invitations are deleted 30 days after they expire, and records of closed invitations after 7 days. Your card is deleted when the invitation closes.

Deactivating a patient

Deactivating a patient removes them from daily operation while preserving their record, which is what a medico-legal registry requires. It is not a destructive erase.

Deleting your account

From Settings → Account → Delete account, with double confirmation. On confirmation:

• The data identifying you (name, surname, email, license number, avatar, and signature) and your patients (name, surname, national ID, email, phone, address, emergency contact, health coverage, photo, and genogram) is deleted immediately.
• All your patients are deactivated and your non-clinical configuration is deleted: session types, pricing policy, and your personal medication library.
• Everything in the Library is deleted entirely — neither anonymized nor retained: the history of the handouts you prepared and of each time you shared them, and any PDF copies left on the device. It is not clinical record, so the retention period does not apply. Anything you already shared is beyond AMD's reach.
• Backups and spreadsheets that AMD was still preparing on the device are deleted. Those you already saved to Files, iCloud Drive, or elsewhere are not: they are outside AMD's reach, and if they contain your patients' data, they remain in your custody.
• The content of the copies of issued certificates is deleted (patient details, your details, and your signature).
• Informed consents are neither deleted nor anonymized: they keep the text, the names, the national IDs, and the signatures. They are part of the medical record (Law 26.529, arts. 16 and 18) and their value as evidence depends on their remaining intact, unlike the copies of certificates, which can be issued again. They stay in your iCloud, in your custody, for the legal retention period. The account deletion screen warns you before you confirm.
• Device preferences are cleaned up: pending reminders, calendar preference, and the biometric lock preference stored in the keychain. Sign in with your Apple Account is turned off and its identifier is deleted from the device keychain. The record the system keeps of Siri & Shortcuts actions is also removed.
• Pending patient intake submissions and invitations are not deleted on the spot, because the server does not know which AMD account they belong to. They are deleted automatically within the periods in §16. The server keeps your public signing key, opaque technical identifiers, and the version and date on which you accepted the addendum: they contain no personal data, but they are linked to one another and to your signing key. AMD does, however, delete the intake keys and your addendum acceptance from your iCloud Keychain. Your other devices receive the deletion when they sync with iCloud.
• If you sent “Next appointment” passes, AMD asks the server to remove them before deleting your keys: they change to “Pass no longer in use” in your patients' Wallet, with a note on the back saying you stopped using them, stop updating and are deleted from the server after 7 days. If there is no connection at that moment, the deletion goes ahead anyway, and the server removes them on its own once your key has not connected for 45 days; they are deleted 7 days later.
• The clinical records — sessions and their notes, diagnoses, anthropometrics, hospitalizations, prior treatments, scales, and payments — and the audit log are retained, without the identifying data in the fields listed above. This is what clinical record preservation requires. Notes, free text, and attachments are kept as you wrote or saved them, so they may contain data that identifies a person; they remain in your custody for the legal retention period.

13. Your rights

As the subject of your personal data, Law 25.326 grants you rights of access, rectification, updating, and erasure. How to exercise them depends on whose data is involved:

• Your data as an AMD user. It is on your device: you can view, correct, or delete it from within the app, with no intermediary and no waiting period. If you need something the app does not let you do, write to soporte.amd@jia.ar. We answer access requests within 10 calendar days and rectification or erasure requests within 5 business days, per Articles 14 and 16 of Law 25.326. Note that, since your clinical record is not on developer servers, the developer cannot access your records or recover them on your behalf: what we can do is guide you and answer for what is genuinely under our control.
• A patient's data. The request must be directed to the professional who keeps their clinical record, who is its controller. The developer has no access and cannot intervene. If you are that professional, AMD gives you the tools to respond: export the record as a PDF, correct any field, and deactivate the patient. The same applies to what a patient sent through patient intake by link: they exercise their rights with their professional. As a data processor, the developer helps the professional with whatever depends on the service, but cannot read the content of submissions.

The supervisory authority in Argentina is the Agencia de Acceso a la Información Pública (AAIP), with which you may file a complaint if you believe your rights have not been addressed.

14. Patients who are minors

AMD is a professional tool: patients are not users of the app. The only way they interact with AMD is the patient intake form, if you use it.

The app can record patients who are minors and flags that status with an indicator on their card so you keep it in view. In the patient intake form, a teenager aged 13 or over can fill in their own details. If the patient is younger, an adult in charge fills it in and states their name and relationship to the patient. For informed consent, AMD suggests who signs based on age: from age 13, the patient themselves for non-invasive treatments (Civil and Commercial Code, art. 26); below that, a representative, with room to note the child's opinion. If the date of birth is incomplete, you choose. You can always pick another option, for example signatures from both the teenager and the adult when there is serious risk. AMD does not verify legal representation: confirming who may sign and documenting it remains your professional responsibility.

The app is not directed at minors as users and is not distributed to that audience.

15. International transfers

The developer transfers data to no country. The only service in which he receives data, patient intake by link, is hosted in Argentina, in DonWeb's data centers, where DonWeb also keeps the backups. The service will not move outside the country without giving you 30 days' notice. If the new destination does not offer an adequate level of protection, the move will only happen after the model clauses of Disposition 60-E/2016 have been signed with the provider.

If you enable sync, your data is stored in Apple's iCloud infrastructure, which may be located outside Argentina. That relationship is between you and Apple, under your account and Apple's privacy policy. If you would rather avoid it, you can use AMD without sync, keeping data on the device only.

The same applies to whichever channel you choose to contact a patient: email, SMS, and WhatsApp operate under their own terms and infrastructure.

The same applies to the destinations you choose when sharing a Library handout.

The same applies to Weather, if you enable it: the query is served by Apple on its own infrastructure, which may be located outside Argentina, under Apple's terms and privacy policy.

The same applies to checking your Apple Account, if you enable that sign-in, and to downloading the speech model for dictation: Apple serves both on its own infrastructure.

The same applies to Siri, if you use it: Apple processes the voice request on its own infrastructure.

The same applies to the patient intake keys: iCloud Keychain syncs them on Apple's infrastructure, under your account.

The same applies to “Next appointment” pass notices: the server sends them to your patient's device through Apple's notification service, which may be located outside Argentina. The notice only carries the device's notification address, with no appointment or patient data.

16. Patient intake by link

What it is. An optional feature, off by default. From AMD you generate a single-use link, valid for 48 hours, and send it to your patient through whatever channel you prefer. Your patient opens a form at ingreso.jia.ar in their browser and enters their intake details. You review them and add them to AMD as a card. To turn the feature on, you have to accept the data processing addendum in the app.

What data is received. First name, last name, and phone, which are required. If your patient chooses, also email, ID document, date of birth, insurer or health plan with member number and plan, address, gender, marital status, education level, nationality, country of residence, occupation, and a photo. If someone else fills in the form for the patient, that person's name and relationship to the patient are also received. If that person is an adult filling it in for the patient, AMD suggests them as the emergency contact, with the phone number from the form; you confirm, change, or discard it before creating the record. No clinical data is requested.

Who is who. You are the data controller for your patients' database. The developer acts as a data processor on your behalf (Article 25, Law 25.326). DonWeb (Dattatec.com S.R.L.) hosts the service and its backups in Argentina, as a sub-processor.

How the data is protected. Your patient's browser encrypts the data before sending it, with your public key, which travels inside the link. Only your private encryption key, stored in your iCloud Keychain, can decrypt it. The server stores ciphertext: neither the developer nor DonWeb can read its content. The service keeps no logs of its own for connections, except a fingerprint of the IP address, never the address itself, which it uses to limit attempts and deletes after 2 hours. The hosting provider keeps its technical logs (IP address and time) for up to one month (§6). The form uses no analytics, third-party cookies, or trackers.

How long it is kept. Each submission is deleted from the server in whichever of these cases comes first:

• when you add it to AMD, that is, when the app detects that iCloud completed a sync after the patient was added;
• when you discard it;
• 30 days after it was sent.

If you do not use iCloud, the 30-day limit applies. Unfinished invitations are deleted 30 days after they expire, and records of closed invitations after 7 days. Deleted data may remain for up to 7 more days in the provider's weekly backup, which is overwritten automatically by the next one. Wallet appointment passes are not stored on the server: they are built and deleted within the same request. “Next appointment” passes are kept while in use and deleted at the first of these: when they are no longer in the Wallet of any of your patient's devices, counting from 7 days after they were sent so your patient has time to add them; 7 days after you remove them; 90 days after the last appointment ends, or after being left with no appointment scheduled; or 7 days after the server removes them because your key has not connected for 45 days (§12). A device's fingerprint and notification address are deleted once that device has no passes left. Deleted data may remain for up to 7 more days in the provider's weekly backup. Unanswered remote consents are deleted 24 hours after they expire. Answered ones are deleted when AMD downloads them or after 30 days at most. In both cases they may remain for up to 7 more days in the provider's weekly backup. Once added to AMD, the data lives on your device and in your iCloud, like the rest of AMD.

Your card. So your patient knows who will receive their details, your name, title, license number, contact email and, if you added it, your address travel unencrypted with each invitation. They are stored on the server until the invitation closes. For those details, the developer is the data controller (§2).

What your patient reads. Before sending, the form shows them a notice with your name, title, license number, contact email and, if you added it, your address. The notice also says which details are required, who else is involved, how long the data is kept, and what their rights are. To send it, your patient has to tick a box giving their express consent.

Your obligations as controller. You must register your patients' database with the AAIP's National Registry of Personal Databases and answer your patients' access, rectification, and erasure requests. AMD reminds you of this when you turn the feature on.

Questions about the service: soporte.amd@jia.ar.

17. Changes to this policy

This policy is versioned and dated in the header. When we update it, we change the version and the last-updated date. If a change materially affects data processing, it will be communicated inside the app.

The policy is also available inside AMD, under Settings → Privacy. Should the two ever differ, the version published on this page prevails. The app's conditions of use are in the terms of use.

Version history

• 2.12 — October 27, 2026. Described the Apple Wallet “Next appointment” pass, which AMD keeps up to date: what the server stores and for how long (§6 and §16), notices through Apple's notification service (§15) and its removal on account deletion (§12).
• 2.11 — October 26, 2026. Added to intake-by-link security (§16) the IP fingerprint the server uses to limit attempts, as in §6.
• 2.10 — October 26, 2026. Clarified that the remote consent text may include health data, how it is encrypted, what technical logs opening the link leaves, and how long it is kept (§6 and §9), and the IP fingerprint the server uses to limit attempts (§6).
• 2.9 — October 26, 2026. Described the backup and the spreadsheet, with and without a password: their contents, encryption, where they go, and importing (§1, §4, §9, §10, §11, and §12).
• 2.8 — October 26, 2026. For patient intake by link (§16), deleted data may remain for up to 7 more days in the provider's weekly backup. On account deletion (§12), AMD deletes the intake keys and the addendum acceptance from iCloud Keychain. Clarified in §6 the connections to the intake server. Described informed consent: its data (§3), the PDF copy (§9), that it is not deleted with the account (§12), and who signs based on age (§14). Described the Apple Wallet appointment pass (§6 and §16) and remote consent (§6, §9, and §16). Clarified what is kept after account deletion (§12): notes, free text, and attachments remain as written. Clarified what the intake server stores and the suggested emergency contact (§6, §9, and §16), reminder authorization and PDF expiry (§4 and §9), and Library technical data (§3). Described the lock period you choose in Settings, on iPhone, iPad, and Mac (§10).
• 2.7 — October 16, 2026. Described optional patient intake by link, available from AMD 1.2 (§16). For that feature, the developer becomes a data processor (§2), with its server in Argentina (§6 and §15), its encryption and its keys in iCloud Keychain (§10), its deletion periods (§12), and the patient form, including for minors (§14). Clarified §1, §3, §5, §9, §11, and §13. "Changes to this policy" is now §17 and "Contact" is now §18.
• 2.6 — October 15, 2026. Added ArgentinaDatos’ published facts about full IP addresses, metadata and retention: access logs until rotation with no published maximum; hourly statistics 30 days and daily statistics 395 days. Knowledge limits for intermediaries and Argentina.gob.ar remain explicit.
• 2.5 — October 12, 2026. Described CPI and public-holiday queries from version 48, their data and connection metadata, and the limits of known retention information (§1 and §6); narrowed the general network statements and corrected the footer version.
• 2.4 — September 30, 2026. Described the copies of issued certificates (§3, §9, and §12), the care and work leave certificates (§9), Siri & Shortcuts and the ICD-11 lookup (§3, §8, §10, §12, and §15), clarified the content and flow of the clinical record PDF (§9), and linked the terms of use (header and §17).
• 2.3 — September 29, 2026. Added the Library of psychoeducational handouts: its history in §3 and §5, the temporary copies in §4, the "Sharing a Library handout" subsection in §9, its relationship to the audit log in §11, and its deletion in §12, with the corresponding clarifications in §1 and §15. Added note dictation (§6, §7, and §8) and sign-in with your Apple Account (§1, §6, §10, §12, and §15), updated the keychain description (§10), and corrected the statement on attachments: their files do sync (§4 and §12).
• 2.2 — September 17, 2026. Added the Weather feature: the location permission in §8, the "Weather and Apple Weather" subsection, and the corresponding clarifications in §1, §3, §6, and §15.
• 2.1 — September 4, 2026. Clarifications on the scope of encryption (§1), the statutory retention period for the clinical record (§12), and the name of the exported PDF (§9).
• 2.0 — September 1, 2026. Initial version of this policy.

18. Contact

For privacy questions or requests about your personal data — access, rectification, updating, or erasure — write to soporte.amd@jia.ar.

Controller: Juan Ignacio Antolini — Ciudad Autónoma de Buenos Aires, Argentina.