Appearance
Patient chart review and record transfers
Epic is the workflow case study; this work does not select an Epic organization as the receiving integration.
Initial browser review: 25 September 2026. Waitlist work was removed from this scope at the user’s request. Follow-up implementation and verification are recorded in FAC-REC-01. The observations below describe the original audit, before those fixes.
What was actually watched
Used Chromium against facility-web on localhost:3200 and the real tenant server on localhost:8788, with the existing synthetic demo data. No mock API, clinical note edits, external record deliveries or patient messages were used. The running demo was reset/restarted during the review: sessions became invalid and the newly registered privacy request disappeared. Evidence below identifies what was observed before that reset; this was not a controlled fresh-seed regression run or a Firefox pass.
Find an existing patient's medical records
As Dr. Ngozi Okafor (Provider):
- Open Patients → Patient directory.
- Search by name, patient number or phone; verify identity and select the patient.
- The profile shows longitudinal vitals, lab results and Attached chart documents & media. Fatima Bello's profile showed a previous clinic card and another attached PDF.
- Select Open chart, then select the relevant visit from Visits. Opening a closed visit did not require check-in, re-registration or a new encounter.
- Use Note, Prescriptions, Labs, Records & media, etc. to review the appropriate information. The profile attachment list was seen; the later chart attachment check was interrupted by the demo reset.
High-priority failure: Selecting Fatima's closed Routine follow-up visit and then Note showed an empty editable composer and enabled Save draft, even though the browser's normal notes request returned HTTP 200 with a SIGNED SOAP note and its author/signature details. The note had noteType: "provider"; the chart and its history card select provider_note. The signed record existed but was invisible in this view. No save was attempted.
Source: verabase-client/apps/facility-web/app/(app)/chart/[patientId]/page.tsx (providerNote, NoteHistoryCard, note composer); verabase-client/scripts/seed-demo-environment.mjs currently creates historical notes with noteType: "provider".
The closed-visit issue also needs an explicit policy independent of that alias bug. The note composer gates editing on note signature, not encounter closure. The note-save repository checks encounter identity/facility, but does not select/check the encounter status in that path. Signed-note versioning and addendum infrastructure already exist and should be preserved. A successful save into a closed encounter was not tested.
Evidence: output/playwright/patient-records-review/closed-visit-note.png, closed-visit-editable.png (both visually inspected). The latter shows the Closed badge, selected visit and enabled Save draft together.
Closed visits and Epic
Recommendation for VERA: historical encounters open in a clearly labelled Closed visit — read-only review mode. Show saved notes, diagnoses, orders/results and provenance. Do not automatically open a new-note composer. Offer a deliberate, permission-controlled Add addendum / late entry workflow that preserves the original and records author, actual entry time, relevant service time and reason. Today's treatment starts in a new encounter. If reopening is supported, make it a separate permissioned, audited operation.
Encounter closure and note signature are distinct states; a closed visit may still have an outstanding documentation task. A result arriving later should remain linked to the original order and available for acknowledgement without silently reopening the visit. Longitudinal patient updates must not be confused with edits to a historical encounter.
Epic's deployed workflows vary by institution. UI Health Care documents Chart Review and adding an addendum after signing a note. Epic's own export specification records encounter-addendum author, timing and open/signed state. These support an explicit amendment workflow, not an unrestricted historical editor:
Portability and compatibility
There are three different outcomes: a patient receiving a readable copy, another clinician reviewing a packet, and another EHR importing structured data. A PDF or JSON download does not establish that the destination EHR can ingest it.
| Existing capability | Current limits / verification |
|---|---|
| Administration → Data-subject rights → Portability → Register request → Download controlled export | Administrator request creation was watched. The first download attempt was interrupted by invalidated sessions during the demo reset; do not count that timeout as an export defect. Source constructs proprietary JSON. |
| Controlled JSON contents | Demographics, identifiers, encounters, admissions, clinical notes, problems and document metadata. No original attachment bytes, allergies, medications, vitals or laboratory/imaging results in this response. Notes are mapped without author/signing-user fields or separately stored addenda. |
| Export completeness | Export calls request 500 rows for several lists, but encounter retrieval uses clampLimit, capped at 200, and export does not iterate further. Large-record completeness is a source-confirmed gap, not a browser-tested large-data case. |
| Export authorization workflow | Role-gated and audited. Export implementation checks request type but not review status; identity/scope are free text, not enforced structured release checks. No recipient, preview/selection or delivered/received confirmation in this screen. |
| FHIR R4 | Source exposes Patient search/read and $everything containing Patient, Encounter, vital-sign Observation, Condition and MedicationRequest. It omits notes, allergies, diagnostic reports, attachments and other record types. No end-to-end destination-EHR exchange was tested. The capability statement advertises individual reads for non-Patient resources, but corresponding direct read handlers were not found in the inspected FHIR route block. |
| HL7 v2 | Source has bounded outbound ADT/ORM and inbound ADT/ORM, plus laboratory import elsewhere. These are partial integration components; they do not prove delivery/reconciliation with another EHR. |
| Readable documents | Chart summary and referral print/PDF controls exist in source; profile attachments were visible. Full-chart PDF/ZIP export was not verified. |
| Patient self-service | The web portal item-action renderer sets a placeholder message on click. A self-service full-record download/share journey was not verified. |
HL7 describes Patient $everything as patient-record access including supporting resources and attachments; the current narrow bundle should not be represented as the complete record. HL7 R4 Patient $everything.
For compatibility with another EHR, choose the receiving organization's supported interface and validate against it. As a case study, Epic documents FHIR APIs and separate document-exchange mechanisms including CDA/C-CDA, Direct, XCA/XDS and patient discovery. Implementing one generic FHIR bundle does not provide all of those capabilities. Epic FHIR interfaces, Epic EHR-to-EHR exchange.
Recommended work order
- Restore visibility of historical/legacy signed notes and add read-only closed-visit review, retaining explicit addenda and controlled late documentation. Verify as the clinician, including permission and server-side refusal cases.
- Build a patient-record release workflow: patient/representative request and authorization, recipient, date range/categories, preview, readable PDF plus original files, structured export with provenance/addenda, and an audit trail.
- Add secure delivery and recipient confirmation, then implement and validate a named external EHR integration, including patient matching, incoming-record review, duplicate handling and reconciliation. File download, delivery and successful import are separate milestones.
This review records findings and recommendations; it does not claim product fixes or a verified external medical-record transfer.