Electronic Health Records, Clinical Visits and Practice Billing

A practice management platform with a shared encounter workflow for staff and integrations.

A patient encounter ties together the work around one visit. Staff book the visit, write up the care, then send the bill for the services on record. This electronic health records case study covers a platform that runs all of that through one encounter service. A visit opened through the API then follows the same rules staff use inside the practice.

The challenge

A form can change from one workflow to the next. The visit it attaches to stays fixed. A note, a questionnaire or a fee sheet still has to belong to the right encounter, whichever screen made it. The system also keeps a patient's own request separate from a staff action, since the two do not share the same access.

What we built

The platform brings patient demographics, insurance details and scheduling together with the clinical notes. Forms capture vitals and notes, with allergies and medications linked to the encounter. Where the laboratory and prescribing modules are in use, they tie orders and results back to the same record.

Billing starts from the encounter's fee sheet, then moves through claim creation and remittance posting with supported US billing formats. A patient portal opens up selected records and booking functions.

Technical approach

The staff interface checks whether the action is allowed, then hands the request to the encounter service. That service validates it, gives it an encounter number and registers a UUID. A FHIR request becomes the same internal operation. Integrations work with the UUID, and the numeric keys stay inside the application.

Each form keeps its own fields in its own tables. A shared index links them to the encounter. Saving a form updates that index, and the lookup for an active encounter checks the deletion state as well as the UUID. A removed encounter does not come back just because an underlying row still exists.

Patient-context tokens are tied to the patient's UUID. Staff actions need the matching permissions. API requests go through site selection and authorization before they reach any domain service.

Several practices can share one copy of the application code. Each one reads its own database settings from the request or the session. Access controls and audit records support daily administration. Clinical deployment review and security setup are still needed before a practice goes live. These controls alone do not make it compliant.

Project success

A visit can carry its clinical forms and its billing through one shared encounter record. Different form types feed that record without changing how it gets built. Integrations get a stable reference to it, and each practice keeps its patient records in a separate database.

Technology stack

Backend

PHP, Doctrine, Laminas MVC, Symfony HTTP components

Database

MariaDB

Templates and interface

Twig, Smarty, AngularJS, jQuery, Bootstrap

Health-data exchange

FHIR, HL7, CCDA, SMART launch

Billing formats

X12, CMS-1500