Deployment
What adopting eMRCare actually involves
Where the system runs, what your facility supplies, how the rollout is sequenced, and what your staff are trained on — written for the municipal health officer or administrator who has to sign for it and then live with it.
Where it runs
On your server, or one we host — and it keeps working when the line drops
Primary care does not stop because the connection does. The system is built so that a clinic day can be recorded whether or not the facility is online at that moment.
On the facility's own server
The system sits on a machine inside the health unit or the municipal hall, and staff reach it over the facility's own network. Records stay on the premises.
On a hosted server
For facilities that would rather not keep and maintain hardware, the same system runs on a server operated for them. Nothing changes about how staff use it, and a facility can move between the two arrangements later.
Through an outage
Consultations, dispensing and results continue to be recorded while the line is down. When the connection returns, the record catches up on its own. Nobody re-encodes a day's work from paper the next morning.
Several facilities, one deployment
Shared where it helps, separated where it must be
A municipality running a main health unit and several barangay health stations — or a provincial office covering many units — can put all of them on one deployment, leaving one set of hardware and one configuration to look after.
What is not shared is the patients. Each facility sees only its own registry, queue, stock and claims. Staff of one facility cannot open another facility's records, and that separation is enforced by the system itself rather than left to policy and good manners. Every access and every change is written to an audit log, so there is a durable trace of who opened a record and when.
What you supply
Four inputs, and they come from the facility
None of these are things a vendor can invent for you. Gathering them early is what keeps go-live calm.
| What is needed | Why the system needs it | Usually held by |
|---|---|---|
| PhilHealth accreditation details | Accreditation identifiers and facility type drive claim assembly and validation, and set what the Konsulta registers expect to see. | Facility head or PhilHealth focal person |
| Staff list and roles | Every user is given one of the ten roles, which decides the dashboard they land on and the pages they are permitted to open at all. | Facility administrator or municipal HR |
| Formulary and price list | The medicines actually stocked, with batches and expiry dates, plus the prices used for billing — these drive dispensing, stock alerts and claim lines. | Pharmacist or supply officer |
| The residents you serve | Existing patient records, household lists or the LGU's own resident register, so the registry starts populated rather than empty on day one. | Health office, barangay health workers, LGU registry |
Rollout
Five phases, in this order
Scoping and data preparation
We walk an actual clinic day with your staff, agree which facilities are in scope, and work through the four inputs above — cleaning the staff list, reconciling the formulary against what is really on the shelf, and deciding how existing records come across.
Install and configuration
The server is prepared, on your premises or hosted. Facilities, accreditation details, users and roles are entered; the formulary, price list and diagnostic panels are loaded; and the capitation rate and its circular are recorded.
Staff training, by role
Short sessions per role rather than one long session for everybody, run on your own configured system with your own staff list and formulary in it.
Supervised go-live
The clinic sees real patients on the system with our people present. We usually begin with one service or one clinic day rather than switching everything at once, and paper is kept alongside for an agreed settling period.
Handover and continuing support
Your administrators are trained to add users, adjust the formulary, correct records and read the registers without calling anyone. Support then continues under whatever arrangement has been agreed.
Training
Each role has its own dashboard, so each role has its own session
A user only ever sees the pages their role permits, and lands on a dashboard showing only that role's work. That makes training shorter and less intimidating: nobody sits through screens they will never open. Administrators are trained twice — before go-live, and again afterwards on what only matters once the system is genuinely busy.
| Role | What their session covers |
|---|---|
| Facility administrator | Users and roles, facility details, the registers, and reading the audit log |
| Physician | Consultation, prescribing, allergy and interaction warnings, and recording a reason when overriding a serious one |
| Nurse | Vitals, the queue, encounter notes and referrals |
| Midwife | Empanelment and the First Patient Encounter screening form |
| Encoder | Registration, consent capture and revocation, and corrections |
| Pharmacist | Stock by batch and expiry, dispensing, low-stock and expiry alerts |
| Laboratory technologist | The structured Konsulta diagnostic panels, plus free-text orders for everything else |
| Radiologic technologist | Imaging orders and reporting |
| Receptionist | Front desk, the queue, and scannable health cards |
| Barangay health worker | Field empanelment on a mobile device and household surveys |
Next
Start with a scoping conversation
The useful first step is a walkthrough against your own facility — your accreditation, your staff list, your caseload — rather than a generic demonstration. From there the phases above can be put on a calendar and costed properly.
If you would rather read first, the pages below cover what the system does and the reporting obligations it is built around.
Request a walkthrough · See what the system covers · Compliance and reporting obligations · Linking to a hospital