Where is Patient Data Stored with Clinical AI?
A data-residency and compliance briefing for hospital IT teams, compliance officers, clinical leaders and CIOs evaluating clinical AI.
Figure 1. Processing happens inside the hospital's own infrastructure. Only the final cited answer returns to the doctor's screen.
The sections below answer the data-residency question first, then set out the deployment options, the connection method and the compliance position behind each one.
The Product
What is MediQuery?
MediQuery is a medical query system built by Yobitel. It answers a doctor's question at the point of care in under 2 seconds, with a citation against every clinical statement. Instead of searching through multiple screens manually, doctors ask and get one consolidated answer pulled from the most relevant sources available.
How does it work?
MediQuery builds each answer live by connecting simultaneously to multiple data sources to build each answer.
Every answer is assembled live from these sources, which means doctors always receive the most current and accurate information available at the time of the query. Nothing is pre-loaded, and nothing is carried over from an earlier query.
What do doctors use it for?
MediQuery handles three core clinical tasks that doctors rely on daily:
Drug interaction checks
Retrieves interaction data from the drug databases, with the source shown, so the doctor can check it before prescribing.
Treatment protocol lookups
Retrieves evidence-backed clinical guidelines on demand for any condition.
Patient record search
Allows doctors to query EHR data using plain, conversational language.
For example, a doctor types:
"Show me this patient's kidney function results from the last 6 months."
Figure 2. All data pulled from live EHR. No data stored. No data sent outside hospital infrastructure.
The Problem
Why Are Doctors Concerned About Where Patient Data Goes?
Doctors are concerned about where patient data goes because most AI tools send patient records to external servers to process the query. Hospitals cannot allow that under HIPAA and other compliance rules.
Here is what published research shows about physician workload, AI adoption, and data privacy in healthcare:
Figure 3. Physician EHR burden and AI privacy sentiment, drawn from peer-reviewed studies and the American Medical Association's 2026 physician survey.
How much time do doctors spend inside the EHR?
- Doctors spend 5.8 hours inside the EHR for every 8 hours of scheduled patient care[1]
- Doctors spend an average of 16 minutes and 14 seconds on the EHR per patient visit, longer than the appointment itself[2]
- Chart review alone takes up 33% of that EHR time, more than documentation (24%) or ordering (17%)[2]
- During pre-rounds, a doctor navigates an average of 6 different EHR screens per patient just to review one chart[3]
These figures come from peer-reviewed studies covering more than 200,000 physicians and roughly 100 million patient encounters.
Labs, medications, and clinical notes each sit on a different screen. A doctor switches between all of them to complete one task. AI tools help solve this problem, but only when the hospital knows exactly where patient data goes.
What research shows about AI adoption and privacy concerns?
- 81% of physicians now use AI professionally, more than double the 38% recorded in 2023[4]
- The most common use is medical research summarisation, used by 39% of physicians[4]
- 86% of physicians say data privacy assurance is important in deciding whether to adopt an AI tool[4]
- Of all the areas the survey measured, patient privacy is the only one where more physicians expect AI to do more harm than good[4]
All the above facts come from the American Medical Association's 2026 survey of 1,692 physicians.
Adoption and privacy concerns occur at the same time. That is not a contradiction. Doctors want the tool, and hospitals need to know where the patient data goes before they deploy any AI tool.
Most hospitals cannot allow patient data to travel to external AI servers under their compliance rules. So every hospital's IT team, compliance officer, and clinical administrator asks the same question, "Where does our patient data actually go?" before deploying any AI tool.
MediQuery is built to give a clear answer to this question.
The Answer
Does MediQuery Store Patient Data Outside the Hospital?
When a doctor submits a query, MediQuery reads the patient record from the live EHR, processes the query inside the deployment environment the hospital chose, returns the answer to the doctor's screen, and deletes the retrieved data immediately after. On on-premise and private cloud deployments, nothing leaves the infrastructure the hospital owns. On Yobibyte GPU Cloud, the data sits in a dedicated environment covered by a signed BAA, and no copy is kept after the answer is returned.
What MediQuery does not do
Deployment Options
Where Can the Hospital Choose to Keep Patient Data?
Patient data lives in any of three environments that the hospital chooses. In all 3, the hospital sets the access rules and holds the audit trail. In the first 2, the data never leaves the infrastructure that the hospital owns. In the 3rd, Yobitel runs the infrastructure as a Business Associate under a signed agreement, and the hospital holds control of data.
| On-premise | Private cloud / VPC | Yobibyte GPU Cloud | |
|---|---|---|---|
| Where data lives | Hospital data centre | Hospital's own AWS, Azure or GCP account | Yobitel's GPU cloud, under a signed BAA |
| Who holds encryption keys | Hospital IT | Hospital IT, via their own KMS | Hospital, via their own KMS |
| Who sets access rules | Hospital | Hospital | Hospital |
| Yobitel's role | Supplies and updates the software | Deploys and updates inside the hospital's account | Runs the infrastructure |
| Outside connections | None with an air gap | None outside the hospital's account | The hospital's chosen cloud region |
| Setup | Hospital IT timeline | Hospital IT timeline | Under 5 minutes |
Scroll the table sideways to compare all three deployments.
The air-gapped option removes every external internet connection, so nothing enters or leaves the building. This suits hospitals under the strictest data regulations, and those operating under FDA 21 CFR Part 11.
Whichever option the hospital picks, one row does not change: the hospital sets the access rules.
The Guarantee
Zero PHI Exposure Guarantee
Figure 4. Other solutions move identity, diagnoses, lab results and medications outside the hospital. MediQuery keeps them inside it.
PHI stands for Protected Health Information. It covers every piece of data that identifies a patient, including name, date of birth, diagnosis, lab results, and medications.
When a doctor types patient data into a general AI tool, that data leaves the hospital network immediately, which puts the hospital at risk of breaching data protection laws in every major jurisdiction:
| United States | Penalties for HIPAA violations are up to $2,190,294 for the most serious categories. A lesser violation carries a smaller penalty, around $36,500. |
| European Union | GDPR violation, fines up to 20 million EUR or 4% of global annual turnover |
| India | Digital Personal Data Protection Act 2023 violation |
| United Kingdom | Data Protection Act 2018 violation |
| Australia | Privacy Act 1988 violation |
| Canada | PIPEDA violation |
| Middle East | National health data regulation violations across GCC member states |
| Singapore | Personal Data Protection Act violation |
| South Africa | Protection of Personal Information Act violation |
What does the Zero PHI exposure guarantee cover?
Integration
How Does MediQuery Connect to and Read Patient Records?
MediQuery reads patient records directly from the hospital's live EHR every time a doctor asks a question. It pulls only the data that the question needs, builds the answer, and removes that data immediately.
Hospitals across the US, UK, Europe, the Middle East, Asia, Africa, Australia, and Latin America run different EHR systems. MediQuery connects to all of them without asking the hospital to change its existing setup.
Which EHR standards does MediQuery connect to?
Figure 5. Three connection routes cover modern, legacy and non-standard clinical systems.
Which standard applies depends on the age of the hospital's system. MediQuery supports both, and the hospital does not need to change anything to use either.
FHIR R4, for modern EHR systems. FHIR R4 is the current international standard for healthcare data exchange. Health authorities across the US, UK, Australia, Canada, Germany, Saudi Arabia, Singapore, India, and the European Union mandate or actively adopt FHIR R4 for national health data exchange. MediQuery connects to FHIR R4 systems through a standard REST API. The hospital's IT team does not need to build anything new to connect MediQuery to its existing FHIR R4 system.
HL7v2, for legacy EHR systems. HL7v2 is a clinical messaging format that hospitals worldwide rely on today. Many hospitals across Asia, Africa, Latin America, Eastern Europe, and the Middle East still run on HL7v2. MediQuery connects directly to these systems as they are, without asking the hospital to upgrade or replace anything. For hospitals running systems that support neither FHIR R4 nor HL7v2, MediQuery provides custom REST API integrations.
EHR platforms MediQuery connects to
MediQuery integrates with 30+ clinical systems across North America, Europe, Asia Pacific, the Middle East, Africa, and Latin America. Key platforms include:
| Epic | US, Canada, Middle East, Europe, Australia |
| Oracle Health / Cerner | Global |
| MEDITECH | US, Canada, UK, Middle East |
| Veradigm | US |
| athenahealth | US |
| Altera Sunrise | US, UK, Europe, Canada, Australia, Asia Pacific |
| Any standards-based system | Any system with FHIR R4, HL7v2, or REST API support |
How many knowledge sources does MediQuery search?
Once MediQuery reads the patient data, it cross-references it against 8+ globally trusted medical knowledge sources. It does not check one source at a time. It searches them in parallel and returns one consolidated answer. These are the same sources clinical teams already rely on, from London to Riyadh to São Paulo.
| Clinical guidelines | UpToDate, ClinicalKey, DynaMed, BMJ Best Practice, Cochrane Library |
| Drug databases | FDA Drug Safety, DrugBank, RxNorm, First Databank, Lexicomp |
| Medical literature | PubMed/MEDLINE, ClinicalTrials.gov, Cochrane Reviews, Embase, Google Scholar |
| Hospital-specific sources | Institutional protocols and local formularies |
Data Handling
What Types of Clinical Data Does MediQuery Use?
MediQuery uses 2 distinct types of data to build each answer: live patient data from the hospital EHR, and medical knowledge from external clinical reference sources. These 2 data types never mix, and patient data never touches the external sources.
Live patient data from the hospital EHR
MediQuery reads this data fresh from the EHR each time a doctor asks a question: active medications, current and past lab values, vital signs, allergy list, clinical notes, past diagnoses and the full encounter history.
Medical knowledge from external clinical sources
MediQuery treats these sources as read-only reference material: clinical guidelines, drug interaction data, published medical research and hospital-specific protocols.
MediQuery takes the live patient data from the EHR and cross-references it against the external clinical sources at the same time. It maps each part of the answer to a specific source. The doctor receives one answer with a citation against every clinical statement in it.
No patient data enters the external clinical sources. The knowledge lookup and the patient record never meet outside the deployment. Only the final cited answer goes back to the doctor's screen, sourced and ready to act on.
How MediQuery builds one answer
MediQuery checks the patient's active medications, allergies, lab values, and drug reactions against every knowledge source at the same time. Every point in the answer carries a citation that the doctor can open and verify immediately. This entire process runs inside the hospital's own deployment environment, whether that hospital operates in New York, London, Dubai, Singapore, Nairobi, or São Paulo.
Responsibility
Who Controls Patient Data Security in MediQuery?
The hospital controls patient data security in every deployment. On on-premise and private cloud deployments, Yobitel never holds or accesses patient data at all. On Yobibyte GPU Cloud, Yobitel runs the infrastructure under a HIPAA Business Associate Agreement, and the hospital keeps the encryption keys, the access roles, and the audit logs.
Who controls what?
Each party holds a clear and separate line of responsibility:
Hospital IT team
Controls the network and hardware.
Hospital compliance team
Sets the access rules.
Hospital security team
Holds the encryption keys.
Yobitel
Maintains the AI layer alone.
On on-premise and private cloud deployments, patient data never crosses into Yobitel's side of that line.
| Yobitel manages | The hospital's team manages |
|---|---|
| Building and updating the MediQuery AI application | Setting network isolation rules and firewall configurations |
| Managing Yobibyte GPU Cloud infrastructure for managed deployments | Holding all encryption keys through the hospital's own KMS |
| Providing FHIR R4 and HL7v2 integration with 30+ clinical systems globally | Assigning access roles to every clinical user |
| Supplying HIPAA BAA, GDPR and DPDP compliance documentation, SOC 2 Type II audit reports, and FDA 21 CFR Part 11 system validation documentation | Reviewing audit logs and enforcing data retention timelines under local and national regulations |
| Handling auto-scaling, system monitoring, and AI maintenance | Making all data residency decisions in line with national data sovereignty laws, and deciding who accesses patient data inside MediQuery and when |
Yobitel runs the software. The hospital runs the data.
MediQuery supports 5 access roles, including Physician, Nurse, Pharmacist, Researcher, and Administrator. Each role's permissions are set at the department level. It connects to the hospital's existing login system through SSO, so clinical staff use the credentials they already have. No new passwords, and no extra steps in the clinical workflow.
Compliance
What Compliance Standards Does MediQuery Meet?
Figure 6. Four global standards, each carrying a distinct legal obligation for the hospital.
MediQuery is built to support the compliance requirements hospital teams face in the US, Europe, and India. Each of the four standards below carries a real legal obligation, and this section sets out what MediQuery does against each one.
HIPAA covers US hospitals. SOC 2 Type II is an independent security audit. GDPR and DPDP cover Europe and India. FDA 21 CFR Part 11 applies to hospitals running regulated clinical work. Skip to the one that applies to you.
A. HIPAA compliant
HIPAA stands for the Health Insurance Portability and Accountability Act. It is the primary US federal law that governs how hospitals and healthcare organisations handle patient data. Any AI system that reads, processes, or stores patient data inside a US hospital must meet HIPAA requirements.
MediQuery meets major HIPAA requirements:
| Encryption | All patient data uses AES-256 encryption at rest. This means patient data sitting inside the hospital's storage system stays fully encrypted at all times. All patient data uses TLS 1.3 encryption in transit. This means patient data moving between MediQuery and the hospital EHR stays fully encrypted during transfer. No unencrypted patient data exists anywhere inside the MediQuery environment. |
| Audit logs | Every time a clinical user accesses patient data inside MediQuery, the system creates a log entry. That log entry records who accessed the data, what data they accessed, and exactly when they accessed it. HIPAA requires hospitals to retain these logs for 6 years. MediQuery goes beyond this requirement and stores audit logs for 7 years, enforced automatically. |
| Access controls | MediQuery assigns each clinical user a role. Each role receives only the access level it needs. A pharmacist's role accesses medication data. A physician's role accesses full clinical records. No user accesses data outside their assigned role. This role-based access system directly meets HIPAA's minimum necessary access requirement. |
| HIPAA BAA | A Business Associate Agreement is a legal contract between the hospital and any vendor that handles patient data on the hospital's behalf. MediQuery provides a HIPAA BAA for all managed cloud deployments on Yobibyte GPU Cloud. This agreement defines exactly how MediQuery handles patient data and what obligations Yobitel carries under HIPAA. |
B. SOC 2 Type II independent audit
SOC 2 Type II stands for System and Organisation Controls 2, Type II. It is an independent security audit standard created by the American Institute of Certified Public Accountants. SOC 2 Type II is not a self-declared certificate. An independent third-party auditing firm conducts the review and issues the report.
MediQuery completes a SOC 2 Type II audit every year. Each audit covers 4 areas:
Access controls
The auditor reviews who has access to the MediQuery system, how that access gets granted, and how the system removes access when a user leaves or changes roles.
Change management
The auditor reviews how MediQuery handles software updates, patches, and system changes. Every change follows a documented approval and testing process before deployment.
System availability
The auditor reviews MediQuery's uptime records, incident history, and recovery procedures. This confirms that MediQuery operates reliably and meets the availability commitments the hospital depends on.
Incident response
The auditor reviews how Yobitel detects, reports, and resolves security incidents. The hospital gets a documented incident response procedure, not a verbal assurance.
When a hospital receives MediQuery's SOC 2 Type II report, it receives a verified, independently audited record of how the system operates. No self-declaration. No marketing claim. A third-party auditor signs the report.
C. GDPR and India's DPDP Act
GDPR stands for General Data Protection Regulation. It is the primary data protection law across all European Union member states. DPDP stands for Digital Personal Data Protection Act. It is India's national data protection law. Both laws give patients legal rights over their personal health data and place strict obligations on any organisation that processes that data.
MediQuery supports 5 features that directly address GDPR and DPDP requirements:
| Data residency controls | The hospital chooses which geographic region stores patient data. A hospital in Germany keeps patient data inside AWS Frankfurt. A hospital in India keeps patient data inside AWS Mumbai. Patient data never moves outside the selected region without the hospital's explicit action. Both GDPR and DPDP require this level of geographic control. |
| Right to delete patient data | Both GDPR and DPDP give patients the legal right to request deletion of their personal data. MediQuery supports this requirement. When the hospital receives a deletion request, the compliance team can action it directly inside MediQuery without requiring Yobitel's involvement. |
| Consent management | MediQuery supports consent records for patient data use. The hospital's compliance team manages consent documentation inside the system and produces it for regulatory review when required. |
| Data minimisation | MediQuery reads only the patient data it needs to answer each specific query. It does not pull entire patient records when a query requires only lab results. This selective data reading directly meets the data minimisation principles that both GDPR and DPDP require. |
| DPO appointment records | Both GDPR and DPDP require hospitals to appoint a Data Protection Officer and maintain records of that appointment. MediQuery supports DPO documentation management inside the compliance administration panel. |
D. FDA 21 CFR Part 11 for regulated clinical work
FDA 21 CFR Part 11 is a US Food and Drug Administration regulation that governs electronic records and electronic signatures in regulated clinical environments. Hospitals running clinical trials, drug research programmes, or regulated diagnostic workflows must meet these requirements. Any electronic system that creates, modifies, or stores records in these environments must comply with 21 CFR Part 11.
MediQuery supports 4 requirements that 21 CFR Part 11 mandates:
| Electronic signatures | MediQuery supports legally valid electronic signatures for clinical records and approvals. Each signature links to a specific user identity and carries a timestamp. The system does not allow shared signatures or unsigned approvals in regulated workflows. |
| Complete audit trails | Every action a user takes inside MediQuery in a regulated environment creates an audit trail entry. The audit trail records the original entry, every modification, and the identity of the user who made each change. Audit trail entries cannot be deleted or altered. |
| Data integrity controls | MediQuery applies data integrity checks that confirm patient records and clinical answers remain unaltered from the point of creation. Any unauthorised modification triggers an automatic alert to the hospital's compliance team. |
| System validation documents | FDA 21 CFR Part 11 requires hospitals to validate every electronic system they use in regulated workflows. MediQuery provides complete system validation documentation that the hospital's compliance team submits to regulators when required. This documentation covers installation qualification, operational qualification, and performance qualification records. |
In Summary
Deploy MediQuery in Your Hospital
MediQuery demonstrates that clinical AI adoption and patient data compliance can coexist. Doctors gain speed and precision while the hospital retains control of its data, infrastructure, and audit trail. It's the architecture shift the healthcare industry needs.
Clinical teams get fast, cited answers. IT and compliance keep full control of patient data. Neither has to give something up for the other to work. Deploy MediQuery on Yobibyte GPU Cloud, through the AWS Marketplace, or inside the hospital's own data centre.
Frequently Asked Questions About Patient Data in MediQuery
Does MediQuery copy the full patient database during setup?
No. MediQuery connects to the live EHR and reads only the records it needs for each query. No bulk copy of the patient database takes place at any point.
Can MediQuery work in a hospital with no internet connection?
Yes. The on-premise deployment with air-gapped configuration runs entirely inside the hospital data centre with zero external network connections.
Does MediQuery store patient data on Yobitel's servers?
No. MediQuery does not store patient records at all. It reads what a query needs and discards it once the answer is returned. On on-premise and private cloud deployments, the data never touches Yobitel infrastructure. On Yobibyte GPU Cloud, processing happens in a dedicated environment under a signed BAA, with nothing retained afterwards.
Does MediQuery train on our patient data?
No. Patient data is used to answer the query in front of it and nothing else. It is not used to train, fine-tune, or improve any model, and it is not pooled with data from other hospitals.
Does MediQuery send patient data to external AI models like ChatGPT?
No. MediQuery runs its AI model inside the hospital's infrastructure. No patient data goes to any external AI model at any point.
Which EHR systems connect to MediQuery?
Epic, Oracle Health/Cerner, MEDITECH, Veradigm, athenahealth, Altera Sunrise, and any system with FHIR R4, HL7v2, or REST API support. MediQuery connects to 30+ clinical systems.
Who sets user access permissions inside MediQuery?
The hospital's admin team sets all access permissions. Available roles are Physician, Nurse, Pharmacist, Researcher, and Admin. Every access event creates an audit log entry.
Does MediQuery work with medical imaging?
Yes. Retrieves and displays imaging studies and associated reports through DICOM integration with PACS systems, OHIF Viewer, and Orthanc.
How many languages does MediQuery support for patient materials?
MediQuery creates patient education materials, discharge summaries, and care plan notes in 20+ languages, adjusted to each patient's reading level.
How fast does MediQuery give a clinical answer?
Under 2 seconds. Every answer includes inline source citations and a confidence score.
How long does MediQuery take to deploy?
Managed deployment on Yobibyte GPU Cloud takes under 5 minutes. On-premise and VPC deployments follow the hospital's security review and IT setup timeline.
Research References
- Sinsky CA, Rotenstein L, Holmgren AJ, Apathy NC. National Comparison of Ambulatory Physician Electronic Health Record Use Across Specialities. Journal of General Internal Medicine, 2024. Study of 200,000+ ambulatory physicians. https://pmc.ncbi.nlm.nih.gov/articles/PMC11534958/
- Overhage JM, McCallie D Jr. Physician Time Spent Using the Electronic Health Record During Outpatient Encounters: A Descriptive Study. Annals of Internal Medicine, 2020;172(3):169-174. https://pubmed.ncbi.nlm.nih.gov/31931523/
- Coleman C, Gotz D, Eaker S, et al. Analysing EHR navigation patterns and digital workflows among physicians during ICU pre-rounds. Health Information Management Journal, 2021. https://journals.sagepub.com/doi/full/10.1177/1833358320920589
- American Medical Association, Centre for Digital Health and AI. 2026 Physician Survey on Augmented Intelligence. March 2026. Research report based on 1,692 physicians. https://www.ama-assn.org/system/files/physician-ai-sentiment-report.pdf