How Do Doctors Find Critical Patient Information Across EHRs?
A practical white paper for doctors, clinical leaders, health information teams and hospital decision-makers.
Doctors often know that the information they need already exists, but finding it can require several searches. Hospitals store diagnoses, medicines, laboratory results, scan reports, discharge summaries and referral documents in different parts of the EHR, departmental systems and uploaded files.
Mediquery gives authorised healthcare professionals one patient-specific place to search that information. The clinician selects the patient, asks a direct clinical question, reviews a concise answer and opens the report or record that supports it.
Figure 1. Mediquery connects patient information, the clinical question, the relevant answer and the supporting source.
The sections below explain the clinical problem first, then show how Mediquery solves it. Application steps and screenshots appear beside the capability they demonstrate, so the article also works as a practical user guide.
The Problem
Why Is Patient Information Hard to Find in EHRs?
Patient information is hard to find in EHRs because hospital records are split across the main EHR, departmental systems, uploaded PDFs, scanned files and external referrals, and no single screen brings them together for the doctor in front of the patient.
Hospital EHRs separate the patient story into different modules.
Medication history, laboratory results, radiology reports, consultation notes and discharge records often appear in different areas. External providers also send PDFs, scanned reports and referral letters outside the structured EHR, so one screen rarely shows the complete history.
EHR navigation starts with a location instead of the clinical question.
A doctor asks what changed, whether the problem happened before or which report supports a finding. The EHR usually requires the doctor to choose a module, date, encounter or document type before reaching the answer.
Long patient histories require manual timeline reconstruction.
The clinician opens several records, compares dates, decides which information is current and returns to the original source before acting. Research on EHR usability and information overload describes the same retrieval burden.[7][8]
Missing reports create a clinical information gap.
The absence of a scan report does not mean that the scan was normal. Clinicians need the application to identify the missing source so they can request it from the correct department, branch or provider.
These four barriers slow clinical review even when the hospital already holds the required information. Mediquery closes this retrieval gap while keeping the hospital's core EHR in place. It gives clinicians a direct route from the selected patient and their clinical question through to the supporting source.
The absence of a scan report does not mean that the scan was normal.
The Approach
How Does Mediquery Work?
Mediquery works in four steps that follow a doctor's clinical review: start with the patient, ask the clinical question, search the connected records and uploaded documents together, and verify the answer against the source.
Start with the patient, not the storage location.
The clinician selects the patient before choosing any system, department or file type. Mediquery keeps connected records and uploaded documents within that patient context.
Ask the clinical question in normal language.
Doctors ask about diagnoses, medicine changes, laboratory results, scan findings, previous symptoms, follow-up instructions or missing reports.
Search connected records and documents together.
Mediquery searches the authorised information that the hospital connects or uploads instead of limiting the review to one EHR screen.
Verify the answer against the source.
Mediquery returns a focused answer and keeps the supporting report or record available so the clinician can confirm the date, wording and patient context.
The diagram below shows the same flow as a continuous review cycle.
Figure 2. Mediquery connects the clinical question, patient-record search, concise answer and source review in one continuous cycle.
The Difference
How Does Mediquery Speed Up Patient Record Review?
Mediquery keeps the EHR as the system of record and improves the review path. The doctor starts with the patient and the clinical question, reaches the relevant information sooner and verifies it against the original source.
Figure 3. A patient-specific search shortens the path from the clinical question to the supporting source.
| Review Stage | Traditional Record Review | Mediquery-Supported Review |
|---|---|---|
| Starting point | Choose a system, screen or document type. | Choose the patient and ask the clinical question. |
| Record search | Open notes, reports, attachments and department systems separately. | Search connected records and uploaded documents together. |
| Result review | Compare several files and dates before finding the relevant detail. | Receive a concise answer focused on the question. |
| Source check | Return to the original system and locate the supporting record. | Open the supporting report or record from the answer. |
| Missing information | Absence may remain unclear until several locations are checked. | The answer can state that the requested report was not found. |
Data Coverage
What Patient Information Does Mediquery Review?
Mediquery brings five types of authorised clinical information into one patient view. Each source contributes a different part of the patient history and supports a different type of clinical question.
| Information Source | What It Covers For Clinicians |
|---|---|
| Structured EHR data | Authorised diagnoses, encounters, medication history, allergies, laboratory values and other structured information exposed through approved EHR connections. Doctors use this information to review the patient's current status and changes over time.[1][2] |
| Narrative clinical reports | Radiology reports, pathology reports, discharge summaries, referral letters and specialist notes. These documents often contain the interpretation and context that a structured result alone does not show. |
| Scanned and photographed medical records | Clear scans of printed reports, prescriptions and external letters attached to the correct patient. Mediquery extracts the readable text and includes it in patient-specific search. Source quality remains essential.[2] |
| Historical document archives | Folders of older patient records processed in bulk. Staff review the completed batch and resolve any file Mediquery cannot match to a patient before clinicians rely on the imported history. |
| Authorised departmental and external sources | Approved branch, departmental and external data sources connected by hospital IT teams. Mediquery includes the authorised information in the same patient-review workflow while the original source remains in place. |
Operating Model
How Does Mediquery Support Multi-Branch Hospitals?
Mediquery supports multi-branch hospitals by giving every authorised doctor the same patient-review workflow across sites, even when each branch runs a different EHR. The existing systems stay in place; Mediquery sits on top as one search and review layer. It reviews only the information the hospital connects or uploads for the selected patient, and flags a missing source as unavailable rather than treating absence as a normal finding.
The hospital controls which systems Mediquery connects, which records each user can access and which tasks each role can perform. This model supports cross-department and multi-branch review without giving every user the same permissions.[1][2]
| Role | Main Responsibility | Typical Mediquery Tasks |
|---|---|---|
| Administrator | Controls the workspace, connections and user access. | Hospital registration, user roles, settings, data sources and operational review. |
| Doctor or Clinician | Reviews patient information for care. | Select a patient, ask clinical questions, read answers and verify sources. |
| Authorised Staff | Maintains patient records and documents. | Create patients, upload reports, capture scans and process historical files. |
| Read-Only User | Reviews permitted information without changing records. | Open authorised records and view approved information. |
Use one review method across locations.
Doctors in different branches select the patient, ask the question and verify the source through the same workflow, subject to hospital permissions.
Keep responsibility with the correct team.
Administrators manage the workspace, authorised staff maintain patient records and documents, and clinicians review patient information for care.
Monitor daily operations.
Administrators review failed connections, documents that remain in processing and files that require matching.
Expand in controlled stages.
The hospital starts with one approved department and adds users, sources and branches after clinical and governance teams validate the workflow.
This positioning differs from a full EHR replacement and from an assistant that works only inside one EHR brand.
Application Walkthrough
How to Use Mediquery: Step-by-Step Workflow
The application workflow below follows the operational sequence used by administrators, authorised staff and clinicians. It starts with hospital setup and patient creation, then moves through document intake, data connection, clinical questioning and source verification. The hospital applies its own access, privacy and clinical governance rules throughout the process.
Step 1: Register the Hospital Workspace
The hospital administrator creates the organisation workspace and enters the hospital and primary contact details. Mediquery submits the registration for verification before clinical users enter the workspace.
Figure 4. Hospital workspace registration captures the organisation and administrator details.
Step 2: Sign In and Review the Dashboard
After activation, approved users sign in with their assigned accounts. The dashboard gives administrators a single view of patient, document, query and data-source activity.
Figure 5. The dashboard summarises daily Mediquery activity and system status.
Step 3: Create the Patient Record
Authorised staff create the patient record before they upload documents or submit patient-specific questions. They use a consistent medical record number so connected data and uploaded files remain attached to the correct patient.
Figure 6. Staff create the patient record with a consistent medical record number.
Step 4: Upload a Medical Document
Staff select the patient and document type, then upload a laboratory report, prescription, referral letter or discharge document. After processing, Mediquery includes the file in patient-specific search.
Figure 7. Staff upload a medical document to the selected patient and document type.
Step 5: Capture a Scanned Record
Staff add a clear scan or photographed document, assign it to the correct patient and submit it for text extraction. They should confirm that the source is readable before clinicians use the extracted information.
Figure 8. Staff link a clear scanned or photographed record to the patient.
Step 6: Process Historical Records in Bulk
Staff use Bulk Upload to process groups of older medical documents together. They select the source, add files or a folder, start the batch and review the processing status.
Figure 9. Bulk Upload accepts groups of historical medical documents as one managed batch.
Step 7: Review the Completed Bulk Upload
When processing finishes, staff review file totals, matched records and any items that require correction. They resolve unmatched documents before clinicians rely on the imported record set.
Figure 10. The completed batch shows processing status and file totals.
Step 8: Connect an Approved Data Source
Hospital IT teams add the approved data source, enter the connection details and test access. Administrators then monitor connection status, last synchronisation and operational health.
Figure 11. The Data Sources area shows connection status, last synchronisation and operational health.
Step 9: Ask a Patient-Specific Clinical Question
The clinician opens Query AI, selects the patient and document scope, and enters a direct question about the patient's history, medicines, laboratory results or reports.
Figure 12. The clinician selects the patient, chooses the document scope and enters the clinical question.
Step 10: Review the Answer and Supporting Source
The clinician reads the answer, opens the supporting report or record and confirms the patient, date and original wording. When Mediquery cannot find the requested information, the clinician treats it as a gap and follows the hospital's process for obtaining the missing source.
Figure 13. Mediquery returns a patient-specific answer and keeps the supporting source available for verification.
These operating steps show how Mediquery fits into daily hospital work. The next section compares this focused record-retrieval workflow with EHR-specific assistants and enterprise data platforms.
The clinician selects the patient, asks a direct clinical question, reviews a concise answer and opens the report or record that supports it.
Market Comparison
Mediquery vs Hospital Record-Search Platforms
Mediquery differs from Epic Art, Oracle Health Clinical AI Agent, MEDITECH Ask Expanse and InterSystems HealthShare in one main way: it is designed to work as an additional patient-review layer across every EHR the hospital already runs, rather than as an in-EHR assistant tied to a single vendor or an enterprise data-aggregation platform. The comparison table below focuses on the capabilities that matter when hospitals need patient-specific questions, medical-document intake, cross-EHR review and source verification.
Compare Mediquery with
| Feature | Mediquery | Epic Art |
|---|---|---|
| Main purpose | Patient-record search across every connected EHR and uploaded document. | Cited patient answers inside Epic. |
| Patient-specific questions in plain language | Yes. | Yes, inside Epic. |
| Source-linked answers | Yes. One click to the source report. | Yes. Epic describes concise, cited answers. |
| Direct upload of PDFs, prescriptions, referrals | Yes. | Handled via wider Epic environment. |
| Scanned and historical file handling | Yes. Native scans plus bulk historical upload. | Limited. Bulk historical upload is not a core feature. |
| Works across different EHR brands | Yes. Additional layer across hospital sources. | Primarily Epic customers. |
| Available on AWS Marketplace | Yes. Listed as a deployable application. | No. |
| Best fit | Multi-branch, mixed-EHR, document-heavy hospitals. | Hospitals standardised on Epic. |
View the full five-platform comparison table
| Feature / Criteria | Mediquery | Epic Art | Oracle Health Clinical AI Agent | MEDITECH Ask Expanse | InterSystems HealthShare |
|---|---|---|---|---|---|
| Main purpose | Patient-record search across every connected EHR and uploaded document. | Cited patient answers inside Epic. | Chart search inside Oracle Health. | Chatbot questions inside MEDITECH Expanse. | Unified patient record from many data sources. |
| Patient-specific questions in plain language | Yes. | Yes, inside Epic. | Yes, inside Oracle Health. | Yes, inside Expanse. | Not the primary purpose. |
| Source-linked answers | Yes. One click to the source report. | Yes. Epic describes concise, cited answers. | Cited answers are not the main public message. | Not the main public message. | Not the main public message. |
| Direct upload of PDFs, prescriptions, referrals | Yes. | Handled via wider Epic environment. | Handled via wider Oracle Health environment. | Handled via wider Expanse environment. | Handled via enterprise data feeds. |
| Scanned and historical file handling | Yes. Native scans plus bulk historical upload. | Limited. Bulk historical upload is not a core feature. | Not a core Clinical AI Agent workflow. | Not a core Ask Expanse workflow. | Handled via integration or migration. |
| Works across different EHR brands | Yes. Additional layer across hospital sources. | Primarily Epic customers. | Primarily Oracle Health customers. | Primarily MEDITECH customers. | Yes. Multi-source aggregation is a core strength. |
| Available on AWS Marketplace | Yes. Listed as a deployable application. | No. | No. | No. | No. |
| Best fit | Multi-branch, mixed-EHR, document-heavy hospitals. | Hospitals standardised on Epic. | Hospitals standardised on Oracle Health. | Hospitals standardised on MEDITECH Expanse. | Data-foundation programmes. |
Swipe sideways to see every column.
Table 3. Publicly documented patient-record search and data-review capabilities, reviewed July 2026.
Mediquery does not replace a complete EHR. It addresses the focused problem of finding, reviewing and verifying patient information across EHR data and external medical documents.
Fit Assessment
Is Mediquery Right for Your Hospital?
Mediquery fits hospitals that already hold the required patient data but struggle to retrieve it quickly across current EHR environments and medical files.
- The hospital stores clinically relevant information across EHR modules, departmental systems, attached reports and scanned documents.
- Different branches, acquired hospitals or specialist departments use different clinical platforms.
- Older patient records remain in folders, archives or scanned files that clinicians cannot search easily during current care.
- Doctors need a concise answer and direct access to the report or record that supports it.
- The organisation wants a recognised procurement route through AWS Marketplace.[2]
When these conditions exist together, Mediquery gives the organisation a practical path from fragmented records to a patient-specific, source-linked review workflow.
Deployment
How to Deploy Mediquery Through AWS Marketplace
Mediquery is available on AWS Marketplace, which makes it especially practical for multi-branch hospital groups. A hospital group that already uses AWS can subscribe through its existing cloud contract, deploy Mediquery once in the central AWS environment, and give authorised doctors across every branch access through the same web-based workflow, without a separate installation project at each site.[2]
Use the existing AWS procurement route.
The organisation evaluates and purchases Mediquery through AWS Marketplace, subject to its own procurement, security and legal review.
Deploy one centrally managed environment.
A hospital group provides authorised access across branches instead of installing a separate application at every location.
Grow capacity with adoption.
The organisation expands the deployment as the number of users, patient records, documents and connected sources grows.
Choose a private deployment model when required.
Hospitals with stricter environment requirements can discuss private-cloud, hospital data-centre and isolated deployment options with Yobitel.[1]
Technology deployment alone does not create safe clinical use. The hospital must also control permissions, source verification and clinical responsibility.
Clinical Governance
How Does Mediquery Support Safe Clinical Use?
Mediquery supports clinical information review. It helps doctors find and organise available information, but clinicians retain responsibility for examination, judgement and the final care decision.
A controlled pilot gives the hospital the best way to test the clinical workflow, operating model and governance controls before wider adoption.
Evaluation Framework
How Should Hospitals Evaluate Mediquery?
A focused pilot measures whether Mediquery solves the hospital's real record-retrieval problem. The hospital tests the same questions that clinicians currently answer through manual EHR navigation and document searches.
| 1 | Select one defined clinical use case. Choose a department and a set of questions that currently require time-consuming record searches. |
| 2 | Connect a controlled record set. Use approved patient records, documents and access permissions for the pilot group. |
| 3 | Measure the existing workflow. Record how long users take to find the information and supporting source without Mediquery. |
| 4 | Test the same patient-specific questions in Mediquery. Ask the same questions and confirm each answer against the original record. |
| 5 | Review answer quality and information gaps. Check whether the source supports the answer, whether Mediquery identifies missing reports and whether clinicians can verify the evidence quickly. |
| 6 | Expand only after approval. Add users, departments and sources after clinical, security and operational owners approve the workflow. |
This pilot turns the purchasing decision into a measurable assessment of record retrieval, source verification and user adoption.
Evidence
Case Study: Testing Mediquery Against the SyntheaDB Patient Dataset
Yobitel tested Mediquery's patient-record search and citation accuracy against SyntheaDB, a synthetic patient-record dataset spanning demographics, laboratory results, imaging and financial records. The test used the same manual-comparison method described in the pilot steps above: a defined set of clinical queries, a controlled record set and manual review of every answer against its source.
| Dataset name | SyntheaDB |
| Dataset description | Patient demographics, laboratory results, scan reports, vitals and imaging, treatments, and financial ledger records. |
| Number of records | 250,000 records |
| Document types tested | CSV data files, images, and PDFs (scan reports, prescriptions and doctor recommendations) |
| Number of questions tested | 100 clinical queries |
| How review time was measured | Manually, as the elapsed time between submitting a query and receiving the answer |
| How citation accuracy was measured | Manually; verified at 95% accuracy across the tested queries |
| Latest test date and Mediquery version | 10 July 2026, Mediquery version 1 |
Hospitals evaluating Mediquery can apply this same manual-comparison method to their own controlled pilot, using their own patient records and clinical questions rather than a synthetic dataset.
In Summary
Find Patient Information Faster with Mediquery
Hospitals already hold the information needed for many clinical questions. The challenge is making that information easy to find, understand and verify during patient review.
Mediquery gives doctors one patient-specific place to ask a question, review a concise answer and open the supporting source. It brings scanned reports, historical files and connected hospital data into the same workflow without forcing the hospital to replace its EHR, and it is available on AWS Marketplace so multi-branch hospital groups can deploy it once and roll it out to authorised doctors across every site.
Frequently Asked Questions About Mediquery
Does Mediquery replace the hospital EHR?
No. Mediquery works alongside existing hospital systems and adds a patient-specific search and review layer.
Can Mediquery search scanned medical reports?
Yes. Mediquery extracts readable text from scanned reports and document images, then includes it in patient-specific search. Extraction quality depends on how clear the source is.
Can hospitals upload historical patient records in bulk?
Yes. Mediquery processes batches of existing medical documents, so staff do not need to upload every file separately.
Does Mediquery show the source of an answer?
Yes. The clinician can open the report or record that supports the answer.
Can Mediquery work across hospital branches that use different EHRs?
Yes. Mediquery works as an additional review layer across authorised EHR sources and uploaded medical documents.
Is Mediquery available through AWS Marketplace?
Yes. Yobitel lists Mediquery as a deployable application on AWS Marketplace.
Does Mediquery work with Epic, Oracle Health, MEDITECH and other EHRs?
Yes. Mediquery is designed as an additional patient-review layer that sits alongside the hospital's existing EHRs. It connects to authorised sources across different EHR brands and includes their information in one patient-specific search, without replacing any EHR the hospital already runs.
How is Mediquery deployed for multi-branch hospital groups?
Mediquery is deployed centrally on AWS Marketplace and made available to authorised doctors across every branch through one web-based workflow. There is no per-site installation.
Who can see patient information in Mediquery?
Only authorised users the hospital assigns. Access is controlled by role, so administrators manage the workspace, authorised staff maintain patient records and documents, clinicians review patient information for care, and read-only users see approved records without changing them.
References
- Yobitel Communications - Mediquery product page: https://yobitel.com/products/ai-applications/mediquery. Accessed 8 July 2026.
- AWS Marketplace - Mediquery AI: Intelligent Healthcare Agentic AI Application: https://aws.amazon.com/marketplace/pp/prodview-ssv463hpeixl2. Accessed 8 July 2026.
- Epic - Art for Clinicians: https://www.epic.com/software/art/. Accessed 8 July 2026.
- Oracle Health - Clinical AI Agent: https://www.oracle.com/health/clinical-suite/clinical-ai-agent/. Accessed 8 July 2026.
- MEDITECH - Expanse for Physicians and Ask Expanse: https://ehr.meditech.com/ehr-solutions/expanse-for-physicians. Accessed 8 July 2026.
- InterSystems - HealthShare Unified Care Record: https://www.intersystems.com/products/healthshare/unified-care-record/. Accessed 8 July 2026.
- Holmes JH, Beinlich J, Boland MR, et al. Why is the Electronic Health Record so Challenging for Research and Clinical Care? Methods Inf Med. 2021;60(1-02):32-48. doi:10.1055/s-0041-1731784.
- Nijor S, Rallis G, Lad N, Gokcen E. Patient Safety Issues From Information Overload in Electronic Medical Records. J Patient Saf. 2022;18(6):e999-e1003. doi:10.1097/PTS.0000000000001002.